[lkml]   [1999]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Possible security hole? [was: verify_area(...) possible problem]
On Sat, Apr 17, 1999 at 12:43:45AM +0200, Jamie Lokier wrote:

> Andi, nice thinking.
> Can this (the current behaviour) be a security hole?
> I'm thinking that two cloned threads could, on an i386 with the
> broken WP protection:
> (a) read a file to hack to bring it into cache, e.g. /bin/su
> (b) does a shared writable mapping of some writable file that is not in cache
> (use your imagination)
> (c) thread #2 spins checking a flag
> (d) thread #1 writes the flag and then writes to the writable mapping
> (e) thread #1 blocks to pull in the page
> (f) thread #2 sees the flag and maps /bin/su into place (read only)
> (g) the page comes in though the mapping is no longer present
> (h) thread #1 unblocks and overwrites a page of /bin/su
> (i) run /bin/su, get root with no password check, H940R D00D2 R001
> --> there isn't even any evidence on disk
> This will not happen if, when thread #1 blocks, the remapping is blocked
> by a lock. But I'm not sure, is it? I don't have an i386 to try it on.

This is a known problem, it is pretty much similar to what happened under 2.0
for all all architectures, not just the i386 and one of reasons for the new
user space access stuff introduced from 2.1.4 on. Now that only the 386 is still
affected just nobody bothered because on the 386 there are other funnies left
which may make running a system used by possibly hostile users a bad idea.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.066 / U:9.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site