Closed
Bug 1407027
(CVE-2017-5095)
Opened 7 years ago
Closed 7 years ago
pdfium Buffer Overflow
Categories
(Core :: Printing: Output, defect, P3)
Core
Printing: Output
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox56 | --- | unaffected |
firefox57 | - | disabled |
firefox58 | - | disabled |
firefox59 | - | disabled |
firefox60 | - | disabled |
People
(Reporter: tjr, Assigned: jwatt)
References
Details
(Keywords: csectype-bounds, sec-high, Whiteboard: [third-party-lib-audit] Fixed by bug 1435230)
Comment 1•7 years ago
|
||
The Chrome team assigned CVE-2017-5095 to this bug, and since we've just incorporated their library we should reference the same one. Looks like this landed in Firefox 56 (bug 1368948) though I don't know whether it was enabled right away. Changing component to match bug 1368948
Is pdfium only used for printing the previous bug suggests? If so we can probably lower the severity to sec-high since it couldn't be exploited just by browsing a malicious page.
Alias: CVE-2017-5095
Blocks: 1368948
status-firefox56:
--- → affected
status-firefox57:
--- → affected
status-firefox-esr52:
--- → unaffected
tracking-firefox57:
--- → +
tracking-firefox58:
--- → +
Component: Graphics → Printing: Output
Keywords: csectype-bounds,
sec-critical
Whiteboard: [third-party-lib-audit] → [third-party-lib-audit] publicly announced vuln
Comment 2•7 years ago
|
||
:brsun doesn't seem to be around. Who should shepherd this fix in?
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(jwatt)
Updated•7 years ago
|
![]() |
Assignee | |
Comment 3•7 years ago
|
||
We're not exposing users to PDFium at all since we haven't yet flipped the pref pdfium.enabled.
This does raise the question of whether or not we can get access to PDFium sec bugs that're reported against chromium before they're released though. Do we have anyone with access?
Assignee: nobody → jwatt
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(jwatt)
Flags: needinfo?(dveditz)
![]() |
Assignee | |
Comment 4•7 years ago
|
||
(In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #3)
> we haven't yet flipped the pref pdfium.enabled.
Err, wrong pref. It's the hidden pref print.print_via_pdf_encoder that needs to be set to 'skia-pdf' (we don't currently ship that). Also that pref only works if mozilla is built with --enable-skia-pdf, which is currently only the case for Nightly. Anyway, regardless of the mechanism, we don't currently expose users to PDFium.
Comment 5•7 years ago
|
||
OK, sounds like I can mark 56/57 as unaffected since we shipped 56 with the pref off and with a specific build. So only 58 should be currently affected even with the pref enabled.
dveditz, does that sound right?
Comment 6•7 years ago
|
||
(In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #3)
> We're not exposing users to PDFium at all since we haven't yet flipped the pref
Great, thanks. I'll mark the current releases "not tracking" and "disabled".
> This does raise the question of whether or not we can get access to PDFium
> sec bugs that're reported against chromium before they're released though.
> Do we have anyone with access?
If I know what to look for I can query for bugs a little before they're released (when they get the label Restrict-View-SecurityNotify).
Flags: needinfo?(dveditz)
Updated•7 years ago
|
Keywords: sec-critical → sec-high
Updated•7 years ago
|
Priority: -- → P3
Updated•7 years ago
|
Comment 7•7 years ago
|
||
(In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #4)
> (In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #3)
> > we haven't yet flipped the pref pdfium.enabled.
>
> Err, wrong pref. It's the hidden pref print.print_via_pdf_encoder that needs
> to be set to 'skia-pdf' (we don't currently ship that). Also that pref only
> works if mozilla is built with --enable-skia-pdf, which is currently only
> the case for Nightly. Anyway, regardless of the mechanism, we don't
> currently expose users to PDFium.
Seems like this is still disabled. Hooray.
Do you have any plans to change that?
Either way, can you update the tracking flags accordingly for us?
Thank you!
Flags: needinfo?(jwatt)
![]() |
Assignee | |
Updated•7 years ago
|
status-firefox59:
--- → disabled
status-firefox60:
--- → disabled
tracking-firefox59:
--- → -
tracking-firefox60:
--- → -
Flags: needinfo?(jwatt)
![]() |
Assignee | |
Comment 8•7 years ago
|
||
(In reply to Frederik Braun [:freddyb] from comment #7)
> Seems like this is still disabled. Hooray.
> Do you have any plans to change that?
No. Future layout plans are being worked on, but not in the near term.
Reporter | ||
Comment 9•7 years ago
|
||
Just wanted to note that I ran a script on pdfium since our last update. 2419 commits and it found the following:
Summary
-----------------
Bugtracker: Restricted Bug : 35 issues identified
Bugtracker Keyword: Security_Severity-High: 30 issues identified
Commit Message Keyword: overflow: 28 issues identified
Bugtracker Keyword: Security_Severity-Medium: 23 issues identified
Commit Message Keyword: fuzz: 21 issues identified
Commit Message Keyword: crash: 18 issues identified
Commit Message Keyword: ASAN: 7 issues identified
Bugtracker Keyword: Security_Impact: 6 issues identified
Commit Message Keyword: MSAN: 4 issues identified
Bugtracker Keyword: Security_Severity-Low: 2 issues identified
Bugtracker Keyword: CVE-: 1 issues identified
Commit Message Keyword: security: 1 issues identified
Total: 176
Reporter | ||
Comment 10•7 years ago
|
||
I'm going to use this bug to track pdfium version updates. Depending on how often they roll pdfium, I may not keep commenting since AIUI pdfium is sitting for a bit until we decide to start using it for stuff.
Update pdfium to 3ae75c2f2e5759fcf8218e59fa380c26b98aa6b6
---------
Whiteboard: [third-party-lib-audit]
Most Recent: 1346291
---------
This is a (semi-)automated bug making you aware that there is an available upgrade for an embedded third-party library. You can leave this bug open, and it will be updated if a newer version of the library becomes available. If you close it as WONTFIX, please indicate if you do not wish to receive any future bugs upon new releases of the library.
pdfium is currently at version 84213b529908d2b9095ad4c33ecc9fdf5d881df5 in mozilla-central, and the latest version of the library released is 3ae75c2f2e5759fcf8218e59fa380c26b98aa6b6.
I fetched the latest version of the library from https://chromium.googlesource.com/chromium/src/+/master/DEPS.
(Technically, this 'latest commit' is not a release, but Chromium has rolled their dependency of pdfium.)
Comment 11•7 years ago
|
||
(In reply to Jonathan Watt [:jwatt] from comment #8)
> (In reply to Frederik Braun [:freddyb] from comment #7)
> > Seems like this is still disabled. Hooray.
> > Do you have any plans to change that?
>
> No. Future layout plans are being worked on, but not in the near term.
If we're not actively working on this, and we're lagging behind on
updating the third-party libraries to secure versions, then I suggest
we simply remove the --enable-skia-pdf from the Nightly build config
until we actually intend to ship that. It seems better that Nightly
tests the config we actually ship, for now.
Does that sound reasonable?
Flags: needinfo?(jwatt)
![]() |
Assignee | |
Comment 12•7 years ago
|
||
We already did that for Windows (the only platform that PDFium can build for) in bug 1435230.
Flags: needinfo?(jwatt)
Comment 13•7 years ago
|
||
OK, great! Then I don't see any reason to keep this bug since
the security issue has been solved.
Tom, please file new bug(s) for future PDFium uplifts as needed.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [third-party-lib-audit] publicly announced vuln → [third-party-lib-audit] Fixed by bug 1435230
Updated•7 years ago
|
Group: gfx-core-security → core-security-release
Updated•5 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•