[tor-bugs] #24400 [Core Tor/Tor]: Seccomp filter incorrectly tries to act on strings, allowing sandbox bypass

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Dec 4 19:10:11 UTC 2017


#24400: Seccomp filter incorrectly tries to act on strings, allowing sandbox bypass
--------------------------+------------------------------------
 Reporter:  Sebastian     |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Major         |     Resolution:
 Keywords:  sandbox       |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by nickm):

 So, I'm sure that the orgininal reporter knows this, but I don't think
 that all the people on this thread know it: the current sandbox code tries
 to do what the the original reporter describes as

 >ensur[ing] the buffers are read-only and disallow `mprotect()` accessing
 that address.

 That's what Tor tries to do right now with all the crazy logic in
 prot_strings().  It tries to prevent mprotect() changes, munmap() or
 mremap() of the memory region, and any mprotect() changes that would
 overlap with the protected region.   It's sure not very clean code,
 though, and I can believe that there are ways around it that we don't know
 about.  How does the `brk()` bypass work here?  What are the other
 bypasses that we should know about?

 ----

 But let's assume that the bypass issues do affect us here.

 I think that in the longer timeframe, the right solution is to have a
 separate process that retains more syscall permissions.  This will take
 more design and implementation work, though.  It would have to be an
 optional thing that only happens when a sandbox needs it, or we'll make
 ios (and android?) sad.  It's a good candidate for a rust thing IMO.

 In the shorter term, we could remove the logic that tries to list all the
 files and only permit those, and instead permit open, openat, rename, etc
 more generally, if there's a benefit to that.

 We should also figure out what timeframe we can do the "right" solution
 on.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24400#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list