Wandering Thoughts archives


Understanding how CVE-2013-1979 might be exploited

CVE-2013-1979 is a more or less just-released locally exploitable 'gives root' Linux kernel vulnerability. Usually when I read CVE bug descriptions I can get at least a vague sense of how something would be exploitable, but this one puzzled me; I could see how the bug was not good but I couldn't see how it would be exploitable. Even the proof of concept code didn't particularly clear this up.

As described in the Red Hat bugzilla the core bug is:

Commit 257b5358b32f ("scm: Capture the full credentials of the scm sender") changed the credentials passing code to pass in the effective uid/gid instead of the real uid/gid.

(See also the Debian CVE entry.)

The first thing to understand is this 'credentials passing'. Simplified, it allows a program that's reading input from a Unix socket to discover the UID and GID of the process that sent the input. Programs can use this to easily implement access control (only certain UIDs can send them input) or authorization (certain UIDs are allowed to do special things), or just use the information for better logging and so on. Crucially, the sending program doesn't need to do anything special to enable this; it's entirely handled by the receiving program. The bug is that at one point the kernel code was changed to tell the receiving program the effective UID (and GID) of the sender, not their real UID and GID. This sounds relatively harmless, but it turns out it isn't. Here's how I think you exploit this.

First you need to find a program or a daemon that uses credentials on Unix domain sockets to make access or authorization decisions and that gives root special privileges. It probably also needs to act on simple, single messages; you connect to it, send it a message, and it does stuff for you. The ideal situation is something that accepts newline delimited ASCII and doesn't drop connections if you send it bad messages. Next you need to find a setuid program that can be tricked into writing a message that you control to standard output or standard error (possibly among other messages). The proof of concept code suggests that that su can be coaxed into doing this under some situations, for selected messages.

(Embedding newlines in command line arguments clearly helps here.)

To perform the actual exploit your wrapper program creates a Unix socket connection to the victim program or daemon, makes the socket connection its standard output and/or standard error, then runs su (or whatever) in such a way that it will print out your evil message. Since this message is actually being printed by a setuid program the daemon will see a valid message being sent to it by a privileged (effective) UID 0 process and proceed to carry out whatever evil you've asked it do for you.

Whether this is exploitable on any particular Linux system depends a lot on what you have running. Building a real exploit would probably take a fair amount of work because I think that most common daemons that talk over Unix domain sockets (such as the DBus daemon) use encoded wire protocols, not simple ASCII messages.

(Possibly I'm wrong here and there's a candidate daemon I'm missing. In any case there's a fix out now so you should be updating pretty fast.)

linux/UnderstandingCredentialsCVE written at 16:00:46; Add Comment

My issue with infinite scrolling web pages: the lack of a stopping point

Lately, 'infinite scrolling' web pages have become a popular design technique. These are pages that add additional content as you scroll down; keep scrolling and they'll keep adding, basically forever. While I can see the attraction of infinite scrolling, for me one of its big features is also my biggest issue with it.

One big appeal of infinite scrolling is that the user never has to interrupt their actions to go on. There is no scrolling to the bottom of one page, following a 'next page' link, and then starting again; instead, the same action of scrolling down is used both for moving through current content and 'navigating' to new content. And this is exactly the problem. When there is a distinct 'go to next' action to do, the bottom of a page (or wherever it is) is a natural place for me to consider whether I want to stop or go on. In an infinite scrolling page there is no such natural stopping point.

The alternate way to put this is that paged navigation creates natural chunks for me to consume content in, while infinite scrolling simply points a massive firehose at me. I find it easier to consume content in chunks; the paradoxical result of feeding me a navigation-free firehose is that I actually browse less of it for various reasons. Sometimes when there's no end it also feels like there's no real point.

(This thought was sparked by Flickr's recent redesign, which added infinite scrolling in a number of new places and thereby discouraged me from scrolling much in general.)

(I don't think that this just me being a curmudgeon about change, but I could be wrong. And I'm handwaving away many possible implementation issues and concerns with infinite scrolling. People who want to can find lots of other reasons to dislike it. I doubt it's going away for any number of reasons, including that I suspect it creates much easier navigation on touch interfaces.)

web/InfiniteScrollingIssue written at 02:01:43; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.