Placeholder Image

Subtitles section Play video

  • There was an exploit found forthat works on Linux

  • and because of the way its works, you'll see when we take it apart, it'll probably work on other Unixes as well

  • that if you type this one command in,

  • then what you end up doing is getting full root control of the machine just by typing in this one command.

  • I should say that it doesn't work on all Linux installations, it has to be set up in the right way,

  • but a lot of the major ones are set up like that.

  • So yeah, if you can remember the command or can find it on Twitter,

  • you can type this in and get full access to control the machine.

  • I think the best place to start is if I show it. So let me just start up the laptop.

  • I've got a Linux virtual machine. It's running CentOS 7.

  • I've just literally gone and downloaded this off the CentOS website and we can now see what's going.

  • You could type it in from inside the graphical user interface.

  • I've found it works slightly better if you switch to a command line.

  • So I've logged in here to the machine and I'm just sitting at the command line in the standard place,

  • and if I try and, say, change the password of root to something else, it'll say:

  • "Only root can specify a user name"; I'm not logged in with any sort of special permissions,

  • but if I type in this command that's been tweeted and so on:

  • cd /etc; Xorg -fp "root [GARBLED SPEECH] " -logfile shadow :1; su

  • Right, so if we hit this...

  • Boom! It goes off and sets a few things up, the screen goes black,

  • but if I switch back to my other one, if I type su again...

  • It's logged me in as root, and of course, I can now change the password on root without any problems.

  • How does this actually work?

  • Well let's sort of break down this command, because actually it's made of three commands;

  • the semi-colons in the thing that we're running actually just say,

  • "execute this command, followed by this one, followed by this one."

  • So the first part of it, cd /etc. Now anyone who's used any Linux will know what that does.

  • It moves into the directory /etc, and if we look in there, there's a whole load of files in there,

  • and that's a standard Unix directory.

  • Inside there, you've got the configuration files that tell you how to mount the filesystems,

  • how to start up the individual programs and things.

  • Also what you have in there are the password file and something called the shadow password file,

  • which contain details of user's usernames and passwords, what their user identifiers are,

  • what their home directory is, and so on.

  • So you've got those files in there.

  • So that's the first command.

  • Let's have a look at the last command next, so we'll come back to the middle one.

  • So the last command is su. The su command basically says, "go superuser."

  • So the su command will log you in, in the same session, as a superuseras root, basically.

  • Now, normally, that would ask you for a password,

  • but as we saw here, after you've done this exploit, it doesn't ask you for a password.

  • So what's going on? What's the middle one?

  • So we've got Xorg, and then we call it with various commands.

  • So we have -fp, and then we give it root: and then various bits and pieces that I'm not going to write out,

  • and then we have -logfile shadow :1.

  • We're running the program Xorg. Xorg is the program that draws everything on the screen,

  • handles the graphics card and things under Unix-/Linux-type machines.

  • Often this will run as root so that it can control the hardware.

  • I think there are ways you can have it not run as root, but by default, often it will be running as root.

  • Now, sometimes, you need to be able to start that as a non-root user,

  • so there's a special way it's set up that we'll look at in a minute

  • which enables us to run it as a normal user but still let that program have access as root.

  • Normally, doing this on its own would not let us get root, because we don't know the password, normally,

  • but after we've executed this command, this Xorg command, then we can get root.

  • So what's going on here? Well, two things we need to see what's happening on.

  • First of allcertainly on this version of Linux, not necessarily on all of them

  • this program is set up with what's called the "SUID bit", or the "set UID bit" set on it.

  • So if we actually have a look at the program,

  • which is in /usr/bin/Xorg, we can see that when we look at the program,

  • it has this s-flag on it in the list of attributes that it's got there.

  • It's read/write and it's got the s-flag. This means "set UID".

  • All that means is that when that program is run,

  • it runs it as the user ID that the program is owned by on the disk,

  • rather than by the current-user-that-started-it's ID.

  • So this program then will run as root, and normally you'd want that to happen.

  • That in itself isn't an exploit, that's what you want to happen.

  • There's lots of programs that work like that, you want that to do it,

  • but it means that, because that program is running as root, because of the way it's set up,

  • it has access to files that the normal user wouldn't have access to.

  • For example, the ones in /etc that set up the password file.

  • If we break this command down a bit further, we've got two parts of this command.

  • We'll come back to this one in a second, but the first one is relatively simple.

  • It's just setting up the log file to be output to the file shadow,

  • which, of course, will be in the directory /etc because we've already moved in to that directory.

  • So all that's telling it is, "when you write a log file telling me what's happening,"

  • so you can track down any configuration errors if you want to see what's— if things aren't working properly,

  • it's gonna be called shadow in the current directory.

  • Now, /etc/shadow is one of the files which stores the password data for Linux and other Unixes.

  • There's actually twooriginally, it was /etc/passwd, and that stored things, and that was world-readable,

  • so you could actually read the hashed versions of people's passwords

  • watch Mike's video on what password hashing is up here.

  • So that wasn't a good idea.

  • So what they did is they sort of kept the password file, took the hashes out of it,

  • and put the hashes in a copy of the password file called shadow,

  • which "shadowed" the password files, hence the name.

  • So that was only accessed by root, which meant that when you needed to check a password,

  • the root stuff could access it and do that, and so on.

  • So we're overwriting that file, shadow, with the log file. So, okay, well, why does that help us?

  • Well, we get to the first part of the command, which is this one here, which is setting the font path.

  • So we're setting the font pathwhich is what the -fp flag does

  • to have this string, "root:, blah, blah, blah". So why does setting the font path,

  • coupled with settinglogging into the shadow file, enable us to grab root access?

  • Well, let's have a look at the log file that was created when we ran the exploit.

  • What we see is all the X logging information as it's started up,

  • telling you what version it is, what operating system we're running on, build IDs,

  • various information about what's happening and so on.

  • So then we get down to this line here at the bottom which is telling us what we've set the font path to,

  • and it happily outputs every single line that we set the font path to.

  • Now, what have we set the font path to? We've set it to the "root:, blah, blah, blah", and so on,

  • and the interesting thing about that is

  • One: it's been copied out on a line on its own in the new shadow file

  • okay, some spaces at the beginning, but that's not a problem

  • but the format of that line we've written is the exact format required

  • to tell the operating system the password for root and all its details,

  • but in this case, the password would normally be between the first two colons, and that's blank;

  • there's no hash there.

  • So when you run su, the programthe operating system looks at the shadow password file,

  • says, "there's no password there! I'll let you log in,"

  • and so you've got this wonderfully clever, almost old-school exploit. There's quite a few like this.

  • There was one in Emacs back in the '80s, which Clifford Stoll documented in his book, The Cuckoo's Egg,

  • and various others where you could do similar things.

  • You could have programs that had access to write as root,

  • could copy files into the right place and then give you root access when perhaps you weren't meant to have it,

  • and exactly the same thing has happened here.

  • We're allowed to run Xorg, because we want to display things on the screen,

  • and sometimes you'll have the machine set up so the users start it when they need it,

  • rather than it starting up in that environment.

  • So running it would be okay, but having the "set UID" bit set is what you need in those cases,

  • but coupled with the fact that we can write out arbitrary data in the font path into the file,

  • coupled with the fact that we can then log that into the shadow file, which we normally wouldn't have access to,

  • we can change the password for root, or any other user we'd want to,

  • and then log in as that user without any issue.

  • Now, of course, the problem is that as soon as you do this,

  • you've overwritten the shadow password file with, basically, junk and lines,

  • so you'd probably want to be able to revert things back.

  • Whether you can do that is an interesting question.

  • Hopefully, it's made a backup of the file; shadow.old looks like it might be a thing.

  • So yeah, there's a backup that we could then move back into place and hide it if we wanted to,

  • but we've now managed to get root access. Once we've got that, we can set up our own user, raise our privileges,

  • and then we've got full control of the machine.

  • The person that discovered it probably sort of thought,

  • "well, actually, okay, I can log into different places, I can write the log file into various different places,"

  • and you think, "well, okay, if I can write the log file into different places,

  • "can I use that as a sort of way to get the data I want into the right place?"

  • So that's what you try and do, you say, "I can write this file here,"

  • but, of course, as we saw, the format is very different,

  • you've got all those square brackets at the beginning of lines,

  • and so you couldn't just use it to, say, overwrite a program file.

  • So, some of the other ones we've looked at,

  • and they were just to overwrite a standard program file and get an exploit that way,

  • and so you look at what options you've got,

  • and you think, "okay, well this font path thing will print out the list of all the font paths,

  • "so if you've got more than one font path, you'd see them all on separate lines, one after the other.

  • "Okay, I can use that, because you can then write out a font path which isn't a path,

  • "but is actually the data you need for the shadow password file,"

  • and suddenly, you've got your exploit that works.

  • Now the reason this actually happened, the reason this has been there

  • and apparently it's been in the code for two years before someone discovered it

  • there used to be a check on the log file command and the module path command

  • there's another slight way you can exploit this as well

  • that would check whether you were running with elevated privileges, i.e. as root.

  • If you were, it wouldn't let you use the -logfile command.

  • It also wouldn't let you change the module path, which is another slight way you can exploit this as well.

  • You could put some arbitrary code and get that into the system as well,

  • and when they were refactoring the code, then theyfor some reason,

  • that bit of the check didn't get put back in, and so on.

  • So the fix would be dead simple, you just put that bit of code back in, so I think patches will be available,

  • but the quickest way to fix this isif you dois to remove the "set UID" bit from Xorg.