*BSD procfs vulnerability

From the archives at Security Focus, In January 1997 a fatal flaw in *BSD procfs code (leading to a local root compromise) was discussed on various security forums. The exploit code dealt with /proc/pid/mem interface. Since then *BSD kernels contained a simple fix which was meant to close this hole. Unfortunately, throughout these three years it was still possible to abuse /proc/pid/mem in a similar, though more complicated fashion, which could lead to local root compromise." Patches are included.

Comments

Similar to the 1997 exploit--just more subtle

[edhall]

Like the 1997 procfs issue, this one involves improper control over a file descriptor opened on /proc/[pid]/mem. The difference is that, instead of modifying the memory of a priviledged process, we coerce a priviledged process into modifying its own memory. An obvious way of doing this is by opening /proc/[pid]/mem on stderr, seeking to the area of memory you wish to modify, then exec()'ing the priviledged program and causing it to log a "message" to stderr that allows you to hijack control via the overwritten memory.

This is harder than the original exploit (process A fork()'s B, grabs access to B's memory, then B exec()'s a priviledged process where A can still write its memory and thus hijack control). But it still involves writing the process memory file. As much as I like the Unix "everything-is-a-file" concept, these two exploits show just how much it complicates security.

-Ed

Re:Similar to the 1997 exploit--just more subtle

[Bryan Andersen]

The way exec works is the new process overlays the old one, getting access to all it's open files. etc. Process A starts process B and grabs access to it's memory, then process B execs a privilaged program. Process A still has access to B's memory. It could then write new code/whatever into B's memory and take control of B to get it to do what it wants.

This is not a dificult problem to overcome, it should be able to be overcome with permitions checking at each access to a file. In this case when B changes ID to the privilaged ID the process space changes ownership. Then when A trys to write to B's process space it fails because of permitions. And yes you could optimize this to cut down the processing overhead by having exec type functions set a recheck perms flag on each call. The first file IO call for each open file would then recheck the perms on the file.