Safe Computing: No Rebooting, Please

I recently had an interesting discussion with Michal Zalewski over at Icamtuf’s blog concerning disclosure policies.  This wound up reminding me of something that’s always been obvious but that I haven’t thought about much recently: the effect that having to reboot in order to install updates has on update take-up.  Given the speed with which vulnerabilities are now weaponized and the increased number of zero-day attacks, this is even more relevant today than ever before.

One of the tasks I take care of at work is monitoring the deployment of Microsoft security updates on machines within the faculty’s Windows domain.  We deploy Microsoft updates using WSUS, which also keeps track of the status of the machines for us.  Unfortunately I haven’t kept any statistical data over the past however-many years, but my subjective impression is that our users are rebooting far more promptly than they used to; this may partly be due to increased awareness of security risks, but I suspect that the regular monthly update cycle plays a big part.  If you know you’re going to need to reboot once a month, and only once a month, there’s no point in putting it off.  If you might be asked to reboot again the following day, you’re less motivated to get it over with.

Even so, the problem wouldn’t arise if updates could be installed without having to reboot.  So, is this possible?  Well, yes – but a qualified yes.  This isn’t easy to do, even if you’re given a clean slate to work with.

Firstly, we need to think a bit more about what we mean when we say “reboot” in this context.  Technically, you’re only rebooting if the OS shuts down and hands control of the system back to the BIOS – to all effects and purposes, the effect is essentially the same as switching the computer off and back on again.  If you took this definition literally, it wouldn’t be too hard to avoid rebooting after updates are installed; for example, you could run the OS inside a virtual machine, and let the hypervisor retain control of the hardware while the OS is reinitialized.  This would probably save some time, since a virtual reboot is typically much quicker than a physical reboot, but it wouldn’t actually help; the user would still have to close and reopen all the applications and documents they were working with, and that’s what they really want to avoid.

Similarly, it isn’t enough to just think about OS updates and whether you can keep an application running (in some sense) while the OS reinitializes itself underneath it.  You also have to make sure that you can also update the application itself without interrupting the user’s work – oh, it probably won’t hurt if the application is unresponsive for a few seconds, but there’d better not be any other visible disruption.  All of the user’s documents need to remain open and in the same state they were in before the update; if it’s a web browser, all the web pages that were open before need to remain open, session cookies need to remain in place, and the internal state of any client-side script needs to be retained.  That’s not going to be easy for the application developer to support, and I suspect that there’s a limited amount the OS can do to help out.

For updating the OS itself, modular design would seem to be key; something like Minix could conceivably be adapted to allow individual modules to be updated one at a time, with both old and new versions of an updated module running simultaneously during the handover to allow the clients to be (transparently, if at all possible) migrated from one to the other.  A similar approach might be possible if the microkernel itself needs to be updated, although if hardware-based security measures have been taken to protect the microkernel from modification it might be necessary to put the OS into hibernation and perform a physical reboot.

I strongly suspect it would be impossible to reliably achieve any equivalent functionality in a more conventional OS design such as Windows or Linux.  [*]

Applications could perhaps be updated in a similar way; allow the old version of the application to continue running in parallel with the new version, then migrate each open document, window, or related set of windows from one to the other in turn.  The internal state of each document/window/set would have to be transformed into a version-independent representation for the handover.  This isn’t going to be easy for the programmer, but there would be some fringe benefits: in addition to allowing transparent updating, a user’s idle applications could also be individually hibernated for more efficient multitasking, or a user’s entire logon session could be transparently migrated from one physical machine to another.

I’ll give this more thought as time permits, but apart from some more or less trivial commentary on how programming languages could be modified to make this sort of thing easier, I’m not sure there’s much more to be said.  Hopefully one day someone will be able to actually try to make something like this happen – come to think of it,  similar issues must come up in the context of cloud computing, so perhaps there’s already a body of work I’m not aware of – and practical experimentation is much more likely to result in useful ideas than mere armchair theorizing!

Harry

[*] Windows has theoretically had support for hotpatching for a number of years, but as far as I know none of the security updates released so far have actually implemented it.  I believe you can also buy support for hotpatching Linux systems, but if my understanding of how this is implemented is correct this only allows certain kinds of updates; enough (in most cases) to keep a system secure without having to reboot it for each individual vulnerability, but not a general-purpose solution.

Advertisements

Tags:

4 Responses to “Safe Computing: No Rebooting, Please”

  1. AnonSecurityGuy Says:

    I don’t know why you call this so hard. It seems like there are simple things you can do.

    First off, high-level comment: On Linux, I almost never have to reboot to take advantage of security exploits. On Windows, I usually do. I think Windows could start by taking a look at how Linux handles this.

    More substantive comments: There are some simple things one can do. One simple thing: allow the existing instances of the application to continue running, executing the old copy of the application; but starting new instances of the application should start the new copy of the application. This works particularly well for applications that aren’t kept open for too long.

    You mention, what if the user has multiple documents open? Well, this is easy to handle if each document is a separate instance of the application (e.g., running in its own process); it just gets handled properly by the above strategy. I do realize that Windows applications for some reason seem to avoid this architecture (they seem to prefer that there’s just one master process that handles all open documents — Windows applications often don’t have a notion of multiple running instances of the application); but I think the single-process architecture common in Windows are a bad design, for multiple reasons, the difficulty of security patching being just one of them.

    What about long-running applications? Well, I suspect we can get a 80% solution by identifying the few common cases (web browser, Word) and handling them specially. For instance, the Firefox web browser has the ability to shut down and restart, re-opening all windows and bringing the browser back to a fairly similar state. You could have some hooks so that any time that an update patches the Firefox application, it restarts itself. You could apply similar techniques to the top 10 most commonly used, long-running applications, and I suspect that alone would be enough to help a lot.

    Bottom line: I don’t see why this has to be so hard as you make it out to be. It seems like one may be able to get some 80% solutions, without as much effort as you suggest. It may be true that Windows has made some poor architectural decisions long ago that it’s now stuck with, which makes it harder to bring rebootless security patches to Windows today — but if so, that’s not fundamental, it’s a symptom of an architectural shortcoming of Windows.

    • harryjohnston Says:

      I’m not an expert, but I suspect that in most cases you do in fact need to reboot Linux in order for an (OS) patch to take full effect – it’s just that the update mechanism doesn’t warn you about it. One of the underlying differences that has an impact here is the file system semantics: Linux allows you to replace a file while the original version is still open, Windows does not. However, if the unpatched version of the file is still running, you probably aren’t actually protected.

      See http://www.ksplice.com/why as one (admittedly biased!) reference in support of this theory. This also offers another approach to addressing the problem – although not one I’m particularly happy with.

      Allowing existing documents to remain open as-is while new documents are opened with the patched version of the application is an interesting idea, and for simple applications of course this happens automatically under Linux because of the aforementioned file system semantics. If the only threat the application is exposed to is corrupted documents, this would actually eliminate the security risk no matter how long the old code continued to run!

      Depending on the way an application is architectured, and on the sophistication of the development tools used to build it, this could also be done in Windows – but it won’t happen without a deliberate effort on the part of the vendor.

      I’m very much in favour of each document being opened in a separate process, incidentally – in my hypothetical ideal OS, this would be mandatory, and furthermore said processes would be securely isolated from one another. One of my own pet peeves is applications that close down, taking all open documents with them, when you close a single document! Macintoshes are particularly bad in this regard, I suspect this behaviour is actually recommended by Apple’s UI guidelines. 😦

      Long-running applications may still be a problem. Firefox, as a typical example, isn’t currently able to restore the full context of an open web page when it restarts, which is why it prompts before restarting itself in order to self-update. If it could run two instances of itself simultaneously (it can’t, due to the way it handles user profiles) it could open all new pages with the updated version, similar to what you suggest for documents. This actually might not be too hard to do if designing a web browser from scratch. It shouldn’t make much difference whether the updater is part of the application or part of the OS.

  2. Aater Suleman Says:

    Boot — whats that? Buy a Macbook Air 🙂 Just kidding, I am not a fan boy

    Extremely important point you make here. I don’t understand why it takes so long for companies to get what the users want.

    . I wanted to share an aggravating experience I with reboots recently. I was running Linux under windows inside a VM. I run Windows because my work wants me to and I run Linux because there are tools I cannot get to run on Windows easily. I fired a loooon (like 20 hours long) simulation on my VM and left the office for the weekend. When I returned Monday, Windows had rebooted due to updates, killed my VM, and somehow corrupted it as well.

    What did I do?
    Now I run Windows and Linux both inside VMs on a Mac. lol .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: