Re: [Podofo-users] [PATCH] PoFoFo: fix CVE-2018-5296 by reducing limit in s_nMaxObjects
Hello Mark, hello all, > On 15 April 2018 at 22:06 Mark Rogers wrote: > > > Hi > > > Here’s a simple patch for CVE-2018-5296 – it reduces the limit returned > by GetMaxObjectCount from std::numeric_limits::max() to 8,388,607 which > is the limit for for the maximum number of indirect objects specified > in Table C.1 in Appendix C.2 Architectural Limits in PDF 32000-1:2008 > the standard says there the limits are 32-bit systems whereas PoDoFo uses 64-bit types in many places, therefore I'm feeling a bit uneasy with the patch: Can anyone please shed some more light on this issue? > > Best Regards > > > Mark > Best regards, mabri -- 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-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] CVE-2017-5855 and CVE-2017-6844
Hello Mark, hello all, > On 15 April 2018 at 18:32 Mark Rogers wrote: > > > Hi > > > I’ve been trying to write unit tests for CVE-2017-5855 and CVE-2017-6844, and > now think both are false positives due to a bug in Address Sanitizer > triggered > by large values passed to std::vector::resize() > > > CVE-2017-6844 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6844 > > https://blogs.gentoo.org/ago/2017/03/02/podofo-global-buffer-overflow-in-podofopdfparserreadxrefsubsection-pdfparser-cpp/ > > > the stack trace shows the problem occurring in a call to > std::vector::resize(count) > > > CVE-2017-5855 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5855 > > https://blogs.gentoo.org/ago/2017/02/01/podofo-null-pointer-dereference-in-podofopdfparserreadxrefsubsection-pdfparser-cpp/ > > > the stack trace shows the problem occurring in a call to > std::vector::resize(count) > > > Without ASAN enabled std::vector::resize with a large count will throw a > std::bad_alloc and be > caught by the catch( std::exception ) statement in ReadXRefSubsection that try/catch was introduced in svn r1843: https://sourceforge.net/p/podofo/code/1843 so CVE-2017-5855 is unlikely to be entirely a false positive (although it could be a DoS "only", a crash by std::bad_alloc not being caught), and AFAICS CVE-2017-6844 is no false positive either because adding two numbers whose sum is too too large for their type can (NB: this is UB, Undefined Behaviour) make the result much smaller (when MSB carry is ignored) and the guard against this was introduced in svn r1840: https://sourceforge.net/p/podofo/code/1840 These commits were performed much later than the CVEs were assigned. > > > Does this analysis make sense? > Summing up: No, at least your conclusion that the named CVEs are false positives is wrong AFAICS. > > Best Regards > > > Mark Best regards, mabri -- 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-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] ABI incompatible changes
On Mon, Apr 16, 2018 at 12:14:59PM +0200, Antonio Larrosa wrote: > Then I checked the full list of changes between 0.9.5 and current > code in trunk and noticed there are many changes that give an > incompatible ABI with respect to 0.9.5 . > > Is there any policy with respect to maintaining ABI compatibility in > different versions of the library? I think it's important for users > to keep a compatible ABI, as otherwise, any update forces a rebuild > of all applications using podofo PoDoFo bumps SONAME in each release, and it has always been like that. As you noticed there are plenty of ABI changes (just looking at the symbols… I haven't actually checked public enums, structs etc). Trying to avoid a single one is kind of pointless. BTW, before trying to achieve some kind of ABI stability, there are plenty of private symbols that leak, which makes tracking ABI very hard¹ > and some times, that's not easy for users to do. That's why in the linux world there distributors between developers and users, to take care of this kind of stuff (that falls in the bigger word of "integration"). And those users that build directly PoDoFo themeselves, they better know what a shared library is and how to handle it, otherwise they probably shouldn't do what they are doing. ¹ I try this pretty much at every release: https://salsa.debian.org/debian/libpodofo/commit/5e4030ce3b889907eb888fdf072cbab466c0b7cb https://salsa.debian.org/debian/libpodofo/commit/df41e92eb97c42f3b3b7f8c60d3d256a2963e0c4 https://salsa.debian.org/debian/libpodofo/commit/4217d13c7e3501331e81ceab67e30ae833db1b5a https://salsa.debian.org/debian/libpodofo/commit/6ff3485962aa9844ed600c0ff7d1461d4d36079b Between the last one and the others I've spent some hours trying to get something that worked for more than only amd64, but there are several symbols that varies across all archs (which is kind of fine, it's due to things like size_t, ssize_t, uint64_t, etc, but there are really too many and I'm convinced very few of them should be visible). -- 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 `- signature.asc Description: PGP signature -- 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-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] ABI incompatible changes
On Mon, 2018-04-16 at 12:14 +0200, Antonio Larrosa wrote: > Is there any policy with respect to maintaining ABI compatibility in > different versions of the library? Hi, as long as such release also bumps the soname version it's all fine. There had been brought this question here in the past too, and PoDoFo does increases its soname version each release. I agree with you that it might be ideal to not do API/ABI changes, but it's sometimes important, either for simplicity, code maintenance or for readability of the code. Bye, zyx -- 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-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] ABI incompatible changes
Hello, While having a look at the changes done in 0.9.5 to fix several CVEs, I noticed a quite easy to fix ABI incompatible change that was introduced in r1835. In that patch, a new ePdfError_BrokenFile constant was added to the EPdfError enum, the problem is that it was inserted between other values, so that changed the values of all the constants below it. This breaks the ABI, since code built to check for a value will check for a different integer value in 0.9.5 and 0.9.6. This can be fixed as easily as moving the new ePdfError_BrokenFile constant to the end of the enum list (right before ePdfError_Unknown = 0x). Then I checked the full list of changes between 0.9.5 and current code in trunk and noticed there are many changes that give an incompatible ABI with respect to 0.9.5 . Is there any policy with respect to maintaining ABI compatibility in different versions of the library? I think it's important for users to keep a compatible ABI, as otherwise, any update forces a rebuild of all applications using podofo, and some times, that's not easy for users to do. Btw, in this link there's a list of things that can and can't be done when developing a library in order to keep a compatible ABI, just in case it's useful: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B Thanks! -- Antonio Larrosa -- 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-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
