secret backdoor found in open source software (xz situation breakdown)

a back door has been found within lib lzma a package within the XZ library that does a lot of the compression on the internet now the reason why this is such a big deal is that the XZ library in this version of lib lzma is used in open SSH you know the package that allows you to have an SSH server that gives people access to your server provided they have credentials by putting a back door in the compression Library it effectively gives that person unfettered access provided they speak the right sequence of words into the back door this story is still developing we're still learning a lot as we go but in this video I want to talk about why this is such a big deal how the person who found it discovered this back door and what this means for the future of contributions to open source projects let's dive right into it also if you're new here hi this is a l learning a channel where I talk about programming cyber security and a bunch of other stuff if you like that or just want to hang out with me hit that sub button really appreciate it so here we are in one of the lists on OSS Security open source software security which is a big thread where people can submit requests and submit comments about open- Source projects as it applies to the security of systems now this list here is by Andre frun I'm probably going to butcher your name dude I'm sorry um he's not a security researcher he's not a malware RSE engineer he's just a guy and as we'll see in his list the reason why he Dove down this rabbit hole is because he noticed a few odd symptoms around lib lzma basically he found that his logins to his sh server were taking a lot longer than usual took 10 times the amount of time it would take for a login to pass and also a ton of Val grind errors if you don't know Val grind is a tool that allows you to do uh software validation to make sure that your project doesn't have any memory leaks and they found that lib lzma in lib osss security began to fail Val grind checks which is pretty interesting he found that the Upstream XZ repository and the XC tarballs have been back doored in this article he talks about exactly what he found now with the craziest part about this is that it's an backdoor and open- Source software now how do you backd door open source software the whole idea being that it's open source everyone can scan through and read the source code and the the way this actually happened is really really interesting and it even calls out here the line in this commit the back door is not in the Upstream source code that builds to host nor is it used by XC in git meaning that the actual code itself for the back door is not inv verion control anywhere what is inversion control is a series of opiscuipt code to test files and they put the first part of their back door into an XZ compressed binary because if you run strings on that if you're looking for evil stuff you're not going to see that and the irony of committing a back door in XZ in an XZ compressed library is insane to me but if you decompress this XZ tarball or this XZ blob and you pump it into bin bash you could run it but what it ends up being is this file that takes another file in the test directory a second injected back door called good large compressed lcma it does some stuff where it cuts certain parts on and off of that binary it decompresses that and pumps that into bsh now we can see that the end result of all of this ends up being with they attached to this list which is injected txt we can go ahead and open that up and what injected txt actually ends up being is a hook into the build process so again we've taken two seemingly benign XZ files which are in the test directory so maybe they're just binary files used to do some tests you know nothing too crazy and it ends up appending this piece of data to the build process of the pro the problem right and and you know that's not so crazy like you want to maybe change up your build process when you're doing certain tests at this point you would never have noticed this because it's all it's all been off fiscated but what's really really crazy is the author then injected this new CRC 64 binary object now this is where it begins to get pretty wild because in the commits the author claims that they made improvements to the CRC 64 algorithm please here you go here are my improvements here are my tests don't worry about it inside the LI lzma binary object is where the final back door is and by injecting this lib lzma crc32 fast into the build process of lib lzma their back door has now been installed without you even realizing it and so this person who again is not a security researcher and not a reverse engineer began to go on and inspect that binary object I am currently in the process of reverse engineering it I wanted to get this video out before I did that I want to talk about the current state of things also there's a link in this list where you can go download the binary object yourself again it is malicious it is a back door so be careful when you try to run it or do things don't don't be too crazy just running this binary um a willy-nilly but let me read what the guy says that he found the back door initially intercepts execution by replacing the initial function resolvers in crc32 resolve and CRC 64 resolve with different code which calls get CPU ID interesting which is a function that's injected into the code which basically would just be static inline functions um and in 561 the backd door version it was obsc further where they removed symbol names now this should have been a red flag completely because to have symbol names removed in a library object file is like complete heresy right the whole point of a shared object is to expose all of the symbols in the binary so that you can link them against the rest of the program especially in the intermediate compilation process of building a library now the back door installs an audit hook into the dynamic Linker now if you're not familiar with that the dynamic Linker is a piece of code in Linux that when you run a program for example like op sshd there's a binary that has to go around and search for all the libraries your program says that it depends on now if you're a malicious piece of code you actually can hook the Linker meaning replace code in the Linker to make the Linker do other things so what you can see here is the Linker overwrites the code that represents RSA public key decrypt now when you're doing SSH authentication the major encryption scheme that you're going to use is RSA an asymmetric encryption scheme where you can exchange a public key and a private key to encrypt a symmetric key when called for that symbol when called being when the linkers called for that symbol the back door changes the value of the address of RS say public he decrypt to point to its own code the PLT is the place where the function is calling another external function when you call an external function that has not been resolved yet you call the Linker the Linker goes out finds that address and puts it into your Elf this back door hooked the Linker so that when RSA public decrypt comes back with an address it says uh-uh nope my address is actually over here and points to its own backd door code and then once that back door is ran it points back into lib crypto to probably check to see if the input matches some public key that the backd door owner owns completely insane they built a back door into the build process of lib mzma that hooks the dynamic Linker that then will Chell RSA public decrypt nope you're not RSA public decrypt you're my code and will then run a custom backo process truly amazing people are still currently running through the malware RSE engineering to figure out what the functionality of that custom code is I think it's literally just going to have a back door public key in there I'm currently reverse engineering it right now if you want to see me do some of that stuff go follow me on Twitch put the link here and uh yeah guys thanks for watching I appreciate it this this is truly this has been a crazy week between the Apple bug the Linux pesque and this I I don't know what we're what we're in store for uh so if you're interested the cve is noted this this cve here I'm putting all the links to this stuff in the description below go check it out and uh I guess we'll see you in the next one yeah take care

Channel: Low Level Learning

Views: 430,039

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

Id: jqjtNDtbDNI

Length: 8min 27sec (507 seconds)

Published: Fri Mar 29 2024