Hacker News

16 hours ago by MrStonedOne

> Open source is a supply chain risk Given the potential impact of OMIGOD, the million-dollar question is “How does an open source component with only 20 contributors on GitHub affect the security of large portions of Azure?” The ease of exploitation and the simplicity of the vulnerabilities makes us wonder if the OMI project is mature enough to be used so widely.

> Yet this scenario is more common than you might think and certainly not unique to Microsoft. One of the benefits of open source is that it’s easy for developers to grab code from different projects and mix it with other open source and proprietary software. As a result, bad open source code can wind up in an enormous range of products and services – inadvertently becoming a “single point of failure.”

The fear mongering about open source in the article seems misplaced.

Any software product could lead to the same thing, and OMI was used as a software product in this instance. I don't see how it being open source changes anything and the article doesn't address this, only goes on a tangent about how "open source code can end up in any software project".

It also leaded with a bit about supply chain attacks, in a way that seemed to imply, without explicitly stating, an intentional cause to this exploit existing.

> Because customers don’t know what franken-code is running in the background of the services they use, they remain at risk and unaware.

Wouldn't this be worse with closed source software thou?

15 hours ago by defaulty

Ironically, the OMI 'open source' package is Microsoft's.

The only recent commit was for "Enhanced security" a month ago:


15 hours ago by jahewson

Indeed! And most of the 20 contributors work for Microsoft. Talk about FUD.

14 hours ago by blibble

I read all of this: https://github.com/microsoft/omi/blob/master/README.md

still don't understand what it does

6 hours ago by q3k

It’s part of dumpster fire that is the DMTF ecosystem. Attempting to understand it if you haven’t been exposed to Windows enterprise bullshit is futile. It’s layers upon layers of meta XML to do the most mundane things in the most overcomplicated way without actually succeeding at making any usable standard.

Or, in other words: if you reaction to SOAP was “damn, this is amazing, we need more of this but with even more indirection”, you’ll feel right at home.

11 hours ago by mook

Ars Technica had an article on three vulnerability that was decently clear: https://arstechnica.com/information-technology/2021/09/secur...

