Possible security hole? [was: verify_area(...) possible problem]

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Sat, 17 Apr 1999 00:43:45 +0200

Andi Kleen wrote:
> In theory not, because early i386 with broken supervisor write
> protection checking depend on on verify_area/access_ok to actually
> check the page tables. The page tables could change while you sleep.
>
> But, the concept is really broken, because e.g. when a user access
> crosses two vm areas, and the user access faults (=sleeps) in the
> first, and the goes on to write to the second, while that has been
> already unmapped by another thread, it overwrites innoncent
> memory.

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.

Enjoy,
-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/