Remedy?

Post #31,777 by kmself 3/12/02 12:12:38 AM Reply	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 by static 3/12/02 12:27:49 AM Reply	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 by ben_tilly 3/12/02 12:41:28 AM Reply	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 by kmself 3/12/02 1:51:32 PM Reply	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?`

Welcome to IWETHEY!