Posted by
michael
on from the sauce-for-the-gander dept.
SirTimbly writes: "CNET is reporting that there is a buffer overflow problem with zlib in linux, which is used for network compression. Supposedly, someone could remotely cause a buffer overflow through mozilla, X11 and many other programs." The advisory from Red Hat is available.
It's not a problem in zlib per se
by
Starship+Trooper
·
· Score: 5, Insightful
This bug causes zlib to free() a malloc'ed block of memory more than once. free() on most other OS's (including Windows, FreeBSD and OpenBSD) is smart enough to check for this and will print a warning instead of destroying the heap; glibc's malloc (and by extension, Linux's) does not and will gleefully make a mess out of the whole memory space. This can cause all sorts of buggery when the next malloc() occurs, including what amounts to a buffer overflow exploit.
So, you should download the patched zlib, but you should also email the glibc maintainers and demand that they implement a sane, error-checking malloc()/free() system. Linux's current allocation model is a disaster waiting to happen.
-- Loneliness is a power that we possess to give or take away forever
Re:It's not a problem in zlib per se
by
Anonymous Coward
·
· Score: 4, Insightful
so what you are saying is that slashdot has been wrong in the past to criticise microsoft for seeking performance ahead of robustness. glad we've cleared things up.
mjl
Not a surprise...
by
Joseph+Vigneau
·
· Score: 2, Insightful
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
Yes; perhaps this is due to the fact that FS/OSS is used by more developers/users. More eyeballs and more code to exercise libraries mean more bugs are discovered. As mentioned, this bug is (relatively) benign, and has already been fixed in the source. So I wouldn't necessarily say that FS/OSS is getting "more buggy", any more than commercial software, whose bugs don't leave the company if users don't discover them first.
Re:Dumb security question
by
jilles
·
· Score: 3, Insightful
The whole issue is not to use insecure languages like C. Such languages allow all sorts of memory manipulation and typically depends on the programmer to secure. The situation is made worse by the lack of something pretty essential: good libraries for string manipulation. While 3rd party libraries are available you can't assume these to be present so many developers still use char*.
Code reviews help, testing helps, good programming helps. But neither of these practices has succeeded in eliminating this type of bugs. It is just not good enough, witness a zillion bugs and security breaches on all major OSes (including the ones deemed secure, and yes I am talking about BSD) throughout the last decade. These OSes only differ in how the issues are dealt with. The occurance of the issue is a fact of life for all of them.
There's no C developer that can claim his program is completely free of buffer overflows (many foolishly do however). There may be some undetected errors in the program, the progrm may depend on third party code that contains bugs (e.g. the compiler or one of the standard libraries). Most likely bugs in all three categories are present.
Automatic checks are indeed the solution to the problem and modern languages build these checks into the run-time environment, where they belong. Buffer overflows are a non-issue in Java, for instance. The exception of this is native code and the JVM itself (written in C).
To eliminate buffer overflows, getting rid of the C legacy is the only solution. Java is probably too controversial as an alternative right now (though arguably it is quite up to the task as far as server side development is concerned) but there are other alternatives. Rebuilding serverside services like ftp, dns, ssh, smtp, pop, etc. is mandatory since each of these services has widely used C implementations that are frequently plagued by buffer overflows. The only way to guarantee that there are none left is to reimplement them.
--
Jilles
Re:more info please
by
mestar
·
· Score: 2, Insightful
Except in all those statically linked versions in who knows how many programs.
If the strength of Linux is closing the barn doors after the horses have ran amok, I think I'll investigate BSD, where they, you know, actively audit the code.
-- Vintage computer games and RPG books available. Email me if you're interested.
Re:Meanwhile back at Microsoft
by
The+Bungi
·
· Score: 1, Insightful
It's amazing how you monkeys react to things like these. There's a bug in zlib, yeah. And your response is to say "Microsoft software has more bugs!" Do you really think you're doing anyone a favor by blabbering your pathetic "insight" for the word to see?
Just when I think I'll finally cease to be amazed at the mass of useless posts in this place someone like you proves me wrong.
Then there's still a problem in glibc malloc()
by
Starship+Trooper
·
· Score: 5, Insightful
*BSD's malloc manages to simultaneously provide high performance while also providing robust (and highly configurable) error checking. glibc's MALLOC_CHECK_ variable does far too much and isn't nearly as fine-grained as BSD's options. Read the "TUNING" section of FreeBSD's malloc(3) manpage. It puts Linux to shame as far as clarity, usefulness, and convenience goes. You only turn on the error checks you need, instead of a few general and poorly-implemented checks in glibc's malloc.
Why Linux can't follow in the supposedly-inferior BSD's footsteps is beyond me.
-- Loneliness is a power that we possess to give or take away forever
Re:That's better
by
cpeterso
·
· Score: 3, Insightful
If they ripped them off as you say they would not be able to licence them as GPL now could they?
sure they could. The BSD license lets anyone do whatever they want, including relicense the code as GPL. There is already BSD code in the Linux kernel.
Re:That's better
by
Geekboy(Wizard)
·
· Score: 2, Insightful
The TCP stack for almost all OS's was {stolen|borrowed|based on} the TCP stack in BSD 4.x (IIRC). I remember once, a few years ago, a system engineer did a special sequence on a Windows 98 computer, and got the BSD copyright to show up.
VM in Linux is a mess. 2 (very) different VM systems, that cause quite a few utilities to be re-writtian. All of the BSD's have one each, and they optimize their VM quite well. FreeBSD has a very robust one, that is a bit slower than Linux's, but seems to be more stable.
OpenBSD just got statefull firewall with the latest version (3.0) Prior to that, they were using Darren Reed's IPF, but due to a licensing fiasco (and petty name calling), IPF was yanked, and PF was created. I use PF in my firewall at home, and I am quite happy. I can't wait until 3.1 (not willing to run -current) to see how much more robust it can get. =)
Remote upgrades : be careful
by
chrysalis
·
· Score: 3, Insightful
If you have to remotely upgrade the zlib library, be *very careful*.
Because SSH/OpenSSH depend on zlib, if you replace your current libz.so file with another version whoose API has a bit changed, your SSH server won't work any more.
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
If SSH doesn't work any more after the zlib upgrade, recompile SSH.
-- {{.sig}}
Pointer aliasing...
by
Tom7
·
· Score: 3, Insightful
I dunno, most double frees come from freeing DIFFERENT copies of a pointer. Setting one to NULL won't help in this case...
(A much better solution is to use a garbage collector.;))
Re:zlib rarely used in MacOS. MacOS safe.
by
Account+10
·
· Score: 2, Insightful
Wrong...
free(p);
free(p);
what happens if there is a thread switch between the two calls to free? Another thread can call malloc and receive the same value 'p' back.
When we switch back to this thread, it will free memory another thread still thinks it owns.
Calling free() twice on the same pointer is never safe.
double free almost impossible to exploit.
by
Anonymous Coward
·
· Score: 1, Insightful
On a single threaded app, a double free is completely harmless with the majority of malloc libraries. This means single-threaded apps such as Apache 1.x is safe. So only a multithreaded app (such as Apache 2.x) could be exploited. But even still, you'd have to know:
- the version of malloc they are using - the heap memory usage pattern of the program
In a multithreaded app, the memory usage is not very deterministic. I don't think anyone will lose any sleep over this.
XFree86 4.2.0??
by
gweihir
·
· Score: 3, Insightful
The latest XFree comes with a copy of zlib 1.0.8.
Does anybody know where this is used and whether I should do a rebuild with the current 1.1.4 version?
In addition to gs, this seems to be the only software package that contains zlib in it. I found it because there is a/usr/X11R6/lib/libz.a on my Linux system.
-- Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
I worked for a company that had a large C program that served requests - for sake of argument, lets call them web page requests. The program leaked so much memory that it had be to killed periodically in order to avoid running into swap space (every few hundred requests or so).
That is a primative form of garbage collection - wait until the garbage has piled up, and then throw it out all at once (sort of like how I implement garbage 'collection' at home actually).
Now, having to start up a complex program takes time, so there was an incentive to increase the life span. Different garbage collectors were tested, commercial, free, and one was chosen and implemented. There was great rejoycing all around from the everything-should-be-garbage-collected people.
Well, the garbage collector was soon completely overrun with garbage, because it is easy to create but takes time to collect. The process would periodically sit and do nothing but collect garbage for tens of seconds as it waded through the 500MB or more of garbage that had been produced since last time. So, the first version won and the garbage collector was removed from the code.
The program went back to being shot in the head every hundred requests or so, and there was great rejoycing from the we-don't-need-no-complex-system-sweeping-through-o ur-data people.
In summary:
1. killing a process every so often is a form of garbage collection. 2. Windows dies periodically, so it is using a form of garbage collection. 3. Windows is not secure, refuting your assertion that all garbage collected code is safe.
a bug in ZLIB???
by
timecop
·
· Score: 0, Insightful
What the hell is wrong with you people? And you complain when there is a bug found in command.com?
Slashdot Mirror
So, you should download the patched zlib, but you should also email the glibc maintainers and demand that they implement a sane, error-checking malloc()/free() system. Linux's current allocation model is a disaster waiting to happen.
Loneliness is a power that we possess to give or take away forever
Is it just me, or have there been a really huge amount of security issues with Free/Open Source software this year?
Yes; perhaps this is due to the fact that FS/OSS is used by more developers/users. More eyeballs and more code to exercise libraries mean more bugs are discovered. As mentioned, this bug is (relatively) benign, and has already been fixed in the source. So I wouldn't necessarily say that FS/OSS is getting "more buggy", any more than commercial software, whose bugs don't leave the company if users don't discover them first.
All of whom were stamped out within hours of being found.
That's the strength of open source.
El riesgo vive siempre!
The whole issue is not to use insecure languages like C. Such languages allow all sorts of memory manipulation and typically depends on the programmer to secure. The situation is made worse by the lack of something pretty essential: good libraries for string manipulation. While 3rd party libraries are available you can't assume these to be present so many developers still use char*.
Code reviews help, testing helps, good programming helps. But neither of these practices has succeeded in eliminating this type of bugs. It is just not good enough, witness a zillion bugs and security breaches on all major OSes (including the ones deemed secure, and yes I am talking about BSD) throughout the last decade. These OSes only differ in how the issues are dealt with. The occurance of the issue is a fact of life for all of them.
There's no C developer that can claim his program is completely free of buffer overflows (many foolishly do however). There may be some undetected errors in the program, the progrm may depend on third party code that contains bugs (e.g. the compiler or one of the standard libraries). Most likely bugs in all three categories are present.
Automatic checks are indeed the solution to the problem and modern languages build these checks into the run-time environment, where they belong. Buffer overflows are a non-issue in Java, for instance. The exception of this is native code and the JVM itself (written in C).
To eliminate buffer overflows, getting rid of the C legacy is the only solution. Java is probably too controversial as an alternative right now (though arguably it is quite up to the task as far as server side development is concerned) but there are other alternatives. Rebuilding serverside services like ftp, dns, ssh, smtp, pop, etc. is mandatory since each of these services has widely used C implementations that are frequently plagued by buffer overflows. The only way to guarantee that there are none left is to reimplement them.
Jilles
Except in all those statically linked versions in who knows how many programs.
If the strength of Linux is closing the barn doors after the horses have ran amok, I think I'll investigate BSD, where they, you know, actively audit the code.
Vintage computer games and RPG books available. Email me if you're interested.
Just when I think I'll finally cease to be amazed at the mass of useless posts in this place someone like you proves me wrong.
Why Linux can't follow in the supposedly-inferior BSD's footsteps is beyond me.
Loneliness is a power that we possess to give or take away forever
If they ripped them off as you say they would not be able to licence them as GPL now could they?
sure they could. The BSD license lets anyone do whatever they want, including relicense the code as GPL. There is already BSD code in the Linux kernel.
cpeterso
The TCP stack for almost all OS's was {stolen|borrowed|based on} the TCP stack in BSD 4.x (IIRC). I remember once, a few years ago, a system engineer did a special sequence on a Windows 98 computer, and got the BSD copyright to show up.
VM in Linux is a mess. 2 (very) different VM systems, that cause quite a few utilities to be re-writtian. All of the BSD's have one each, and they optimize their VM quite well. FreeBSD has a very robust one, that is a bit slower than Linux's, but seems to be more stable.
OpenBSD just got statefull firewall with the latest version (3.0) Prior to that, they were using Darren Reed's IPF, but due to a licensing fiasco (and petty name calling), IPF was yanked, and PF was created. I use PF in my firewall at home, and I am quite happy. I can't wait until 3.1 (not willing to run -current) to see how much more robust it can get. =)
If you have to remotely upgrade the zlib library, be *very careful* .
Because SSH/OpenSSH depend on zlib, if you replace your current libz.so file with another version whoose API has a bit changed, your SSH server won't work any more.
So if you don't have access to the console, open a classical 'telnet' port for a few minutes, just during the upgrade. Once you've checked that SSH is still ok, you can remove the telnet daemon.
If SSH doesn't work any more after the zlib upgrade, recompile SSH.
{{.sig}}
I dunno, most double frees come from freeing DIFFERENT copies of a pointer. Setting one to NULL won't help in this case...
;))
(A much better solution is to use a garbage collector.
Wrong
free(p);
free(p);
what happens if there is a thread switch between the two calls to free?
Another thread can call malloc and receive the same value 'p' back.
When we switch back to this thread, it will free memory another thread still thinks it owns.
Calling free() twice on the same pointer is never safe.
On a single threaded app, a double free is completely harmless with the majority of malloc libraries. This means single-threaded apps such as Apache 1.x is safe. So only a multithreaded app (such as Apache 2.x) could be exploited. But even still, you'd have to know:
- the version of malloc they are using
- the heap memory usage pattern of the program
In a multithreaded app, the memory usage is not very deterministic.
I don't think anyone will lose any sleep over this.
The latest XFree comes with a copy of zlib 1.0.8.
/usr/X11R6/lib/libz.a on
Does anybody know where this is used and whether I should do a rebuild with the current 1.1.4 version?
In addition to gs, this seems to be the only software package that contains zlib in it. I found it because there is a
my Linux system.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
I worked for a company that had a large C program that served requests - for sake of argument, lets call them web page requests. The program leaked so much memory that it had be to killed periodically in order to avoid running into swap space (every few hundred requests or so).
o ur-data people.
That is a primative form of garbage collection - wait until the garbage has piled up, and then throw it out all at once (sort of like how I implement garbage 'collection' at home actually).
Now, having to start up a complex program takes time, so there was an incentive to increase the life span. Different garbage collectors were tested, commercial, free, and one was chosen and implemented. There was great rejoycing all around from the everything-should-be-garbage-collected people.
Well, the garbage collector was soon completely overrun with garbage, because it is easy to create but takes time to collect. The process would periodically sit and do nothing but collect garbage for tens of seconds as it waded through the 500MB or more of garbage that had been produced since last time. So, the first version won and the garbage collector was removed from the code.
The program went back to being shot in the head every hundred requests or so, and there was great rejoycing from the we-don't-need-no-complex-system-sweeping-through-
In summary:
1. killing a process every so often is a form of garbage collection.
2. Windows dies periodically, so it is using a form of garbage collection.
3. Windows is not secure, refuting your assertion that all garbage collected code is safe.
What the hell is wrong with you people? And you complain when there is a bug found in command.com?