> 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
