#2470 closed defect (fixed)
0-day: rebuild with new pdfium dll
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | blocker | Milestone: | 4.1 |
Component: | platforms | Version: | 3.0.x |
Keywords: | Cc: |
Description
Details here: New Chrome 0-day Bug Under Active Attacks – Update Your Browser Now!: the other resides in the PDFium (CVE-2019-13721) library
Change History (14)
comment:2 Changed 16 months ago by
Modifying the PKGBUILD
to try to build revision 3976 and copying the patch file to the new name pdfium-3976.patch
gives lots of rejects:
==> Starting prepare()... can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -c pdfium.orig/build_gyp/gyp_pdfium pdfium/build_gyp/gyp_pdfium |*** pdfium.orig/build_gyp/gyp_pdfium 2016-05-09 10:47:41.000000000 -0300 |--- pdfium/build_gyp/gyp_pdfium 2016-05-09 10:44:18.208997100 -0300 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 2 out of 2 hunks ignored can't find file to patch at input line 42 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -c pdfium.orig/core/fxcrt/fx_basic_util.cpp pdfium/core/fxcrt/fx_basic_util.cpp |*** pdfium.orig/core/fxcrt/fx_basic_util.cpp 2016-05-09 10:47:41.000000000 -0300 |--- pdfium/core/fxcrt/fx_basic_util.cpp 2016-05-09 10:43:40.187642300 -0300 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 2 out of 2 hunks ignored can't find file to patch at input line 79 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -c pdfium.orig/core/fxcrt/include/fx_system.h pdfium/core/fxcrt/include/fx_system.h |*** pdfium.orig/core/fxcrt/include/fx_system.h 2016-05-09 10:47:41.000000000 -0300 |--- pdfium/core/fxcrt/include/fx_system.h 2016-05-09 10:43:40.203267200 -0300 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 99 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -c pdfium.orig/core/fxge/win32/fx_win32_dwrite.cpp pdfium/core/fxge/win32/fx_win32_dwrite.cpp |*** pdfium.orig/core/fxge/win32/fx_win32_dwrite.cpp 2016-05-09 10:47:42.000000000 -0300 |--- pdfium/core/fxge/win32/fx_win32_dwrite.cpp 2016-05-09 10:43:40.218892400 -0300 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file core/fxge/win32/fx_win32_gdipext.cpp Hunk #1 FAILED at 691. Hunk #2 FAILED at 706. 2 out of 2 hunks FAILED -- saving rejects to file core/fxge/win32/fx_win32_gdipext.cpp.rej can't find file to patch at input line 158 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -c pdfium.orig/pdfium.gyp pdfium/pdfium.gyp |*** pdfium.orig/pdfium.gyp 2016-05-09 10:47:42.000000000 -0300 |--- pdfium/pdfium.gyp 2016-05-09 10:43:40.218892400 -0300 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored can't find file to patch at input line 323 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -c pdfium.orig/samples/samples.gyp pdfium/samples/samples.gyp |*** pdfium.orig/samples/samples.gyp 2016-05-09 10:47:42.000000000 -0300 |--- pdfium/samples/samples.gyp 2016-05-09 10:43:40.218892400 -0300 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 2 out of 2 hunks ignored ==> ERROR: A failure occurred in prepare(). Aborting...
comment:3 Changed 16 months ago by
Trying to build (with limited patching):
$ ninja ninja: error: loading 'build.ninja': No such file or directory
Docs say we're supposed to use gn?
$ gn --help gn.py: Could not find checkout in any parent of the current path. This must be run inside a checkout.
What does this even mean?
I want to build your software, why is it so hard?
(makes autotools look easy!)
comment:4 Changed 15 months ago by
pdfium is a Google project. Google (Chromium team) uses Ninja build system.
Try to run ninja with proper parameters:
ninja -C <directory> pdfium_all
For more details see https://pdfium.googlesource.com/pdfium/
comment:5 follow-up: 6 Changed 15 months ago by
@sergey: there are no build.ninja
files anywhere, I believe that's where gn
comes in.
comment:6 follow-up: 9 Changed 15 months ago by
Replying to Antoine Martin:
@sergey: there are no
build.ninja
files anywhere, I believe that's wheregn
comes in.
Sure. 1st of all it's necessary to generate build configs:
gn gen <directory>
For example:
gn gen out/Default
And then
ninja -C out/Default pdfium_all
If you see error
gn.py: Could not find checkout in any parent of the current path. This must be run inside a checkout.
your checkout is not full. I do not think it's possible to build pdfium with just clone the repository. It's necessary to checkout all dependencies. I've try official way and it did work on my Fedora:
mkdir repo cd repo gclient config --unmanaged https://pdfium.googlesource.com/pdfium.git gclient sync cd pdfium
comment:7 Changed 15 months ago by
Security Risks of PDFium-based Apps and SDKs: The high number of reported PDFium vulnerabilities compared to some PDF libraries doesn’t necessarily imply an unusual degree of insecurity for open source; but it creates challenges for developers, DevSecOps?, and security teams.
comment:8 Changed 15 months ago by
Another option would be to cherry pick some of the fixes and apply them to the version in mingw.
Some of the fixes may not be needed.
ie:
- https://nvd.nist.gov/vuln/detail/CVE-2019-5868 Use after free in PDFium in Google Chrome prior to 76.0.3809.100 allowed a remote attacker to potentially exploit heap corruption via a crafted PDF file. Issue 983867: Security: Use-after-free in CPDFSDK_ActionHandler::ExecuteFieldAction
- https://nvd.nist.gov/vuln/detail/CVE-2019-13721 Use after free in PDFium in Google Chrome prior to 78.0.3904.87 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. https://bugs.chromium.org/p/chromium/issues/detail?id=1013868 (no details yet)
Commits:
- Replace UnownedPtr with RetainPtr to parser objects in fpdfdoc
- Remove const from public fpdfview types
The last change in mingw: update to latest branch (2729) : Diego Sogari committed on May 9, 2016..
comment:9 Changed 15 months ago by
Replying to Sergey:
Sure. 1st of all it's necessary to generate build configs:
..
I do not think it's possible to build pdfium with just clone the repository.
Looks like they managed to do it in MSYS2.
Things have changed since the build file was made and adapting it to the new code is hard, so now I am leaning towards applying the fixes to that branch instead.
Here's the build file: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-pdfium-git/PKGBUILD.
And here is the patch I am most interested in applying: https://pdfium-review.googlesource.com/changes/pdfium~57854/revisions/8/patch?zip
If you want to try it, it should be trivial using an mswindows box:
- install MSYS2
- clone https://github.com/msys2/MINGW-packages
- go to
MINGW-packages/mingw-w64-pdfium-git
- run
makepkg -sCLf
comment:10 Changed 12 months ago by
Milestone: | 4.0 → 4.1 |
---|
Upstream ticket: update pdfium-git / git fetch fails.
comment:11 Changed 5 months ago by
Milestone: | 4.1 → 4.2 |
---|
comment:12 Changed 3 months ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
As suggested in the MINGW-packages ticket I had created: update pdfium-git / git fetch fails: switching to pdfium-binaries in r28023 "fixes" things and saves me having to figure out how to build this beast.
We're using the plain x64
DLL build, I don't think we need anything from the PDFium with V8 and XFA
variant. (in fact, it is a lot safer to not include all this extra code)
comment:14 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2470