CVE-2019-12114

9.8 CRITICAL

📋 TL;DR

CVE-2019-12114 allows unauthenticated attackers with access to pod-to-pod communication to execute arbitrary code on ONAP HOLMES engine management pods via port 9202. This affects all ONAP Operations Manager (OOM) setups before the Dublin release, enabling remote code execution within Kubernetes pods.

💻 Affected Systems

Products:
  • ONAP HOLMES
  • ONAP Operations Manager (OOM)
Versions: All versions before Dublin release
Operating Systems: Linux (containerized in Kubernetes)
Default Config Vulnerable: ⚠️ Yes
Notes: Only affects deployments where attackers have access to pod-to-pod communication within the Kubernetes cluster.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Complete compromise of the ONAP HOLMES engine pod leading to lateral movement within the Kubernetes cluster, data exfiltration, and potential control over ONAP orchestration functions.

🟠

Likely Case

Attacker executes arbitrary commands within the compromised pod, potentially accessing sensitive ONAP configuration data and disrupting orchestration services.

🟢

If Mitigated

Limited impact due to network segmentation and pod isolation preventing lateral movement beyond the initial compromise.

🌐 Internet-Facing: LOW - Requires access to pod-to-pod communication within the Kubernetes cluster, not directly internet-exposed.
🏢 Internal Only: HIGH - Attackers with internal network access to Kubernetes pod communication can exploit this vulnerability without authentication.

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ⚠️ Yes
Complexity: LOW

Exploitation requires network access to port 9202 on dep-holmes-engine-mgmt pods but no authentication credentials.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Dublin release or later

Vendor Advisory: https://jira.onap.org/browse/OJSI-10

Restart Required: Yes

Instructions:

1. Upgrade ONAP to Dublin release or later. 2. Update all HOLMES components. 3. Restart affected pods and services. 4. Verify no pods are running vulnerable versions.

🔧 Temporary Workarounds

Network Policy Restriction

linux

Implement Kubernetes Network Policies to restrict access to port 9202 on dep-holmes-engine-mgmt pods

kubectl apply -f network-policy.yaml

Service Mesh Implementation

linux

Deploy service mesh (like Istio) with mutual TLS and strict pod-to-pod communication policies

istioctl install --set profile=demo

🧯 If You Can't Patch

  • Implement strict network segmentation and Kubernetes Network Policies to isolate dep-holmes-engine-mgmt pods
  • Deploy intrusion detection systems monitoring for unusual traffic on port 9202 and implement regular pod security audits

🔍 How to Verify

Check if Vulnerable:

Check ONAP version and verify if running pre-Dublin release: kubectl get pods -l app=holmes-engine -o jsonpath='{.items[*].spec.containers[*].image}'

Check Version:

kubectl describe deployment dep-holmes-engine-mgmt | grep Image

Verify Fix Applied:

Confirm ONAP version is Dublin or later and test that port 9202 on dep-holmes-engine-mgmt pods rejects unauthenticated connections

📡 Detection & Monitoring

Log Indicators:

  • Unauthenticated connection attempts to port 9202
  • Unusual process execution within holmes-engine pods
  • Kubernetes API server logs showing pod compromise

Network Indicators:

  • Unexpected traffic to port 9202 between pods
  • Outbound connections from holmes-engine pods to unusual destinations

SIEM Query:

source="kube-audit" AND (objectRef.resource="pods" AND objectRef.name="*holmes*" AND verb="create" OR verb="exec")

🔗 References

📤 Share & Export