Closed Bug 1598040 Opened 4 years ago Closed 4 years ago

Allowing clock_nanosleep unconditionally is a sandbox information leak

Categories

(Core :: Security: Process Sandboxing, defect, P1)

Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox-esr68 72+ fixed
firefox71 --- unaffected
firefox72 --- fixed

People

(Reporter: jld, Assigned: jld)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

See bug 1294286 for more context; the short version is that, on Linux, the clockid_t type can reference various measures of elapsed CPU time for any process or thread in the caller's pid namespace.

I've confirmed that these timers work with clock_nanosleep and it's possible to sleep until a given other process has used a given amount of CPU time. This isn't a sandbox escape by itself, but we shouldn't allow it, the same way that we don't allow polling these timers with clock_gettime.

Attached file Proof of concept

Proof of concept: forks, then the parent process waits for the child to consume 1 second of CPU; without BUSYLOOP defined the child blocks in pause and the parent hangs forever, but with it defined the child busy-loops and the sleep completes in about 1 second.

The clockid_t type on Linux has a space of values which encode a pid
and allow measuring the CPU usage of other processes; we don't want to
allow sandboxed processes to do that.

Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5cddc200d6f2
Filter clock IDs in clock_nanosleep sandbox rule. r=gcp
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

Jed, https://bugzilla.mozilla.org/show_bug.cgi?id=1597792 indicates that the patch here needs to be uplifted to release, could you request the uplift please? We are building RC in a few hours. I talked with Emilio and we are not taking the uplift in the RC build given the low impact on end-users, that will be in 72 early January.

Flags: needinfo?(jld)

Comment on attachment 9110452 [details]
Bug 1598040 - Filter clock IDs in clock_nanosleep sandbox rule.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixes regression from bug 1597792 which is needed to use the profiler on Linux with the upcoming release of glibc.
  • User impact if declined: Sandboxed processes will have access to information that they shouldn't; it's relatively minor but could possibly be leveraged as part of a larger exploit. (Also, keep in mind that I could have backed out bug 1597792 and required changes for relanding, but landing a fix separately seemed simpler and less disruptive.)
  • Fix Landed on Version: 72
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The end result after this patch is still more permissive than before bug 1597792, when this system call was completely denied. In particular, the only use case we've seen so far (in bug 1597792) is allowed.
  • String or UUID changes made by this patch: none
Flags: needinfo?(jld)
Attachment #9110452 - Flags: approval-mozilla-esr68?

(Requesting ESR 68 only, to match the current status of bug 1597792.)

Comment on attachment 9110452 [details]
Bug 1598040 - Filter clock IDs in clock_nanosleep sandbox rule.

linux sandbox update, approved for 68.4esr

Attachment #9110452 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
See Also: → 1678174
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: