
Microsoft Put Off Fixing Zero Day for 2 Years - todsacerdoti
https://krebsonsecurity.com/2020/08/microsoft-put-off-fixing-zero-day-for-2-years/
======
cpgxiii
So if I get this right, the attack vector here is

1) Take signed .MSI

2) Add my JAR of malware to the end of it

3) Send file to target

4) Target's computer recognizes the file as a signed MSI, ignoring the extra
stuff at the end that's not part of the MSI

5) Target computer calls the JRE to launch the JAR

6) JRE ignores the MSI parts at the beginning of the file because compressed
JAR files are loaded back-to-front

Obviously a major bug that signature validation ignores "extra" parts of the
file, but a signature validation bug that (1) only affects specific types of
files executed by a third-party runtime and (2) doesn't threaten system files
(or any native executables at all) isn't an obviously critical vulnerability
like an arbitrary "signature validation is totally broken" bug.

~~~
Lammy
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](https://news.ycombinator.com/item?id=20435699)

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

~~~
Xylakant
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.”

~~~
a2tech
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.

~~~
Xylakant
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...](https://blog.virustotal.com/2019/01/distribution-of-malicious-
jar-appended.html?m=1)

~~~
pbhjpbhj
>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

~~~
lawnchair_larry
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.

~~~
pbhjpbhj
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.

~~~
lawnchair_larry
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.

------
elmo2you
What about criminal liability? I know that it's highly unlikely that Microsoft
will ever get what it truly deserves (at least as long as the USA remains what
it is), but still.

I find it rather telling, how many argue that Microsoft is (obviously) wrong
in their behavior, yet I don't read much about how the company deserves severe
punishment (maybe even forced break-up or having control taken away from it
altogether), for knowingly not fixing a security fuck-up like this, for this
long. Maybe an interesting case for anthropologists one day, to study
social/cultural conditioning.

I'm sure that Microsoft will have it's reasons and considerations, but that
should not excuse or exclude them from liability for the consequences of their
actions. Whether that will ever succeed in court, given both the reality of
what Microsoft and the USA are (many other countries too, by extension), that
is another story. But it should not take rocket science to figure out that it
will only get worse if Microsoft gets away with this without repercussions
(again). Guess, how we got here in the first place.

~~~
cpgxiii
How would you define criminal liability to achieve this?

You have a bug that, _at best_ allows a third-party runtime to execute a
malicious program without warning the user that the program is untrusted.
Practically, how would you write a statute so that this case would be
different from Windows not warning about malicious file in $arbitrary third-
party file format$ that exploits bug in $arbitrary third-party software$? You
don't want vendors legally responsible for the behavior of third-party code on
their systems, that's how you get entirely walled-garden platforms that have
no user freedom.

~~~
Retric
Laws don’t need to be that specific, that’s what the legal system is for. So
instead terms like negligence are used which have very specific legal
meanings, and then people consider if a Microsoft was legally negligent in
their behavior. The downside is it’s more vague, but the upside is it can
rapidly evolve over time as new information comes to light.

[https://legal-dictionary.thefreedictionary.com/negligence](https://legal-
dictionary.thefreedictionary.com/negligence)

~~~
cpgxiii
Laws don't necessarily need to be specific, but if you rely solely on
interpretation to distinguish between different types of responsibility
involving third-party software, you will either achieve (1) appeals courts
defining responsibility as narrowly as possible, or (2) the complete
destruction of third-party software and all independent software development
as no vendor is willing to risk exposure.

~~~
Retric
Liability is always limited to the value of the company. Thus even in the
extreme case liability would at worst force companies to run each pice of
software as it’s own legal entity. Aka Microsoft is going to keep selling
Windows as an OS even if they need to spin off a subsidiary.

~~~
cpgxiii
Well, then you've still destroyed small independent software vendors, open
source projects, and individual projects for which the cost and complications
of running an LLC as a liability shield is unsustainable.

The issue with defining liability here is primarily what conduct should make a
company liable in the first place (and doing so in a way without horrible
consequences for user freedom), not what the damages can be.

------
Lammy
Is the implication supposed to be "Microsoft finally given 'okay' to fix zero-
day now that it is no longer useful to Intelligence?"

~~~
jlgaddis
That was my first thought as well.

Why else would they leave a known vulnerability unfixed for _two years_!?