(Sounds like it's a Linux port of some Windows management feature.)

4 hours ago by matja

yes, checking the secret before setting the uid/gid does seem like "Enhanced security" : https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9...

15 hours ago by paxys

Exactly. It's not like Microsoft picked up a random unaudited open source project and shoved it into all Azure VMs. OMI is maintained by Microsoft and the fact that it is open source is a good thing security wise. I'd wager being able to look at the source code greatly helped the researchers in their diagnosis as well.

15 hours ago by craigkerstiens

At some level, agreed that it probably helped security wise for researchers. That the fix was committed in public and then vulnerability remained for a month and well still currently for customers is where one could make a case that the open source nature did as much damage as good.

6 hours ago by hannob

> That the fix was committed in public and then vulnerability remained for a month

That's an indication that Microsoft is bad at handling security issues. Which isn't news and has very little to do with open source. Something very similar happened with Exchange, it led to plenty of people being compromised, and Exchange is not open source.

9 hours ago by formerly_proven

When you distribute patches for a vulnerability it basically makes no difference whether the source for those patches is available - people are quickly going to figure out what the vuln is. This is a patch rollout problem and nothing else.

32 minutes ago by beckman466

> As a result, bad open source code can wind up in an enormous range of products and services – inadvertently becoming a “single point of failure.”

What's the alternative? A black-box proprietary bug that becomes an NSO or NSA exploit?

The logic on this is so bad.

Linus's law: "given enough eyeballs, all bugs are shallow".

13 hours ago by Veserv

Indeed, it is quite ridiculous to lay the blame for this on an open source project. They did not force Microsoft to use their software and deploy it to all their customers. It is entirely Microsoft's decision to accept software that waived all warranty, liability, and guarantee of fitness for purpose and then deploy it to all of their paying customers without doing appropriate due diligence.

Any company in any other field that accepted dependencies without doing quality checks to verify that those dependencies met their requirements would rightly be called grossly incompetent. This is one step further than even that as the dependencies openly guaranteed nothing and they still did not verify if it was of acceptable quality before making vast amounts of things depend on it as a critical component. This is the absolute basics of the basics and Microsoft has completely failed at even that. This is indicative of deeply-rooted gross systemic incompetence in much the same way that failing FizzBuzz demonstrates a complete lack of programming ability. As such, their opinion on matters of security and their ability to deliver security should be completely disregarded until their organization is completely overhauled.

12 hours ago by virgilp

What? This is Microsoft's open source project - they didn't need to "do quality checks", they developed it!

12 hours ago by hippyup

Your comment makes no sense to me - you're saying we shouldn't blame open source but in the same breath say that anyone who uses open source without carefully reviewing and auditing every line of code is an idiot who can't even do FizzBuzz. I'm a developer and if I'm faced with the choice of auditing every line of code in a dependency or just writing what I need I'll just write what I need nine times out of ten. Honestly your position is closer to the article than you seem to realize.

16 hours ago by orf

The apparent fix: https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9...

Looks like a standard, absolutely gigantic C/C++ project that re-invents absolutely everything including an event loop, http server, XML parser, a C++ tool to generate C code to create a “str hash” implementation, a custom lexer for WQL and a parser for a “mof” file format.

Still not clear on what it does. Seems safe.

13 hours ago by dralley

> a standard, absolutely gigantic C/C++ project that re-invents absolutely everything including an event loop, http server, XML parser, a C++ tool to generate C code to create a “str hash” implementation, a custom lexer for WQL and a parser for a “mof” file format.

This is the part that gets missed when people talk about "dependency inflation" re: Rust. Absolutely, it is a problem, but most C codebases of a sufficient size and vintage are vendoring some absolutely insane hidden "dependencies" that, on average, probably get a lot less testing and attention than the average package on crates.io.

There are definitely risks with both approaches.


8 hours ago by capableweb

Not sure why what you're saying would be more true for C/Rust/JavaScript or any other language. The perverse idea of adding dependencies without actually reading through all the code you pull in exists in basically all language ecosystems, Rust included.

7 hours ago by jstanley

In C it is much more inconvenient to include external dependencies, so it's much more common for people to roll their own implementations rather than using a tried-and-tested one.

12 hours ago by gsam

CIM/WBEM goes all the way back to 1996. They essentially wanted a management infrastructure on all kinds of devices (including different architectures, so actually C made sense then), but that also notably included remote access. At the time, SOAP was still popular, so here we are with a rather silly transport protocol and all kinds of overhead reinventing things like SSH. However, the overall goal still makes sense, it was essentially a way of 'object'-ifying everything from logs to other metrics. This fit in with the overall mode of thinking in MS with DCOM and COM (and registry), and structured configuration/management. I'm sure it's paid massive dividends on Azure Linux infrastructure. For highly structured objects, SOAP and XML aren't a terrible fit, but I doubt many people would do the same thing again today.

Honestly, they just needed to rewrite it in a safer stack. However, that still may not have saved them from all these vulnerabilities, given the scope of what they're implementing as remote management protocols. The relative scrutiny, fuzzing and manpower just hasn't been there, especially when it's obfuscated by various layers.

11 hours ago by onionisafruit

Not to take away from the rest of what you said, but I don’t think SOAP was _still_ popular in 1996. I don’t think it had become popular yet. I don’t think I even heard of SOAP before 1999 or 2000. I’m not a trend setter or anything, but if it was popular, I probably would have at least heard of it.

10 hours ago by homarp

13 hours ago by jerf

Greenspun's law, "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." is really just a special case of a general principle. There's a lot of cases where if you use the wrong tool and/or don't know the right libraries, or don't or can't use them, or just won't, that you'll reinvent something that already exists, badly.

5 hours ago by the-dude

12 hours ago by reilly3000

After the JEDI black eye and slow attrition of frustrated developers/CIOs, this feels like a huge blow. Cloud is all about trust. They broke trust by installing the agent without disclosures, and shattered it with this vulnerability. Their customers running Linux vms have a pretty simple migration path to other cloud/hosting vendors, and most people have learned that only having one approved vendor for cloud just doesn’t work. Q4 and 2022 could be real rough for MSFT at least within the scope of affected customers. Moreover the torture that is Teams has got to have consequences as millions have had to suffer, and Windows 11 is a dumpster waiting to catch fire. My Threadripper 1950X can’t run Win11, and Edge is so difficult to detangle it’s practically antitrust-worthy. Oh, and setting up hundreds of thousands of developers to unknowingly commit licensing violations via Copilot…

Whatever magic Nadella brought to revive the company is starting to wear off, at least from where I’m sitting.

10 hours ago by isoprophlex

This can't be real, I thought. This is just a stub in a random commit somewhere.

But no. Same code is on master branch atm.

What is this, a joke?

"Never attribute to humor, that which is adequately explained by incompetence"

7 hours ago by dspillett

I'm going to give some benefit of the doubt and assume¹ that is some sort of stub for dev/test, replaced by one of a selection of proper symmetric encryption options in any production use. Amusing anyway.

¹ Anyone with more spare time than I want to look deeper to confirm or contradict?

6 hours ago by formerly_proven

It's used there: https://github.com/microsoft/omi/blob/e4d72481fa2f805148c9c8...

Also note that neither EncryptData nor DecryptData have any way of passing a key in their API. So it's very unlikely that these implementations could be conditionally compiled in place of a real implementation (but they're the only definition of these functions in the repository anyway).

