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.
Since this clearly was a known problem I think it should have been mentioned in the afterboot manual page in OpenBSD.
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.
"Last words are for fools who haven't said enough." - Karl Marx
Is it me or is the html broken?
r y_id=535
http://daily.daemonnews.org/view_story.php3?sto
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.
I know because Eric Raymond says it's true.
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.
Read the latest edition of Kernel Traffic, there's discussion of the weaknesses of the Linux /proc filesystem. For those of you who don't know, Kernel Traffic is a weekly summary of discussion on the Linux kernel developlement mailing list, and can be accessed at http://kt.linuxcare.com.
Why does this article say "from the procfs:a-bad-idea-anyway- dept."? I've always thought procfs was a *good* idea. It prevents having to read /dev/kmem directly. It allows software to still work when changes to the kernel are made. It reduces the number of suid or sgid binaries that are required.
I've never seen anyone before claim that procfs is a bad idea.
BSD not Open Source? All the source code is there, and you are free to look at it, modify it, heck, even make love to it. If you notice a flaw, feel free to submit it to the core developers, and they will deal with it. If you fixed it, then they may even incorporate your fix into the next release.
The BSD license does not make it closed source. It only makes it more friendly to larger corporations.
JB
Feed The Need[goatse.cx]