new SSH exploit is absolutely wild

one of the world's most widely used pieces of software op SSH has recently been found to have a remote code execution vulnerability in it anybody can run remote code as root on a server that runs op ssh in this video we're talking about regression a bug found about the qual threat Research Unit that allows people to run code on a server that runs op sshd which is most servers on the internet in this video we'll do a technical breakdown of how the bug Works discuss how you can protect yourself from it and why at the end of the day it's not as scary as people are making it out to be now if you're new here hi this is L LEL learning a channel where I make videos about software security and cyber security and all kinds of other fun programming stuff so if you like that or just want to hang out hit that sub button I really appreciate it if you don't know what SSH is literally it stands for secure shell so when people want to manage a server that they own or maybe log back into their house when they're out abroad they use a protocol called SSH ssh gives them as a name implies a secure shell on the remote system now what's so secure about it if there are bugs what SSH is supposed to do is do two primary things one authentication so when I log in to my server like lowlevel Academy for example I have to say that I am the person that I say I am you can do this in two ways one with a password I I say the magic catchphrase that allows me into the system or I do a key exchange where there's a known public key on the remote end I have the private key it does a signing exchange and then from there I am able to get into the server also does confidentiality so if somebody is sitting in the middle and listening to me do this key exchange and manage my server they can't see all my secrets because the code is encrypted so SSH is a very well-known tool and op SSH is just a open- source package on the internet that implements that standard that sounds all very well and good that sounds nice and secure so what about that could be vulnerable to attack just like any other piece of code on the internet code is code and people can make mistakes when they write the code and as a result the software can have memory corruption or other kinds of vulnerabilities in it that hackers can take advantage of and use for malicious purposes right so op sshd or sshd which is the software end the D standing standing for Damon recently has been found to have a critical vulnerability from what is known as a race condition so if you're new to this community and don't know what a race condition is effectively when you have software that runs a synchronously or there are two things that can happen at the same time if you have critical areas of data like for example you're trying to update a counter if two threads are trying to update that counter if there isn't a lock on who has control of that data at one time the code is naturally vulnerable to a race condition where the outcome of the software is purely a race of who gets there first there is no deterministic way to say what happens now this bug is extremely complex we're not going to go into the entire thing this literally would take like 2 hours to read the entire article I'm going to do the wave tops here and explain to you what's going on for people that may have a hard time reading this paper because I know for me even as someone who's been in this community for a long time this is an extremely thick article that I'm hoping that you guys get through easier the vulnerable versions to this bug of open H our open SSH is before 4.4 which is literally from like 20 years ago 2006 so if you're using open SSH 4.4 re-evaluate your life um the one of the bugs the signal Handler race condition was actually patched out at at 2006 it was gone up until version 8.5 in open SSH and then a commit into the open SSH project accidentally reintroduced a vulnerability in the signal Handler that reintroduces race condition now the bug itself stems from a really interesting problem in the world of C programming so what happens here is if you try to log into the server and you take longer than login grace Time seconds which is a time that you specify in the config of open sshd the Sig alarm will get thrown into the open sshd Damon and what Sig alarm acts as in terms of programming or synchronous programming is an interrupt so no matter where in your code the current program counter is the Sig alarm will trigger what is called an alarm Handler or an interrupt Handler or a signal Handler now the signal Handler is called asynchronously so even if you're not doing threaded coding if you're not doing an asynchronous application the nature of calling a signal is inherently asynchronous because you could be in the middle of a line of code and then boom the signal goes off and you have to go handle that signal so the signal Handler is called asynchronously but if you call inside the signal Handler functions that are not async signal safe or thread safe for example CIS log this can have a weird inter action with the current memory state of the program and so what they actually found is that if you are on one of the vulnerable versions so again pre 4.4 after 8.5 when you try to log into the server if you take longer than 120 seconds when it throws the Sig alarm you're able to use that Sig alarm to corrupt the Heap and exploit a heap memory corruption to get code execution on the server now how do they do that let's find out some more so the nature of the vulnerability is if they're able to time the Sig alarm to be thrown at a specific place when another part of the program is running the Malik call they're able to use the fact that they're able to arbitrarily stop the code and do something else to take control of the structure of the Heap in a way that gives them an advantage so what the paper says here and again I'm not going to read the whole thing I'm literally just showing you guys like the the wave tops here if this code path is interrupted by Sig alarm after line 4327 but before line 4339 so effectively what they're saying is if they can interrupt it somewhere in here what they're able to do is create a state where the Heap is in a different state internally than the user has access to the chunk so by calling Malik they're able to get a very very large chunk that would in the Heap technically not give them access to the rest of the further chunks the way they have to do this is by calling this set head function that effectively moves the head of the Heap further because they've allocated the back end of it right but if they can get access to this chunk before the head of the Heap is updated they effectively create what is known as an overlapping chunk and here in the paper they do a pretty good job of overlapping it so by interrupting the Malik call what they're able to do is they get access to this chunk but what should actually be happening is this so whatever is living in this hole in the Heap they're able to overwrite right because they get access via Malo to this artificially enlarged remainder chunk because they interrupted Malik before it was able to clean up the Heap and then what they do here is in this small hole they have a file structure so the file structure in C is a structure that has a bunch of function calls that you're able to call when you do things to that file so for example F read unlocked iow file underflow there's a bunch of function calls in a vtable structure that live in that file structure so if they're able to interrupt the Malik call with Sig alarm use that to get access to all this memory and put previously a file structure in this whole by overwriting the data in that buffer that they shouldn't normally have access to they can overwrite the function pointers that live at that location and point it to code that they've put elsewhere in the program truly an amazing idea if they're able to pull this off now the nature of how they do this is actually pretty interesting what they do is they do a series of what are called Heap grooming or Heap spraying where by sending and receiving a series of key exchanges a digital signing algorithm key exchange they're able to control the layout out of the Heap to set it up in this deterministic way the way they do this is they give the SSH server a series of correctly and incorrectly formed certificates that form the Heap into a particular fashion that allows them to do this exploit that when triggered by the Sig alarm gives them this overflow condition now once they have the Overflow they proven they can overwrite the function pointers in the file V table and use that to point a code to call the code and give them effectively remote code execution on the far server as rot which is crazy but here is why this bug while impressive is not super scary again the world of exploitation is really interesting and the bugs that are the scariest are when they are truly remote unauthenticated and can kind of just happen you can close your eyes you don't have to know a bunch about the remote server and you can just go hit it and get in there because what they're doing is they have to go into the server they have to do multiple connections that all wait within the 1202 window and not all of them are going to the race they say effectively it takes up to 10,000 tries to win that race where they're able to hit the Sig arm just at the right point that triggers that Heap corruption it takes roughly three to four average hours on average to win the race condition and then 6 to8 hours to actually obtain a remote root shell because of aslr so aslr if you don't know what that is that is a dress space layout randomization in binary exploitation what computer designers and people who write operating systems have figured out is that if the hacker doesn't know where all the code is if they don't know where their code is if they don't know where the program is if the addresses have been randomized it is much harder to exploit the system because without a leak you don't know where to go you don't know what to set PC to to make your bad code happen so because in this condition they don't have a leak they have to effectively guess what the address layout of the system is and because right now there are only two locations in the 32-bit implementation of GBC it can take either 3 to 4 hours or 6 to8 hours if either one of those locations is guessed incorrectly so while this is a crazy exploit at this current time it still takes anywhere from 3 to 8 hours to get a single execution also as you're probably well aware the majority of the world is currently in 64-bit land right so you know architectures of CPU started as 32-bit not started but like they they were 32-bit for a long time uh and then 64-bit CPUs came out and now they're kind of the Baseline for servers because the majority of code on 64-bit servers is a SLR the address space is literally multiple orders of magnitude larger it is currently not known if you can even exploit this on a 64-bit server and with aslr how long would it take it could take on the order of days to weeks exploit this bug so what can you do if you have open SSH connected to the internet and you want to not be vulnerable to this well step one get your SSH off of the internet I know the whole point is like it provides authentication so if you can hit it you need to have a key to get through it um but the problem is open SSH is code like anything else code can have vulnerabilities and all it takes is one good SSH OD day like this to get your entire network if not the world compromised so I recommend first of all don't expose SSH to the internet step one uh step two you can go and update right now there is a patch out for this that fixes the vulnerability so that's really really important but also two you can set login Grace time to zero which effectively says it will immediately close the connection if it doesn't authenticate the first time which gets rid of the opportunity for this raise condition to happen so I want to give my hats my shout out to the qualities research team the the the paper itself go give it a read it is extremely long and dense and it takes a while to read it took me a long time to even comprehend it highly recommend it but this just goes to show like even for services that are known to be secure op SSH vpns things that you think give you a sense of security they do but at the end of the day they're just code code can have bugs in it and if you don't know what you're code is doing or if you know there's a one major vulnerability in these things things start to kind of fall apart we're very lucky that this was a race condition that takes hours to execute and not this quick like oh boom I'm in because this would have been detrimental to the world right uh so yeah if you like this video do me a favor hit like hit subscribe and then go check out my video on the XZ back door it really is crazy how much of the world depends on open source software and we're only a couple mistakes away from things like this happening more and more often we'll see you there

Channel: Low Level Learning

Views: 296,011

Keywords: apple, apple m1, m1 bug, cpu bug, hackers, vulnerability, cache

Id: Rj3sTAMYNQk

Length: 11min 58sec (718 seconds)

Published: Wed Jul 03 2024