You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Wolfgang Bauer <Wo...@xitrust.com> on 2019/02/28 09:04:12 UTC
PDF Signature Spoofing
Hello everybody,
as you have probably already heard, there are currently new attacks on
pdf signatures very popular in the media.
https://www.pdf-insecurity.org/
In particular the demo doucuments of Attack 2: Incremental Saving
Attack and Attack 3 can be parsed with the pdfbox library and the
ShowSignature example even validates the malicious signatures.
Are there any plans to include some validation steps into pdfbox to
cope with these problems?
Thanks
Wolfgang
Re: PDF Signature Spoofing
Posted by Wolfgang Bauer <Wo...@xitrust.com>.
Hi Tilman,
thanks for the hint with the lenient mode (I wasn't aware of this
feature, as it is not exposed by the static PDDocument.load methods).
I tried it and now the COSParser throws an Exception as expected.
>
> Can you explain what you mean? I thought that the current check did
> just
> that.
>
As far as I understood the attack, the signature object is modified by
the attacker and the /Byterange modified in such a way that the
cryptographically verification still holds (the gap between the two
signed ranges is increased). As a result of this, the actually used
/Byterange (the modified one) is no longer part of the signed data.
So my first idea was to check if the actually used /Byterange array is
covered by the signature (is not in the unsigned gap).
Anyway, I think turning off the lenient mode together with the "covers
whole document" check, should provide an adequate security level.
Thanks a lot for your valuable feedback,
Wolfgang
Re: PDF Signature Spoofing
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 28.02.2019 um 16:24 schrieb Wolfgang Bauer:
> Hi Tilman,
>
> thanks for the quick response.
>
>
> All of my tests had the "Signature does not cover whole document" in the output. This result is obvious for the Incremental Saving Attack.
>
>
> For the more advanced Signature Wrapping attack the check
>
> byteRange[1] + contentLen != byteRange[2]
>
> triggers the output (at least for the provided test document).
>
>
> If you have a signature with many 0 padding bytes the malicious code might be placed without changing the contentLen. But it should not be possible to replace the xref table without changing the contentLen.
>
>
> So the "Signature does not cover whole document" - check should be sufficient to cope with these attacks. Do you agree or do you see any additional attack scenario?
TBH I haven't had the time to study the paper in detail. What I did read
sounded scary, especially the third attack. I did try the files and all
had the "Signature does not cover whole document".
> Nevertheless I would feel more comfortable, if we had a “more robust” mechanism to detect malicious documents. E.g. reject documents as described in the “Incremental Saving Attack” as they are not PDF compliant at all.
My thought is to switch off lenient mode when checking signatures, in
the hope that this would detect these files as malformed. I haven't
tested it yet.
>
> Additionally, I'd like to add a check if the actually used /ByteRange array is covered by the signature. Is there an easy way to implement this?
Can you explain what you mean? I thought that the current check did just
that.
Tilman
>
>
> Thanks
>
> Wolfgang
>
>
>
>
>
>
> On Don, 2019-02-28 at 10:33 +0100, Tilman Hausherr wrote:
> did it have "signature covers whole document" at the beginning of the
> output?
>
> Tilman
>
>
> ------------------------------------------------------------------------
> Gesendet mit der Telekom Mail App
> <https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer>
>
>
>
> --- Original-Nachricht ---
> Von: Wolfgang Bauer
> Betreff: PDF Signature Spoofing
> Datum: 28.02.2019, 10:04 Uhr
> An: users@pdfbox.apache.org<ma...@pdfbox.apache.org>
>
>
>
>
>
> Hello everybody,
>
> as you have probably already heard, there are currently new attacks on
> pdf signatures very popular in the media.
>
> https://www.pdf-insecurity.org <https://www.pdf-insecurity.org> /
>
> In particular the demo doucuments of Attack 2: Incremental Saving
> Attack and Attack 3 can be parsed with the pdfbox library and the
> ShowSignature example even validates the malicious signatures.
>
> Are there any plans to include some validation steps into pdfbox to
> cope with these problems?
>
> Thanks
> Wolfgang
>
> Xi-Events to come:
>
> 04.-08. März 2019 – RSA Conference 2019 <https://www.rsaconference.com/events/us19>
>
> 17. Mai 2019 – XiTrust Friends Network Event Red Bull Ring <https://www.xitrust.com/xitrust-network-event/>
>
> 17.-19. September 2019 – DSAG Jahreskongress 2019 <https://www.dsag.de/veranstaltungen/2019-09/dsag-jahreskongress-2019>
>
> 17.-19. September 2019 – Zukunft Personal Europe 2019 <https://www.europe.zukunft-personal.com/de/zpeurope19/>
>
>
> So geht Live Business 2018 – das neue MOXIS Video: https://youtu.be/r1rujX4dhvg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: AW: PDF Signature Spoofing
Posted by Wolfgang Bauer <Wo...@xitrust.com>.
Hi Tilman,
thanks for the quick response.
All of my tests had the "Signature does not cover whole document" in the output. This result is obvious for the Incremental Saving Attack.
For the more advanced Signature Wrapping attack the check
byteRange[1] + contentLen != byteRange[2]
triggers the output (at least for the provided test document).
If you have a signature with many 0 padding bytes the malicious code might be placed without changing the contentLen. But it should not be possible to replace the xref table without changing the contentLen.
So the "Signature does not cover whole document" - check should be sufficient to cope with these attacks. Do you agree or do you see any additional attack scenario?
Nevertheless I would feel more comfortable, if we had a “more robust” mechanism to detect malicious documents. E.g. reject documents as described in the “Incremental Saving Attack” as they are not PDF compliant at all.
Additionally, I'd like to add a check if the actually used /ByteRange array is covered by the signature. Is there an easy way to implement this?
Thanks
Wolfgang
On Don, 2019-02-28 at 10:33 +0100, Tilman Hausherr wrote:
did it have "signature covers whole document" at the beginning of the
output?
Tilman
------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer>
--- Original-Nachricht ---
Von: Wolfgang Bauer
Betreff: PDF Signature Spoofing
Datum: 28.02.2019, 10:04 Uhr
An: users@pdfbox.apache.org<ma...@pdfbox.apache.org>
Hello everybody,
as you have probably already heard, there are currently new attacks on
pdf signatures very popular in the media.
https://www.pdf-insecurity.org <https://www.pdf-insecurity.org> /
In particular the demo doucuments of Attack 2: Incremental Saving
Attack and Attack 3 can be parsed with the pdfbox library and the
ShowSignature example even validates the malicious signatures.
Are there any plans to include some validation steps into pdfbox to
cope with these problems?
Thanks
Wolfgang
Xi-Events to come:
04.-08. März 2019 – RSA Conference 2019 <https://www.rsaconference.com/events/us19>
17. Mai 2019 – XiTrust Friends Network Event Red Bull Ring <https://www.xitrust.com/xitrust-network-event/>
17.-19. September 2019 – DSAG Jahreskongress 2019 <https://www.dsag.de/veranstaltungen/2019-09/dsag-jahreskongress-2019>
17.-19. September 2019 – Zukunft Personal Europe 2019 <https://www.europe.zukunft-personal.com/de/zpeurope19/>
So geht Live Business 2018 – das neue MOXIS Video: https://youtu.be/r1rujX4dhvg
AW: PDF Signature Spoofing
Posted by Tilman Hausherr <TH...@t-online.de>.
did it have "signature covers whole document" at the beginning of the
output?
Tilman
------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<https://kommunikationsdienste.t-online.de/redirects/email_app_android_sendmail_footer>
--- Original-Nachricht ---
Von: Wolfgang Bauer
Betreff: PDF Signature Spoofing
Datum: 28.02.2019, 10:04 Uhr
An: users@pdfbox.apache.org
Hello everybody,
as you have probably already heard, there are currently new attacks on
pdf signatures very popular in the media.
https://www.pdf-insecurity.org <https://www.pdf-insecurity.org> /
In particular the demo doucuments of Attack 2: Incremental Saving
Attack and Attack 3 can be parsed with the pdfbox library and the
ShowSignature example even validates the malicious signatures.
Are there any plans to include some validation steps into pdfbox to
cope with these problems?
Thanks
Wolfgang