Vulnerability in OpenSSH “for two decades” (no, the sky isn’t falling!)

Thanks to Luke Groves of Sophos for his help with this article.
Q. What’s the most widespread remote access protocol – the technology most frequently used to get access to servers that are in another room, office, town, state, country?
Ask any sysadmin…
A. SSH.
SSH is short for Secure Shell, and it’s very widely used not only for logging in to a remote shell (jargon for a command prompt in a terminal window), but also to create secure tunnels (jargon for encrypted network circuits you can use to keep pretty much any network communications safe from prying eyes).
Secure tunnels are an effective way to ensure security for inter-network software updates, file downloads, data backups, system logs and much more.

Q. What’s the most widespread SSH server out there – the actual app used for handling the SSH connections in the first place?
Ask any sysadmin…
A. OpenSSH.
The OpenSSH software came out of the super-security-conscious operating system project OpenBSD, the “free, functional and secure” operating system that boasts on its website that it’s suffered “only two remote holes in the default install, in a heck of a long time!”
Compared to the average Linux distro, or Windows, or macOS, or pretty much any mobile phone you care to mention, that isn’t an idle boast, even if it’s not the sort of claim a traditional marketing department might go for.

What if SSH breaks?

We’ve met sysadmins who live like a metaphorical Damocles, worrying every night that they’ll wake up to news of an SSH remote code execution exploit, or a long-overlooked cryptographic hole that allows anyone to login just about anywhere.
That sort of bug, they say, wouldn’t be a Heartbleed – it would be a Heartattack.
So when we saw headlines today pronouncing an SSH vulnerability “affecting all OpenSSH versions,” we figured we’d better take a look.
In fact, the bug affects all versions since at least 2000, it seems – so we felt a twinge of trepidation that this could be The Big One at last – a collective cryptographic coronary, to put it crudely.
The bad news is that those headlines are true; the good news is that they’re just headlines, and carefully omit the detail that would make it obvious that this isn’t really such a big deal.
Ironically, the vulnerability was just a bug when it was fixed – Polish researchers had pointed it out to the OpenSSH team in mid-July 2018.
The bug was listed as: “delay bailout for invalid authenticating user until after the packet containing the request has been fully parsed.”

(The ok deraadt in the image above is a note from OpenBSD chieftain Theo de Raadt to approve the change.)
It was only after the bug was fixed in the code tree that it turned into a vulnerability.
Security researchers trawling through the recent list of modifications in the code (known in the jargon as diffs, after the program diff that’s used to display the differences between two versions of a file) urged that this change deserved an official vulnerability number…
…because it meant that the old versions of OpenSSH had a user enumeration flaw. (This bug is now officially CVE-2018-15473.)
A user enumeration flaw is where a system will admit to you whether a username is valid without making you login first.
By trying to login to OpenSSH using a deliberately malformed network packet, you’d expect an error message to come back – but, until this code change, OpenSSH would come back slightly sooner if the username was invalid than if you’d used a genuine name.
Technically, that’s not supposed to happen – in fact, for decades, starting long before 2000, there’s been a school of thought that says you should always pop up username/password prompts in as an inseperable pair, and never tell the user which one was wrong in the event of a failed login.
You’re supposed to say “invalid username and/or password”, or just “bad luck, start again from the top”, treating both the username and the password as though they’re secret data.

Should usernames be secret any more?

We accept that this OpenSSH change was a code improvement, and we don’t see any routine reason to give out information about usernames if it’s not necessary.
But we’re not so sure about the ongoing wisdom of treating usernames as the precious nuggets of data they used to be.
Back when you couldn’t choose your own login and you were issued with machine-generated usernames like duck21994, there was at least something unpredictable about your username.
In an era where 8 lower case letters constituted a super-duper-secure password, and users were happy to pick one password and use it everywhere, it probably made sense to treat those five weird digits at the end of your username as another security hurdle for crooks to vault over.
Those days, however, are over.
Many mainstream sites are changing their login workflow so that you start with your username, and only if it exists in the system do you get asked for your password.
Likewise, systems with two passwords – a static one and a two-factor authentication (2FA) code – often confirm your username and then your password before asking for a 2FA code at all.
In any case, your username often isn’t anywhere near a secret, because it’s your email address, and your email address – especially your business one – is probably constructed in a predictable way.
After all, it’s a bit silly to have an email address at which you want people to be able to contact you and then make it easy to get wrong.

What to do?

Make no mistake – the less information about your system that you allow out at the authentication stage, the better.
So this is definitely a code fix worth making, and the change is both purposeful and desirable.
If you’re worried, you can easily apply the patch yourself and rebuild your own copies of OpenSSH.
But don’t get too hung up on usernames-as-secrets.
That’s a bit like assuming that the lock on your door automatically becomes harder to pick if you obscure the manufacturer’s name, even though the lock itself and its internals are exactly the same.
(If the crook already has what he thinks is the key, he’ll just try it anyway – if the lock opens, he won’t care whether it’s a cylinder lock, a lever lock or some other more esoteric sort.)
Likewise, if your SSH connections depend on the secrecy of your usernames for their security, we think you’re doing something wrong and ought to change it.