There have been recent reports of a security bug in sudo (CVE-2017-1000367) where you can fool sudo into thinking what controlling terminal it is running on to bypass its security checks. One of the first things I thought of was, is procps vulnerable to the same bug? Sure, it wouldn’t be a security bypass, but it would be a normal sort of bug. A lot of programs in procps have a concept of a controlling terminal, or the TTY field for either viewing or filtering, could they be fooled into thinking the process had a different controlling terminal?
Was I going to be in the same pickle as the sudo maintainers? The meat between the stat parsing sandwich? Can I find any more puns related somehow to the XKCD comic?
TLDR: No.
How to find the tty
Most ways of finding what the controlling terminal for a process is on are very similar. The file /proc//stat is a one-liner pseudo file that the kernel creates on access that has information about the particular process. A typical file would look like:
20209 (bash) S 14762 20209 20209 34822 20209 4194304 32181 4846307 625 1602 66 3 0 16265 4547 20 0 1 0 139245105 25202688 1349 18446744073709551615 4194304 52421 32 140737059557984 0 0 0 0 3670020 1266777851 1 0 0 17 1 0 0 280 0 0 7341384 738 8228 39092224 140737059564618 140737059564628 140737059564628 140737059569646 0
The first field is the PID, the second the process name (which may be different than the command line, but that’s another story), then skip along to field #7 which in this case is 34822. Also notice the process name is in brackets; that is important.
So 34822, how do we figure out what device this is? The number is the major and minor device numbers of the controlling terminal. 38422 in hex is 8806, the device has a major number of 88h or 136 and a minor number of 06. Most programs just scan the usual device directories until they find a match (which is basically how procps does it).
Device 136,6 is /dev/pts/6
crw--w---- 1 user tty 136, 6 May 29 16:20 /dev/pts/6 $ ps -o tty,cmd 20209 TT CMD pts/6 /bin/bash
The Bug
The process of taking the raw stat file and having a bunch of useful fields is called parsing. The bug in sudo was due to how they parsed the file. The stat file is a space-delimited file. The program scanned the file, character by character, until it came across the 6th space. The problem is, you can put spaces in your command and fool sudo.
Once you know that, you can make sudo think the program is running on any (or at least a different) controlling terminal. The bug reporters then used some clever symlinking and race techniques to then get root.
What about procps?
The parsing of the current (as of writing) procps on the stat file is found in proc/readproc.c within the function stat2proc(). However, it is not just a simple sscanf or something that runs along the line looking for spaces. To find the command, the program does the following:
S = strchr(S, '(') + 1;
tmp = strrchr(S, ')');
num = tmp - S;
if(unlikely(num >= sizeof P->cmd)) num = sizeof P->cmd - 1;
memcpy(P->cmd, S, num);
P->cmd[num] = '\0';
S = tmp + 2; // skip ") "
The sscanf then comes after we have found the command, using the variable S, to fill in the other fields including the controlling terminal device numbers. procps library looks for the command within brackets. So if your program has spaces in it, it is still found. By using a strrchr (effectively, find the last) you cannot fool it with a bracket in the command either.
So procps is not vulnerable to this sort of trickery.
Incidently, the fix for the sudo bug now uses strrchr for a close bracket, so it solves the problem the same way. The check for the close bracket appeared in procps 3.1.4 back in 2002, though the stat2proc function was warning about odd named processes before then. As it says in the 2002 change:
Reads /proc/*/stat files, being careful not to trip over processes with names like “:-) 1 2 3 4 5 6”.
That’s something we can all agree on!
Leave a Reply