OPERATING SYSTEMSOS Linux

new SSH exploit is absolutely wild

OpenSSH has been rocked by a new RCE vulnerability. But, it may not be as scary as people are making it out to be. Find out why in this video.

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

🏫 COURSES 🏫 Learn to code in C at https://lowlevel.academy

🛒 GREAT BOOKS FOR THE LOWEST LEVEL🛒
Blue Fox: Arm Assembly Internals and Reverse Engineering: https://amzn.to/4394t87
Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation : https://amzn.to/3C1z4sk
Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software : https://amzn.to/3C1daFy
The Ghidra Book: The Definitive Guide: https://amzn.to/3WC2Vkg

🔥 SOCIALS 🔥
Come hang out at https://lowlevel.tv

source

by Low Level Learning

linux foundation

36 thoughts on “new SSH exploit is absolutely wild

  • But if this really boils down to signal + malloc, isn't a lot of software besides OpenSSH affected? And does this mean that signals are useless for everything except maybe doing some cleanup and logging before shutting the process down?

    I really hope I misunderstood something.

  • Basically while the OpenSSH "regreSSHion" vulnerability sounds concerning, it's not a major threat. Exploitation is complex and requires hours of attempts under specific conditions, making widespread attacks unlikely. Many systems already have mitigations like brute-force detection in place, and the scope is limited to certain OpenSSH versions. Patch your systems
    …no need to panic.

  • anyway… who uses 32 bit nowadays?
    are there any researchs on amd64?
    And who has his ssh ports open to the wild without any wireguard connection or something else to protect it? Takes a long time on a amd64 with a non stable internet connection…
    the attack vector is there but with minimum security most likely avoidable

  • Would you be able to do a video explaining ASLR? I understand the basic concept, but don't understand how it doesn't cause code to break.

  • Everyone keeps showing that SSH has one of the easiest and most insanely powerful mechanics to exploit, that just won't stop getting hammered with a high success rate over time

    You don't have a use case for it, it doesn't do anything for a daily driver

    But its name includes the word "secure", and it's been labelled as safe; so you MUST install SSH onto everything NOW — or you're just crazy, and have wrong opinions

  • Why can you even "send" code to the openssh process? It should first check the credentials? Am i missing something?

  • More evidence of how social media nowadays over blows everything for content. This hack blows, its old and it would never work on any decently/badly defended infrastructure. The end.

  • Setting LoginGraceTime to zero does not log you out after 1 failed attempt. It appears to remove a login time limit completely. While it's good to always be using the latest releases, if you are set up to disconnect after three failed attempts, is this problem moot, since timing is not involved?

  • I dislike titles like this. This is not "new" in any meaningful way – its like finding a "new" exploit in Win7 or vista – clickbaiting to make SSH seem vulnerable when the version is eons old is dishonest.

  • Noob here. What does it mean "Step 1: Get your SSH off the internet"
    How then am I supposed to connect to a remote server? Or was that meant generally to keep the SSH port closed if you are not using it?

  • "Don't expose ssh to the internet"… ok, so what is the better option for secure remote access to servers? What's the magical software that is more secure and has a smaller attack surface? Or are you suggesting computers simply can't be managed remotely? Way to undermine your whole video with wildly dumb advice at the end.

    Update your servers. Disable ssh password authentication. Maybe configure bans after a number of failed attempts. Definitely don't just throw up your hands and give up on secure remote access.

  • This can be mitigated with a trivial change to a config file
    It takes concerted effort over time on 32-bit
    It probably isn't possible on 64-bit due to planning to prevent these things
    It's been fixed and an update has been released
    It's never been proven to exist in the wild.

    So, not losing any sleep AT ALL over this one. Academically fun, but not something that rising to any concern whatsoever.

  • "SSH is a joke, I know the guy who made the backdoor" – Programmers are also human, 2024

  • yo, i'm no code guy but enjoy stuff like this from u, primeagen, dave's garage n the likes, i appreciate the logic n informative value u guys bring

  • For critical projects like this (at the very least), there should be a process built into the commit procedure that checks for various types of vulnerabilities, and especially for specific vulnerabilities that were previously found and patched.

  • I'm gonna go out on a limb and guess that some of the people who work on making that software work for the NSA under the table. Hiring insiders like that is part of the fed's m.o. for purposes like this.

  • I have disabled ssh service & uninstalled openssh in linux distro. Am I safe?

  • I have disabled ssh service & uninstalled openssh in linux distro. Am I safe?

  • I sent a similar video to someone at my office. He's like: updating the libraries now. We then talked about the importance of testing known weak points in code (since it was a regression). Gotta keep an eye on known previous points of failure.

  • Your explaination for laypersons is very very good. I'm not a programmer or security expert by any means, but found it was easy to comprehend thanks to your summary

Comments are closed.