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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: tedd, Assigned: tedd)

References

Details

(Whiteboard: sblc1)

Crash Data

Attachments

(1 file)

Whiteboard: sblc1
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 ]
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)
Attachment #8772842 - Flags: review?(gpascutto) → review+
(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.
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 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+
(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.
(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
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: