Post #31,721
3/11/02 5:46:41 PM
|
zlib advisory
[link|http://www.gzip.org/zlib/advisory-2002-03-11.txt|Here]
This one is bad. It affects anything, anywhere, that is using zlib. Think "uses gzip's compression mechanism". In other words, if it is a .tar.gz, it is affected. Compressed SSH, it is affected. And so on...
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #31,768
3/11/02 11:25:28 PM
|
Re: zlib advisory - a similar link.
[link|http://www.nytimes.com/cnet/CNET_0-1003-200-9051213.html?pagewanted=print&position=bottom|Link.]
It does seem serious.
Alex
"People demand freedom of speech to make up for the freedom of
thought which they avoid." -- Soren Aabye Kierkegaard (1813-1855)
|
Post #31,777
3/12/02 12:12:38 AM
|
Remedy?
This looks like a PITA.
Since compression touches damned near everything, including kernels, this seems to require a recompile on a hell of a lot of software. Debian's identified at least 20 effected packages, I'm already in the middle of an RH update, looks like there's more of that in store.
Revving kernels though, is something of a pain, particularly on production servers. Any tips here?
--
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]
[link|http://kmself.ix.netcom.com/|[link|http://kmself.ix.netcom.com/|http://kmself.ix.netcom.com/]]
What part of "gestalt" don't you understand?
|
Post #31,778
3/12/02 12:27:49 AM
|
Erg.
Well, my server could do with a general upgrade, anyway.
Wade.
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #31,781
3/12/02 12:41:28 AM
|
Well OpenBSD was never vulnerable. :-)
The problem is that Linux' malloc implementation doesn't by default protect against people calling free() twice in a row on the same memory. The *BSD family does.
There is a tunable environment variable MALLOC_CHECK_ which can be set in Linux to values from 0-2 to detect simple errors like this and optionally do nothing, report on STDERR, or crash. Set that in obvious global places, update zlib, and restart. That will block *most* of this, and help with several other problems.
In general for statically linked stuff, I would focus on machines and applications which are exposed to the network or files from there. (Like, say, OpenSSH.) As it stands, you can deliver a DoS this way, but exploitability seems somewhat remote. Since local users can do a local DoS fairly easily (unless you have paranoid ulimits set), remote users are the main risk.
And perhaps it would be a good idea to have OpenBSD on any machine directly on the general network? :-)
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #31,854
3/12/02 1:51:32 PM
|
OpenBSD as server
There are a few problems.
First, OpenBSD's update process is limited. While it's improving, and oBSD wasn't vulnerable to this potential exploit, my experience has been that of the three major options (Debian/apt, RedHat/rpm, oBSD), the ease-of-maintenance continuum flows left to right.
Second, OpenBSD lacks SMP support. Uniprocessor only. That's a nonstarter for several of our systems. As an appliance, it's acceptable. As a server, it shows clear failings.
Third, even placing oBSD as a bastion system in front of your servers, you're open to exploits in CGIs or other server-side software, behind the firewall. Security is a process, not a product.
I'm happy with the fact that I am able to update my Debian systems within 24 hours of this alert with no issues. Red Hat I'll have to wrestle with over the course of the day, and OpenBSD I'm glad I don't have to mess with. Given a choice of "secure by default" and "very narrow vulnerability window", I've come to prefer the latter, though a sane-by-default configuration also helps.
--
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]
[link|http://kmself.ix.netcom.com/|[link|http://kmself.ix.netcom.com/|http://kmself.ix.netcom.com/]]
What part of "gestalt" don't you understand?
|
Post #31,787
3/12/02 2:25:22 AM
3/12/02 2:29:24 AM
|
Re: zlib advisory
Red Hat has new zlib packages available, and a new kernel package. I got mine by using up2date.
A [link|http://www.redhat.com/support/errata/RHSA-2002-026.html|full list] of the packages affected is available.
Peter
Shill For Hire
[link|http://www.kuro5hin.org|There is no K5 Cabal]
Edited by pwhysall
March 12, 2002, 02:29:24 AM EST
|
Post #31,864
3/12/02 2:29:21 PM
|
Re: zlib and up2date
Got my update as well. That is so painless!
Alex
"People demand freedom of speech to make up for the freedom of
thought which they avoid." -- Soren Aabye Kierkegaard (1813-1855)
|
Post #32,263
3/14/02 10:07:28 PM
|
Microsoft vulnerable too - uses zlib code
[link|http://news.com.com/2100-1001-860328.html|MS Uses ZLib Code] Members of the open-source compression project, Gzip, have posted a list of nearly 600 applications that a detection program has flagged as using the zlib code. Nine Microsoft applications are included in the list: Microsoft DirectX 8, FrontPage, the next-generation Graphics Device Interface, InstallShield, Internet Explorer, Office, NetShow, Visual Studio and Messenger.
The next-generation Graphics Device Interface is part of Windows XP, meaning that the operating system itself could be at risk. Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #32,287
3/15/02 1:45:18 AM
|
Risk: adopting FS code without adopting FS practices
Microsoft has adopted and appropriate free software code. It's failed to adopt free software practices. The risk here is rather similar to the one pointed out (with a certain charming amount of repetition) by our very own LAME, ASD some years ago: the secretary's got the source code.
I was watching an NT 4.0 WS system here boot the other day, and something caught my eye. "Build 1381". That's the same build of the NT 4.0 kernel that I had on my desktop in 1997. Proprietary code has a strong tendency to rev very slowly, and a given build of a program may be extant in large numbers for years. Part of the security of free software comes in the quick cycle time -- people outrun the bugs. The other side of the security coin comes from the rich multitude of software versions out there. While it's (sometimes) a nightmare for compatibility, it also makes the cracker's job more difficult -- scripted attacks are likely to work against only a small number of vulnerable systems, just by virtue of the changing target syndrome.
I'll wager that a significant portion of Debian systems are already revved past this week's zlib flaw. I'll also wager that in three years, a significant portion of proprietary software systems based on zlib code will continue to exhibit the exploit, while the GNU/Linux and other free software systems have moved far beyond it.
Food for thought: you can't half adopt FS.
--
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]
[link|http://kmself.ix.netcom.com/|[link|http://kmself.ix.netcom.com/|http://kmself.ix.netcom.com/]]
What part of "gestalt" don't you understand?
|
Post #32,417
3/15/02 9:37:37 PM
|
But note that MS doesn't update the build #'s
I don't know the details, but I've noticed that updating the system via service packs doesn't change the build number; it's the same build number (1381) followed by the Service Pack #.
I'm not sure where other OS 'upgrades' (such as installing later versions of IE) are tracked.
Tony
|
Post #32,274
3/14/02 11:08:50 PM
|
I'm confused about the entire thing
In my experience, a program that tries to free() an already free()'d area and thus leading to a corrupted memory arena just dies and dumps core. I can see how causing memory dumps might lead to a denial of service attack, but I am failing to see how this could lead to an actual attack on anything.
Enlighten me, Oh Fellow Unix'ers. And, please, stop pissing your pants, you alarmists.
One, give me one, actual exploit. Just one. Then I'll be dribbling along my legs.
With experience with free'ing corrupted memory spaces, this alert is just so much bullshit until something, somewhere, anywhere demonstrates an exploit. Programs will dump core. Maybe possibly there is an exploit. Yah right.
Where each demon is slain, more hate is raised, yet hate unchecked also multiplies. - L. E. Modesitt
|
Post #32,278
3/14/02 11:38:03 PM
|
DoS is an attack
And that is the main risk here, as was clearly laid out in the advisory. The main reason why this is big is not that you can do that much to the system, it is the sheer amount of stuff that is affected.
As for a more useful exploit, well a double free causes corruption of memory somewhere. With more traditional means of doing so (eg buffer overflows) you get some control over what is corrupted, where. With a double free you don't. It is theoretically possible that the corruption could be such that you won't core dump, but instead will do something random. For instance a double-free at point A will lead to point B starting to execute code from point C, where C holds a user-defined text string. In that event then, given the fact that memory allocation issues are often deterministic, you might get the ability to exploit an application.
The possibility is admittedly remote, and would take both luck and careful analysis to find. But full exploits have been demonstrated in the past of this type of bug, and it is likely that between all of the architectures and applications that there are a few exploitable instances out there.
As is normal when talking about security and bugs, identifying which ones are exploitable is not really worth it (unless you are a black hat). The bug exists, is fixable, and fixing it is easier than detailed analysis.
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #32,282
3/15/02 12:08:18 AM
|
Re: DoS is an attack
For instance a double-free at point A will lead to point B starting to execute code from point C, where C holds a user-defined text string. Right. When these alarmists can give an example of an actual exploitation, I'll believe it. This alarm involves a known problem that could involve a hypothetical problem that might somehow let another hypothetical exploit theoretically invoke a buffer overflow that might possibly have a problem. It may be a security problem, but I see it as a FAR less problem than most of the hundred other Microsoft problems. It's not a maximum "red alert" piss-your-pants problem that it's been portrayed as. Where each demon is slain, more hate is raised, yet hate unchecked also multiplies. - L. E. Modesitt
|
Post #32,316
3/15/02 9:56:32 AM
|
Then I suggest...
...that you simply not upgrade any of your systems that might be affected. Wait until someone can figure out how to exploit it. And then you can attempt to maybe possibly use your machine as an after-the-fact honeypot.
Meanwhile, I'll just go run red-carpet, update my system, and not worry about it.
-YendorMike
Real programmers use "vi a.out".
|
Post #32,434
3/16/02 10:05:44 AM
|
I've run into double-free problems before
The memory arena is corrupted, and eventually the program core dumps. I can't get my mind around a way to reliably exploit it. Getting the condition to happen and somehow using it for a denial of service attack, I can see how that might be possible, but it's not worth worrying about for a home system.
Where each demon is slain, more hate is raised, yet hate unchecked also multiplies. - L. E. Modesitt
|
Post #32,361
3/15/02 2:12:46 PM
|
It's a known class of exploit...
...touching a large number of programs and systems. Buffer overflows are a very common class of root causes for security exploits. Testing for, and avoiding, overflows is a (relatively) simple, prophilactic measure that can avoid many, many possible exploits.
[link|http://www.openbsd.org/|OpenBSD] uses modified C libraries to do just this. Proprietary products (IIRC, StackGuard is one) work similarly. I also believe that one of the ideas behind Java is to protect writeabe (and readable) memory. One of the classic explorations of comparative robustness of free software vs. proprietary software is [link|http://online.securityfocus.com/library/2087|Fuzz Revisited], uses the relatively simple test of throwing arbitrary junk input to a program and watching the results.
I suggest again looking at my "Risks" comment above.
--
Karsten M. Self [link|mailto:kmself@ix.netcom.com|kmself@ix.netcom.com]
[link|http://kmself.ix.netcom.com/|[link|http://kmself.ix.netcom.com/|http://kmself.ix.netcom.com/]]
What part of "gestalt" don't you understand?
|
