The Untrusted Path
It happened again the other day: I received a pop-up telling me to update Flash. In the previous few days, I’d received prompts to update Office and Adobe Acrobat; I’ve also seen recent update prompts for Firefox, MacOS, and assorted minor pieces of software.
In some sense, this is all to the good. Most security problems are due to bugs for which patches already exist; anything that gets people to patch their software will help. But — are the patches legitimate? That is, are they real patches, or are they malware pretending to be patches?
I’ve been worrying about this for quite some time. I’m a sophisticated user, of course, and I hesitate to say how many decades I’ve been doing systems administration. My response to a pop-up saying "there are patches available for package XYZZY" — which doesn’t happen to be running at the time — is to cancel the request and manually check for updates to that package. Most people can’t or won’t do that. Password prompts and requests to go ahead are meaningless if they’re not linked — clearly and visibly linked — to the actual changes to be made. Otherwise, some piece of nasty software can generate the exact same prompts, or possibly the genuine system prompt for permission. This has now happened.
The traditional approach to this problem is the trusted path, some unspoofable mechanism that ensures the user is talking to a system component. Traditionally, the trusted path is entered when the user hits the Secure Attention Key (SAK). (Remember how Windows XP would insist that you hit CNTL-ALT-Delete to log in? Now you know why. Newer versions of Windows use the same SAK sequence to get to things like the task manager and the password change dialog.) This works well for protecting passwords, by ensuring that they go only to the operating system, but doesn’t help much if a piece of malware can invoke the standard system update mechanism. The real system will ask for your password, but it’s granting privileges to malware.
For many people, of course, the right thing to do is to enable auto-update: if a patch is fixing a serious security hole, you almost certainly want it installed as soon as possible. Note the word "almost", though; if you’re relying on a system, you probably want to test the update, or at least wait to hear about other people’s opinions before you install it. Even sophisticated companies can make mistakes in their patches.
To my knowledge, no system has a good solution to secure update problem. Pieces of the solution exist in various places, but they’ve never been put together properly.
- Passwords or other authorization to do certain things should never be entered by the user unless and until the user has hit the Secure Attention Key. This is necessary for all such interactions, and not just at login time. (And note that this is a challenging matter, especially in a networked environment. By definition, the SAK invokes the Trusted Path. How do you do remote administration, when SAK will go to your OS? Besides, how can you send a SAK — an unspoofable signal — over a network? Even without networks, SAK is used to establish a trust path to several different system components; ensuring that it’s the right one — the system’s update manager pointed at whatever software wants to be updated — and not the generic one.)
- The user must be given a very clear statement about what will be changed. We don’t get good indications today, a problem I’ve complained about in the past.
- The privileges granted to the update process must be
such that only the indicated application can
be touched. This might be achievable if every application
package has its own userID; if the update process ran as
that user, it wouldn’t be able to tinker with any other
pieces of the system. (This is
similar
to the way that Android sandboxes its apps.)
If this property exists, it may be possible to simplify things a bit. If an update package is digitally signed with a key known to the current version (or, more precisely, registered to the operating system when the current version was installed), it most likely came from the same source and should be accorded the same trust. No password entry is needed, though it’s still necessary to seek user consent.
We’re far from this ideal today. Until our systems address it, we’ll be victimized by increasingly clever pieces of malware, and software updates will be done via an untrusted path.