ISTM that someone else found out about the vulnerability out (" _... which
Microsoft acknowledged was actively being exploited._ ") -- perhaps after the
NSA used it against them? -- so now that the cat is out of the bag and _they_
are at risk of compromise -- they let Microsoft know and get it fixed.

~~~
simiones
This doesn't seem like the kind of vulnerability a security service would
really care about. It's just about whether Windows does or doesn't show a nag
prompt when trying to run the malicious file.

I doubt there are any real systems where the only thing standing between the
system being secure or not is Windows code signing.

~~~
jlgaddis
> _This doesn 't seem like the kind of vulnerability a security service would
> really care about. It's just about whether Windows does or doesn't show a
> nag prompt when trying to run the malicious file._

And yet, if memory serves, they went to the trouble of stealing a code-signing
certificate from a software development company so that they could do _exactly
that_ in an Iranian nuclear facility!

Besides, even if this one weren't all that useful on its own, we've seen time
and again how a few of these these "minor" vulnerabilities can be "chained"
together, eventually resulting in a full compromise.

~~~
cpgxiii
To be specific, in that case the NSA wanted to install a malicious driver on
Windows machines that required driver signature enforcement, so there was no
other way to get a driver installed except to steal a certificate to sign
their driver.

------
qeternity
> Microsoft’s advisory makes no mention of security researchers having told
> the company about the flaw, which Microsoft acknowledged was actively being
> exploited.

Most likely part of an ongoing campaign by a three letter agency which would
have requested the delay...

~~~
simiones
I doubt that three-letter agencies typically attack targets whose only
protection is the Windows "this file may be dangerous, are you sure you want
to open it?" pop-up..

~~~
Lammy
Who said anything about "only" protection? Besides you, I mean. Real-world
attacks tend to involve simultaneous exploitation of multiple vulnerabilities,
like this real iOS Safari watering-hole/drive-by attack maliciously using the
same exploit chains as my favorite iOS jailbreak tool:
[https://googleprojectzero.blogspot.com/2019/08/a-very-
deep-d...](https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-
into-ios-exploit.html)

~~~
imtringued
I see. If you visit a sketchy website then it is entirely possible that you
won't notice anything. If a random unsigned installer nag pops up after you
clicked on an ad there is a decent chance that the user closes the dialogue
and "walks" away unscathed.

------
MatthiasP
The Virus Total detection list is very interesting [1]. How can your
antivirus-software not detect a dangerous, publicly known, two year old
exploit? How can anyone take these products seriously? Of course McAfee does
not detect it.

[1]
[https://www.virustotal.com/gui/file/dd71284ac6be9758a5046740...](https://www.virustotal.com/gui/file/dd71284ac6be9758a5046740168164ae76f743579e24929e0a840afd6f2d0d8e/detection)

------
jl6
Kolmogorov’s razor: never attribute to malice or stupidity that which can be
adequately explained by uncontrolled complexity.

~~~
elmo2you
.. but keep your eyes peeled, for cases where the latter is intentionally used
as a lame excuse for any of the two former (or Kolmogorov's razor itself, for
that matter).

------
watt
There is "zero day" mentioned in the title, but nothing in the article text. I
am confused: what does this has to do with "zero day" now? It's not "zero day"
now, is it.

~~~
gerdesj
It isn't zero day now but it was for at least two years. That rather stretches
the definition of zero day but for two years Windows machines have been
vulnerable to something nasty that was known about.

~~~
fulafel
It was a bug in the third party scanning products though. ("This behaviour
could be used to hide and distribute malicious code in MSI signed files, in
fact several security solutions rely on the output of Microsoft Windows code
signing validation to avoid an in-depth scan").

------
jojobas
What exactly is the attack vector?

Are the users supposed to receive an unexpected jar file and run it? Or can it
pretend it's an MSI the user legitimately wanted, yet execute malicious code?

~~~
llarsson
The latter. You download an MSI from some file hosting mirror, who cares,
because you then diligently look and see that it has been signed correctly by
the company that made the software.

But the vulnerability makes it rather trivial to have appended arbitrary
content, even executable code, to it, without impacting the supposed validity
of the signature.

This is really bad.

~~~
Xylakant
No, the former. The file is renamed it .jar by the attacker and executed by
the java runtime. The msi part is ignored - it only serves to cloak the jar
from the scanner - it recognizes the file as msi and ignores signed msi files.

------
Ekaros
Wouldn't this be more so issue with Java and not Windows? As I don't think any
good program should run a file it does not completely understand?

~~~
stjohnswarts
If microsoft was doing their job they wouldn't ignore a mysterious blob of
binary stuck to their MSI. That is HORRIBLE, even the most 101 student of
security would realize that, if you've ever even done a CRC on a file you
would realize why that is HORRIBLE. I'm with the others in thinking that they
deliberately ignored this for some reason, possibly 3 letter agency access.

------
ed_elliott_asc
Ive used this as a feature before to add some unique data into the end of an
executable after it had been signed.

~~~
Agenttin
[https://xkcd.com/1172/](https://xkcd.com/1172/)

------
temac
Well, you can just write an installer that uses an elevated cmd anyway. I
think conemu does that? (not sure, maybe it is another software)

Is unsigned software subject to further restrictions by default compared to
signed but "unknown" software (sometimes a pain to use with Defender)

And I kind of remember there was already other bugs with MS code signing
checks? (not sure)

I agree this bug probably breaks the (informal/perceived?) security model of
some hardened configuration, but that kind of hardening should not be
considered completely sound anyway. It's like the UAC that is not to be
considered a security boundary, yet somehow useful against casual threats or
even just errors.

If you download and try to execute random code, you should consider it _will_
be executed regardless of the expected checks and perceived hardening of your
system. And you should consider that your OS is full of security bugs
absolutely everywhere. Your web browser too (yep, that means JS is an insane
threat now).

Not really a reason to not fix that kind of things though, but nothing serious
enough to loose our mind.

------
anonu
Semantics question here: but if this was "actively exploited" for 2 years" \-
when do we stop calling it a zero day?

------
rkagerer
For anyone wondering, it looks like Windows 7 also recieved the fix.

------
gigatexal
That’s nothing. While nowhere near as severe there’s an ansi padding bug in
SQLserver when doing replication that they refuse to fix for going on 10+
years now iirc

------
ltbarcly3
Well, its terrible they took so long to fix this, but it seems to me it was
only a 0-day for one day two years ago?

Do people just use 0-day as a synonym for exploit now?

~~~
pr0zac
The zero in 0-day refers to the number of days since a patch/fix was released.
Since a patch wasn't released for two years, it was a zero day that whole
time.

~~~
ltbarcly3
Every definition I can find disagrees with your definition. People must use
the term loosely.

------
ReptileMan
Calling that a zero day is a stretch since it requires a lot of user
interaction and is local only.

It is not that scary of a bug.

~~~
detaro
nothing in the definition of "zero day" requires a bug to be "scary".

~~~
dumbfounder
You are right, but to most people that term seems very scary. Most people
don't know what zero day means, and so putting it in the title invokes
doomsday type visions for a lot of people.

~~~
detaro
Most people that don't know what it means also aren't reading Krebs' blog. I
feel like different expectations apply here than on a mainstream publication -
where not using it in the title or immediately clarifying/reiterating the
definition would be appropriate.

------
ck2
which means the millions of Windows7 installs still in use are vulnerable?

------
TheButlerian
This is why zero-days should be made public a week after reporting them to the
company...without ANY fear of prosecution. Trust me, after the first 50 cases
- the companies will have a dedicated team working on such exploits.

Wow, they made this public and MS still didn't handle it...I guess it should
be more widely advertised then.

~~~
elmo2you
I fear that because of the asymmetric power/financial balance between the
parties involved, such a choice could easily lead to a kind of war, in which
the companies will have the upper hand. They will have may more
means/resources at their disposal and when it gets ugly (out of the public
eye) things could get nasty.

Please, don't get me wrong. On itself I think this whole responsible
disclosure culture is bullshit. It wouldn't be if more companies actually
treated it more sincerely. But I have seen too many companies abuse
responsible disclosure, or simply hide behind bug hunting programs to
limit/squash exposure (too many times even without fixing anything), and then
burn anyone who doesn't want to play by rules they themselves set.

The problem is, there are far more things than just legal prosecution when
this would turn into a clash between companies and security researchers.
However, maybe a union or anonymous organization could level that playing
field. Problem with that is that many security researchers also want
recognition, at the same time as feeling safe (.. something about cake).

~~~
gruez
Just publish it anonymously? Make a site called exploithub and host it as a
hidden service. I'm sure most cybersecurity professionals wouldn't have
problems accessing it.

~~~
macintux
If you’ve already disclosed it to the vendor, a leak of the information
shortly thereafter would likely not be so anonymous.

~~~
gruez
If you're disclosing it to the vendor, then you're probably cooperating with
them and are going to give them 90 days to fix it. If they don't fix it within
that time, anonymously publish it a month or two after. That gives a total
time of around 4-6 months between you discovering it and the "anonymous
researcher" on exploithub "independently" discovering it.

------
luxuryballs
I’ve always said Java was a virus.

------
gwillen
This is an easy and popular bug to write. The ZIP file format (which is used
for JAR files as well), which puts the header at the end, is truly the sin
that keeps on giving.

A consequence of this choice is that ANY file concatenated with a ZIP file is
a ZIP file (and the same therefore goes for JAR files as well.) So if you
concatenate an MSI file with a ZIP/JAR file, your MSI file detector will look
at the file and go "yeah, looks good!", and your ZIP/JAR file detector will
also say yes. (This also shows off the hazards of automatic filetype
sniffing.)

This is related to one of the very oldest Android rooting vulnerabilities. The
update.zip files use the signed JAR file format, where the file contains a
signature on its own contents. Naturally the signature can't cover the entire
file; it only covers the contents referenced by the header.

But the sin-that-keeps-on-giving strikes even harder here: The end-of-file ZIP
header also has an end-of-header comment field, of arbitrary size! This means
that a single file can actually have MULTIPLE valid ZIP headers. Which means
two different tools can interpret the file as two different ZIP files (much as
the bug here can interpret the same file as either a ZIP or an MSI.)

Don't do drugs, kids. And don't do automatic filetype detection. And don't do
ZIP/JAR files if you can avoid it. And for the love of god, don't put your
header at the end.

