Open
Bug 1326361
Opened 8 years ago
Updated 2 years ago
Audit local-domain sockets held by Linux Firefox content process
Categories
(Core :: Security: Process Sandboxing, defect, P3)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox53 | --- | affected |
People
(Reporter: jld, Unassigned)
References
Details
(Whiteboard: sb+)
Attachments
(1 file)
3.28 KB,
patch
|
jld
:
review-
|
Details | Diff | Splinter Review |
Eventually we will stop desktop content processes from creating new connections to system services exposed over local-domain (Unix-domain) sockets. However, connections already created when the sandbox is started are still a problem. (Mac OS X has a similar issues with Mach ports.)
We can check this by iterating through the fd numbers, using getsockopt() with SO_FAMILY to find the AF_LOCAL sockets (and if we find any sockets that *aren't* AF_LOCAL, that's probably bad; non-sockets will fail with ENOTSOCK), and using getpeername() to find what they're connected to. In addition to auditing, this approach could also be used as a defensive measure to prevent system libraries from accidentally undermining the sandbox.
Unnamed sockets from socketpair() have empty addresses, but a Linux-specific trick (previously relied on by Chromium and Breakpad; see also https://crbug.com/357670) is that the ends of a socketpair have consecutive inode numbers. That's probably not something we want to try to make use of automatically (especially because we wouldn't know whether to subtract or add 1), but it can be useful for manual auditing.
Reporter | ||
Comment 1•8 years ago
|
||
Patch for printing out socket info when starting sandbox.
I tested locally and found, in addition to the X11 and PulseAudio connections we already knew about, a connection to the DBus session bus.
There's probably a way to use DBus to escalate to arbitrary code execution outside the sandbox, and there are definitely ways to do things that a “sandboxed” process shouldn't be able to do.
Attachment #8825528 -
Flags: review-
Reporter | ||
Comment 2•8 years ago
|
||
Also, it says "content" in the title of this bug but I also checked out a GMP process. The only sockets I saw were unnamed sockets connecting it to the chrome and content processes, plus a socketpair where it's holding a unique descriptor to both ends (i.e., no other process seems to have a descriptor for either); I'm not sure what's going on with that, but it seems harmless.
And while I'm at it: the content process's unnamed sockets also appear to all be connections with other processes (chrome or GMP) in the same browser instance.
Updated•8 years ago
|
Whiteboard: sb? → sb+
Updated•7 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•