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 superuser—as 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 all—certainly 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 two—originally, 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 path— which is what the -fp flag does—

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

coupled with setting— logging 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 program— the 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 they— for 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 is—if you do— is to remove the "set UID" bit from Xorg.