Hacker News Reader

Comment by cwyers | Hacker News Reader

If someone has managed to compromise Windows Update (which I doubt seriously based on what's presented here), why on Earth would they not bother to come up with text more convincing than the garbage on display here?

View on HN

Yeah I'd say it's more likely someone or something in the update toolchain screwed up.

The other option is a deliberate "ethical" hack.

Wouldn't that also call for putting in text that at least makes it clear it's an ethical hack? The only explanation for that garbage is either lorem ipsit filler text (something never meant to get out) or the theory buffoon had about it being a hash collision.

Because its not a hack most likely, its just MS screwing up. As someone who has managed/been tortured by WSUS for years, nothing surprises me about how MS handles its update infrastructure. WU is something of a pig and errors come up now and again, both on the client and server-side. In 24 hours this will be forgotten and yet another example of web hysteria.

Considering MS's typical QA with updates, this shouldn't be terribly surprising. I'm going to guess that this was a test patch that got loose. Big companies aren't fault immune, if anything they are fault prone.

> Because its not a hack most likely, its just MS screwing up.

That was my point, yeah.

That might have been the only text that allowed the updated to be signed.

That's an interesting theory, but seems unlikely given that the TLDs are all real. Also that would imply a successful hash collision attack which seems exceedingly unlikely. And if true, why not mutate some random bytes in the payload to get the collision rather than the update text (which also may not actually even be stored as part of the signed update).

May be their attack is so specific that they could only use Microsoft signed files in update payload, so they send old vulnerable versions.

That would be an amazing exploit. I doubt it's the case, and I hope it's not, but it would be pretty amazing.

Well, two years ago I tried to report a few fairly critical security vulnerabilities on update.windows.com and they responded saying it wasn't an issue. I'd consider denial of service, buffer overflow, possible remote code execution (didn't test because I didn't want to make MSFT mad), and sensitive configuration information enumeration critical vulnerabilities. Especially on update.microsoft.com, which distributes Windows updates. But apparently they don't. So who knows.

I'm not saying the OP's link is a result of these vulns being exploited, but them being exploited is always a possibility in the future if it hasn't already happened or been fixed.

How did you verify a buffer overflow in their remote code?

Reply on news.ycombinator.com