Restrictions on sendmsg() could be bypassed through race using MAP_SHARED

[GoogleCodeExporter]

When the nascent thread is starting, it forks a subprocess which does
a sendmsg() call to the trusted process.

The reason for doing the sendmsg() in a forked subprocess is
presumably to stop the untrusted threads from tampering with
sendmsg()'s "struct msghdr" arguments, which are passed in memory and
not in registers.

However, the trusted thread uses the new thread's stack for the
"struct msghdr" (%ebp in trusted_thread_i386.S).  This stack is mapped
by untrusted code, and it could have been mapped with MAP_SHARED, in
which case fork() will not create a private copy.

This means untrusted code could bypass the sandbox's restrictions on
sendmsg() by racing to overwrite this memory.  e.g. It could fill out
a non-NULL msg_name value.

I haven't tried testing this though.

The fix would be to use any page that is guaranteed to be mapped with
MAP_PRIVATE.

Does this sound right, Markus?

Original issue reported on code.google.com by mseaborn@chromium.org on 23 Sep 2010 at 9:50

[GoogleCodeExporter]

Good catch! I am so happy to have another pair of eyes going over this code.

Yes, your analysis sounds correct and the bug should in fact be pretty easy to 
fix. I suspect the easiest option would to just call mmap() in the child 
process in order to allocate memory for scratch space.

Original comment by zod...@gmail.com on 23 Sep 2010 at 10:05

[GoogleCodeExporter]

Fixed in r124.

Original comment by mseaborn@chromium.org on 29 Sep 2010 at 1:23

• Changed state: Fixed