Slashdot Mirror


*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.

1 of 14 comments (clear)

  1. Similar to the 1997 exploit--just more subtle by edhall · · Score: 3

    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