6 hours ago by mulander

It used to have actual Windows specific crypto code[1] which has been removed in the linked commit.

I assume this has been ported from Windows and later never implemented the ripped out components. That said, I don't know the windows API so apart from confirming that they exist in Windows docs[2] I can't assess how valid their usage was.

[1] - https://github.com/microsoft/omi/commit/edbe231042173018c529...

[2] - https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-...

5 hours ago by dspillett

> neither EncryptData nor DecryptData have any way of passing a key

There could have been other smells involved, like the key being held in some more global scope instead of being passed in via the call stack.

11 hours ago by cube00

Let's hope memcpy hasn't been #defined

13 hours ago by watermelon0

At least it's fast. :D

12 hours ago by jamesfinlayson

And properly SAL annotated too.

12 hours ago by haimez

An encryption scheme with truly memcpy-like performance characteristics.

9 hours ago by asien

No surprise to be honest.

What rather surprises me are the comments claiming MSFT is suddenly going to go bankrupt because there is a pre-install spyware.

Have you ever worked in a Fortune 500 ?

Do you know how hard it is in those company to get anything done that has not been budgeted and planned years in advance ?

Do you seriously believe Fortune 500 using MSFT are going to suddenly migrate ALL their Azure workload somewhere else like some kind of startups run by 3 devs ?

Yes Azure VMs have spywares builtin , but last time I checked all Europeans companies that are using American Cloud fall under the « Cloud Act » legislation which « legally » requires cloud vendor to hand over ALL the data the company is currently hosting.

I’ve worked in some of the largest insurances in Europe they LOVE Microsoft and Azure , even if there is this spyware issue , they will pretend it doesn’t exist and do business as usual.

Im pretty sure everyone will forget about this news in 1 month or so.

15 hours ago by smcleod

It blows my mind how easy it is to get root with this - "Simply remove the auth header and you are root."


12 hours ago by reilly3000

That the kind of thing you get with homegrown web servers and corporate deadlines. I see how a QA person wouldn’t test that case, it’s almost a base assumption that the header would be mandatory.

14 hours ago by icecap12

Wiz is definitely trying to drum up some excitement around their new business with all these recent disclosures. Related but slightly off topic, we pay an industry analyst for high level market research and he's been screaming from the building tops about Wiz.io for the last 6 months. I'm honestly tired of hearing about it, he must get a cut of the sale. I wonder how long Wiz will keep this up; until they get sold presumably, then they'll go the way of the other big cyber firms and tone down the big hacks.

13 hours ago by shir1

If you want to see what all the hype is about - I can try arrange a demo meeting for you ;) shir@wiz.io

10 hours ago by bostik

Peeking in from the sidelines, as someone who probably will want to arrange a demo too, here's a thing I've been scratching my head with. Your online pitch contains a logical puzzle I haven't been able to decipher.

Patch management and vulnerability checks, right. (VM) OS configuration checks, sure, why not. "No agents or sidecars to deploy" ... hang on, how does that combine with the other two? In order to check for installed/missing patches for on-system software you have to have some kind of access to the underlying system.

Surely you are not snapshotting root volumes for your analysis needs?

13 hours ago by flyinglizard

Very slim chance it’ll get sold. It’s going for an IPO to play alongside other cyber security companies like Sentinel One. The founders are already rich enough from previous ventures.

16 hours ago by DrAwesome

While I think this article is unnecessarily critical of the Azure OMI agent, this is a very "What the heck, Microsoft!?" moment for me. Of all the pieces of Azure infrastructure, the OMI agent is absolutely something I expect to be well-tested and secure.

I recognize that bugs happen, but allowing a remote client to execute commands as root by simply removing the authorization header should have been caught by automated testing.

Daily digest email

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.