> > This one tiny error totally breaks the loading of the whole file, bc > Podofo does not read the next subsection properly. > Instead of '8 5', he reads '5 958' as next sub section! > The tiny error does not break the whole loading process, I've mistaken this with other pdf files. In this case, like stated below, it 'only' disrupts the parsing of the following xref entries, resulting in the signature object not being parsed at all.
Am Mi., 6. März 2019 um 16:11 Uhr schrieb F. E. <[email protected]>: > > No, This is really not good idea. Probably many pdf which are working now >> with podofo will stop working. First pdf which I checked now has SPACE+LF >> and it opens fine in any possible pdf viewer. Also OpenOffice generates >> SPACE+LF (version 4.1.2 on windows probably). >> >> Also in pdf reference is stated that if end of line marker is single >> character then it is preceded by space, check page 94. >> > You are right, i didn't recognize that part. Maybe thats the reason why > the Tests fail as well. We could easily add that to the check, though (but > maybe with more than one line): > > bool emptyValid = false; >> if ( empty1 == '\r' ) { emptyValid = (empty2 == '\n'); } >> else if (empty1 == '\n' ) { emptyValid = (empty2 == '\r'); } // May be >> removed if LF+CR shall not be allowed! >> else if (empty1 == ' ') { emptyValid = (empty2 == '\n' || empty2 == '\r' >> ); } >> if ( read != 5 || !emptyValid ) >> > > Maybe better would be to check whether are both empty1 and empty2 >> whitespaces. >> > Yep, that would be better, agreed.All the patch should accomplish is > safely failing when the xref entry size is not correct. Bc right now it's a > gamble whether podofo fails to load or is parsing nonsense. > > On the contrary I think podofo is too strict. Maybe would be better that >> it actually can open these files with xref entries shorter or longer than >> 20 chars as readers from that page do. I think some readers are implemented >> to read xref table by lines (by using for example c++ function getline). >> > I disagree. To much leeway only creates more attack surface for malicious > pdfs, since parsing is alwas a delicate procedure. A lax handling of the > standard is the reason why the researchers had so much success with > tinkering pdf files for circumventing the signature check. To be more > specific, all the shown SIWA attacks use to-short xref entries. And it > looks that this is actually a requirement for this attacks, otherwise the > restrictions regarding offsets (secured by the signature) are much harder > to meet. > > >> I checked this file and all 3 xref tables has CR+LF > > Nope. Check it again, there is one entry with only LF: > In the second xref table, right before the '8 5' subsection, the entry > '0000005131 00000 n' is missing it. > > This one tiny error totally breaks the loading of the whole file, bc > Podofo does not read the next subsection properly. > Instead of '8 5', he reads '5 958' as next sub section! > > Trust me, I checked every pdf file provided by the researchers, more than > half of it had this error. Mostly the Load failed, but two of them could be > loaded (e.g. the one I linked earlier). For this two pdf files, I could not > find any siganture fields at all, bc. Podofo did not parse properly. The > reference to the signature object was there, but it pointed to a not > existing object. And thats the REAL issue here, when Podofo does NOT fail > at loading, but the parsed document is insufficient. > > Greetings > F.E. >
_______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
