Hacker News Reader

Comment by cpgxiii | Hacker News Reader

I don't think that follows from what's been disclosed. What seems to be the case, based on the disclosures, is that the signature validation code does a correct job validating the parts of the file the MSI header describes, but does not check parts of the file that aren't described in the header. As far as I'm aware, adding arbitrary anything to the end of an MSI doesn't do anything since it's not described in the headers, so you can't use this to compromise an actual MSI file. You can only use this bug to fake signing for specific other file types that are read back-to-front where the actual MSI parts will be ignored.

View on HN

Why are MSI files designed like this? Why allow for just a specific part of the file to be signed? (I have no technical experience dealing with them.)

Extra bytes at end of file will be ignored by most formats. You generally don't want to depend on file length.

Other than a possible checksum calculated from the entire file contents, many binary formats use either:

  - Headers describing a section, including the length of a section.  

  - Prefixing each section with a size.  

  - Using a marker pattern (such as a null byte) to mark the end of a section of data.

(there are more than these three, but these are the most common) That last one isn't used very often, and when it is, it's mostly for textual data.

The consequence of using the first two techniques is that it's entirely possible to add data to the end of the format, since a parser would just read the last section and stop (assuming the format supports knowing what the last section is).

If you hashed the entire file you wouldn't be able to append that hash to the file for distribution because it would change the hash of the file. That's why FOSS software signatures are usually MD5/SHAwhatever in a separate text file.

The format could still be "hash of everything else + everything else"

RPMs contain the signatures in the archive. DEB packages don’t, something I consider a major shortcoming in the Debian package format.

You can, if the consuming system is format-aware. I think MSI can fall into that category.

I developed something like this to put an md5 hash in a comment in the first line of a code module at a place I worked. It simply read the file, removed that line, and hashed the rest of the file data to generate the hash for comparison.

This was just to stop programmers changing the code without submitting it to a secondary system for validation/tracking (easy to work around, but that shows intent to bypass policies when we see it in the repo).

Well I guess the actual payloads would all be fairly individualized, so that makes sense.

Reply on news.ycombinator.com