Slashdot Mirror
New ssh Exploit in the Wild
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."
I have to wonder if UsePrivilegeSeparation was enabled. (see the manpage)
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.
Trolling is a art,
Reading the mailing list, it appears that there's nothing confirmed so far. Let's hope its just a false rumour.
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.
IP Therefore I am.
Won't having the sshd wrapped (/etc/hosts.allow, /etc/hosts.deny) help offset the damage somewhat?
No sig
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.
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).
"Provided by the management for your protection."
What a troll. Aiming to trick mods into "Informative", I suppose.
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.
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.
None of the rants assumed it couldn't happen.
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.
Engineering and the Ultimate
Easy, the buffer for a period of time is not as big as the struct indicates. So between the time the buffer size variable is set and the time the realloc is performed, there is a window of opportunity to fill that buffer beyond is alloced boundary if another process/thread goes to put stuff in that buffer at the wrong time.
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.
XML is like violence. If it doesn't solve the problem, use more.
I'm on a couple of the lists that should have been informed. As one example, NetBSD's security officer has received no information from the openssh team at all. I'm unaware of other groups having received official word.
If you are aware of a security team that was informed officially, I'd be interested to hear about it.
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"?
Unlimited growth == Cancer.