SSH stands for SECURE SHell

SSH stands for SECURE SHell

Security Published on 3 mins Last updated

A big security alert has just been announced: CVE-2024-6387.

Dubbed regreSSHion, it was discovered in OpenSSH's server (sshd). What action do you need to take?

Fear sells

If you came across my previous blog regarding security scans, you will know that I’m rather sceptical about whether they really justify the time and effort spent. At the end of the day, fearmongering and scare tactics are always good click-bait and help sell products. So you will quickly find that most alarmist articles are either run by or affiliated with companies selling software that sells security scans.

And, in the same vein, I'm a little skeptical about this particular vulnerability. Why? Well, several websites have called it “critical”, “significant” or “high-severity”, while at the same time using words like “could” and “potentially”.

So what's the truth?

Editor's note: Just to be clear the regreSSHion bug is a serious vulnerability that should definitely be patched in any potentially affected system.

What is CVE-2024-6387?

The devil is in the detail with this one.

If you read the document issued by Qualys regarding their disclosure, you will quickly discover a few things...

regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

Only glibc-based systems are affected. Yes they are the majority, but if you use any flavour of BSD, or perhaps a musl-based Linux (i.e. Alpine Linux), you are safe.

In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR).

This proves that the vulnerability isn’t easily exploitable. It requires time and knowledge.

we have started to work on an amd64 exploit, which is much harder because of the stronger ASLR.

It’s 2024, so the chances of you running a 32-bit operating system are rather low. This vulnerability is already difficult to exploit and it would be even more difficult on 64-bit systems.

Don’t get me wrong. I’m not saying that it’s all impossible, but there's no need to panic just yet.

What action do I need to take?

Instead of checking your servers in a frenzy for a potentially affected version of the sshd, you should instead invest time in making sure that your network is secure.

Firstly, do you require port 22 (or perhaps 2222, security by obscurity 😀) to be facing the public internet?

Secondly, your company should use a VPN or other secure tunnel for the admins to connect to your internal network.

Thirdly, use your firewall. You most likely know the IP addresses of the people who should access your machines via SSH. Just block anyone who isn’t on the approved list.

My prediction?

Extensive exploitation appears unlikely.

Distribution-specific conditions (like ASLR) and glibc-version-specific struct layouts render the vulnerability unsuitable for widespread exploitation. An attacker has to know which Linux distribution they are targeting to create a functional exploit.

On top of all that (as mentioned before) it requires several hours of sustained effort. If someone is hammering your servers for an extended period of time, you ought to notice! That’s why you pay for your state-of-the-art firewall and monitoring tools after all, isn’t it?

To sum up...

Security is important, but you shouldn’t be losing sleep over every single newly announced CVE. Ensuring your firewalls and other safeguarding tools are optimized should keep you covered and give you justifiable peace of mind.

Having said that, we strongly recommend that you need to update your load balancers to v8.11.3 to fix the regreSSHion vulnerability (CVE-2024-6387).

Want the truth?

Speak to one of our ADC technical experts