Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
BSD Operating Systems News

*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.
This discussion has been archived. No new comments can be posted.

*BSD procfs vulnerability

Comments Filter:
  • 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.

  • It's a horrid idea. It's yet another way to get around having to write good code.

    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.

  • by Anonymous Coward
    This wouldn't be a problem if BSD was Open Source. If it were, this would have been found and fixed immediatly.

    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.

    -Ed
  • I'm not sure I understand this... If A opened the file, wouldn't B inherit A's permissions, and thus not be able to write the file? Or is there something I'm missing?
  • 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 [linuxcare.com].
  • 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.

  • 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

You will have many recoverable tape errors.

Working...