Closed
Bug 1286185
Opened 8 years ago
Closed 8 years ago
Seccomp sandbox violation: sys_fadvise64 called in content process of Firefox desktop
Categories
(Core :: Security: Process Sandboxing, defect)
Core
Security: Process Sandboxing
Tracking
()
RESOLVED
FIXED
mozilla50
Tracking | Status | |
---|---|---|
firefox50 | --- | fixed |
People
(Reporter: tedd, Assigned: tedd)
References
Details
(Whiteboard: sblc1)
Crash Data
Attachments
(1 file)
644 bytes,
patch
|
gcp
:
review+
jld
:
feedback+
|
Details | Diff | Splinter Review |
Crash reports show that sys_fadvise64 is called in the content process:
https://crash-stats.mozilla.com/search/?product=Firefox&reason=~SIGSYS&address=0xdd&_sort=-date&_facets=cpu_arch&_facets=address&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports
Updated•8 years ago
|
Whiteboard: sblc1
Updated•8 years ago
|
Crash Signature: [@ libc-2.22.so@0xdfefd ] [@ libc-2.23.so@0xde7fd ] [@ libc-2.23.so@0xf745d ] [@ libc-2.23.so@0xfafbd ] [@ libc-2.23.so@0xdeb4d ]
Assignee | ||
Comment 1•8 years ago
|
||
Assignee: nobody → julian.r.hector
Attachment #8772842 -
Flags: review?(gpascutto)
Comment 2•8 years ago
|
||
Comment on attachment 8772842 [details] [diff] [review]
Add sys_fadvise64 to seccomp whitelist. r=gcp
Review of attachment 8772842 [details] [diff] [review]:
-----------------------------------------------------------------
There's also sys_fadvise64_64 in 32-bit mode, for great amusement.
This call is harmless, but on the other hand it's clearly setting up to do IO and adding more attack surface. Should we consider just eating it?
Attachment #8772842 -
Flags: feedback?(jld)
Updated•8 years ago
|
Attachment #8772842 -
Flags: review?(gpascutto) → review+
Assignee | ||
Comment 3•8 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #2)
> There's also sys_fadvise64_64 in 32-bit mode, for great amusement.
Jed filed Bug 1287008 for that.
Comment 4•8 years ago
|
||
My feeling is: allow it for now but file a followup bug to see about quietly ignoring it.
Also, it looks like fontconfig uses this only to read its cache files, and I wonder if there's a way to make that happen before sandboxing starts, or if it could need to reload the files later on regardless so there's no point.
Comment 5•8 years ago
|
||
Comment on attachment 8772842 [details] [diff] [review]
Add sys_fadvise64 to seccomp whitelist. r=gcp
Review of attachment 8772842 [details] [diff] [review]:
-----------------------------------------------------------------
See previous comment. (Also, it occurs to me that we might *already* be doing fontconfig initialization early enough, which would explain why it mostly works in testing, and the crashes we're seeing could be those cases where it tries to reload the cache later because new fonts were installed or something.)
If you wanted to dup the fadvise64_64 bug onto this and handle them both with one patch that would also be fine, but I don't care too much either way.
Attachment #8772842 -
Flags: feedback?(jld) → feedback+
Assignee | ||
Comment 6•8 years ago
|
||
(In reply to Jed Davis [:jld] [⏰MDT; UTC-6] from comment #4)
> Also, it looks like fontconfig uses this only to read its cache files, and I
> wonder if there's a way to make that happen before sandboxing starts, or if
> it could need to reload the files later on regardless so there's no point.
There is a timer going off every 30 seconds or so where the system font configs are checked to see if there has been a change or not. Maybe that's what triggers this system call.
Comment 7•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b83fcff9edd2e930eaf518d0a337eb53b75ec9f1
Bug 1286185 - Add sys_fadvise64 to seccomp whitelist. r=gcp
(In reply to Jed Davis [:jld] [⏰MDT; UTC-6] from comment #5)
> Comment on attachment 8772842 [details] [diff] [review]
> See previous comment. (Also, it occurs to me that we might *already* be
> doing fontconfig initialization early enough, which would explain why it
> mostly works in testing, and the crashes we're seeing could be those cases
> where it tries to reload the cache later because new fonts were installed or
> something.)
I can reproducely crash with this signature.
It happens when Nightly is running while installing/updating font with package manager pacman (Manjaro/Arch) which always also updates icon theme cache.
Crash is immediately after icon theme cache update.
bp-7f45584a-7c3f-442e-924e-26e802160722
bp-51e4713e-8ab1-4749-a26b-5a8d12160714
bp-3be1b8dd-3baf-447f-822d-bf8922160714
Comment 9•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox50:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in
before you can comment on or make changes to this bug.
Description
•