Messages in this thread | | | Date | Sat, 17 Apr 1999 00:43:45 +0200 | From | Jamie Lokier <> | Subject | Possible security hole? [was: verify_area(...) possible problem] |
| |
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/
| |