*BSD procfs vulnerability 14
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.
man (Score:1)
Ok, now it's fixed, but it would have been nice to know about it when we needed to know, i.e. pre-fix, now is a little late.
Re:Procfs a bad idea?! (Score:1)
How exactly? By adding a convenient abstraction layer to complex data structures? Seems like a way to allow people to write good, simple, portable (within different versions of the same OS) code to accomplish what they need to.
FreeBSD obviously thought it was a good idea, and it bit them in the ass.
An implementation bug does not mean something's a bad idea. There's probably not a single setuid program or network service that has not had a security hole on at least one Unix.
This wouldn't be a problem... (Score:1)
I know because Eric Raymond says it's true.
Similar to the 1997 exploit--just more subtle (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.
Re:Similar to the 1997 exploit--just more subtle (Score:1)
Re:Procfs a bad idea?! (Score:1)
Re:Similar to the 1997 exploit--just more subtle (Score:2)
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.
Procfs a bad idea?! (Score:1)
I've never seen anyone before claim that procfs is a bad idea.
BSD is open source (Score:1)
The BSD license does not make it closed source. It only makes it more friendly to larger corporations.
JB