OMIGOD RCE vulnerability in Azure: Patch it yourself, says Microsoft

The bad news: when it comes to the critical (CVSS 9.8) remote code execution vulnerability affecting Azure (dubbed OMIGOD and discussed by The Stack in our write-up here), Microsoft thinks you should fix it yourself. The good news -- the devastatingly effecting exploit, which gives an attacker root access -- only appears to affect 56 companies that have specifically configured their Linux management in a particular way.

Unfortunately, that's not the end of the story. There were three other privilege escalation vulnerabilities reported at the same time by cloud security startup Wiz and an attacker who managed to access an affected virtual machine through any other route can go move laterally and gain root using OMI syntax.

The OMIGOD vulnerability stems from the open-source OMI agent that is embedded in many Azure services and quietly deployed when customers set up a Linux virtual machine (VM) in their cloud, in order to orchestrate configuration management and log collection. ("Any user can communicate with it using a UNIX socket or via an HTTP API when configured to allow external access" Wiz noted. "As a result, the vulnerabilities we found would allow external users or low-privileged users to remotely execute code on target machines.")

https://twitter.com/i/status/1437898746747097090

In updated guidance, Microsoft said September 16 that the RCE bug (CVE-2021-38647) only impacts customers using a Linux management solution (on-premises SCOM or Azure Automation State Configuration or Azure Desired State Configuration extension) that enables remote OMI management.

(Detailed analysis by Censys CTO Derek Abdine found 56 companies including a "major health organization and two major entertainment companies" were vulnerable. It has notified the companies.)

Controversially, however, despite the vulnerability coming from open source software maintained by Microsoft and quietly deployed at the heart of its infrastructure, Redmond has put the onus on customers to "update vulnerable extensions for their Cloud and On-Premises deployments as the updates become available" (schedule, per Microsoft, below), rather than fixing vulnerable deployments itself.

Post continues below

Post continues below

The whole OMIGOD vulnerability has been wrapped in increasing controversy, spanning disclosure, patch responsibility, open source and more. According to Arstechnica's review of emails between Redmond and Wiz, for example, Microsoft specifically said OMI was out of scope for Azure Management bounties, passing it off as an open source-related issue.

And although updates for the vulnerability were posted on GitHub back on August 11, said it didn't release security details then to "provide partners who depend on this software time to implement the updates before we released the details of the vulnerability." (That fix appears to articulate little more detail than a bare-bones "security update").

AWS's Matthew Wilson noted: "While it is not a completely unusual practice for bug fixes to be committed in an upstream repository without calling out the security implications of a fix, following up with a CVE, I think it is unusual to do this. Call me old-fashioned (well, this is an old fashioned software package) but I expect to see a security bulletin sent to https://openwall.com/lists/oss-security/, if the issue wasn't pre-disclosed to distros@ (which it doesn't appear to have been)."

Exclusive: NATO hires its first CIO