Fast Reset, Trusted Boot and the security of /sbin/reboot

In OpenPOWER land, we’ve been doing some work on Secure and Trusted Boot while at the same time doing some work on what we call fast-reset (or fast-reboot, depending on exactly what mood someone was in at any particular time…. we should start being a bit more consistent).

The basic idea for fast-reset is that when the OS calls OPAL reboot, we gather all the threads in the system using a combination of patching the reset vector and soft-resetting them, then cleanup a few bits of hardware (we do re-probe PCIe for example), and reload & restart the bootloader (petitboot).

What this means is that typing “reboot” on the command line goes from a ~90-120+ second affair (through firmware to petitboot, linux distros still take ages to shut themselves down) down to about a 20 second affair (to petitboot).

If you’re running a (very) recent skiboot, you can enable it with a special hidden NVRAM configuration option (although we’ll likely enable it by default pretty soon, it’s proving remarkably solid). If you want to know what that NVRAM option is… Use the source, Luke! (or git history, but I’ve yet to see a neat Star Wars reference referring to git commit logs).

So, there’s nothing like a demo. Here’s a demo with Ubuntu running off an NVMe drive on an IBM S822LC for HPC (otherwise known as Minsky or Garrison) which was running the HTX hardware exerciser, through fast-reboot back into Petitboot and then booting into Ubuntu and auto-starting the exerciser (HTX) again.

Apart from being stupidly quick when compared to a full IPL (Initial Program Load – i.e. boot), since we’re not rebooting out of band, we have no way to reset the TPM, so if you’re measuring boot, each subsequent fast-reset will result in a different set of measurements.

This may be slightly confusing, but it’s not really a problem. You see, if a machine is compromised, there’s nothing stopping me replacing /sbin/reboot with something that just prints things to the console that look like your machine rebooted but in fact left my rootkit running. Indeed, fast-reset and a full IPL should measure different values in the TPM.

It also means that if you ever want to re-establish trust in your OS, never do a reboot from the host – always reboot out of band (e.g. from a BMC). This, of course, means you’re trusting your BMC to not be compromised, which I wouldn’t necessarily do if you suspect your host has been.

Friendly exploits

If you happen to be friends with me on Facebook you will have seen a bunch of rather strange updates from me last night. This all started with a tweet (that was also sent to Facebook) by a friend who joked about doing something with the <MARQUEE> tag (see http://www.angelfire.com/super/badwebs/ for an example of it and similar things). I saw the joke, as I was reading it through Gwibber or the Facebook website. However…. Leah saw text scrolling over the screen… just like the <MARQUEE> tag actually did.

She was looking at it on her iPad using an app called Friendly.

So I immediately posted a status update: “<script lang=”javascript”>alert(“pwned”);</script>”. This is a nice standard little test to see if you’ve managed to inject code into a web site. If this pops up a dialog box, you’ve made it.

It didn’t work. It didn’t display anything… as if it was just not running the script tag. Disappointing. I soooo wanted it to break here.

I did manage to do all sorts of other things in the Live Feed view though. I could use just about any other HTML tag… including forms. I couldn’t get a HTTP request to my server out of a HTML form in the Live Feed view… but once we did manage to crash Friendly (enough that it had to be force quit on the iPad).

I posted a photo of me holding up the iPad to my laptop web cam to show off the basics:

And then one of what happened when I tried a HTML form (this wasn’t reproducible though… so kind of disappointing):

What we did notice however was that HTML tags were parsed in comments on images too…. which made me wonder… It’s pretty easy to make a HTML form button that will do something… so I posted the same image again with a button that would say “Next” but would take you to a web page on one of my servers instead. It worked! I got a HTTP request! Neat! I could then present a HTML page that looked legit and do the standard things that one does to steal off you.

But I wonder if scripts would work…. so I posted:

Photos are proving more exploitable.... <script lang="javascript">alert("pwned");</script>

and then clicked on the image on the iPad……

Gotcha!

I could from here do anything I wanted.

Next… I should probably report this to the developers…. or steal from my friends and make them post things to facebook implying improper relationships and general things that would get you fired.

I went with the former… but the latter would have been fairly easy as the Facebook page for the app nicely tells me which of my friends use it. I could even target my attack!

So I sent a warning message to friends (the 18 of them who use the Friendly app), sent a “contact the developer” message to the developers, sent out a warning on Twitter and went to bed.

Got an email overnight back from the developer: “We just pushed a server update that solves this issue.”

Now… in my tcpdump while trying some of the earlier things I was just seeing https requests to facebook API servers from the iPad, but I don’t thing I looked too closely at images. I have no idea if they’ve actually fixed the holes and I don’t have an iPad to test it on. If you do, go try it.