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

141–150 of 158 posts

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

#141

Post by robertlagrant »

growse wrote: post #139
tharkun__ wrote: post #132

Earlier quoted context omitted.

The point of input in any case is that you are going to validate it and then process it. Any input that isn't validated should not be trusted, even in the most benign scenarios and triply so in security relevant contexts. Someone specifies the `null` algorithm? Reject the token outright, someone's trying fudge things. Someone specifies the `blahwhatever` algorithm that you actually trust yourself. Sure, try that algo…

The existence of algorithm confusion attacks shows that it's not nearly as simple as just saying "Reject 'null'". It's a complete minefield, and the fact that the JWT scheme punts that complexity and "make sure you hold it correctly!" onto the application is bad . Had the algorithm been standardised to a single value out of band (ie. in the spec), that would have squashed a whole load of vulnerabilities.

What whole load is that? The only one I know of is the (silly) existence of the null algorithm.

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

#142

Post by tzs »

lambda wrote: post #114
robertlagrant wrote: post #102

Earlier quoted context omitted.

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!

The assertion was that allowing signatures for sub-parts of the information is extremely fragile. Your example of null signatures being allowed would equally affect sub-part signing and whole document signing, so doesn't really show that sub-part signing is a problem.

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

#144

Post by tptacek »

DaiPlusPlus wrote: post #140
tptacek wrote: post #135

Earlier quoted context omitted.

https://fly.io/blog/api-tokens-a-tedious-survey/

Nothing in that article mentions any kind of "fragility" in JWT's design - and the issues it documents (e.g. consumers overrwriting the signature portion) concern only extremely non-compliant (i.e. dodgy) JWT scenarios - which sounds like someone applying a bodge because they were forced to implement JWT because it was thrust onto them, usually because JWT is already so popular already - so it's nothing inherent in J…

No, none of that is true. Follow the links, too. Really, the whole article is about how to do better than JWT in an auth token format.

It's always interesting to come across people who are surprised by things like JWT being considered a poor format. The only reason you don't see this said all the time in 2023 is that it was settled years ago. Cryptography engineers hate JWT.

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

#145

Post by growse »

robertlagrant wrote: post #141
growse wrote: post #139

Earlier quoted context omitted.

The existence of algorithm confusion attacks shows that it's not nearly as simple as just saying "Reject 'null'". It's a complete minefield, and the fact that the JWT scheme punts that complexity and "make sure you hold it correctly!" onto the application is bad . Had the algorithm been standardised to a single value out of band (ie. in the spec), that would have squashed a whole load of vulnerabilities.

What whole load is that? The only one I know of is the (silly) existence of the null algorithm.

For example: simply take a valid identity's public key, and use it as the secret to forge a token with alg=hs256. A service receiving this token will use its copy of the public key (by key id) to verify the signature, but because it's being told that it's an HMAC-signed token, will construct an HMAC.

Of course this HMAC will verify correctly because both you (the attacker) and the server hold the same public key used. And now the server thinks its a legitimate JWT because the signature is valid.

Mixing symmetric and asymmetric cryptography types in the same message scheme is just one of the many ways in which JWT is a bad idea.

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

#146

Post by Foobar8568 »

necovek wrote: post #97
beambot wrote: post #95

Earlier quoted context omitted.

Managing electronic signatures (e.g. DocuSign & file storage) is a 10x improvement for me compared to printing, signing, mailing or faxing, and file cabinets. The complexity & reduced costs are definitely worth it. YMMV.

DocuSign is a very weak signing system: signatures it produces are forgeable by anyone getting even a temporary access to an email (eg sitting on an unlocked computer or grabbing an unlocked phone), and the graphical part is something anyone can't replicate twice, unless you use one of their fonts making it even more easily forgeable. I don't even remember seeing an option to say that a particular email should always…

Because you believe that a wet paper signature is actually better or even verified? And you have multiple levels of requirements in e-signature.

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

#147

Post by bombcar »

D13Fd wrote: post #11

> For documents of prime importance, such as contracts and invoices Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off. Why? Because it has worked that way for hundreds of years. It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic…

It's been said repeatedly that high-level business deals (think: Manhattan real estate) are done with handshakes, because if you're not worth your word, you're done in the business.

You might fight over the terms, but once you say "ok" you're not going to fight over "that wasn't me who signed it".

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

#148

Post by necovek »

Foobar8568 wrote: post #146
necovek wrote: post #97

Earlier quoted context omitted.

DocuSign is a very weak signing system: signatures it produces are forgeable by anyone getting even a temporary access to an email (eg sitting on an unlocked computer or grabbing an unlocked phone), and the graphical part is something anyone can't replicate twice, unless you use one of their fonts making it even more easily forgeable. I don't even remember seeing an option to say that a particular email should always…

Because you believe that a wet paper signature is actually better or even verified? And you have multiple levels of requirements in e-signature.

There are strong electronic signatures which are as safe as a signature can be: iow, a question of who generated the key (an issue with keys provided by official cert authorities) and how is it kept safe at rest (basically, how much care a user takes of them).

DocuSign is, in general, neither of these. I am sure there are less convenient options with DocuSign than the email based one, but I've only ever been asked to "sign" by attempting to draw my signature using a mouse or their own font.

I'd rather have someone attempt to forge my handwriting which experts can usually detect, and which requires a bit more sophistication: my concern is not about them being validated, but that instead if I claim how that's not my signature, I can easily provide a bunch of past signatures to an expert to prove my point.

There are free software and free hardware tokens which can generate secure certificates to use for encryption or signing. I would probably trust those best.

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

#149

Post by zajio1am »

dfox wrote: post #90
kjetil wrote: post #74

Earlier quoted context omitted.

In the EU (and EEA), eIDAS distinguishes between - "electronic signatures", which can be any electronic data used to sign, like a drawn signature - "advanced electronic signature" (AdES), usually a type of digital signature (XML-DSig, PDF signature, etc.) - "qualified electronic signature (QES), which is a digital signature created by a certified signature device QES is legally equivalent to a "wet signature", but in…

AdES is mostly an technical standard that specifies how to use existing PKCS and IETF standards to produce eIDAS conforming signature, timestamp or “seal” (ie. timestamped signature) and how that should be mapped onto CMS (CAdES), XML-Signature (XAdES) and PDF (PAdES). How legally binding the result of that process is then depends on things like QSCTs, their LoA used in that and such things. And then there are variou…

> for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that)

AFAIK that is not true. In CZ national law, there is also recognized electronic signature (RES, "uznávaný elektronický podpis"), which may be either QES (per eIDAS, "kvalifikovaný elektronický podpis"), or just AdES based on certificate from qualified CAs (per national law, "zaručený elektronický podpis, založený na kvalifikovaném certifikátu").

If you use QSCD to generate CSR and get it signed by right CA, you get QES, but if you use just 'openssl req' to generate CSR and get it signed by right CA, you get RES that is not QES.

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

#150

Post by ljm »

lambda wrote: post #114
robertlagrant wrote: post #102

Earlier quoted context omitted.

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!

It’s also difficult to actually get people on board with the idea of supplying a user-specific signing key instead of relying on a global one.

Instead they’ll end up persisted in a data store, making them stateful, because there’s no reliable way to invalidate such a token simply by rotating the signing key. Or using a cookie-backed session.

Post reply on HN