8 ms·

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

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

tempfs 5y ago
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.
matt123456789 5y ago
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.
paxys 5y ago
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.
- craigkerstiens 5y ago
  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.
  - formerly_proven 5y ago
    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.
    - zoobab 5y ago
      $ apt update Oh, wait, fix not available in the Debian/Ubuntu official repos, only M$ trusted ones.
  - hannob 5y ago
    > 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.
craigkerstiens 5y ago
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.
defaulty 5y ago
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/4ce2cf1cb0aa656b8eb934c5acc3f4d6a6796bfa https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9...
- jahewson 5y ago
  Indeed! And most of the 20 contributors work for Microsoft. Talk about FUD.
- blibble 5y ago
  I read all of this: https://github.com/microsoft/omi/blob/master/README.md https://github.com/microsoft/omi/blob/master/README.md still don't understand what it does
  - mook 5y ago
    Ars Technica had an article on three vulnerability that was decently clear: https://arstechnica.com/information-technology/2021/09/security-researchers-at-wiz-discover-another-major-azure-vulnerability/ https://arstechnica.com/information-technology/2021/09/secur... (Sounds like it's a Linux port of some Windows management feature.)
    - hughrr 5y ago
      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.
  - q3k 5y ago
    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.
belltaco 5y ago
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.
- tcoff91 5y ago
  The thing about dependencies is most people don't actually read the source. But at least you have the option.
- prepend 5y ago
  "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.
Veserv 5y ago
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.
- virgilp 5y ago
  What? This is Microsoft's open source project - they didn't need to "do quality checks", they developed it!
- hippyup 5y ago
  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.
jamesfinlayson 5y ago
Yeah I thought the list of maintainers for bash and curl were pretty short (like one or two people each).
randomfool 5y ago
https://github.com/microsoft/omi/blob/master/CONTRIBUTING.md https://github.com/microsoft/omi/blob/master/CONTRIBUTING.md "Currently, this project is not accepting contributions or pull requests." Last changed Aug 17, 2016.
- pabs3 5y ago
  Looks like they do use pull requests though, I guess only ones from Microsoft employees are accepted. https://github.com/microsoft/omi/pulls https://github.com/microsoft/omi/pulls
devwastaken 5y ago
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.
beckman466 5y ago
> 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".
twirlock 5y ago
It's hilarious we're using the actions of microsoft as an example of opensource failing.

tempfs 5y ago

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.

matt123456789 5y ago

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.

paxys 5y ago

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.

craigkerstiens 5y ago
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.
- formerly_proven 5y ago
  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.
  - zoobab 5y ago
    $ apt update Oh, wait, fix not available in the Debian/Ubuntu official repos, only M$ trusted ones.
- hannob 5y ago
  > 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.

craigkerstiens 5y ago

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.

defaulty 5y ago

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/4ce2cf1cb0aa656b8eb934c5acc3f4d6a6796bfa https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9...

jahewson 5y ago
Indeed! And most of the 20 contributors work for Microsoft. Talk about FUD.
blibble 5y ago
I read all of this: https://github.com/microsoft/omi/blob/master/README.md https://github.com/microsoft/omi/blob/master/README.md still don't understand what it does
- mook 5y ago
  Ars Technica had an article on three vulnerability that was decently clear: https://arstechnica.com/information-technology/2021/09/security-researchers-at-wiz-discover-another-major-azure-vulnerability/ https://arstechnica.com/information-technology/2021/09/secur... (Sounds like it's a Linux port of some Windows management feature.)
  - hughrr 5y ago
    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.
- q3k 5y ago
  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.

belltaco 5y ago

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.

tcoff91 5y ago
The thing about dependencies is most people don't actually read the source. But at least you have the option.
prepend 5y ago
"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.

Veserv 5y ago

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.

virgilp 5y ago
What? This is Microsoft's open source project - they didn't need to "do quality checks", they developed it!
hippyup 5y ago
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.

jamesfinlayson 5y ago

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

randomfool 5y ago

https://github.com/microsoft/omi/blob/master/CONTRIBUTING.md https://github.com/microsoft/omi/blob/master/CONTRIBUTING.md "Currently, this project is not accepting contributions or pull requests." Last changed Aug 17, 2016.

pabs3 5y ago
Looks like they do use pull requests though, I guess only ones from Microsoft employees are accepted. https://github.com/microsoft/omi/pulls https://github.com/microsoft/omi/pulls

devwastaken 5y ago

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.

beckman466 5y ago

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

twirlock 5y ago

It's hilarious we're using the actions of microsoft as an example of opensource failing.