What a Tangled Web of Code We Weave
Posted by jericho
While digging around the usual sources of vulnerability information tonight, I ran into this sequence of links trying to find where an underlying vulnerability really was:
- sux0r 1.6 was released to fix a vuln
- this was due to a vuln in MagpieRSS, which v 0.72 fixed
- the MagpieRSS issue was due to a vuln in Snoopy
At this point, the sux0r release was linked two steps back to Snoopy, via MagpieRSS. This leads me to stress the value of vendors including such details in their release notes and changelogs. It can save people a lot of time when trying to figure this stuff out. Also attached to the same original vulnerability:
Obviously, most people in the security industry who read Bugtraq or Full-Disclosure for their only source of vulnerability information didn’t see all of this. Unless they are as deranged an anal retentive as I am, or monitor several vulnerability databases, they may have missed the fact that several software packages had a fairly serious vulnerability. This is a good example of the value-add that some vulnerability databases offer due to their followup research and organization.
I also have to wonder if the authors of sux0r know that one of the packages they use, also uses other packages. This makes me wonder how many layers deep some of the software goes these days, and if the authors of these packages fully grasp the web of code and dependencies that are created. Imagine having a really accurate mapping of such relationships and integration, that would let us see just how far one vulnerability can spread into different codebases. A while back, I mentioned how this would be incredibly helpful to vulnerability databases in some cases. Imagine having this same type of system that linked software package integration and dependancies. When a given package is found to contain a vulnerability, you could instantly know that it likely affects seven other software distributions, all of which need to upgrade their dependancies or fix the issue themselves. I know, pipe dream but still a nice thought!
I doubt that most authors even consider the depth of linkage involved in their programs. In fact, I suspect that most coders think “Where can I find the function I want? I’ll just add that into my headers.”. Linux coders seem to be the most egregious offenders - running ldd on most binaries is distressing at best:
% ldd /opt/gnome/bin/ximian-connector-setup-2.4 | wc -l 98
is a classic example of depth of linking.
I agree that it would be interesting to have an accurate mapping of code dependancies - not just for vulnerabilities, but to be able to modify and upgrade software with some idea of the expected impact (I presume that most of the readers here have had the experience of modifying their revision of glibc…).