> > > 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. >
I do not think that allowing xref entries shorter than 20 chars is vulnerability. On the other side it could extend supported PDFs (if such PDFs really exists). > 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. > Or there is hole in standard: https://pdfsig-collision.florz.de In contracts with first two attacks seems SWA does not violate standard, at least not with ByteRange key. From what I see in pdf reference there is nothing what states that byte range must not include only contents. And there is also not stated that there must be always exactly two ranges. But seems for example acrobat reader does not accept more than 2 ranges and checks whether byte range covers what it should. 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! > > >From what I read about SWA I really do not think that too short xref entry had role in that attack. I rather think that this is simply mistake or bug in software which manipulated these pdf files. Only one entry is shorter and there is sequence CR+LF+LF at the end of xref right before "trailer". I am sending fixed version. Can you try it? 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. > > These attack pdf files are supposed to load correctly, signature verification part must handle and resist them. Greetings > F.E. > _______________________________________________ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users >
siwa.pdf
Description: Adobe PDF document
_______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
