Hacker News Reader

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

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

https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9...

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

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

still don't understand what it does

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

This is one reason I stay the hell away from Windows focused software on Linux. There’s a complete impedance mismatch. Also MSFT’s GitHub open source fairy dust project stewardship is a shit show from experience.

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.

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

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.

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.

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.

$ apt update

Oh, wait, fix not available in the Debian/Ubuntu official repos, only M$ trusted ones.

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

Yes. The explanation given under that rather provocative headline does not mention how the OMI project being open source, as opposed to closed source, enhances its status as a supply chain risk. Microsoft could have just as easily not released that code - it still would have included the vulnerability.

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.

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

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.

Open source supply chain is a real thing, but not sure it's at all relevant in this case. In this case it appears to be an open source package that was simply open sourced by Microsoft as opposed to some broader community project.

That it's open source there could an interesting argument made that it's easier for one to hunt for vulnerabilities when they can review the code. In this case what was the advantage or point of it being open sourced when it is clearly a Microsoft project for Microsoft purposes. Maybe for collaboration internally? But the open source nature of it doesn't gain much.

The open source nature–in this particular case becomes more complicated when the fix is in plain sight for a month now with a seemingly easy ability to take advantage of. So in this case closed source fix that wasn't public how to exploit maybe would have been better indeed.

The open source vs. not is a bit more of a red herring relative to the overall situation. It's certainly not the central theme, but when you overanalyze I can see how some of the analysis maybe happened.

The fear mongering of open source is fabricated by the very people whom intentionally include vulnerable code in proprietary software running on every device. They don't want you to see it.

Exactly, they were doing fine until they made a point to shit on all open source software instead of limiting their focus to this one, Microsoft-sponsored outfit.

https://github.com/microsoft/omi/blob/master/CONTRIBUTING.md

"Currently, this project is not accepting contributions or pull requests."

Last changed Aug 17, 2016.

Looks like they do use pull requests though, I guess only ones from Microsoft employees are accepted.

https://github.com/microsoft/omi/pulls

There are also people who think open source is the holy grail of security because "given enough eyeballs, all bugs are shallow". And is used as an argument. So it cuts both ways.

The thing about dependencies is most people don't actually read the source. But at least you have the option.

"given enough eyeballs, all bugs are shallow" Is certainly true, but that doesn’t make OSS the holy grail.

In fact, I’ve never met anyone who thinks that. And “all bugs are shallow” doesn’t mean there are no bugs, it just means it’s easier to find bugs.

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

Yeah I thought the list of maintainers for bash and curl were pretty short (like one or two people each).