New ssh Exploit in the Wild 754
veg writes "In the last few hours there have been several reports of a new ssh bug, with an exploit seemingly in the wild. Oh god not again... The lengths some people will goto to try and damage Theo's pride." Update: 09/17 00:24 GMT by T : friscolr writes "Hot on the heels of rev 1 of the buffer.adv advisory, here is revision 2, which fixes more than revision 1 did. Also see the 3.7.1 release notes."
Uh oh (Score:5, Funny)
Another place to find the patch/bug advisory (Score:5, Informative)
Re:Uh oh - no funny (Score:5, Funny)
See this comment for BSD patch and info (Score:5, Informative)
Re:See this comment for BSD patch and info (Score:5, Informative)
since RH hasn't released any yet...
it's backported from the 9.0 update ssh SRPM.
my bandwidth is VERY limited... so AIM ME at "Swell500" and i'll send ya a link to grab them until RH releases official patches.
ChiefArcher
Re:See this comment for BSD patch and info (Score:3, Interesting)
Your intentions are probably noble, but why should I trust you? Would you trust "you"?
Trust me... View the srpm (Score:5, Informative)
you can always grab it and see for yourself..
I only changed buffer.c
Feel free to see for yourself..
I had to make all of these this morning to patch our systems..
ChiefArcher
Re:See this comment for BSD patch and info (Score:3, Informative)
I've packaged up rpm's (minus the x11-askpass stuff) for Red Hat 7.2 and 7.3. You can download the packages at http://projects.standblue.net/rpms/openssh/3.7p1/
Re:See this comment for BSD patch and info (Score:3, Informative)
Please take only the package you need.
intentions are noble and MIRROR now (Score:5, Informative)
you have an email address to...
and a resume www.briangannon.com
and the Source RPMS.
http://stradlin.com/ssh [stradlin.com]
if you do a diff on the sources, you will see I only edited buffer.c
my intentions are completely noble.
How can you really trust Redhat? One of the disgruntled developers could put a backdoor in a patch?
ChiefArcher
Questions. (Score:5, Interesting)
I have to wonder if UsePrivilegeSeparation was enabled. (see the manpage [openbsd.org])
One message in the thread indicates it is but this isn't first-hand knowledge. If PrivSep was enabled then is OpenBSD immune to this attack due to other parts of the OS being hardened (much like the zlib hole a few months back)? Also are these default installations or are they "tweaked"? As an aside, PermitRootLogin defaults to enabled, something I always disable as I have no need for it.
Even if this does count as a new remote hole in OpenBSD, it's still a phenomenal track record they can be proud of.
Re:Questions. (Score:4, Informative)
That means that Debian's default configuration for sshd is also secure.
CRAP! (Score:3, Informative)
The advisory itself says The systems in question are FreeBSD, RedHat, Gentoo, and Debian all running the latest versions of OpenSSH. So i'm going to assume that OS X is affected as well.
Re:CRAP! (Score:3, Insightful)
iptables -A INPUT -p tcp --dport 22 -m state --state NEW --limit 5/min --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
Public Service (Score:5, Funny)
Patch (Score:5, Informative)
Full Disclosure (Score:4, Informative)
christopher neitzert chris@neitzert.com
Mon, 15 Sep 2003 13:48:34 -0400
More on this;
The systems in question are FreeBSD, RedHat, Gentoo, and Debian all
running the latest versions of OpenSSH.
The attack makes an enormous amount of ssh connections and attempts
various offsets until it finds one that works permitting root login.
I have received numerous messages from folks requesting anonymity or
direct-off-list-reply confirming this exploit;
The suggestions I have heard are:
Turn off SSH and
1. upgrade to lsh
2. add explicit rules to your edge devices allowing ssh from only-known
hosts.
3. put ssh behind a VPN on RFC-1918 space.
On Mon, 2003-09-15 at 12:02, christopher neitzert wrote:
> Does anyone know of or have source related to a new, and unpublished ssh
> exploit? An ISP I work with has filtered all SSH connections due to
> several root level incidents involving ssh. Any information is
> appreciated.
The "Full Disclosure" message is stupid (Score:5, Insightful)
It appears that the OpenSSH people found this bug first, and released a fix in version 3.7. People who studied this fix then found the exploit. So it's stupid for this guy to tell people "upgrade to lsh", since the whole reason his buds know about this bug is because 3.7 fixes it.
Debian? (Score:4, Informative)
running the latest versions of OpenSSH.
The attack makes an enormous amount of ssh connections and attempts
various offsets until it finds one that works permitting root login.
Odd. I run Debian on all of my systems and PermitRootLogin is set to no on all of them. Sarge and Sid also have UsePrivilegeSeparation set to yes by default.
Telnet (Score:5, Funny)
Re:Telnet (Score:3, Funny)
Re:Telnet (Score:3, Interesting)
Of course, if you used telnetd-ssl, you might be correct. :)
[ Caveat: Haven't been following the security problems with telnetd-ssl ]
Nothing confirmed so far... (Score:3, Interesting)
There's only one guy that says it its ISP has blocked all incoming SSH connection due to "several root level incidents".
One guy did say that there was a bug somewhere and that a patch existed...No one knows what patch or where it is though.
Let's hope to publish this one quickly before there's any ral damage done.
Wrapping defense (Score:4, Interesting)
Re:Wrapping defense (Score:3, Informative)
However, if you're a paranoid or pessimistic kind of person, you shouldn't rely on hosts.allow to protect you.
Assuming that your ISP is taken over (either by hackers, or the FBI), they can re-number any internet packets destined to you. The hosts_access system will have no way to tell that a datastream is from a spoofed source. The "source address" field of IP packets can be falsified, and th
It'll help, and also: (Score:5, Informative)
DenyUsers *
AllowUsers you@your_ip_address
(and restart sshd)
You can also firewall the port off. I've done a hodge-podge of these solutions on different systems I admin until I can actually get the 3.7p1 source from the mirrors (they dont' seem to have it yet).
Re:It'll help, and also: (Score:3, Informative)
If you want to block all users but your list of allowed users, just use:
AllowUsers user1@users_ip_address user2@users_ip_address
or AllowUsers user1 user2
That DenyUsers string blocks your list of allowd no matter where you put it.
ERROR: MOD (my) PARENT DOWN, MOD THIS UP INSTEAD (Score:5, Informative)
Sorry.
AllowUsers you@your_ip_address
Remember, always test making a new ssh connection before logging out of your existing one, after restarting sshd.
Re:It'll help, and also: (Score:4, Informative)
It is better explained as "AllowUsers localAccount@remote_ip_address". It means: "Allow SSH connections from anybody at remote_ip_address to connect to localAccount." (Of course the remote user still must authenticate successfully.)
The syntax unfortunately looks like it specifies a remote user. It doesn't. It defines a relationship between a remote IP address and a local user.
Trust me, I wrote the book [snailbook.com]. :-)
Bits and pieces so far... (Score:5, Informative)
It will be 3.7p1 for us non-OpenBSD people.
It is a patch to one file, buffer.c, which fixes some allocation/offset stuff.
It seems that privilege separation does *not* help here - so get them systems patched (and firewalled)!
Update for debian (Score:5, Informative)
For anyone running debian stable:
apt-get update
apt-get upgrade
Re:Update for debian (Score:5, Insightful)
bug 211205 [debian.org], which deals with this expoit, was resolved in 2h after the announcement. I had my box patched 15min after the slashdot story hit.
Really good stuff.
Re:Update for debian (Score:3, Interesting)
It's impressive in more ways than that - a quick nmap run shows that it has *heaps* of services running, freely available from the net. Among them, postgres, (some) named and SSH.
Apart from the single-point-of-failure problem, why on earth are we running updates from a machine with more holes than a swiss cheese?
Wouldn't it be pretty simple to find an exploit in one of the many services (I bet postgresql will have an overflow or two, having it avail
Re:Update for debian (Score:3, Interesting)
vsftpd is defensible, given that it's an FTP server. And that's it.
Why do *I* need SSH, finger, DNS, PostgreSQL,
If you telnet to a known postgresql server and send it 'asdf', it will reply with 'EFATAL 1: invalid length of startup packet'. When you telnet to security.debian.org on it's postgresql port, it responds with exactly the same message.
So, to answer the other poster: it pretty much looks like a postgresql server - and it sure didn't firewall
Re:Update for debian (Score:4, Informative)
For i386 the exact link is http://incoming.debian.org/ssh_3.6.1p2-6.0_i386.d
For Gentoo (Score:5, Insightful)
- cp openssh-3.6.1_p2.ebuild openssh-3.7_p1.ebuild
- emerge --update openssh
The emerge will fetch the file and complain that there is no digest.- ebuild openssh-3.7_p1.ebuild digest
- emerge --update openssh
Just tested it here, worked fine.Pat
Re:For Gentoo (Score:5, Informative)
It renames the gentoo ebuild, which uses it's own name to figure out what to fetch and install.
So basically a 3.7_p1 named ebuild goes out and fetches the new 3.7 openssh package, compiles it and installs it.
Mirror of the vulnerability description (Score:3, Informative)
http://unthought.net/ssh-vuln.html [unthought.net]
Re:Mirror of the vulnerability description (Score:5, Interesting)
The bug must center around this line:
It looks like the problem here is that buffer->alloc (which presumably stores the size of the buffer) grows on every try, while the actual size of the buffer grows only on successful tries. So you could have a situation where, after a couple of tries, the buffer is 65536, but buffer->alloc is 98304. This could potentially cause another part of the program to run past the actual end of the buffer.
The patch addresses this by only updating buffer->alloc after the new memory has been successfully allocated.
Re:Mirror of the vulnerability description (Score:3, Informative)
It kind of does. Seems that fatal() calls fatal_cleanup() [cf fatal.c], which runs thru a list of callback procedures before exiting. Somewhere in those callbacks the function buffer_free() [cf buffer.c] might be called on the offending buffer. That function does a memset(buffer->buf, 0, buffer->alloc), and there's your overrun.
QED.
Re:Mirror of the vulnerability description (Score:5, Insightful)
Why are they bothering with proper cleanup? This is FATAL CONDITION! ABANDON SHIP!
Only guessing, but how about to ensure that the freed memory isn't handed over to a subsequently-run app, still stuffed full of cryptographically-sensitive information?
guess who (Score:5, Funny)
This is precisely... (Score:4, Funny)
...why I always go back and add security holes to all of my programs. If some future (or current) anti-regime hacker needs to be able to break into a local power plant, I want to make sure my code can help!
[I considered signing this post "love, Theo" but then thought better of it.]
Suggestions for a newbie? (Score:5, Interesting)
How worried should I really be about this? And what steps should I be taking (or ask dad to take)? Since I gather Lindows is similar to Debian, should I just look for a Debian tutorial?
Thanks in advance.
Re:Suggestions for a newbie? (Score:5, Informative)
Now, if you feel you need sshd, but can go without for a while, uninstall sshd in the short term and wait for an upgrade for your OS, at which point you can safely reinstall (it's a simple "apt-get install sshd").
Re:Suggestions for a newbie? (Score:3, Informative)
If you don't log on to your computer from another machine at school or wherever, then the safest thing would be to ensure that the ssh daemon is disabled. You can test this by just trying a "ssh localhost" at a command prompt. If you get a "Connection Refused" message, you're probably fine. To make sure, try executing "/et
WOW!! (Score:5, Funny)
I must be on the wrong site.
NarratorDan
Re:Suggestions for a newbie? (Score:3, Funny)
In fact, you don't need to imagine it. Microsoft are on the record as stating that it's one of the reasons why they can't possibly reveal Windows source mode widely [eweek.com].
Re:Suggestions for a newbie? (Score:3, Insightful)
This open ssh bug is "believed" to be a vulnerability, but they didn't want to worry about trying to find out if it was. They found the bug in a code audit and fixed it. They weren't forced to reveal it because of a threat of bad publicity.
And finally:
With the report last week of Linux being the mos
Try looking around a bit... (Score:5, Informative)
GOOD!! Red Hat, fix your RPMs!! (Score:5, Insightful)
Great, now maybe Redhat will fix their damn openssh RPMs that they fubarred [redhat.com] with their last patch!
Re:GOOD!! Red Hat, fix your RPMs!! (Score:5, Informative)
1.- Download the file openssh-3.7p1-1.src.rpm from any of the mirrors. For example:
ftp://ftp.easynet.be/openssh/portable/r
2.- Build an
# rpm --rebuild openssh-3.7p1-1.src.rpm
3.- Upgrade your OpenSSH packages:
# rpm -Fvh
4.- Re-start your sshd daemon:
service sshd restart
5. Profit!^H^H^H^H^H errr, that's it.
Peace.
Re:GOOD!! Red Hat, fix your RPMs!! (Score:4, Funny)
I think you mean:
Gentoo
I saw this exploit used (Score:5, Funny)
A librarian peeked around the corner to see where the noise was coming from, then put her finger to her lips and said, "Ssh!"
The kids ignored her and kept talking, completely and utterly exploiting the hole, and circumventing the 'Ssh'!
Never was I so frightened.
Comment removed (Score:5, Informative)
Mirror for mailing lists (Score:5, Informative)
... can be found here http://archives.neohapsis.com/archives/fulldisclo
OpenSSH 3.7 Release Announcement (Score:5, Informative)
Subject: OpenSSH 3.7 released
Date: Tue, 16 Sep 2003 14:07:00 +0200
From: Markus Friedl
To: openssh-unix-dev _at_ mindrot.org
OpenSSH 3.7 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support.
We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters.
We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18
For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu
Security Changes:
All versions of OpenSSH's sshd prior to 3.7 contain a buffer management error. It is uncertain whether this error is potentially exploitable, however, we prefer to see bugs fixed proactively.
OpenSSH 3.7 fixes this bug.
Changes since OpenSSH 3.6.1:
* The entire OpenSSH code-base has undergone a license review. As a result, all non-ssh1.x code is under a BSD-style license with no advertising requirement. Please refer to README in the source distribution for the exact license terms.
* Rhosts authentication has been removed in ssh(1) and sshd(8).
* Changes in Kerberos support:
- KerberosV password support now uses a file cache instead of a memory cache.
- KerberosIV and AFS support has been removed.
- KerberosV support has been removed from SSH protocol 1.
- KerberosV password authentication support remains for SSH protocols 1 and 2.
- This release contains some GSSAPI user authentication support to replace legacy KerberosV authentication support. At present this code is still considered experimental and SHOULD NOT BE USED.
* Changed order that keys are tried in public key authentication. The ssh(1) client tries the keys in the following order:
1. ssh-agent(1) keys that are found in the ssh_config(5) file
2. remaining ssh-agent(1) keys
3. keys that are only listed in the ssh_config(5) file
This helps when an ssh-agent(1) has many keys, where the sshd(8) server might close the connection before the correct key is tried.
* SOCKS5 support has been added to the dynamic forwarding mode in ssh(1).
* Removed implementation barriers to operation of SSH over SCTP.
* sftp(1) client can now transfer files with quote characters in their filenames.
* Replaced sshd(8)'s VerifyReverseMapping with UseDNS option. When UseDNS option is on, reverse hostname lookups are always performed.
* Fix a number of memory leaks.
* Support for sending tty BREAK over SSH protocol 2.
* Workaround for other vendor bugs in KEX guess handling.
* Support for generating KEX-GEX groups (/etc/moduli) in ssh-keygen(1).
* Automatic re-keying based on amount of data sent over connection.
* New AddressFamily option on client to select protocol to use (IPv4 or IPv6).
* Experimental support for the "aes128-ctr", "aes192-ctr", and "aes256-ctr" ciphers for SSH protocol 2.
* Experimental support for host keys in DNS (draft-ietf-secsh-dns-xx.txt). Please see README.dns in the source distribution for details.
* Portable OpenSSH:
- Replace PAM password authentication kludge with a more correct PAM challenge-response module from FreeBSD.
- PAM support may now be enabled/disabled at runtime using the UsePAM directive.
- Many improvements to the OpenSC smartcard support.
- Regression tests now work with portable OpenSSH. Please refer to regress/README.regress in t
Right... (Score:5, Insightful)
OpenSSH Security Advisory (Score:4, Informative)
Coincidence, Or... (Score:5, Interesting)
So I hear about this ssh exploit the exact same day that my inbox has Markus Friedl's announcement of the release of OpenSSH 3.7.
Either someone on the ssh team is making money from new releases or some black hat, upon downloading 3.7 and seeing the exploit fixed, decided to strike while the iron was still hot (machines weren't yet upgraded).
Re:Coincidence, Or... (Score:3, Insightful)
There isn't a grand conspiracy. It's just how people work. I person says something like, "So I heared that there is the possibility of an exploit due to a bug in OpenSSH t
Updating for Gentoo (Score:5, Informative)
cd
cp openssh-3.6.1_p2.ebuild openssh-3.7_p1.ebuild
emerge -f openssh-3.7_p1.ebuild
ebuild openssh-3.7_p1.ebuild digest
emerge openssh-3.7_p1.ebuild
Re:Updating for Gentoo (Score:5, Informative)
If you don't want to wait for the official ebuild:
/usr/portage/net-misc/openssh/
cd
cp openssh-3.6.1_p2.ebuild openssh-3.7_p1.ebuild
emerge -f openssh-3.7_p1.ebuild
ebuild openssh-3.7_p1.ebuild digest
emerge openssh-3.7_p1.ebuild
This will fail if you have kerberos support USE'd, with an error involving gssapi.h not being found. The solution? Replace the final line with this:
USE="-kerberos" emerge openssh-3.7_p1.ebuild
Why all the lsh plugs? (Score:5, Insightful)
Why are there people suggesting to go from a secure package to an insecure one?
Redhat RPMs are available (Score:4, Informative)
Redhat Advisory RHSA-2003-279 (Score:4, Informative)
FreeBSD Security Advisory FreeBSD-SA-03:12.openssh (Score:5, Informative)
Corrected:
2003-09-16 16:24:02 UTC (RELENG_4)
2003-09-16 16:27:57 UTC (RELENG_5_1)
2003-09-16 17:34:32 UTC (RELENG_5_0)
2003-09-16 16:24:02 UTC (RELENG_4_8)
2003-09-16 16:45:16 UTC (RELENG_4_7)
2003-09-16 17:44:15 UTC (RELENG_4_6)
2003-09-16 17:45:23 UTC (RELENG_4_5)
2003-09-16 17:46:02 UTC (RELENG_4_4)
2003-09-16 17:46:37 UTC (RELENG_4_3)
2003-09-16 12:43:09 UTC (ports/security/openssh)
2003-09-16 12:43:10 UTC (ports/security/openssh-portable)
iptables and ipchains scripts to limit SSH access (Score:5, Informative)
iptables:
#!/bin/sh
insmod iptables
iptables -F INPUT
iptables -P INPUT ACCEPT
iptables -A INPUT -j ACCEPT -p tcp --destination-port 22 -s 1.2.3.4
iptables -A INPUT -j DROP -p tcp --destination-port 22
iptables -A INPUT -j DROP -p udp --destination-port 22
ipchains:
#!/bin/sh
insmod ipchains
ipchains -F input
ipchains -P input ACCEPT
ipchains -A input -j ACCEPT -p tcp --destination-port 22 -s 1.2.3.4
ipchains -A input -j DENY -p tcp --destination-port 22
ipchains -A input -j DENY -p udp --destination-port 22
Re:interesting comment on how to stop it... (Score:3, Informative)
Re:interesting comment on how to stop it... (Score:5, Informative)
lsh has grown mature since then, and has an excellent code quality. I recommend it. Any day over OpenSSH, after having looked at the code of both projects. Up-to-date documentation, as on the web page, or the README inside the tarball, doesn't contain the warning.
Fixed that ancient LSH README (Score:5, Informative)
Re:interesting comment on how to stop it... (Score:3, Informative)
Nope. You only need openssl-0.9.6 or later. See the INSTALL doc in the openssh 3.7p1 source.
Re:very early (Score:3, Informative)
Re:very early (Score:4, Insightful)
It also may give those who need it on something to watch for until a patch does come out.
Re:very early (Score:3, Informative)
Re:very early (Score:5, Insightful)
Really?
How about hearing about it when you find your machines rooted?
Even though there is no patch available (yet), this heads-up is extremely valuable, as it allows people who cannot afford to be compromised to shut down or appropriately filter SSH on their systems.
Re:very early (Score:5, Insightful)
Even though there is no patch available (yet)
There is a patch available, as well as it being fixed in 3.7, which was just released this morning. That's the point of all of this. The mention of the bug was in the 3.7 release notes, i believe.
Re:Is ths a hoax? (Score:4, Informative)
technoid
Re:deceit (Score:4, Informative)
And as comparison, how many patches do windows users normally need to install over the 'default install' to get it secure and close every hole in the default setup? Methinks slightly more than 1 or 2...
Re:deceit (Score:5, Funny)
Re:deceit (Score:4, Interesting)
Besides, what have they "swept under the carpet"? What do you mean "you have probably"?Just because you seem to have something personal with Theo going on, we're supposed to take your word for this "deceit"?
Re:deceit (Score:4, Informative)
OpenSSH refuses to allocate a buffer over a certain size, but doesn't set the buffer size value back to its previous value. When this occurs, OpenSSH immediately calls fatal() to clean up and exit. The connection is closed, and the buffer is not reused.
The problem is that the cleanup code will, in some cases, attempt to zero the block at the larger size, resulting in OpenSSH crashing.
Because no data other than zeroes is every written to this buffer after the failed allocation (unless the FreeBSD folks missed something), this bug cannot be exploited except as a denial-of-service attack unless combined with some other exploit that allowed you to overwrite the exception handling vectors and add arbitrary code (in which case, there are probably much easier ways to perform the exploit).
Re:deceit (Score:3, Insightful)
"Given that the default install has ssh turned on, will they change it to "two remote holes" ?"
Yes, if they confirm the exploit. They've changed this notice in the past. It went from 0 to 1.
"Lets make some noise and force Theo to finally update that!"
Why? Just to piss off the developers? The openssh code is open and subject to review by anyone.
I think since you didn't catch this bug, we shou
Re:deceit (Score:4, Informative)
# dmesg | head -n2
OpenBSD 3.4-current (GENERIC) #62: Tue Sep 12 22:49:18 MDT 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/c
Re:MOD PARENT DOWN (Score:5, Funny)
It'd serve you right if he gave you one.
Re:deceit (Score:3, Informative)
Re:install base (Score:5, Interesting)
Any "linux user" who has openssh open to the world is a huge dumbass. What part of "firewall rules" don't you understand?
How would you suggest it be configured then? Just turn off remote login entirely? Or what other "firewall rule" could help in this situation?
I assume you are suggesting that people only allow ssh access from a specific, previously-known host. That removes much of ssh's utility (no more checking your system from a laptop in the hotel room), and even that sacrifice is not enough to be protective!
An attacker sniffing packets at your ISP can learn exactly which addresses you accept ssh connections over. Then he can spoof from that same address, and go right through the firewall.
The only way to protect yourself from unwanted outside connections is with correct crypto code.
Re:install base (Score:5, Funny)
That's okay, I will.
I bet this guy's life that a server on the bottom of the ocean is secure.
Re:install base (Score:3, Insightful)
Re:OpenSSH is big and fat (Score:4, Insightful)
To put the size comment in perspective (this is 3.7p1 on Linux/x86):
$ du -ks
272
224
Suggestions? (Score:5, Insightful)
That's right! It can form remote connections, and generate random keys, and... and... uh, well, that's about it, actually. Form connections, generate session keys.
Public/private key generation? Different program. Managing keys on a local machine? Different program. Transferring files securely? Different (wrapper) program.
Got any concrete suggestions there? Exactly how would you divide the existing tools up? Precisely which tools would you create? In what ways -- details, now -- would they be different from the half-dozen programs that come with ssh now?
Re:Great opportunity. (Score:3, Insightful)
That's a good idea. Time for the Ada-zealots [adahome.com] to "put up or shut up". Those guys never seem to put out much code... and of course they become rarer every day. If their language was really more secure, correct, and easy (yes, they claim that!), then an sshd reimplementation would be a fine demonstration to prove it.
Re:Pot = Kettle = Black (Score:4, Interesting)
The nature of _my_ rants at least, include the following:
* UNIX does better at risk minimization (i.e. - chroot jails, more services running as unprivileged users, using processes rather than threads, etc)
* UNIX vulnerabilities are published quickly, and hotfixes are available quickly. In this case, we have a _potential_ vulnerability patched before anyone knows of any way to exploit it. In addition, it made frontpage Slashdot - everyone agrees it's a big deal. This is different from the MS attitude of "sweep it into the next service pack and noone will know".
* I have the source code to the patches, so I can validate whether or not the fix does indeed fix the problem it proposes to, and whether there will be any other impact caused by the patch.
* The patch doesn't require me to reboot anything - I can patch a running system and keep on trucking. Kernel patches should be the only thing that needs a reboot (and, when HURD gets mainstream, we won't even need to then).
* The source code is open to allow more scrutiny. Having the source code available still gives Linux users fewer security-incidents-per-feature than Microsoft while keeping their source closed. Ballmer, I believe, said under oath that giving out the source code to Windows publicly would be a threat to national security.
Nothing about the release of an exploit for Linux changes any of these issues.
Re:Pot = Kettle = Black (Score:4, Insightful)
The MS rants are well deserved.
While your statement about security bugs can happen on any platform is technically correct, unintended bugs are not the only thing that causes security problems. Both MS and *NIX can have unintentional bugs, which lead to security problems. In this case, MS should not be blamed for "insecure" code.
Where the MS rants are well deserved is when a system is insecure by design. It may not have been a design goal, but the design can still be insecure. Just one past example: IIS runs under the SYSTEM account. It is installed by default and turned on by default. These kinds of problems deserve to be ranted about, and MS deserves the resulting reputation. Apache may or may not be installed and/or turned on by default, depending on distribution, but even if it could be compromised, it runs as "nobody" or "wwwrun" or some other unprivileged account.
Re:Pot = Kettle = Black (Score:3, Insightful)
Re:Can somebody enlighten me? (Score:4, Interesting)
Also, I'm not sure exactly how 'fatal' the fatal is in there, it could be that it breaks out of the function, but leaves the buffer size parameter at too large a value for the alloc in that buffer.
One or both of those problems is exploitable.
Re:Does this effect Cygwin??? (Score:5, Funny)
Re:Ermm.. can anyone say "Microsoft" (Score:5, Informative)
Yep, *nix systems have exploits, and an hour or two turnaround between discovery and a fix. I'd like to see Microsoft match that.
"Linux has no exploits that need patching"
People who actually know Linux would never claim that there are no known exploits, just that the time-to-fix is much shorter and that applying these fixes to running systems is usually much easier (in most distributions) than in a Windows system (ie no reboot required, one location for all necessary fixes, better software package management, etc)
I use Linux and BSD at home, but manage Windows machines at work (I have no decision making power, I'm just a grunt) and I must say that Windows management is a royal pain in the ass. We've had no problems with the recent Windows viruses and worms, but I do spend an inordinate amount of time applying patches, rebooting machines, and checking that the new patches did not wipe out the old ones. I don't think that it is unreasonable for Microsoft's customers to demand better patch/upgrade management, a single location for updates to both applications, servers, and the OS, and a better method for confirming that the files included in a patch contain the all of the required fixes (for that file) even if they came from different departments at microsoft.
Re:Ermm.. can anyone say "Microsoft" (Score:5, Insightful)
Remember, we're supposed to seperate the OS and the apps that have the holes...remember?
Or are we still using the term "Windows hole" when referring to Outlook?
Re:Theo's "Pride" (Score:4, Interesting)
If you are aware of a security team that was informed officially, I'd be interested to hear about it.