Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

usenix.org

Post reply on HN
Print view View original

111–120 of 158 posts

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#111

Post by denton-scratch »

tptacek wrote: post #85
denton-scratch wrote: post #83

Earlier quoted context omitted.

> Never sign XML "XML" is ambiguous. You have to understand what exactly you're signing, which the average notary or whatever doesn't know. And you have to know what you're verifying, which is equally difficult. Office documents are (extremely complicated) XML; so it's hardly surprising that they adopted a signature scheme that involves signing XML. But this sounds cowboyish; along the lines of "No reputable security…

I don't see what's ambiguous here. I'm saying: never sign anything XML-encoded. Never use XML signatures.

Heh!

I wasn't saying you were ambiguous; I meant that "XML" can mean the system of nodes that is an XML document; a string that is a representation of that document; and the specific string that was parsed to create the document.

An infinite number of strings can describe the same document, because there is the concept of ignorable whitespace when parsing XML. So "XML" is ambigous because the acronym could mean any of several things; and ambiguous the other way, because XML allows multiple string representations of the same object.

[Edit] So I don't know how you can sign an "XML document"; the only thing I know how to make a signature for is a specific serialization of that document. May be someone's invented a way of signing the abstract document object, but I haven't heard of it.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#112

Post by robertlagrant »

kevincox wrote: post #103
robertlagrant wrote: post #102

Earlier quoted context omitted.

I don't see why that's fragile? E.g. JWTs work this way.

No they don't. JWTs sign the whole token.

They sign the header and payload. The third section is the signature itself.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#113

Post by g_p »

robertlagrant wrote: post #112
kevincox wrote: post #103

Earlier quoted context omitted.

No they don't. JWTs sign the whole token.

They sign the header and payload. The third section is the signature itself.

And (unless you manually fix your verification approach) they trust the (unverified at that time) header to declare the signature method used... Which at one point many implementations would accept as "null".

So you could take a signed JWT, strip the signature, and set the header to indicate to the verified a null signature was verified.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#114

Post by lambda »

robertlagrant wrote: post #102
hannob wrote: post #57

I feel there are some fundamental misconceptions about signatures that are baked into many of these older standards. There have been similar attacks on XML signatures, email signatures and PDF files (with some overlapping authors). It usually comes down to creating some complex formats where signatures are allowed to sign sub-parts of the information. This is an extremely fragile design, and should probably be consid…

I don't see why that's fragile? E.g. JWTs work this way.

JWTs are the poster child of fragile signature design. If something is like JWTs, you should reconsider. Many implementations allowed JWTs with a null signature scheme, completely bypassing any security!

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#115

Post by kevincox »

robertlagrant wrote: post #112
kevincox wrote: post #103

Earlier quoted context omitted.

No they don't. JWTs sign the whole token.

They sign the header and payload. The third section is the signature itself.

That is effectively "the full token". It is pretty difficult to sign the signature.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#116

Post by kevincox »

g_p wrote: post #113
robertlagrant wrote: post #112

Earlier quoted context omitted.

They sign the header and payload. The third section is the signature itself.

And (unless you manually fix your verification approach) they trust the (unverified at that time) header to declare the signature method used... Which at one point many implementations would accept as "null". So you could take a signed JWT, strip the signature, and set the header to indicate to the verified a null signature was verified.

Yes. This is definitely one of the weaknesses of JWT. It is prudent to whitelist the allowed headers. And the fact that any implementations accepted `null` as an algorithm is awful.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#117

Post by robertlagrant »

g_p wrote: post #113
robertlagrant wrote: post #112

Earlier quoted context omitted.

They sign the header and payload. The third section is the signature itself.

And (unless you manually fix your verification approach) they trust the (unverified at that time) header to declare the signature method used... Which at one point many implementations would accept as "null". So you could take a signed JWT, strip the signature, and set the header to indicate to the verified a null signature was verified.

This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#118

Post by robertlagrant »

kevincox wrote: post #115
robertlagrant wrote: post #112

Earlier quoted context omitted.

They sign the header and payload. The third section is the signature itself.

That is effectively "the full token". It is pretty difficult to sign the signature.

It is, but that is the topic at hand:

> Signatures should really just be applied to whole files or data structures, everything else should be considered dangerous

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#119

Post by growse »

robertlagrant wrote: post #117
g_p wrote: post #113

Earlier quoted context omitted.

And (unless you manually fix your verification approach) they trust the (unverified at that time) header to declare the signature method used... Which at one point many implementations would accept as "null". So you could take a signed JWT, strip the signature, and set the header to indicate to the verified a null signature was verified.

This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.

> This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.

What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#120

Post by maccard »

growse wrote: post #119
robertlagrant wrote: post #117

Earlier quoted context omitted.

This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format.

> This is possible with anything, though. If your verification code trusts the input, that's bad. That's not a structural weakness of the JWT format. What's the purpose of the algorithm field in the header if clients shouldn't trust it? It's "input", after all...

There's a difference between trust and blindly trusting.
Post reply on HN