There are four vulnerabilities in Azure’s Open Management Infrastructure (OMI), one allowing an unauthenticated attacker on the internet to execute code as root, the other three allowing local users of any level to execute code as root.

Unauthenticated Root RCE

This one does require that the OMI management port be exposed which mitigates the risk as for most but not all services with OMI. It is exposed by default on the Configuration Manager and System Center Operation Manager. And as far as vulnerabilities go, by simply not providing the Authorization header the authorization code is never run resulting in the authInfo fields uid and gid never being initalized to non-zero values. Zero being the uid/gid of the root user on most Linux systems.

Local Privileges Escalation (CVE-2021-38648)

Somewhat similar to the prior issue, however taking place in the omicli application which is used to communicate with the omiengine (which processes when necessary, and passes along requests to the omiserver running as root). By capturing a legitimate command execution request from omicli and removing the authentication part omiengine will pass along the authInfo to omiserver with zeroed values, which omiserver has no choice but to trust.

Local Privileges Escalation (CVE-2021-38645)

Unlike the prior two this one is actually a bit of a race condition and improperly trusting incoming messages from the users as server messages. First the authentication process is that omicli sends credentials to omiengine and omiengine sends them to omiserver to be validated. omiserver sends a response back.

An attacker can attempt to race that response, by sending a success message to omiengine before omiserver replies. This does require knowing the connection number for the omicli connection as it is included in the response from omiserver however according to the author this is usually a number less than 10, and I imagine it is an incremental number so it should be fairly predictable, and you can try multiple times.