A serious security flaw has been identified in Zlib, a widely used data compression library. Fixes have begun to appear, but a large number of programs could be affected.
Post a Comment
Member since:
---
Member since:2005-06-29
Member since:---
Look again. The update is available:
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/zlib-1.2.2-5....
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/zlib-devel-1....
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/zlib-1.2.2-5....
ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/zlib-devel-1....
Check your settings and verify that you are using a valid mirror.
Member since:
---
Member since:
---
not to troll...
since we have discussed before the pros/cons of ways to handle packages with some distros rolling everything into one package, i think gobo linux and pc-bsd or something....
And as was mentioned before instead of one hole in your operating system you would have numerous occurances. Here is one shining example...is it not?
Member since:2005-07-06
most likely your refering to pc-bsd as gobolinux still have the libs seperated from the apps. ie, update ones and you get them all. as long as the update dont break one of them.
still, if that happens you can keep the lib around for those few and as they are updated they will no longer use the old one. so eventualy you can remove it.
Member since:
2005-07-02
I actually learned about the vulnerability when I saw that there was a updated zlib package for Ubuntu.
I have to say I'm quite pleased with the speed of updates on this distro.
To the anonymous troll: do you view security flaws in Windows as a failure of the closed-source software model?
Member since:
2005-06-29
Member since:
2005-06-29
Member since:
2005-07-06
Member since:---
Member since:
---
Member since:
2005-06-29
Member since:2005-07-06
Huh, where are you getting this info? I just searched through Mandriva and Suse security advisories, and there are only 2 zlib security advisories within the last 2+ (almost 3) years...
I really don't think this is that big of a deal. Pretty much all major Linux distributions had a fix within 24-48 hours after the discovery. And it certainly is painless to update this. As they explain in the article, pretty much everything uses this as a shared library. One update to fix most of the affected software.
Member since:
---
first - i make a montion to ban (IP: 66.98.198.---)
second - software is written by humans, therefore fallible.... security comes into question when something is discovered and not fixed, shall we bet who has it fixed first. And should we bet who will KNOW they have it fixed the open source systems that have to update one library or the closed-source systems that have it rolled into a bunch of different programs? Do they know what all programs have it, what about third party closed-source programs that use it? How will M$ update some program you downloaded from the web that happens to use the library...they WONT!
open source has reqponded to the threat and due to better design it will be a simple fix, M$ on the other hand....go figure...
can I second the motion as well... 
Member since:2005-07-07
I agree, that software is fallible. But software can be a lot better if the programmers focus on quality. Both open and closed software has its share of ignorant/lazy coders and quality can be good or bad for both open and closed software.
Libraries used in so much software ought to be better. And the lack of quality control is as much a responsibility of the programmers that use the library as the programmers that make the library.
Regarding fixes: The really important aspect is how easy it is for the user to fix the problem. And for some distros this is easyer than for Windows, and for some it is not. But this is somthing open source is getting much better at IMO.
Member since:2005-07-06
What do you mean a lack of quality control? If there was a total lack, this hole wouldn't even be known and yet here it is announced having been fixed!
I don't understand how so many people can jump all over developers every time a *fix* to a venerability is released. Where does the unreasonable expectation that all software be released in a perfect state come from?
No products are ever perfect when they are released and many classes of products can take generations to get right. Using the classic car example, consider how much safer and longer-lasting automobiles have become over the years as they refine their processes? Does anyone seriously think that the first Model-T should have rolled off the line looking and feeling like a modern-day compact that can do 200,000 miles in its lifetime and is outfitted with airbags, anti-lock breaks, crumple zones, and an alarm system? That's just plain unreasonable.
Any new piece of software that does something different is somewhat akin to a new line of car. Every new software author is similar to a new and upcoming auto manufacturer. Each product (car, software, candy, etc) always has its own shares of quirks which can take a long time to iron out and each time a new manufacturer or developer enters the scene, they have a lot of things to learn about getting up to speed with what they are doing, what the common practices are, and how to generally do business.
There will be mistakes. Some developers are still learning the tricks of the trade and some software is maturing and settling in to its niche where finally the quirks are becoming understood. Don't ever let anyone fool you into thinking that the "professional" software developers are somehow more prepared than the amateurs in this regard - after all, it seems the only thing that separates a professional from an amateur is wether or not they get paid for it. Most highly active open source authors are professional programmers or system administrators during the day. When they go home and release something they've created on their own time they suddenly become listed as an amateur and when there's a bug it is clearly the fault of inexperience and/or ineptitude? That makes no sense.
Member since:
---
RE: re (IP: 66.98.198.---)
Member since:
2005-07-07
Member since:---
Anybody hear when the source code is released?
Here's the patch from Gentoo Linux's CVS repository:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-libs/zlib/...
Member since:
2005-06-29
Hadn't read this story, but I noticed it was fixed on my Ubuntu desktop machine and Debian server when I checked for updates a couple of hours ago. Certainly fast work, a good example of how free software folks can get their act together when it's something this critical. Still got a FreeBSD machine to do tomorrow when I get around to it, but the advisory is already on their website as well.
Now I just need to wait for Apple, who will hopefully have an update available tomorrow morning.
Member since:
---
Member since:2005-07-07
I don't know if the ZLib team posted a patch, but you can use the patch [1] included in the Debian source package [2] which fixes this security issue. It seems that the only file concerned is inftrees.c. This is the patch I used to fix zlib-1.2.2 on Slackware Linux 10.1.
[1] http://www.debian.org/security/2005/dsa-740
[2] http://linuce.free.fr/zlib-1.2.2-inftrees.c.diff
Member since:
---
Hmmmm... The update found by an OSS team auditing the source code. They make a fix in a couple of minutes, then pass it on to the original author, who double checks everything and in less than a day they've got a verified patch that's picked up by major distributors and disseminated. Since only the library needs to be replaced, it's a small fix.
Meanwhile, MS is "looking into it". Since zlib is statically linked into many of their executables, I suspect the "looking" involves decising whether or not it's worth the hassle of fixing now or waiting to see if they can roll it into the next service pack.
RE[2]: re (IP: 66.98.198.---)
RE[2]: re (IP: 66.98.198.---)
Member since:
2005-07-06
Ok, this is getting rediculous. Zlib has a flaw and it gets patched. One small little program. This is a 3rd party library that linux distros include. It's not created from the linux kernel hackers or distro makers themselves. So how does the speed this is being patched compare to Microsoft releasing patches for a whole operating system instead of one small program? It doesn't at all. You are comparing a 3rd party to the vendor. Apples and oranges.
Member since:2005-07-05
It is relevant because Microsoft uses Zlib too.
The Linux, BSD, etc. guys are already patched (or at least have a patch available), but Microsoft can't do that so they are "looking into it". This means that your Windows box(es) are still vulnerable to the flaw while the OSS systems out there are not.
That's why the comparison is far from "rediculous"
Member since:
---
> So how does the speed this is being patched compare
> to Microsoft releasing patches for a whole
> operating system instead of one small program?
a) statically linking is lame unless it's in a kernel or rescue app, mmmmk?
b) if it affects MS products, a patch should come fast
c) most every other vendor using zlib has responded
d) microsoft keeps shouting "WE ARE MORE SECURE" from rooftop
For reference, I run Gentoo Linux.
scylla# ls -l /lib/libz*2
-rwxr-xr-x 1 root root 69768 Jul 6 11:12 /lib/libz.so.1.2.2
That's right, the date says yesterday @ 11:12am.
Every second that there isn't patching for MS' products is another strike against them.
Member since:
---
Member since:
---
What is being lost in all the comparisons with MS is that this vulnerability was discovered by Tavis Ormandy of the Gentoo Linux Security Audit Team. For those who don't understand: He was performing a security audit of the code - something that very few vendors do of their own stuff, even when they charge an arm and a leg for their crapware.
Member since:2005-06-29
"For those who don't understand: He was performing a security audit of the code - something that very few vendors do of their own stuff, even when they charge an arm and a leg for their crapware."
What so many people don't realize is that programming isn't as simple as the "baking a cake" analogy they are often presented with, that is by far an over simplification. Programming is more comparable to advanced math in my opinion, you need to do research, problem solve, design the program, write it, test it to see if it works, and finally fix any bugs you find. If you do happen to find a bug, you have to filter through all the code to find out where its happening, then you have to figure out why its happening and finally you have to figure out how to make it work. It can take an eternity to make sure code doesn't have bugs, and developers can't make money if they don't release their software eventually.
Programming languages aren't pseudocode, a lot of people think of writing a program in terms of the way a human mind would work: people can read instructions off a piece of paper and follow them despite grammar errors, mispelled words, incorrect words, and of course people can compensate for errors in the instructions. Programming isn't like that, you don't get to think in terms of how things work in your brain any more, you have to think in terms of what the compiler can translate instead, and even when something compiles that only means the compiler hasn't found any of the common errors in the code that is was programmed to recognize, not in the way the program would work. Trust me, writing a program isn't as simple as what you've seen on TV or in person, you can't get a grasp of what's going on inside the developer's head when you're only watching them work, just because a developer knows what to type doesn't mean its always easy.
Of course you know by now that I am going by the assumption that you haven't any prior experience with programming, please don't be insulted if this isn't the case as the assumption was simply so I wouldn't write anything too complicated if my assumption turned out to be correct.
My point is basically that people don't know or appreciate how complicated programming can get. I get really irritated when people believe what they see in movies, where some "hollywood hacker" sits at a computer, glances at someone's code for a minute or two, and then points out and fixes all the bugs in it. Why does it irritate me? The simple answer is because so many people believe that its really that easy. Writing software isn't really so easy that any Joe Sixpack off the street can learn it in 24 hours, or in 7 days; learning how to program is actually gradual, and with languages like C++ it will usually take at least two years to get a good grasp of the language. Finding bugs gets even harder than writing the program, and that's because most bugs aren't obvious, may never be found for years, and are usually discovered by accident because they didn't show up in tests. Please keep that in mind before you assume that because software has bugs in it, the developer didn't audit it enough.
Member since:
---
Member since:2005-07-07
Member since:2005-07-07
Member since:
2005-07-06
Member since:
2005-07-06
I work primarily as a closed-sourced developer, and I can attest, after seeing MANY thousands of lines closed-source code, that open source code is normally of a much higher quality. It is simply amazing to me the number of $1,000,000 projects that consist of code with no real coding standards - poor indentation, poorly-named variables, etc. When I look at the code to open-source programs I have to compile, I see none of this.
Member since:2005-07-06
Member since:2005-07-07
> Open/closed source is a LICENSE, not a methodology for the style to write code.
You are right. However when you write open source code, you know by definition that you potentially expose it to public developers, among whom there are competent people. Sometimes they are even more competent than you, so you tend to write it as clean as you can. Obviously, it does not mean your code is not error-prone. By the way, "as clean as you can" is quite subjective and does not always mean "clean"
Member since:
2005-07-04
I believe you should implement a new feature in OSNews 3.1.
There should be a ban person button under each comment. People using anonymizer.com or not logged in should not be able to use this. It should only allow one click per IP address per post. If more than 30 people click to ban someone from the site in a certain time period, their ip address should be completely blocked access. I don't think we should have to wade through some of the posts being put on this forum, espescially people who are subscribers (I'll admit I'm not, and never will be until this problem is fixed).
Even if people don't end up getting banned, it will keep them in-line.
Member since:
---
If you load up a new WinXP install and go to Windows Update and load all the updates, count how many of them involve resolving problems which otherwise could have lead to a remote system compromise. <tin foil hat conspiracy time> There's tons of them. I wonder if they're really bugs at all or just publically discovered backdoors.</tin foil hat>
Thank god modern Linux distros don't suffer from all these remote compromise holes.
RE[2]: Remote takeover exploits with Windows
Member since:
---
Member since:
2005-07-08
CAN-2005-2096
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096
DSA-740
http://www.debian.org/security/2005/dsa-740
FreeBSD-SA-05:16
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:16...
GLSA-200507-05
http://www.gentoo.org/security/en/glsa/glsa-200507-05.xml
RHSA-2005:569
http://rhn.redhat.com/errata/RHSA-2005-569.html
SUSE-SA:2005:039
http://www.novell.com/linux/security/advisories/2005_39_zlib.html
USN-148-1
http://www.ubuntulinux.org/support/documentation/usn/usn-148-1
Please, somebody provides reference to Microsoft's security advisories.
Member since:
2005-07-06
I think there is a difference between bugs and vulnerabilities...
Bugs are those problems of a software that affect users, either something is malfunctioning or displaying unexpected behaviour, during the software's expected usage.
Vulnerabilities are usually those potential holes of a software where malicious people can write speicific code attacking such holes to achieve their specific purpose.
Compared to bugs that can be prevented or removed through extensive testing from programmers and users, vulnerabilities are usually more difficult to be detected. This is not only because the fact that most programmers are not malicious people ;D , but also because people usually have a set of assumptions and don't usually foresee problems that may have if these assumptions have not been met.
It's like, bakers have to make sure the bread they bake is safe to eat, delicious and good-looking. But it's just difficult for them to foresee (or do anything) to stop malicious people from adding in poisons to the bread intentionally to kill someone.
If the world is so perfect, London's police and intelligence departments could have stopped Bin Laden's bombers before anything happens. As always, things can be improved, but even god is so powerful, there are still chances where devil comes in and mess things up. So, please do not blame the programmers (either Microsoft's or not) for not being as thoughtful as Bin Laden...
However, the zlib example demonstrates how bugs and vulnerabilities of commonly used shared libraries can pose widespread and serious risks... the world will need discussions on how better methodologies or procedures can be implemented to eliminate such risks if things do go wrong.
Member since:
2005-07-06
Member since:
2005-07-07
Obviously there is quality control. But maybe it should have taken place before release. A lot of programmers have used the library before sufficient quality control.
No products are ever perfect -- I agree on that. But a library which is designed to be used by many different applications should be of a better quality than the average software. The OpenBSD team have shown the way!
Not all programs need to be designed with security in mind. But many do.
I am not blaming the programmers who created the library. But if programmers use libraries without doing anything to assess the quality, they should be aware of the risks. So you have to either trust the team that made the library, check if anyone else have controlled the software, or check it yourself (or live with the uncertainty).
