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."
Great, now maybe Redhat will fix their damn openssh RPMs that they fubarred with their last patch!
Anything is possible given time and money.
I appreciate it when Slashdot informs me of a patch I need to apply, but really, I'd rather hear about it once the exploit is actually understood and the patch is available.
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.
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Debian is absolutely amazing.
bug 211205, 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.
-- bartman
- 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
As opposed to the lengths people will go to to damage Microsoft? But that's ok, right?
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.
It seems to me that a package that goes through code security audits regularly and is actually finished is infinitely more secure than an incomplete package?
Why are there people suggesting to go from a secure package to an insecure one?
A significant number of changes in 3.7 are removals (Kerberos 4, Kerberos5 in SSH1, AFS, Rhosts auth). Most people agree that simplicity is a wonderful goal... until that means the dropping (or not including) the feature they need or want. Then simplicity versus functionality versus security becomes a balancing act.
/usr/local/sbin/sshd /usr/local/bin/ssh /usr/local/sbin/sshd /usr/local/bin/ssh
To put the size comment in perspective (this is 3.7p1 on Linux/x86):
$ du -ks
272
224
$ find
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.
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?
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
No, it would still be an ssh vulnerability.
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?
"Sufferin' succotash."
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?
Tubal-Cain smokes the white owl.