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)

Unspecified
Linux
defect

Tracking

()

Tracking Status
firefox53 --- affected

People

(Reporter: jld, Unassigned)

References

Details

(Whiteboard: sb+)

Attachments

(1 file)

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.
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-
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.
Whiteboard: sb? → sb+
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: