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."
Well, one post says
"The attack makes an enormous amount of ssh connections and attempts various offsets until it finds one that works permitting root login."
So even if the root hole cannot be exploited with priv. sep, you still have to worry about all those SSH connections eating up your resources.
If linux was installed on 98% of all machines in the world you can bet there would be a worm by now that would have taken advantage of this. Don't throw too many stones linux users.
Great, now maybe Redhat will fix their damn openssh RPMs that they fubarred with their last patch!
Anything is possible given time and money.
On the other hand, it's good to have the heads up if something might not be as secure as we think it is. This warning gives those who turn it on occasionally the knowledge they need to turn it off if not needed, and not just leave it on.
It also may give those who need it on something to watch for until a patch does come out.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
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.
Remind me why the most security critical part of ssh is written in C again... shouldn't a supposedly security conscious group be using a more suitable language?
Yes of course, but the point is that floods of SSH connections are going to be more likely due to people attempting to exploit this bug. Even if you're not vulnerable, they'll still try to exploit it.
"In the last few hours there have been several reports of a M$ bug, with an exploit seemingly in the wild. Oh god not again... The lengths some people will goto to try and damage Billy Gate's pride."
See how easy it is - that should be a -1 flamebait topic on your post.
Now that thats over with I belive (read: may be mistaken) but the latest version from www.openssh.com addresses that issue. But it could just be a similar issue and i'm reading it wrong. If I am enlighten me.
Ave Molech Setting
Are you behind a firewall? If you are using a device such as a nat dsl router that is blocking the ssh port inbound then you are pretty safe. As always, the best bet is to disable services that aren't absolutely necessary. So if you have no need to ssh in to the lindows machine you can disable sshd and have no worries at all about sshd exploits. As for Lindows, don't really know anything about it. Do they release patches? If so, and you really do need incoming ssh, then you might disable it until a patch becomes available. Just my 2c, hope it helps.
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?
Obviously the *NIX side of the world isn't bulletproof either. Now perhaps we might be spared (at least for a day or two) about the anti-M$ rants about insecure M$ code. It can happen, and it can happen regardless of OS platform.
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?
Why the conspiracy theory? Why isn't it possible that the bug had been identified, the developers decided it was enough of a reason to push a new release, and when the new release is pushed, with the reason being b/c of a bug that may or may not be exploitable. Then unsubstantiated rumors of exploits start floating around b/c of this.
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 they found." Someone overhears and turns around and tells the next person they see, "There's a hole in ssh that's exploitable!" and it takes off from there.
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
I'd love to see some network infrastructure servers done in Ada.
That's a good idea. Time for the Ada-zealots 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.
Does OpenSSH run on Windows?
If so this would be a Windows vulnerability too.
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.
Anyone who is relying on slashdot for critical security updates is being extremely irresponsible. If your site is so sensitive, you should have blocked/filtered/whatever ssh last night when it first came out on Full Disclosure or whatever list/service you subscribe to for critical security updates..
There are two kinds of sysadmins: paranoids and losers. I'm both kinds.
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)
Amazing how a newsworthy point about a ssh bug becomes an attack on an entire operating system and/or person.
"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 should all be asses and target you for harrassment.
"If you follow misc@ carefully you have probably seen it done before."
Bullshit. If you follow misc@, most of the exploits discussed hit previous unpatched versions of OpenBSD. The point of OBSD is to catch bugs and bad code ahead of time; it undergoes near constant review.
A lot of folks want OBSD to add to this count stuff OBSD noticed may have been exploitable, then patched it anyways, frequently weeks or months or years ahead of a known exploit. When the known exploit comes out, they point to the OBSD version 6 months ago.
Exploits are counted that can violate current, stable systems, not OBSD 2.8.
This is like blaming MS for the exploit that allowed slammer to spread; if people patched their systems when they were supposed to, they wouldn't have been inconvenienced. OTOH, MS should have caught the bug ahead of time.
I feel OBSD falls into the latter category, not the former. They are more than likely ahead of the game. Given what I've seen of security reports on Linux and FreeBSD over the past 2 years, OBSD tends to play catchup in coming up with fixes. Rather, they tend to fight the tide that their "policy" in reporting exploits is wrong.
Oddly, I think that is more a testament to them doing things right as opposed to your attitude that they are being purposefully deceitful.
Good point. Something like:
...might do the trick of slowing them down. Mind you, you wouldn't be able to get a connection either if they were attacking your box
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
Get your own free personal location tracker
also are quick fixed and is *generally* harder to exploit. And the patches are stable. not as the first slammer patch that wasn't fixing the M$ problem @ 100%, thus requiring a second patch for the same problem....
I was there.
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 most-breached operating system
A very misleading statement, as this study only counted breachs by a human hacker and not a auto-vulnerability (worm, virus, etc.). There own statistics prove this, note the following lines from the article:
Clearly, overall server attacks were down while just as clearly, all attacks were up. In fact, server attacks were 1/40th of the economic cost of all attacks. The dwindling cost of server attacks is probably attributed to the continued movement of web servers to apache and away from anything MS.
A great many people think they are thinking when they are merely rearranging their prejudices. -- William James
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."
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.
In your netbsd prompt type ssh -V. It's probably using ssh 3.4, not 3.6, assuming you're using the core system's ssh (Not the pkgsrc one). You should be unaffected by this hole.
Or are we still using the term "Windows hole" when referring to Outlook?
Well, if you had said Outlook Express, then the answer is YES since MS claims OE is an inseperable component of IE and IE is an inseperable component of Windows itself, then OE == Windows.
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.
This bug is only public knowledge because the OpenSSH people have already fixed it.
And it's only a problem because they didn't tell anyone else. There are too many people looking at SSH for holes to try and slip a security fix into a new version without mentioning it and backporting the fix. Maybee they didn't appreciate that it was an exploitable bug. Maybee this whole topic is hype and there is no exploit. Assuming they new it was an exploitable bug, they should have coordinated a fix before releasing a patched version. A local root exploit in Galeon, Grip, etc...upsetting but no use losing sleep over it. A remote root exploit in SSH, Apache, xinetd, etc...get is fixed ASAP and don't hide the problem.
SECURITY 101: The only way to really protect yourself from unwanted connections from the outside world is to unplug from the network. Of course, that's hard if you're trying to build a Web Service. Even that isn't a guarantee if you can't provide physical security to prevent access to the system console. There's a handy little floppy boot disk I've seen that will break into any Windows box made, though it won't help you if the file system is encrypted. I have a feeling there are similar exploits possible on Linux or other UNIX systems if you can get to the physical box.
Point being, security is a question of choices and compromises. What series of choices (such as leaving a ssl port open or closed) gives you an acceptable risk, and still allows you to do what you need to do?
Your Servant, B. Baggins