Hacker News Reader

Comment by Lammy | Hacker News Reader

Disagree on lack of severity; this is the kind of thing that calls into question any signed MSI I've downloaded over non-TLS HTTP or even over HTTPS served from a possibly-downgrade-attacked HTTP→HTTPS redirect.

e: or any signed MSI from a compromised system, like happened to Palemoon last year: https://news.ycombinator.com/item?id=20435699

Endless rabbit-hole of course but that's already a lot of low-hanging fruit

View on HN

If I read the description correctly, it would need to be a jar file, though, not an msi. The trick allows to hide a malicious jar file from the scanner, not to hide a malicious msi. I think it’s better described by “take a malicious jar and prepend a signed msi to hide it from the scanner.”

This is separate from anything an AV might do, so forget the scanner part. A virus scanner with a signature for this malicious JAR will still catch it. What this is avoiding is the prompt and extra scrutiny Windows throws up if you try and run an executable from the Internet.

Think of the legitimate MSI and malicious JAR files as separate short stories in the same book. The 'book' comes to your computer claiming to be one thing (the legitimately signed MSI) but the second chapter is something completely different (the malicious jar file). When your computer reads the book (calculates and verifies the signature) it only does it off the first chapter. That lets the second part slide under the additional scrutiny Windows applies to files downloaded from the Internet.

By “scanner” I meant the built-in windows defender tooling, which is - afair - affected. It trusts the signature. But you’re entirely correct - a virus scanner that does not rely on the signature w could catch the malicious code.

However, this blog post mentions that various security solutions trust the windows code signing, but it does not mention which ones - https://blog.virustotal.com/2019/01/distribution-of-maliciou...

>It trusts the signature. //

Wtf? Am I reading this right, if part of the file is signed by MS then it just doesn't bother running it through the detection algo?

That looks exceedingly like a designed in security hole.

Presumably paired with the OP "bug" means MS could, with an NSA letter say, drop malware on devices if those devices were using Windows Defender for AV.

Just as well MS don't snoop on what software user's are running./s

I may very well be wrong, but that’s how I read the beginning of this blog post: https://medium.com/@TalBeerySec/glueball-the-story-of-cve-20...:

“ Digitally signed files are more trusted by the Operating System. This higher trust allows such files to execute in sensitive contexts or excluded from Antivirus scans.”

It seems that msi installer packages with a trusted code signature (1) are excluded from scans by various antivirus protections. Which kind of makes sense: driver packages may contain code that would trigger heuristics a lot.

> Presumably paired with the OP "bug" means MS could, with an NSA letter say, drop malware on devices if those devices were using Windows Defender for AV.

Microsoft can already do that. To be quite honest - pretty much every institution with the right signing powers can on practically all OS. Have you verified the latest chrome installer package?

This bug seems to allow something more insidious: you could download the latest google chrome msi and append your payload jar to that msi and redistribute it. The signature remains valid. This allows bypassing the code signing checks even if you have no code signing powers.

(1) not from Microsoft, Microsoft only hands out the certificates, the signing is done by the developer

This isn’t suspicious at all. All AV does it for good reasons, both efficacy and performance related.

And no, that’s not how the NSA works.

All AV ignores files which are concatenated to an MS-signed file? Huh, presumably you mean only on Windows, but really? No AV treats .jar files concatenated with signed MSI as suspicious -- how did that situation arise?? It's a strange heuristic.

Isn't it like having a special 'I know my bag smells like drugs to sniffer dogs but I promise I don't have drugs' channel at airport arrivals; and when people go down that channel you don't bother to check their bags.

Don’t we have that? I don’t think TSA pre-check goes through the sniffers. Not sure what benefits that gives on arrival. I know there’s an express lane on the US/Canada border though.

Yes, kind of like that. That’s basically the point of digital signatures (when they don’t have a bug to bypass them, like in this case).

They don’t treat concatenated malicious files as safe, they trust that files signed by MS are safe. You aren’t supposed to be able to concatenate a file and still have the signature check out. That’s the bug.

If you want a good reason why, ask McAfee about the time that they incorrectly detected svchost.exe as a virus and made every customer’s windows machine around the world unbootable.

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.

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

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).

And since Microsoft still serve updates from the Microsoft Update Catalog over HTTP, let's not mistakenly think that all downloads are protected via TLS, even today.

Is this still the case for windows 10?

Yes, but all updates are a specialized .MSU format and don't fall in this end-of-file parsing trap.

The Update Catalog is only for manual downloads, so if you mean Windows Update, this is all downloaded over HTTPS.

Or any signed MSI if downloaded from a country where security services can secretly oblige companies to act against their users - China, USA, and probably many others.

Is there any technologically advanced country where that is not the case?

Reply on news.ycombinator.com