The xz attack may be bad, but trusting Microsoft certs is worse | Hacker News Reader

The xz attack may be bad, but trusting Microsoft certs is worse

twitter.com

59 pointsstandapart19 comments

The submission title is editorialized (easy karma bait), the tweet doesn't say anything like that, not even mentioning xz or the word trust. And also it's an entirely different type of security incident.

You can make the first sentence of the tweet fit the HN submission word limit

"CISA and review board torches Microsoft response about the 2023 compromise"

Yes, the submitted title broke the site guidelines badly. From https://news.ycombinator.com/newsguidelines.html: "Please use the original title, unless it is misleading or linkbait; don't editorialize."

Submitters: If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

It's interesting article though, isn't there a way to get it to reflect that instead of flagging it into the void?

I have submitted the report here:

https://news.ycombinator.com/item?id=39919628

Agreed, and flagged.

I'm not sure why there's a sudden surge of xz ragebait submissions.

Because karma number go up, and for some people that's reason enough.

The CISA report is definitely worth a read and so is questioning Microsoft's security posture. Comparing the incident to the xz attack doesn't make a whole lot of sense though.

Yeah, they’re entirely different classes of failure (from a security pov, not personal failing, esp nothing the old xz maintainer did).

Also the only reason the xz attack isn’t overwhelmingly worse than the MS attack is because it was caught (by an MS person as well I think?) before it was deployed.

It was caught by a person on MS payroll, that's true, but it didn't get caught by any security processes institutionalized by Microsoft. So the credit goes to Andres Freund, who was working off-the-clock (according to The Verge) not to Microsoft.

I don't know if off the clock accurate. My job is to work on postgres, I was helping out with the development of a feature (avoid a perf regression in a degenerate case, in a patch improving much more common cases). OTOH, I think it was late at night at that point. What's on/off the clock for an OSS dev...

Would it be fair to say that the perpetrators could have covered their tracks better? Could they for example, have fixed the valgrind errors? And if so, would this backdoor have remained hidden for much longer?

What was the moment like, when you realized you have stumbled upon a backdoor? I mean, it is riveting just to read the various reports of this backdoor!

> Would it be fair to say that the perpetrators could have covered their tracks better? Could they for example, have fixed the valgrind errors? And if so, would this backdoor have remained hidden for much longer?

Yes. Mostly they should have reduced the cost of starting up sshd with the backdoor. A lot of that seems to be due to all the symbol lookups they needed to do, while staying obfuscated. It feels like they started with a reasonable set of features and then just piled on more and more, leading to the noticeable cpu usage.

I think the valgrind warnings were only triggered when using -fno-omit-frame-pointers. Which, at the time they wrote this stuff, wasn't the default anywhere. They got unlucky in that Fedora changed to default to that and that I happened to have that set in my valgrind tests.

> What was the moment like, when you realized you have stumbled upon a backdoor? I mean, it is riveting just to read the various reports of this backdoor!

It was many hours of slowly figuring that out, room for different emotions. Lots of nervous cackling. Thinking I must just be hallucinating. Worry about how to deal with this. And more...

Edit: Grammar

Whether MS deserves credit or not, he's a very senior SW engineer at Microsoft so this should at least provide some reassurance that the company has technical leaders who are looking out for these sorts of security risks...

Oh yeah, I know it wasn’t ms security reporting it or anything, I just found it funny (and ironic I guess? given this report came out a few days later).

Wasn’t it an annoyed database administrator?

Haven’t trusted Microsoft in a long time. So at least that’s not changing.

Yeah, nothing new under the sun about this.

I'm in cyber threat intelligence, not someone known or anything, but I've got a decent bit of experience in both building exploits and mitigating them through controls before starting to write about them. I actually created this account to comment on this, after lurking here forever.

It's possible to have both things be true at once. XZ shows that the FOSS ecosystem is uniquely vulnerable and the Storm-0558 and Midnight Blizzard attacks show that cloud security and proprietary software "security through obscurity" is still as flawed as it has always been.

That said, I find significant deficiencies in yesterday's report. The panel of stakeholders that were consulted includes all of Microsoft's cloud competitors, a threat intelligence firm owned by one, and Palo Alto Networks - which has had significant breaches of its own. I don't like how Microsoft has enterprise environments by the short hairs on the Windows environment and leverages that to push its SaaS offerings (especially in security). I think it's ridiculous that the technical indicators for the initial compromise were paywalled behind logs that the US government had to pressure them to make open for everyone. That said, their threat landscape is not at all similar to PAN and Google Cloud's. The entire federal government works on Microsoft's stack, especially for Office and Windows. State-sponsored hackers will dedicate more resources to compromising Microsoft than any of their peers. AWS has GovCloud, which is the next closest thing that an adversary may want, but the intelligence value of getting the Secratary of ___'s email vs. an S3 bucket or an EC2 instance isn't comparable.

It's clear from their blog posts and press releases that they themselves have no idea what caused the loss of the MSA key. The lack of logging to confirm their preferred theory is bad. Throwing it out as if they had evidence of it and then posting a silent update to their blog post last month admitting they had no clue is worse. The flaw in their IAM that allowed a key from 2016 to sign enterprise tokens is an oversight that a company with the trust Microsoft has shouldn't allow.

The CSRB could have made a great report on the above and let the facts speak for themselves. Instead, the pointed jabs at MSFT - especially during the Findings section where they spend several pages showing Microsoft's failings and then follow with how their cloud platforms happen to do so much better - risk the effort landing as a smear campaign.

Either Stallman-esque principles will need to be implored for products in commerce with very heavy profit-killing taxes on non-compliance, or we'll need to start requiring PEs and liability bonds/insurance, etc.

Downvote me all you want, but take your pick: Either be Stallman-esque in openness of design and intent (but not distribution) at risk of heavy end-product sales tax, or your product must be signed off by a software PE in order for you to legally charge money in any way for it or its use (or even pester for donations). Trust me, fall on the Stallman sword, it's smaller.

See post history for a better write-up of what I mean by proprientary-tax and the national security threats of not being able to understand and replace all your firmwares.

Sure the response can be excoriating, but the US government isn't giving up on Microsoft shit.

The USG is Linux-hostile, with exceptions like the NSA doing SELinux, Gidra, and other toolchains.

Linux would be the absolute best, along with things like OpenOffice and other FLOSS tools. The difference is to take the money you pay to MS and redirect them to FLOSS devs.

But, that'll never happen.

Reply on news.ycombinator.com