[Podofo-users] another bunch of crashes

[Agostino Sarubbo]

Please consider the following:

https://blogs.gentoo.org/ago/2017/03/02/podofo-invalid-memory-read-in-colorchangergetcolorfromstack-colorchanger-cpp/
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-graphicsstacktgraphicsstackelementtgraphicsstackelement-graphicsstack-h/
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-colorchangergetcolorfromstack-colorchanger-cpp/
https://blogs.gentoo.org/ago/2017/03/02/podofo-heap-based-buffer-overflow-in-podofopdfvariantdelayedload-pdfvariant-h/
https://blogs.gentoo.org/ago/2017/03/02/podofo-global-buffer-overflow-in-podofopdfparserreadxrefsubsection-pdfparser-cpp/
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-podofopdfcoloroperator-pdfcolor-cpp/
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-graphicsstacktgraphicsstackelementsetnonstrokingcolorspace-graphicsstack-h/
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-podofopdfvariantdelayedload-pdfvariant-h/
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-podofopdfxobjectpdfxobject-pdfxobject-cpp/
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-podofopdfcolorgraypdfcolorgray-pdfcolor-cpp/

[Mattia Rizzolo]




All of these now have CVEs associated.

I find the Debian view for security issues particularly nice to look at:
https://security-tracker.debian.org/tracker/source-package/libpodofo

[Mattia Rizzolo]

Post by Mattia Rizzolo




All of these now have CVEs associated.

And apparently the Debian release team is considering these severe
enough to warrant removing libpodofo from the next debian stable release
rather then leaving them unfixed (http://bugs.debian.org/856592).
I severely lack time (and real proper knowledge) to start to help with
these, but I'd appreciate if you could prioritize them.

Post by Mattia Rizzolo
https://security-tracker.debian.org/tracker/source-package/libpodofo

[Mark Rogers]

Is there any way to use SourceForge tickets just for security bugs?

It looks like some CVEs have been fixed, some CVE patches rejected, but there’s no way from the mailing list to tell which CVEs have been fixed because most of the mailing list and commit messages don’t reference the CVEs.

At the moment it’s hard even to contribute patches because there’s no way to tell which CVEs are fixed, which are being worked on, and which are still outstanding.

If SourceForge tickets don’t work is there another alternative , for example, an empty GitHub repo with an issue tracker?

Best Regards
Mark

Mark Rogers - ***@powermapper.com
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL

Post by Mattia Rizzolo

…

All of these now have CVEs associated.

And apparently the Debian release team is considering these severe
enough to warrant removing libpodofo from the next debian stable release
rather then leaving them unfixed ().
I severely lack time (and real proper knowledge) to start to help with
these, but I'd appreciate if you could prioritize them.

Post by Mattia Rizzolo
https://security-tracker.debian.org/tracker/source-package/libpodofo

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

[zyx]

Post by Mark Rogers
Is there any way to use SourceForge tickets just for security bugs?

Hi,
if the folks are not used to issue tracker then having "only for
certain type of issues" would not work, I'm afraid. Not talking that
you cannot teach outer audience about when to use it and when not.

Post by Mark Rogers
It looks like some CVEs have been fixed, some CVE patches rejected,
but there’s no way from the mailing list to tell which CVEs have been
fixed because most of the mailing list and commit messages don’t
reference the CVEs.

Right. It had been just a coincidence that two people here reported one
same issue and I happen to fix it without the reference (also because I
didn't use Agostino's reference, but that other person's).

I had a private chat with Agostino on Tuesday, he asked me to drop a
commit link to his blog post when the change references one of those
issues, from which I understood that he'll update the Debian summary
page (link given earlier in this thread).

Post by Mark Rogers
At the moment it’s hard even to contribute patches because there’s no
way to tell which CVEs are fixed, which are being worked on, and
which are still outstanding.

All except "which are being worked on" is on the Debian summary page.
Even I plan to look on them, then I do not know when, thus I do not do
any false promises, time lines, nothing like that. I'll surely check
the Debian page first, and also this list for any outstanding patches,
before starting on anything.

Post by Mark Rogers
If SourceForge tickets don’t work is there another alternative , for
example, an empty GitHub repo with an issue tracker?

No, please do not. You give false expectations to the users and
possible contributors, which is harmful for the project itself.

Bye,
zyx

[Mattia Rizzolo]

Post by zyx
Right. It had been just a coincidence that two people here reported one
same issue and I happen to fix it without the reference (also because I
didn't use Agostino's reference, but that other person's).

I think it would be greatly appreciated (from me at least), if the CVE
IDs were to be included in the commit message. That would be more than
enough to reference such issues unambiguously.

Post by zyx
I had a private chat with Agostino on Tuesday, he asked me to drop a
commit link to his blog post when the change references one of those
issues, from which I understood that he'll update the Debian summary
page (link given earlier in this thread).

I also can update that summary page whenever is needed (talking about
https://security-tracker.debian.org/tracker/source-package/libpodofo,
and all of those referenced from there)
If you need so feel free to drop me a line.

[zyx]

Post by Mattia Rizzolo
https://security-tracker.debian.org/tracker/source-package/libpodofo

Hi,
I made a little walk-through of the CVEs and
https://security-tracker.debian.org/tracker/CVE-2017-6846
references reproducer for CVE-2017-6845, it should be
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-graphicsstacktgraphicsstackelementsetnonstrokingcolorspace-graphicsstack-h/
instead.

I'm currently at revision 1842 and I cannot reproduce CVE-2017-6841,
CVE-2017-6845, CVE-2017-6846, CVE-2017-6849, CVE-2017-8053 and that
TEMP-0854605-651F03, which end with exception, instead of crashing,
thus I guess they've got fixed meanwhile. I do not get any invalid
read/write from valgrind too. It's possible that my environment doesn't
reproduce for whatever reason, though I had no problem to reproduce
almost all other CVEs locally. It would be great if anyone could
confirm with latest trunk.
Bye,
zyx

[Mattia Rizzolo]

Post by zyx
I made a little walk-through of the CVEs and
https://security-tracker.debian.org/tracker/CVE-2017-6846
references reproducer for CVE-2017-6845, it should be
https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-graphicsstacktgraphicsstackelementsetnonstrokingcolorspace-graphicsstack-h/
instead.

Uops, copy-paste failure on my side, fixed, thank you!
I suppose I could start cherry-picking the one with a fix, so the index
would get a bit more clear

Post by zyx
TEMP-0854605-651F03, which end with exception, instead of crashing,

btw, about this thing, I asked for a CVE, and was denied as "not a
security bug"

[zyx]

....

Hi,
I tried on couple of CVE-s, using trunk at revision 1834. I chose to
behave in a non-forgiving way, but feel free to discuss those
"solutions" here, if you can think of anything better.

CVE-2017-5852 - fixed with revision 1835:
http://sourceforge.net/p/podofo/code/1835

CVE-2017-5854 - fixed with revision 1836:
http://sourceforge.net/p/podofo/code/1836

CVE-2017-5886 - fixed with revision 1837:
http://sourceforge.net/p/podofo/code/1837

Bye,
zyx

[Mark Rogers]

Hi

I’ve been doing some patching over the past couple of days and have patches for most of the CVEs.

I think the patch in r1835 fixes the case where pObj == pObj->GetParent() but I don’t think it fixes cases where pObj == pObj->GetParent()->GetParent() or pObj->GetParent() == pObj->GetParent()->GetParent(). There’s also the problem of an attacker deliberately creating a PDF with very deeply nested objects to cause a stack overflow.

This patch adds a recursion depth counter and throws an error if the recursion gets too deep. It’s probably worth combining the patches since the pObj == pObj->GetParent() case is probably the most common, but the depth check covers other types of loops in the “Parent” structure and protects against deeply nested PDFs

Best Regards
Mark

--
Mark Rogers - ***@powermapper.com
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL

....

Hi,
I tried on couple of CVE-s, using trunk at revision 1834. I chose to
behave in a non-forgiving way, but feel free to discuss those
"solutions" here, if you can think of anything better.

CVE-2017-5852 - fixed with revision 1835:
http://sourceforge.net/p/podofo/code/1835

CVE-2017-5854 - fixed with revision 1836:
http://sourceforge.net/p/podofo/code/1836

CVE-2017-5886 - fixed with revision 1837:
http://sourceforge.net/p/podofo/code/1837

Bye,
zyx

--
http://www.litePDF.cz ***@litePDF.cz

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Podofo-users mailing list
Podofo-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

[zyx]

I’ve been doing some patching over the past couple of days and have
patches for most of the CVEs.

Hi,
okay, I'll wait for your changes then.

I think the patch in r1835 fixes the case where pObj == pObj-

GetParent() but I don’t think it fixes cases where pObj == pObj-
GetParent()->GetParent() or pObj->GetParent() == pObj->GetParent()-
GetParent(). There’s also the problem of an attacker deliberately

creating a PDF with very deeply nested objects to cause a stack
overflow.

Yes, that's true. One of the reasons why I asked for discussion of
those changes.

I committed your change as revision 1838:
http://sourceforge.net/p/podofo/code/1838
Bye,
zyx

[zyx]

Hi,
I looked on other bunch of the CVEs and here's the result:

CVE-2017-5855 - fixed with revision 1843.
http://sourceforge.net/p/podofo/code/1843

CVE-2017-6840 - fixed with revision 1844+revision 1845. It fixes also
CVE-2017-6842 and CVE-2017-6843.
http://sourceforge.net/p/podofo/code/1844
http://sourceforge.net/p/podofo/code/1845

CVE-2017-6847 - fixed with revision 1846. It fixes also CVE-2017-6848.
http://sourceforge.net/p/podofo/code/1846

CVE-2017-7378 - fixed with revision 1847.
http://sourceforge.net/p/podofo/code/1847

CVE-2017-7380 - fixed with revision 1848. It fixes also CVE-2017-7381,
CVE-2017-7382 and CVE-2017-7383.
http://sourceforge.net/p/podofo/code/1848

CVE-2017-7994 - fixed with revision 1849.
http://sourceforge.net/p/podofo/code/1849

There currently lefts only CVE-2017-8054, as far as I know. I'm
currently unsure how to fix it. Once it will be done it would be good
to retest all the CVEs on some other machine, because it's possible
that my build environment could hid some issues, thus a re-check
against svn trunk by someone being able to reproduce all the issues
would be highly appreciated.

Bye,
zyx

[Mattia Rizzolo]

I've uploaded to Debian unstable most of the patches.

To my count, this leaves out:
https://security-tracker.debian.org/tracker/CVE-2017-8787
https://security-tracker.debian.org/tracker/CVE-2017-8378
https://security-tracker.debian.org/tracker/CVE-2017-8054

Also, the following are claimed by you to be unreproducible in current
trunk, it would be very cool if somebody could identify the fixing
commits:
https://security-tracker.debian.org/tracker/CVE-2017-8053
https://security-tracker.debian.org/tracker/CVE-2017-6849
https://security-tracker.debian.org/tracker/CVE-2017-6846
https://security-tracker.debian.org/tracker/CVE-2017-6845
https://security-tracker.debian.org/tracker/CVE-2017-6841


Just for the record, I didn't upload the patches for the following
because the first one breaks the ABI and I'm not happy to do it (two
choices here: either break it as it's a private method anyway, or
provide a wrapper), and the other is quite invasive and didn't have the
chance to sit long enough with it.
https://security-tracker.debian.org/tracker/CVE-2017-5852
https://security-tracker.debian.org/tracker/CVE-2017-7994

I got rid of that TEMP-
 issue, as Mitre claimed it's not CVE-worthy,
and you said it's fixed in trunk either way.

[zyx]

Hi,

Post by Mattia Rizzolo
https://security-tracker.debian.org/tracker/CVE-2017-8787

Fixed with revision 1851:
http://sourceforge.net/p/podofo/code/1851

Post by Mattia Rizzolo
https://security-tracker.debian.org/tracker/CVE-2017-8378

This cannot be reproduced with revision 1850, it ends with
ePdfError_InvalidEncryptionDict exception. This applies to
revision 1842 (see another thread here).

Post by Mattia Rizzolo
https://security-tracker.debian.org/tracker/CVE-2017-8054

I've still no good idea about this one, I'm sorry.
Bye,
zyx