13 ms·
Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
- urbandw311er 3y agoI can’t find a date for this paper, there is nothing on the web page or PDF
- layer8 3y agoOctober 4th 2022, according to the PDF date (and according to the "We have not received any feedback from OnlyOffice as of October 4th, 2022" in the PDF).
- proto_lambda 3y agoUSENIX '23 will take place in August.
- zwp 3y agoThe PDF ("sec23summer...") has metadata creation/modification timestamp of 20221004165319Z (October 2022). So presumably the paper was written last October and released for Usenix 2023. (Reference [12] is from Usenix July 2022. See "Prior work" in the introduction).
- gnfargbl 3y agoOne of the authors lists the paper as 2023 on their homepage [1], and the naming of a preprint [2] suggests summer 2023. It's a recent paper. [1] https://casa.rub.de/en/research/publications/detail/every-signature-is-broken-on-the-insecurity-of-microsoft-offices-ooxml-signatures https://casa.rub.de/en/research/publications/detail/every-si... [2] https://www.usenix.org/system/files/sec23summer_235-rohlmann-prepub.pdf https://www.usenix.org/system/files/sec23summer_235-rohlmann...
- hovav 3y agoIt's listed as a summer deadline accepted paper for USENIX Security 2023: https://www.usenix.org/conference/usenixsecurity23/summer-accepted-papers https://www.usenix.org/conference/usenixsecurity23/summer-ac... Per the call for papers [https://www.usenix.org/conference/usenixsecurity23/call-for-papers https://www.usenix.org/conference/usenixsecurity23/call-for-...], that means the paper would have been submitted for review by June 7, 2022, accepted for publication as of September 2, 2022, and had the final ("camera-ready") version uploaded by October 4, 2022. The conference itself won't take place until August of this year.
- ERUIONKP 3y ago[flagged]
- nailer 3y agoI've heard the same for Windows code signing certs - that's it possible to modify the payload and have the signature still apply.
- ioquatix 3y agoSounds like a useful feature to me.
- dijit 3y agoI mean, aside from bypassing the whole point of having them.
- wongarsu 3y agoThere are plenty of use cases. Like having your code signed, but putting a license key or access tokens or endpoint URLs into the unsigned part. That way you can sign binaries with your heavily guarded key, but still have some web server give people individualized binaries that don't have to ask for information (better UX if you install it once, or a big deal for software meant to be rolled out across many machines). Of course software can abuse it by loading code from the unsigned portion, but that requires code in the signed portion to be complicit. In that case the signature still does its job of telling you exactly who was responsible for that fuck-up.
- tankerkiller 3y agoWe do this where I work, and we HEAVILY verify all information that comes in from the unsigned/unauthenticated parts of the code. Not only types checks, but regex checks, and other validations. And if there's something there that shouldn't be there our program will kill itself. We don't even show any error prompts or anything just incase.
- password4321 3y agohttps://news.ycombinator.com/item?id=8203164 https://news.ycombinator.com/item?id=8203164 > These attributes are not part of the signedAttributes which is used to actually authenticate the signature https://learn.microsoft.com/en-us/archive/blogs/ieinternals/caveats-for-authenticode-code-signing#cheating-authenticode https://learn.microsoft.com/en-us/archive/blogs/ieinternals/... > unverified data within the PKCS #7 blob itself which will not be taken into account when verifying the Authenticode signature
- D13Fd 3y ago> 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 signature solutions don't necessarily solve it.
- layer8 3y agoAt least in Europe, electronic signatures of a certain form are legally equivalent to handwritten signatures [0], and are increasingly used as such. Emails don’t provide that legal value. [0] https://en.wikipedia.org/wiki/EIDAS https://en.wikipedia.org/wiki/EIDAS
- cedilla 3y agoI agree, in Europe digital signatures are very common now. Although at least for me it's almost exclusively PDFs.
- londons_explore 3y ago> Emails don’t provide that legal value. In general, agreeing to something by text in an email is as legally enforceable as a signature.
- logifail 3y ago> In general [..] ...but apparently not always. Not something I'd want to bet my business or reputation on. "AUSTRIA’s Federal Administrative Court [..] declared a framework contract from Austrian Federal Railways (ÖBB) to Stadler for the delivery of up to 186 double-deck trains to be null and void due to an alleged formal error in the qualified electronic signature of the offer." (September 2021) https://www.railjournal.com/news/austrian-court-annuls-stadlers-obb-train-contract/ https://www.railjournal.com/news/austrian-court-annuls-stadl...
- 666satanhimself 3y ago[dead]
- munchler 3y agoDoes this affect the security of password-protected Office documents as well? I think there's lots of valuable information locked up with simple Excel or Word passwords.
- tialaramex 3y agoI expect not, Office last century previously had a very simple password scheme (broken essentially instantly with modern tools) and then a poor one (take a couple seconds to break typical passwords) before I think settling on a more modern design where brute force isn't practical for a decent password. It's possible they threw that away to use this approach but seems unlikely
- jabroni_salad 3y agoThey are still using AES256 with 16 bytes of salt as far as I know. It's good security but it's not like you can rate limit attempts or anything and password bruteforcing has gotten pretty good lately. You also have to wonder if there isn't a skeleton key of some kind hanging around, too.
- meepmorp 3y agoAren't 256 bit AES keys computationally infeasible to crack? Assuming the rng and implementation aren't broken somehow, the best known attack is 2^254.3 operations to brute force a 256 bit key.
- mplewis9z 3y agoYou’re assuming the key is 256 random bits, which is almost certainly untrue for a human-rememberable password. The 16 bytes of salt are public, and AES is designed to be _fast_, so this scheme is horribly insecure for password-based security.
- tialaramex 3y ago
- benmmurphy 3y agois there a rationale for doing the signatures like they do? do they need to support multiple parts of the document signed by different people? I think a model where you just sign a blob of data seems much more straight forward and doesn't have any of these problems. the blob signing model does have some problems. for example lets say in the blob signing model for OOXML you would just sign a zip file that has all the xml files. the problem is the person doing the signature could try and craft the zip or the files in such a way that the document renders differently for different people. this is a problem but it is not as bad as the problem where someone who is not the author can create a new document based on an existing signed document because the signature scheme is very difficult to implement correctly.
- praseodym 3y agoWould this also affect macro signatures so that this can be used to make malware documents, or do macro signatures use a different signing mechanism?
- cratermoon 3y agoThis smells a lot like the XML Signature Wrapping Attacks known to affect SAML. In essence, the attack fools the signature check into thinking that it's checking the signature of a different document than the one it's given.
- tptacek 3y agoThey tested XSW attacks against OOXML and couldn't find any, but yes, this line of attacks and XSW both sort of follow from the malleability/flexibility of XML. It's generally not secure to build signature systems "inside" of XML.
- neilv 3y agoI discovered a related problem before, while integrating with an enterprise customer/partner. Some critical software they used was erroneously signing&validating the wrong part/extent of a very security-sensitive message. I raised the issue on my company's end, and we had to explain to the customer/partner their big problem. > On macOS, we could reveal a surprising result: although Microsoft Office indicates that the document is protected by a signature, the signature is not validated. I wonder whether someone discovered the incorrect digital signatures approach while working with the code on the occasion of a MacOS port/implementation, slammed the brakes on that while escalating the issue internally, a decision was made to keep it quiet, and the MacOS implementation was shipped just stubbing out the signature validation behavior (or otherwise made to always claim validation OK)? I wonder whether these broken digital signatures were exploited in the wild. Were forged invoices paid, or banking details changed, while trusting the signature? Was a digital signature held up as evidence in legal proceedings? Are there any automated systems that rely upon the digital signatures in these documents? > acknowledged and awarded our research with a bug bounty. Rather than just uncomfortable conversations everyone wishes they weren't a part of... there's cake? :)
- tptacek 3y agoSigned OOXML Word files are ZIP files defined by what appear to be 3 manifests: a content-types.xml file, a document.rels.xml file that maps symbolic IDs to filenames, and the "Package Info" section of the signature block, which supplies hashes for all signed files. The rendering of an OOXML Word file starts from "document.xml". Here are the attacks, as I understand them: 1. OOXML doesn't sign content-types.xml. It also doesn't sign the literal contents of document.rels.xml, but rather appears to parse it and sign the values from the file. So: you can add arbitrary files to a signed OOXML bundle. That shouldn't matter, because none of those new files will be referenced by "document.xml", which is signed. But: there are files that Word will render without references, like "people.xml" (which describes the authors of a document); you can add that file after signing, and its content can take over the whole document render. 2. Document styles are stored in "styles.xml". You can create an OOXML file without a "styles.xml", sign it, and then later add an unsigned "styles.xml"; since the binding between "document.xml" and "styles.xml" is implicit and not cryptographically verified, if you're clever about the original document you have signed, you can use styles to change the meaning of the document later. 3. There's a tricky attack involving the interaction between .DOC and .DOCX that I don't totally follow, but the gist is: you can get a benign .DOC signed, and then write a malicious .DOCX file, and scrape the signature from the .DOC into the .DOCX file, along with the contents of the .DOC. Signature verification will follow the contents of the .DOC, but the render will be of the .DOCX. 4. There's apparently a nasty implementation bug where the verifier doesn't check to make sure that the hashes in the signature manifest are related to the signature itself, but rather just that the hashes are valid. So you can take an XML signature from any other source (a SAML token, for instance) and splice it into a self-signed OOXML file, replacing the signature but not the hash manifest. Both will verify independently. 5. You can take any signed OOXML Excel spreadsheet and inject a malicious .DOCX into it. Then rename the file from ".xlsx" to ".docx". Word will open it, prompt you to "repair" the file, and then render it as if it was signed. The core issues here seem to be: 1. Never sign XML. 2. Never sign a file/bundle format that gives you as much flexibility as OOXML does: being able to add and remove files after a signature was applied without invalidating that signature is the root of most of the attacks in the paper. 3. When you're trying to do signatures over something as complicated as Microsoft Word documents, it's not enough to have a coherent model for signing the structure of the file format --- which, it looks like, was the brief for the designers of OOXML signatures; your model needs to take into account the behavior of the whole program ("people.xml", styles and "styles.xml", "document repair"). You can imagine a team at Microsoft that understands how signatures work getting the assignment to design this feature, and coming up with it based only on the documentation for the file format, because Word itself is a beast, and who wants to spend a year figuring out how it works? 4. You have to test these things. Attack #4 is a table stakes vulnerability that could have been a unit test for how simple it is.
- hannob 3y agoI 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 considered broken unless proven otherwise. Signatures should really just be applied to whole files or data structures, everything else should be considered dangerous.
- mati365 3y agoIsn't the file part of the file system which can be file too? Basically everything everywhere is broken.
- GranPC 3y agoPeople typically do not share documents, such as signed contracts, by providing an image of their entire filesystem containing the signed file.
- est31 3y agoThey also don't want to share two files, one for the file, one for the signature. Ideally, it's integrated, which means there needs to be some management. And ideally, it's also applied to the data before it's compressed, so that you can apply advanced compression and deduplication to archived documents like zopfli for example.
- nightpool 3y ago"Signed documents" are a joke and everybody knows it. As the XKCD goes: How to use PGP to verify that an email is authentic: Look for this text at the top -----BEGIN PGP SIGNED MESSAGE----- If it's there, the email is probably fine The abstract only mentions it offhandedly, but I think the least emphasized bug in their paper is actually the most important, because it really drives this point home: "We discovered that on macOS, it is sufficient to include a sig1.xml without any content to force the application to show a security banner stating that the document is protected by a signature" BEGIN PGP SIGNED MESSAGE indeed.
- jaza 3y agoHey, what do you expect, it's only Pretty Good Privacy, not Actually Good Privacy!
- xvilka 3y agoAnd it's not even really open, unlike ODF.
- tzs 3y agoHow so?
- pieter_mj 3y agofor the nitty gritty, check out groklaw.net. permalink : http://groklawstatic.ibiblio.org/staticpages/index.php%3fpage=20051216153153504 http://groklawstatic.ibiblio.org/staticpages/index.php%3fpag...
- tzs 3y agoI remember reading most of those back at the time they were written. The main one I recall for claims of not being open was that the drafts at the time had markup for marking things such as "use Word 6 line spacing" and "use WordPerfect 7 paragraph wrapping" or similar. The claim was that since those formats and behaviors were not openly documented having elements for them made OOXML not open. That was a questionable claim for a couple reasons. First, that markup was not there for use in newly made documents, and new word processors (including those from Microsoft) were not expected to implement it--they were expected to ignore it. What it was there for as archiving. For example at the time WordPerfect was pretty much the de facto standard for legal documents. Many legal publishers and large law forms stored all their documents as WordPerfect files, and had tools to manipulate those documents outside of WordPerfect. Those tools were based on reverse engineering of the WordPerfect formats. These places had large archives of WordPerfect documents. Suppose they wanted to move to a more current, better documented archive format such as ODF or OOXML. It would be possible to write a converter that would turn a WordPerfect document into an ODF or OOXML document and change their internal document tools to understand ODF and OOXML, but since Star Office's and Microsoft Office's formatting options were not a superset of WordPerfect's that conversion would be lossy. The straightforward way to deal with that is to find some way to add some extra data when you do that conversion to record what WordPerfect formatting options that you could not map to ODF/OOXML were in effect at a given point in the document. Make your tools understand the extra data your converter adds and then your tools can reproduce accurate copies of the originals when needed. There were multiple parties that would be doing that. It would be silly for them to each come up with their own way to add that extra data. Some might make it custom tags. Some might make custom attributes. Some might do it with comments. Or CDATA. It would be much nicer if all the people who were extended ODF or OOXML to archive WordPerfect documents used the same way to add that extra information. That would make it easier if they ever wanted to exchange archived WordPerfect documents. And that's what things like use "WordPerfect 7 paragraph wrapping" were: Microsoft saying "You all who have reverse engineered WordPerfect and want to mark in your document archives that some document uses some WordPerfect specific formatting, mark it this way". They did this for a bunch of older word processor and spreadsheet formats. Second, I believe they took this out of a later draft.