Rant-of-the-day: on the dangers of orphaned software (the dark side of open source)
Earlier today, one of our readers (who asked not to be identified) alerted us that a number of Linux and BSD distros were releasing new versions of gzip which address several new vulnerabilities (CVE-2006-4334 through 4338). A quick look at the Mitre site shows those vulnerabilities as still 'under review' so there are no details as to what underlying problems are being fixed. I decided to take a look at the "official" site for gzip to see if there was any info there. I first went to www.gnu.org and found info on gzip. They said the "official" site was www.gzip.org, so I went over there for a look. That is when I became very discouraged. The last official version of gzip listed on that site is 1.2.4 (dated Aug 1993, well 1.2.4a is on the FTP server dated Feb 1999) and the latest "beta" listed is 1.3.3, but all of the Linux distros, FreeBSD, even Sunfreeware are on 1.3.5 (I finally found the 1.3.5 source on the alpha.gnu.org FTP server, dated Sep 2002). Looking at the bottom of the page, I see that the page itself hasn't been updated in over 3 years. Is there someplace that one can find the current definitive source for gzip? I don't know. I found a Windows version on Sourceforge. I know there have been vulnerabilities in both gzip and zlib over the last 3 or 4 years and I know that most vendors have patched them, but if there is no authoritative owner for the software, are the vendors patching the same way? Do all the patches actually work? How have the various vendor versions diverged over the last 3+ years? This is the downside of open source software. What happens to it when the original maintainers tire of it, move on to other things, get hit by the proverbial bus,...? I admit that I have not yet tried contacting support@gzip.org or the original authors of this excellent tool to find out if they have passed maintenance on to anyone else. I am reasonably certain that the various vendor versions could be reconciled and an official version could be produced again, but who should/would take ownership of it?
Anyway, from what I can tell from the FreeBSD and Ubuntu bulletins, these issues can result in gzip (or, I believe more accurately, gunzip/gzip -d) crashing, causing high CPU utilization, and possible code execution from a properly crafted .gz file, so you'll probably want to update your gzip as soon as your favorite distro provides the update.
Update: (2006-09-19 20:52 UTC) These vulnerabilities collectively now have Bugtraq ID 20101 and the RedHat notice gives a little more hint at what the various CVE's are about.
----------------------------
Jim Clausing, jclausing /at\ isc dot sans dot org
Anyway, from what I can tell from the FreeBSD and Ubuntu bulletins, these issues can result in gzip (or, I believe more accurately, gunzip/gzip -d) crashing, causing high CPU utilization, and possible code execution from a properly crafted .gz file, so you'll probably want to update your gzip as soon as your favorite distro provides the update.
Update: (2006-09-19 20:52 UTC) These vulnerabilities collectively now have Bugtraq ID 20101 and the RedHat notice gives a little more hint at what the various CVE's are about.
----------------------------
Jim Clausing, jclausing /at\ isc dot sans dot org
Keywords:
0 comment(s)
My next class:
Reverse-Engineering Malware: Malware Analysis Tools and Techniques | Coral Gables | Nov 18th - Nov 23rd 2024 |
×
Diary Archives
Comments