[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