Slashdot Mirror
Flaw Made Public In OpenSSH Encryption
alimo20 writes "Researchers at the Royal Holloway, University of London have discovered a flaw in Version 4.7 of OpenSSH on Debian/GNU Linux. According to ISG lead professor Kenny Patterson, an attacker has a 2^{-18} (that is, one in 262,144) chance of success. Patterson tells that this is more significant than past discoveries because 'This is a design flaw in OpenSSH. The other vulnerabilities have been more about coding errors.' The vulnerability is possible by a man-in-the-middle intercepting blocks of encrypted material as it passes. The attacker then re-transmits the data back to the server and counts the number of bytes before the server to throws error messages and disconnects the attacker. Using this information, the attacker can work backwards to figure out the first 4 bytes of data before encryption. 'The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH, said Patterson. ... Patterson said that he did not believe this flaw had been exploited in the wild, and that to deduce a message of appreciable length could take days.'"
OpenSSH 5.2 was released in February already which has builtin countermeasures against this form of "attack." Next.
Whew. Glad I use Telnet.
MABASPLOOM!
From the article it seems that it is more of a design flaw of SSH and not specifically OpenSSH
And in other news it also appears that the word "chink" is banned in the comments section.
Anyone else remember when Unix was the usual target, and MS/DOS the "safe" OS?
-Space for rent
Did you read the article?
It indicates that it effects SSH in general, not only one particular implementation.
Go green: turn off your refrigerator.
If the flaw is in the design of SSH, wouldn't all OS's be effected? Why does this only effect Debian?
The 2^-18 is _really_scary_
The 'first 4 bytes', not so much.
So, meh. Of course true hardcore cryptanalysts are sure to be already ditching OpenSSH or maybe piping it through GPG first.
how long until
". . .discovered a flaw in Version 4.7 of OpenSSH on Debian/GNU Linux."
"The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH"
So which is it, is it an implementation specific bug, which is specific to OpenSSH on Linux specifically, OpenSSH on all O/Ses, or is it a flaw in the RFC, which should make it exploitable on *all* implementations of SSH, shouldn't it? How can a flaw in the standard only be exploitable in one version of one implementation of the standard on one specific target OS?
According to TFA, "OpenSSH version 5.2 contain[s] countermeasures". For Ubuntu users, note that Ubuntu 8.04 LTS (Hardy) is using the vulnerable version 4.7. Versions 8.10 (Intrepid) and above appear to use version 5.1.
Does anyone know whether 5.1 contains the flaw and/or the "countermeasures"?
Also, can any security gurus comment on the danger level here? It sounds like there is a low-probability to access a small amount of information... but the very existence of this vulnerability makes me uncomfortable. Also, why does it mention Debian specifically? Don't most distros use an OpenSSH package based on the exact same design? Shouldn't they all be vulnerable?
http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
Its in Debian? But a quick look at their repositories shows that oldstable has 4.3 and stable 5.1. Unless of course they compiled
After years of not using a signature, I am going to make one to say the following: Fuck Beta
So is it a flaw in the design of SSH or in the Debian patched OpenSSH implementation? If it's the former (as the quote seems to imply), why does it matter what SSH implementation, OS they found it on? Shouldn't it affect everyone?
sic transit gloria mundi
No.
Get off my lawn!
FTA, this vulnerability is addressed in newer versions of OpenSSH, not by fixing the specification, but by employing some kind of workaround to make it impractical. I didn't know that from the summary, since I don't really keep current on where OpenSSH is with their releases.
It seems like this attack has an awfully small chance of success. I am wondering if there is that small chance of success to decode a message after many days, or if because of the small chance of success, it would take multiple days before you had anything.
If this is really something that has almost no chance of working at all--period, I'm not too worried. If it is something that makes the encryption breakable in a few days, that's a pretty big deal and am surprised that it didn't get outed sooner as a flaw.
Can/should the RFC be revised to close this hole? Are there other (perhaps more obvious) examples of weakness in the RFC that have implementation-specific fixes applied?
This flaw was published in Nov 2008 with simple configuration fix, and OpenSSH released a default fixed version in March 2009.
Also, this attack gives only 4 bytes of unencrypted output after crashing your session many thousands of times, which is sure to be noticed. If you were repeating the exact same network traffic in millions of SSH sessions, an attacker might get something interesting after weeks of crashing your sessions. It's just one of the lamest exploits I've seen, worth mitigating eventually, but not worth all the press it's getting, especially 6 months after release...
The fix is simple, just use CTR mode encryption instead of CBC, or upgrade to OpenSSH 5.2 or later.
For more details go to the OpenSSH security page.
Blessed are the pessimists, for they have made backups.
Anyone else remember when VMS was the usual target, and Unix the "safe" OS?
It is because that happened to be the system that they found the vulnerability on.
Nothing more than that, really.
This is not your lawn. The property line clearly indicates...
wait a minute...
you are on MY LAWN!
Anyone else remember when stone tablets were the usual target, and cave drawings considered "safe"?
-Space for rent
This is a technicality that no one cares about anymore I think even Stallman gave up on it.
Just enough to tell 'em what you think...
Everybody knows this. Nobody cares, except for Richard Stallman.
Obviously the flaw itself is (a) old, and (b) not specific to Debian.
The only point of (little) interest of the article is that it highlights that the SSH specifications - the RFC - has not been updated yet.
ftfa:
"The flaw, which lies in version 4.7 of OpenSSH on Debian/GNU Linux"
"Patterson said his group had worked with OpenSSH developers to mitigate the flaw, and that OpenSSH version 5.2 contained countermeasures."
They are unclear on whether or not it's only debian's repos that are affected, so I'd suggest upgrading to 5.2 or later.
Gnu/Linux is not an operating system either.
"Fedora core 11" is an operation system.
Command to determine openSSH version: ssh -V Output: OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 I assume if you get the same results as I did you are not affected because you are running version 5.1.
Yes. That's why we now have replaced telnet/rsh/rcp and authenticated FTP with ssh and scp, NIS with LDAP+Kerberos, /etc/shadow, authentication in NFS, support for other filesystems like CIFS, etc.
Microsoft, for their part, haven't changed all that much.
My blog
Implies man-in-the-middle already, and the odds of figuring 32 bits of a particular packet are somewhat low. The worst case i could think about is when i pass my password or a very specific short data (cc number?). That particular data must be the decripted one, and in the 1/256k odds of happening, IF i have someone in the middle actively trying to get it. With that chances, the attacker well could expend his time playing lotto that have more chances to win.
Of course, those numbers are regarding a specific distribution/ssh version, could be different for other versions, but still, looks somewhat hard to happen ever.
> Patterson said that he did not believe this flaw
> had been exploited in the wild, and that to
> deduce a message of appreciable length could take
> days.
Is my social security number a "message of appreciable length?"
--I'm so big, my sig has its own sig.
-- See?
It's only a few GNU people like you who are still bitter about the fact that Linus did in a few months what GNU took years to not do -- build a working kernel.
Hey that's not fair. They will have an alpha version of Hurd ready before 2012 and the world ends. They swear this time!
Article? Even the summary would've sufficed.
This was never a real threat, just another piece of Academic FUD. To be vulnerable as an interactive ssh user you would have to ignore 100,000 aborted sessions to expose 14 bits of plaintext, I think I would notice, and block the attacker.
There are a whole suite of cyphers, including AES aka Rijhndael are configurable, have you done yours?, and not vulnerable.
Finally the protocol is trivially fixed.
Now I for one, whilst I have the highest respect for the work done by people like Ross Anderson and Schnieer am fed up to the back teeth with alarmism from governments, NGOs and academics -- all of which add up to give us more money.
If you dont know these researchers were working for the UK equivalent of Homeland Security and failed to inform SSH of the details of the attack, doubtless quoting National Security.
These people who parade nonsense should be tarred an feathered and sent on the next rail.
While I agree that using "GNU/Linux" instead of "Linux" is not of utmost importance, GNU is more important to modern Free operating systems than most other components, so "GNU/Linux" makes more sense than "GNU/X.org/Apache/BSD/Linux".
While some very small Linux-based systems use C libraries other than Glibc, can you name one that doesn't depend on GNU development tools? In fact, it's hard to find a non-Microsoft operating system in common use (Free or non-Free) that doesn't depend on GNU development tools.
Coreboot is irrelevant, as it's neither an operating system nor an operating system kernel. Coreboot initializes hardware, then loads a target. Originally, the target was always a Linux image, but now it can be a number of other things. Linux by itself can't do much useful. The only thing I can think of is routing, but that must be set up by userspace programs.
Clearly, Linux has been far more successful than the GNU kernel project. The GNU people are very happy for the success of Linux. However, Linux could not have become as successful as it is without the groundwork laid by the GNU project. So, while I don't think it's necessary to always mention GNU with Linux, I try to do so because it seems that GNU often isn't given enough credit.
I can't find a reference to it. Certainly they submitted a bug report. They mention they found it on debian, so it seems like they would have file one.
"It is better to die on one's feet than to live on one's knees." - Albert Camus
Yes. That's why we now have replaced telnet/rsh/rcp and authenticated FTP with ssh and scp, NIS with LDAP+Kerberos, /etc/shadow, authentication in NFS, support for other filesystems like CIFS, etc.
Microsoft, for their part, haven't changed all that much.
You're talking about changes since the tools developed in the 1980s. Microsoft completely replaced their consumer OS, moving from the Win95-based platform to the infinitely more secure NT-based platform, moved to AD, replaced an unsecure method of storing passwords with a secure one, invented CIFS, moved to a filesystem where all actions can be audited, etc.
The non-Linux Unixes, for their part, are mostly the same as they were in 1985 (that Oracle OS, Sol-something or other, being the one exception).
Socialism: a lie told by totalitarians and believed by fools.
Don't complain about Debian GNU/Linux to us, complain to the Debian people. That's what they call their distro. Based on their web page, it would be equally correct to call it Debian, but the longer name gives more context for people who don't recognize several distro names on sight.
"Debian GNU/Linux" is a name. You can use it without arguing about the words and their implications, just like you can use the name "Microsoft Works".
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
It passed the decrypted packet_length value back to the other end in an error message, according to the article. Shouldn't that have allowed arbitrary recovery of plaintext by just xoring the returned packet length with the previous ciphertext block used as the IV?
Particularly when using Krb5 for session encryption ;-) Of course how many slashdotters know that you can use telnet with session encryption on an intranet? Slim to none?
LedgerSMB: Open source Accounting/ERP
Mammaw wants help getting the push-mower started again.
All you boys ever do is fish.
Get your dogs out of my four-o`clocks!
replaced an unsecure method of storing passwords with a secure one
While that is true, the Microsoft default is to still have the old insecure methods enabled. You need to disable them with active directory policy or editing the registry.
That's NoLMHash = 1 and lmcompatibilitylevel = 5 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
I believe Microsoft finally changed the defaults in Vista.
What you say is true.
However, who says SSH has to be interactive? What about rsync backups over SSH? Automated connections that use SSH? Basically, anything and everything is tunnelled through SSH, so this is huge. If the attacker has time and you have a network of, say, 100 machines that initiate 1000 SSH sessions a day, you could have a breach in a day. If the attacker has a few weeks to work undetected, you could have a huge breach and have no idea because you're basking in the false security of working in SSH. Think you'd notice that?
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Because it describes a particular flavor of Debian; we use GNU libc+userland (well, now embedded GNU libc) and the Linux kernel. We also distribute GNU/kFreeBSD and GNU/Hurd variants as well. If someone actually wanted to, ports using a different libc and userland could also be made, and would have a different nomenclature.
In the end though, it is what the Debian project has decided to call its particular port, so if you want to reduce ambiguity, that's what you should call it to.
http://www.donarmstrong.com
GNU is more important to modern Free operating systems than most other components
I disagree.
I believe it's possible to deploy X.org without GCC. It is not, however, possible to create a reasonable desktop operating system without a GUI of some sort.
Linux could not have become as successful as it is without the groundwork laid by the GNU project.
Nor could the GNU project become as successful as it is without the groundwork laid by Unix. Nor could Linux have become as successful as it is without Apache.
Don't thank God, thank a doctor!
I'm not complaining about Debian GNU/Linux.
I'm complaining about someone bringing up the whole "It's not Linux, it's GNU/Linux" argument in a context where no one got it "wrong" anyway -- Debian already calls it GNU/Linux.
It's kind of like someone saying "Linux is a great OS", and someone responding, "OMG, you're so wrong, Linux is a great OS!" And then ranting for pages about why it's a great OS.
Don't thank God, thank a doctor!
In other words, they've done a lot, but they have always been playing catch-up.
Have you used AIX or HPUX or the like recently? Windows may be playing catch-up, but at least they're trying. Give me Windows any day over an OS stuck in the age where limiting a user name to 8 characters was acceptable, and even the most basic tools (i.e., SSH) are only avaliable as a third-party port.= with no formal vender support.
Socialism: a lie told by totalitarians and believed by fools.
I assume the parent failed every numerate course he ever took, and never took any kind of statistics for idiots course, and has not bothered to read and understand the attack.
... then I have to tolerate 100000 failures/connection.
An continues to spread FUD.
The attack requires a Man in the Middle scenario, if I ssh into a random machine the MiM is __VERY__ unlikely to work unless the NSA and my ISP are in cahoots and I dont notice that connection takes a nonsensically longer time (15min v 3s),
Now comes the idiot who talks about rsync, and scripted connections, which, for brevity I did not address and tries to use multipicative probability leveling to try to convince us we have a problem; sorry now you need 1000+ MiM attacks, and fail to notice that they are failing, so you also dont notice a net cable kicked out, or a cable cut by a backhoe.
Look guys, get real, if you want to use statistics or probability learn some and understand contingent probability which is essential to risk evaluation.
... Although OpenSSH is usually included along with the Linux kernel in complete distributions of an OS. In fact (calling attention to the 'Open') it was actually developed by the OpenBSD group.
Categorizing this story as 'Linux' is misleading. OpenSSH is used with a variety of platforms, of which Linux is only one.
Microsoft completely replaced their consumer OS, moving from the Win95-based platform to the infinitely more secure NT-based platform
Thank goodness. I'd hate to think they were shipping anything insecure to their well deserved 97% of the market...
(And are you including OpenBSD in your "non-Linux UNIXes" list, by any chance?)
you had me at #!
My understanding is that one packager screwed up one package (openssl), which (while a _big_ screw-up) would hardly amount to a "history of fucking up packages".
Can you cite any other examples that would indicate such a trend?
I have. I'm a Unix systems engineer. HP-UX includes fully supported SSH in 11i and later. AIX has supported >8 usernames and passwords for since 4.2 and SSH is included in the box. Both have support for LDAP and Kerberos, again, out of the box, which allows for >8 character usernames and passwords.
Solaris, for it's part, has supported MD5 passwords since version 8 and 9 and 10 have it enabled by default.
My blog
To mitigate on clients and servers: in /etc/ssh/sshd_config and /etc/ssh/ssh_config and/or any ssh clients you use, add:
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha1
To verify:
ssh -v host
look for the output:
debug1: kex: server->client aes128-ctr hmac-sha1 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-sha1 zlib@openssh.com
You are particularly interested in the aesXXX-ctr segment. If that specifies a CBC mode, then you probably need to change that server's config. For the blowfish-using type, I'm uncertain of the attack's applicability to blowfish-cbc. YMMV. For server testing, you probably want to make sure your ssh client isn't forcing the CTR mode. To test that, do
ssh -v -o Ciphers=aes256-cbc,aes192-cbc,aes128-cbc,aes256-ctr,aes192-ctr,aes128-ctr
and look for similar debugging output as above.
Summary? Common fucking sense would've sufficed.
I am the lawn!
That now makes more sense. Thank you for the more detailed explanation which actually makes some kind of sense. So, in a way, this isn't *exactly* a flaw in the standard, but how the OpenSSH team decided to implement that particular clause of the standard (that is, how they interpreted the standard).
You can disagree all you want, but can you back up your opinion with any facts? Can you, for example, give an example of an operating system that uses Linux and Xorg, but not any GNU tools? While GNU was inspired by Unix, it contains no Unix code at all. Neither does Linux contain any Apache code. I'm not talking about simply being successful, but about one project depending on the other. I challenge you to give an example of a single operating system that uses Linux, but doesn't depend on GNU in any way.
For all operating systems that do depend on both Linux and GNU, I think it makes sense to call them GNU/Linux, though that's certainly not the only correct description. I use "Ubuntu." That one word is short and descriptive enough most of the time. Ubuntu is based on GNU/Linux, but it's necessary to beat people over the head with it.
Can you, for example, give an example of an operating system that uses Linux and Xorg, but not any GNU tools?
Linux without GNU tools -- how about busybox + uclibc? Done and done.
Xorg without GNU tools -- I was making an assumption based on some very vague mentions in the documentation. The closest I can find are completely alternate X implementations -- at least one of which is proprietary, and runs natively under Windows, therefore I assume it uses no GNU.
Even in this case, it could be called X11/Linux, rather than Xorg/Linux.
I'm not talking about simply being successful, but about one project depending on the other.
Success is a dependency. Otherwise, development dies.
For all operating systems that do depend on both Linux and GNU, I think it makes sense to call them GNU/Linux, though that's certainly not the only correct description. I use "Ubuntu."
I'll agree with you there.
The main difference is, I have no problem shortening to "Linux" either. A kernel is still significant in which software is likely to work -- for instance, any given statically compiled program, GNU or not, could only have the kernel as an external dependency. Even if I'm ultimately using it to refer to a typical collection of GNU, Linux, and other software as a distribution -- for instance, talking about "Linux distributions" -- it's just cumbersome to say "GNU/Linux distributions" instead.
Anyway, I'll stop now. I don't really want to have this argument again. My main point (originally) was that someone posted this "It's GNU/Linux, not Linux" rant, in a context where the term "GNU/Linux" had been used "correctly" anyway.
Don't thank God, thank a doctor!
You still haven't named an operating system that is based on Linux, but nothing from GNU. I'm very curious if such a beast exists. I think it makes a lot of sense to call an operating system based on Linux and GNU "GNU/Linux" and AFAIK, that includes all operating systems based on Linux. If you think it's possible to build a system on Linux, but not GNU, please give an example.
You still haven't named an operating system that is based on Linux, but nothing from GNU. I'm very curious if such a beast exists.
Actually, I did:
Linux kernel + busybox + uclibc.
Maybe you don't have modutils. Fine, build a monolithic kernel, with everything compiled in.
Granted, it's possible this hasn't been put together. It's also possible this wouldn't make a very good operating system, but it would be an operating system.
I think it makes a lot of sense to call an operating system based on Linux and GNU "GNU/Linux"
The problem is, I see no reason GNU should get special status there. You could build a desktop OS based on GNU, Linux, but without X.org, and it would suck. Just like I can build a desktop OS based on Linux, but without GNU, and it sucks. Put them all together, why should it be called GNU/Linux, and not Xorg/GNU/Linux?
If it's a question of dependencies, GNU is as dependent on a kernel as a kernel is dependent on a userspace C library.
Don't thank God, thank a doctor!