Januscape: Guest VM ಅನ್ನು Host ಗೆ ಎಸ್ಕೇಪ್ ಮಾಡಲು ಅನುಮತಿಸುವ 16-ವರ್ಷಗಳ ಹಳೆಯ KVM ದೋಷ

ಟೆನೆಂಟ್‌ಗಳ ನಡುವಿನ ಗೋಡೆ ಈಗಷ್ಟೇ ಬಿರುಕು ಬಿಟ್ಟಿದೆ

ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್‌ನ ಸಂಪೂರ್ಣ ಭರವಸೆಯು ಒಂದು ಸರಳ ಊಹೆಯ ಮೇಲೆ ನಿಂತಿದೆ: ನೀವು ಬಾಡಿಗೆಗೆ ಪಡೆಯುವ virtual machine ಅದು ಚಾಲನೆಯಲ್ಲಿರುವ ಭೌತಿಕ host ಅನ್ನು ಸ್ಪರ್ಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಖಂಡಿತವಾಗಿಯೂ ಅದರ ಪಕ್ಕದಲ್ಲಿರುವ ಅಪರಿಚಿತರ VM ಅನ್ನು ಸ್ಪರ್ಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆ ಗೋಡೆಯನ್ನು hypervisor isolation ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಮತ್ತು Linux ನಲ್ಲಿ ಇದನ್ನು KVM — ಜಗತ್ತಿನ ಕ್ಲೌಡ್ ಸರ್ವರ್‌ಗಳ ಪ್ರಮುಖ ಭಾಗವನ್ನು ನಡೆಸುವ Kernel-based Virtual Machine ನಿಂದ ಜಾರಿಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಜುಲೈ 4, 2026 ರಂದು, Linux kernel ನಿರ್ವಾಹಕರು ಹದಿನಾರು ವರ್ಷಗಳಿಂದ ಆ ಗೋಡೆಯನ್ನು ರಹಸ್ಯವಾಗಿ ದುರ್ಬಲಗೊಳಿಸುತ್ತಿದ್ದ ದೋಷವನ್ನು ಮುಚ್ಚಲು ತುರ್ತು stable ರಿಲೀಸ್‌ಗಳ ಸರಣಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದರು. CVE-2026-53359 ಎಂದು ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾದ ಮತ್ತು "Januscape" ಎಂದು ಅಡ್ಡಹೆಸರಿಡಲಾದ ಇದು, ಸಾಮಾನ್ಯ guest VM ನೊಳಗೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಕೋಡ್ host kernel ಅನ್ನು ಕರಪ್ಟ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ — Intel ಮತ್ತು AMD ವ್ಯವಸ್ಥೆಗಳೆರಡರಲ್ಲೂ. ಪ್ಯಾಚ್ ಲಭ್ಯವಾಗಿದೆ ಎಂದರೆ ಇದರ ವಿವರಗಳು ಸಾರ್ವಜನಿಕವಾಗಿವೆ ಎಂದರ್ಥ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಪರಿಹಾರ ಎಲ್ಲಿದೆಯೋ, ಅಲ್ಲೆಲ್ಲಾ ಶೀಘ್ರದಲ್ಲೇ ಸಾರ್ವಜನಿಕ exploit ಕೂಡ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ಈಗ ಅತ್ಯಂತ ಪ್ರಮುಖವಾಗಿದೆ.

Januscape ನಿಜವಾಗಿ ಏನಾಗಿದೆ

Januscape ಎಂಬುದು use-after-free ದುರ್ಬಲತೆಯಾಗಿದೆ. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಒಂದು ಪ್ರೋಗ್ರಾಂ ಮೆಮೊರಿಯ ತುಣುಕನ್ನು ಹಿಂತಿರುಗಿಸಿದ ನಂತರ ಮತ್ತು ಅದನ್ನು ಬೇರೆ ಯಾವುದಕ್ಕೋ ಮರುಬಳಕೆ ಮಾಡಿದ ಮೇಲೆಯೂ ಸಹ ಬಳಸುತ್ತಿದ್ದರೆ use-after-free ಸಂಭವಿಸುತ್ತದೆ — ಅಂದರೆ ಬಾಡಿಗೆದಾರರು ಖಾಲಿ ಮಾಡಿ ಅಪರಿಚಿತರು ಬಂದ ನಂತರವೂ ಅದೇ ವಿಳಾಸಕ್ಕೆ ಪತ್ರ ಕಳುಹಿಸಿದಂತೆ. ಆ "freed" ಜಾಗದಲ್ಲಿ ಬರೆಯಲು ದಾಳಿಕೋರನು ಸಿಸ್ಟಮ್ ಅನ್ನು ಒಪ್ಪಿಸಿದರೆ, ಅದನ್ನು ಮೂಲ, ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾ ಎಂಬಂತೆಯೇ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಈ ದೋಷವು KVM ನ shadow MMU ನಲ್ಲಿದೆ. Guest VM ಒಂದನ್ನು ರನ್ ಮಾಡಿದಾಗ, ಅದು ಮೆಮೊರಿ ವಿಳಾಸಗಳ ತನ್ನದೇ ಆದ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಆದರೆ ಅವು host ನ ನೈಜ ವಿಳಾಸಗಳಲ್ಲ. ಈ ಎರಡರ ನಡುವೆ ಅನುವಾದಿಸಲು ಏನಾದರೂ ಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಆ ಕೆಲಸವನ್ನು memory management unit ಮಾಡುತ್ತದೆ. ಹಲವು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ KVM ಈ ಅನುವಾದವನ್ನು ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ host ನ ನೈಜ ಪೇಜ್‌ಗಳಿಗೆ guest ನ ಪೇಜ್‌ಗಳನ್ನು ಮಿರರ್ ಮಾಡುವ "shadow" page tables ಬಳಸಿ ಮಾಡುತ್ತದೆ. Januscape ಎಂಬುದು ಆ shadow-MMU ಎಮ್ಯುಲೇಶನ್‌ನಲ್ಲಿರುವ ಒಂದು ದೋಷವಾಗಿದೆ: ಕೇವಲ guest-side ಕ್ರಿಯೆಗಳ ಮೂಲಕ, ದಾಳಿಕೋರನು host kernel ನ shadow page ಅನ್ನು — ಅಂದರೆ guest ಅನ್ನು ಗಡಿಯೊಳಗೆ ಇಡಬೇಕಾದ ರಚನೆಯನ್ನೇ ಕರಪ್ಟ್ ಮಾಡಬಹುದು.

"Intel ಮತ್ತು AMD ಎರಡೂ" ಎಂಬುದು ಏಕೆ ಭಯಾನಕ ಭಾಗವಾಗಿದೆ

ಹೆಚ್ಚಿನ virtual-machine escape ದೋಷಗಳು ವೆಂಡರ್-ನಿರ್ದಿಷ್ಟವಾಗಿರುತ್ತವೆ. ಅವು Intel ನ VT-x ಅಥವಾ AMD ನ AMD-V ನ ಒಂದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ದುರ್ಬಳಕೆ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದು ಚಿಪ್ ಅನ್ನು ಬಳಸುವ ಪ್ರೊವೈಡರ್ ಅಪಾಯದಲ್ಲಿದ್ದರೆ ಇನ್ನೊಬ್ಬರು ಸುರಕ್ಷಿತವಾಗಿರುತ್ತಾರೆ. ಆದರೆ Januscape ವಿಭಿನ್ನವಾಗಿದೆ. ಇದು KVM ಎರಡೂ ವೆಂಡರ್‌ಗಳಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳುವ shadow-MMU ಕೋಡ್‌ನಲ್ಲಿದೆ, ಅದಕ್ಕಾಗಿಯೇ ಇದನ್ನು Intel ಮತ್ತು AMD x86 ವ್ಯವಸ್ಥೆಗಳೆರಡರಲ್ಲೂ ಟ್ರಿಗರ್ ಮಾಡಬಹುದಾದ ಸಾರ್ವಜನಿಕವಾಗಿ ತಿಳಿದುಬಂದ ಮೊದಲ guest-to-host escape ಎಂದು ವರ್ಣಿಸಲಾಗಿದೆ.

ವಿವಿಧ ಹಾರ್ಡ್‌ವೇರ್ ಹೊಂದಿರುವ ಕ್ಲೌಡ್ ಆಪರೇಟರ್‌ಗೆ, ಇದು ಸಾಮಾನ್ಯ ಸುರಕ್ಷಿತ ಮಾರ್ಗವನ್ನು ಇಲ್ಲದಂತೆ ಮಾಡುತ್ತದೆ. ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಮೈಗ್ರೇಟ್ ಮಾಡಲು ಯಾವುದೇ "ಸುರಕ್ಷಿತ" ಪ್ರೊಸೆಸರ್ ಇಲ್ಲ. ಈ ದುರ್ಬಲ ಕೋಡ್ ರನ್ ಆಗುವ ಪ್ರತಿಯೊಂದು ಸ್ಥಳದಲ್ಲೂ ಈ ಒಂದೇ ತಂತ್ರವು ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಇದು ನಿಜವಾಗಿಯೂ ಎಷ್ಟು ಗಂಭೀರವಾಗಿದೆ

ಸಾರ್ವಜನಿಕವಾಗಿ ಬಿಡುಗಡೆಯಾದ proof-of-concept ಹಾನಿಯ "ಸೌಮ್ಯ" ಆವೃತ್ತಿಯನ್ನು ಮಾಡುತ್ತದೆ: ಇದು host ಅನ್ನು ಪ್ಯಾನಿಕ್ ಮಾಡುತ್ತದೆ. ಅದು ಹಾನಿಕಾರಕವಲ್ಲವೆಂದಲ್ಲ — ಅಂತಹ ಒಂದು ಪ್ಯಾನಿಕ್ ಸಂಪೂರ್ಣ ಭೌತಿಕ ಮೆಷಿನ್ ಅನ್ನು ಮತ್ತು ಅದರಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು tenant VM ಅನ್ನು ಕ್ರಾಶ್ ಮಾಡುತ್ತದೆ, ಇದು ಆ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿರುವ ಎಲ್ಲರಿಗೂ denial-of-service ಉಂಟುಮಾಡುತ್ತದೆ.

ಇನ್ನೂ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ ಬಿಡುಗಡೆಯಾಗದ ಭಾಗ. ಈ ದೋಷವನ್ನು ಕಂಡುಹಿಡಿದು ವರದಿ ಮಾಡಿದ ಭದ್ರತಾ ಸಂಶೋಧಕ Hyunwoo Kim (@v4bel), ಬಿಡುಗಡೆಯಾಗದ ಇನ್ನೊಂದು ಪ್ರತ್ಯೇಕ exploit ಇದೇ ದೋಷವನ್ನು ಸಂಪೂರ್ಣ host code execution ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ ಎಂದು ತಿಳಿಸಿದ್ದಾರೆ. ಅದು ಅತ್ಯಂತ ಭಯಾನಕ ಸನ್ನಿವೇಶ: ಒಂದು ಅಗ್ಗದ VM ನಿಂದ ದಾಳಿಕೋರನ ಕೋಡ್ host ನಂತೆ ರನ್ ಆಗಿ, ಪಕ್ಕದ ಪ್ರತಿಯೊಂದು tenant ನ ಮೆಷಿನ್ ಅನ್ನು ಓದಲು ಮತ್ತು ಮರುಬರೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಈ ದೋಷವು ಎಷ್ಟು ಗಂಭೀರವಾಗಿತ್ತೆಂದರೆ, ಸಂಪೂರ್ಣ guest-to-host escape ಗೆ 250,000 US dollars ವರೆಗೆ ಪಾವತಿಸುವ Google ನ kvmCTF ರಿವಾರ್ಡ್ ಪ್ರೋಗ್ರಾಂಗೆ ಇದನ್ನು zero-day ಆಗಿ ಸಲ್ಲಿಸಲಾಗಿತ್ತು. ಮತ್ತು ಇದು ಸುಮಾರು ಹದಿನಾರು ವರ್ಷಗಳ ಕಾಲ ಕಣ್ಣೆದುರೇ ಅಡಗಿಕೊಂಡಿತ್ತು.

ನಿಜವಾಗಿ ಯಾರಿಗೆ ಅಪಾಯವಿದೆ

ಇದು ನಿಮಗೆ ಸಕ್ರಿಯ ಬೆದರಿಕೆಯಾಗಲು ಎರಡು ಷರತ್ತುಗಳು ನಿಜವಾಗಿರಬೇಕು:

ನೀವು untrusted guests ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ. Public clouds, VPS providers, shared CI/CD runners, sandbox services — ಅಂದರೆ ನೀವು ನಡೆಸುವ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಅಪರಿಚಿತರು VM ಅನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದಾದ ಯಾವುದೇ ಸ್ಥಳ.

ನೀವು nested virtualization ಅನ್ನು ತೋರಿಸುತ್ತೀರಿ (expose). ದಾಳಿಯ ಮಾರ್ಗವು ಆ guests ಗಾಗಿ nested virt ಎನೇಬಲ್ ಆಗಿರುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ.

ನಿಮ್ಮ ಸ್ವಂತ ಕೆಲಸದ ಹೊರೆಯನ್ನು (workloads) ಮಾತ್ರ ಹೋಸ್ಟ್ ಮಾಡುವ single-tenant ಸರ್ವರ್ ಅನ್ನು ನೀವು ರನ್ ಮಾಡುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಅಪಾಯವು ಅತ್ಯಂತ ಕಡಿಮೆಯಿರುತ್ತದೆ — ಏಕೆಂದರೆ ದಾಳಿಕೋರನು ಈಗಾಗಲೇ ನಿಮ್ಮ ಸ್ವಂತ VM ಒಂದರ ಒಳಗಿರಬೇಕಾಗುತ್ತದೆ. ಆದರೆ ನೀವು ಕಂಪ್ಯೂಟ್ ಅನ್ನು ಮಾರಾಟ ಮಾಡುತ್ತಿದ್ದರೆ ಅಥವಾ ಹಂಚಿಕೊಳ್ಳುತ್ತಿದ್ದರೆ, ಇದನ್ನು ತುರ್ತು ವಿಷಯವೆಂದು ಪರಿಗಣಿಸಿ.

ಹಂತ 1: ನೀವು ಅಪಾಯದಲ್ಲಿದ್ದೀರಾ ಎಂದು ತಿಳಿದುಕೊಳ್ಳಿ

ಚಾಲನೆಯಲ್ಲಿರುವ kernel ಆವೃತ್ತಿಯನ್ನು ಮತ್ತು nested virtualization ಎನೇಬಲ್ ಆಗಿದೆಯೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ:

# Which kernel am I running?
uname -r

# Is nested virtualization on? (Intel host)
cat /sys/module/kvm_intel/parameters/nested

# Or on an AMD host
cat /sys/module/kvm_amd/parameters/nested

ಒಂದು ವೇಳೆ ಯಾವುದೇ ಕಮಾಂಡ್ Y (ಅಥವಾ 1) ಅನ್ನು ನೀಡಿದರೆ ಮತ್ತು ನಿಮ್ಮ kernel ಕೆಳಗೆ ನೀಡಲಾದ ಫಿಕ್ಸ್ ಮಾಡಿದ ರಿಲೀಸ್‌ಗಳಿಗಿಂತ ಹಳೆಯದಾಗಿದ್ದರೆ, ನೀವು ಅಪಾಯದ ವ್ಯಾಪ್ತಿಯಲ್ಲಿದ್ದೀರಿ.

ಹಂತ 2: ಫಿಕ್ಸ್ ಮಾಡಿದ Kernel ಗೆ ಪ್ಯಾಚ್ ಮಾಡಿ

ಫಿಕ್ಸ್ ಮಾಡಿದ stable kernels ಜುಲೈ 4, 2026 ರಂದು ಬಿಡುಗಡೆಯಾಗಿವೆ. ಈ ಕೆಳಗಿನ ಯಾವುದಾದರೂ ಒಂದಕ್ಕೆ ಅಪ್‌ಡೇಟ್ ಮಾಡಿ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ರಿಬೂಟ್ ಮಾಡಿ:

7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

ಹೆಚ್ಚಿನ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್‌ಗಳಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯ ಪ್ಯಾಕೇಜ್ ಅಪ್‌ಡೇಟ್ ಆಗಿದೆ:

sudo apt update && sudo apt full-upgrade   # Debian / Ubuntu
sudo dnf update kernel                       # Fedora / RHEL family
# then reboot into the new kernel
sudo reboot

ರಿಬೂಟ್ ನಂತರ uname -r ನೊಂದಿಗೆ ನೀವು ಪ್ಯಾಚ್ ಮಾಡಿದ ಬಿಲ್ಡ್‌ನಲ್ಲಿದ್ದೀರಿ ಎಂದು ದೃಢಪಡಿಸಿ.

ಹಂತ 3: ನಿಮಗೆ ತಕ್ಷಣವೇ ಪ್ಯಾಚ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, Nested Virtualization ಅನ್ನು ಡಿಸೇಬಲ್ ಮಾಡಿ

Untrusted guests ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಆದರೆ ತಕ್ಷಣವೇ ರಿಬೂಟ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ host ಗಳಿಗೆ, nested virtualization ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು ದಾಳಿಯ ಮಾರ್ಗವನ್ನು ಇಲ್ಲದಂತೆ ಮಾಡುತ್ತದೆ:

# Intel host
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

# AMD host
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

ಇದು ಜಾರಿಗೆ ಬರಲು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ರೀಲೋಡ್ ಮಾಡಿ (ಅಥವಾ ರಿಬೂಟ್ ಮಾಡಿ). ಇದರ ಪರಿಣಾಮವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ: ಇದು ನಿಮ್ಮ tenants ಅವಲಂಬಿಸಿರುವ ಯಾವುದೇ ನ್ಯಾಯಸಮ್ಮತ nested virtualization ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ — ಅಂದರೆ VMs ಒಳಗೆ ರನ್ ಆಗುವ VMs. ಇದು ಒಂದು ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರವೇ ಹೊರತು, kernel patch ಗೆ ಪರ್ಯಾಯವಲ್ಲ.

ಉಪಸಂಹಾರ

Januscape ಎಂಬುದು ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್‌ನಲ್ಲಿನ ಅತ್ಯಂತ ಬಲವಾದ ಗೋಡೆಯು ಇಂದಿಗೂ ಸಾಫ್ಟ್‌ವೇರ್‌ನಿಂದ ನಿರ್ಮಿತವಾಗಿದೆ, ಮತ್ತು ಹದಿನಾರು ವರ್ಷಗಳ ಹಿಂದೆ ಬರೆದ ಸಾಫ್ಟ್‌ವೇರ್ ಇಡೀ ಉದ್ಯಮಕ್ಕೆ ಬೆದರಿಕೆ ಹಾಕುವಷ್ಟು ಸಮಯ ಒಂದೇ ತಪ್ಪನ್ನು ಅಡಗಿಸಿಡಬಲ್ಲದು ಎಂಬುದಕ್ಕೆ ನೆನಪೂಟಿಕೆಯಾಗಿದೆ. ಶುಭ ಸುದ್ದಿ ಏನೆಂದರೆ ಪರಿಹಾರವು ಈಗಾಗಲೇ ಲಭ್ಯವಿದೆ ಮತ್ತು ತಡೆಯುವ ಮಾರ್ಗ ಸರಳವಾಗಿದೆ. ಕಂಪ್ಯೂಟ್ ಹಂಚಿಕೊಳ್ಳುವ ಪ್ರತಿಯೊಬ್ಬ ಆಪರೇಟರ್ ಮುಂದಿರುವ ಕೆಲಸ ಸ್ಪಷ್ಟವಾಗಿದೆ: ನಿಮ್ಮ kernel ಪರಿಶೀಲಿಸಿ, ಪ್ಯಾಚ್ ಮಾಡಿ, ಮತ್ತು ಇಂದು ಪ್ಯಾಚ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಸಾಧ್ಯವಾಗುವವರೆಗೆ nested virtualization ಅನ್ನು ಆಫ್ ಮಾಡಿ. ಸಾರ್ವಜನಿಕ ಪ್ಯಾಚ್ ಮತ್ತು ಅಪಾಯಕಾರಿ ಸಾರ್ವಜನಿಕ exploit ನಡುವಿನ ಸಮಯವು ದಿನಗಳಲ್ಲಿರುತ್ತದೆ, ತಿಂಗಳುಗಳಲ್ಲ.

ಸಕಾರಾತ್ಮಕ ಅಂಶಗಳು

• ಪರಿಹಾರವು ಈಗಾಗಲೇ ಲಭ್ಯವಿದೆ. ದೋಷ ಸಾರ್ವಜನಿಕವಾದ ದಿನವೇ ಪ್ಯಾಚ್ ಮಾಡಲಾದ stable kernels ಬಿಡುಗಡೆಯಾದವು, ಆದ್ದರಿಂದ ಪರಿಹಾರವು ಸಾಮಾನ್ಯ ಅಪ್‌ಡೇಟ್ ಆಗಿದೆ, ಯಾವುದೇ ಸಂಶೋಧನಾ ಯೋಜನೆಯಲ್ಲ.
• ಸ್ಪಷ್ಟ, ತಕ್ಷಣದ ಮುನ್ನೆಚ್ಚರಿಕಾ ಕ್ರಮ. Nested virtualization ಡಿಸೇಬಲ್ ಮಾಡುವುದರಿಂದ ನೀವು ಹೊಸ kernel ಗೆ ರಿಬೂಟ್ ಮಾಡುವ ಮುಂಚೆಯೇ ದಾಳಿಯ ಮಾರ್ಗವನ್ನು ಮುಚ್ಚುತ್ತದೆ.
• ಸಂಯೋಜಿತ ಬಹಿರಂಗಪಡಿಸುವಿಕೆ (Coordinated disclosure) ಯಶಸ್ವಿಯಾಗಿದೆ. Google ನ kvmCTF ರಿವಾರ್ಡ್ ಪ್ರೋಗ್ರಾಂ ಮೂಲಕ ದೋಷವು ನಿರ್ವಾಹಕರನ್ನು ತಲುಪಿತು, ಮತ್ತು ಹಾನಿಕಾರಕ exploit ಬರುವ ಮೊದಲೇ ಪ್ಯಾಚ್ ಬಿಡುಗಡೆಯಾಯಿತು.

ನಕಾರಾತ್ಮಕ ಅಂಶಗಳು

• ಹದಿನಾರು ವರ್ಷಗಳ ಕಾಲ ರಹಸ್ಯವಾಗಿ ಅಪಾಯಕ್ಕೆ ಸಿಲುಕಿದ್ದ ಸ್ಥಿತಿ. ಬಹಿರಂಗಪಡಿಸುವಿಕೆಗೆ ಮೊದಲು ಈ ದೋಷವನ್ನು ರಹಸ್ಯವಾಗಿ ಎಂದಿಗೂ ದುರ್ಬಳಕೆ ಮಾಡಿಕೊಂಡಿಲ್ಲ ಎಂದು ಯಾರೂ ಖಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ.
• Cross-vendor ವ್ಯಾಪ್ತಿ. ಇದು ಹಂಚಿಕೊಳ್ಳಲಾದ shadow-MMU ಕೋಡ್‌ನಲ್ಲಿ ಇರುವುದರಿಂದ, ಬದಲಿಯಾಗಿ ಬಳಸಲು ಯಾವುದೇ "ಸುರಕ್ಷಿತ" Intel ಅಥವಾ AMD ಚಿಪ್ ಲಭ್ಯವಿಲ್ಲ.
• ಸಂಪೂರ್ಣ RCE exploit ಖಾಸಗಿಯಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ. ಸಾರ್ವಜನಿಕ PoC ಕೇವಲ host ಅನ್ನು ಕ್ರಾಶ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಬಲವಾದ, ಬಿಡುಗಡೆಯಾಗದ ಆವೃತ್ತಿಯು host code execution ಸಾಧಿಸುತ್ತದೆ ಎಂದು ಸಂಶೋಧಕರು ದೃಢಪಡಿಸಿದ್ದಾರೆ.

ಎಚ್ಚರಿಕೆ

ಸಾರ್ವಜನಿಕ proof-of-concept ಅನ್ನು ಅಪಾಯದ ಗರಿಷ್ಠ ಮಿತಿ ಎಂದು ಭಾವಿಸಬೇಡಿ. ಇದು ಕೇವಲ host ಅನ್ನು ಪ್ಯಾನಿಕ್ ಮಾಡುತ್ತದೆ; ಸಂಪೂರ್ಣ host execution ಪಡೆಯುವ ಖಾಸಗಿ exploit ನಿಜವಾದ ಅಪಾಯವಾಗಿದೆ. ನೀವು multi-tenant ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಅನುಕೂಲಕ್ಕಿಂತ kernel patch ಗೆ ಆದ್ಯತೆ ನೀಡಿ, ಮತ್ತು uname -r ನೊಂದಿಗೆ ಪ್ರತಿಯೊಂದು host ನಿಜವಾಗಿಯೂ ದೋಷ ಸರಿಪಡಿಸಲಾದ ಬಿಲ್ಡ್‌ಗೆ ರಿಬೂಟ್ ಆಗಿದೆಯೇ ಎಂದು ದೃಢಪಡಿಸಿ — ಹಳೆಯ kernel ಅನ್ನು ಇನ್ನು ರನ್ ಮಾಡುತ್ತಿರುವ ಪ್ಯಾಚ್ ಮಾಡಲಾದ ಪ್ಯಾಕೇಜ್ ಯಾವುದನ್ನೂ ರಕ್ಷಿಸುವುದಿಲ್ಲ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

ಇದು ನನ್ನ ವೈಯಕ್ತಿಕ ಲ್ಯಾಪ್‌ಟಾಪ್ ಅಥವಾ ಡೆಸ್ಕ್‌ಟಾಪ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆಯೇ? ಪರೋಕ್ಷವಾಗಿ ಮಾತ್ರ. ನೀವು nested virtualization ನೊಂದಿಗೆ untrusted guest VMs ರನ್ ಮಾಡುತ್ತಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಈ ದಾಳಿಯ ಮುಖ್ಯ ಗುರಿಯಲ್ಲ — ಆದರೆ ನಿಮ್ಮ kernel ಅನ್ನು ಪ್ಯಾಚ್ ಮಾಡುವುದು ಸೂಕ್ತ ನೈರ್ಮಲ್ಯವಾಗಿದೆ.

Nested virtualization ಅನ್ನು ಡಿಸೇಬಲ್ ಮಾಡುವುದು ಒಂದೇ ಸಾಕೇ? ಇದು untrusted guests ಗಾಗಿ ತಿಳಿದಿರುವ ದಾಳಿಯ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದರೆ ಇದು ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರವಾಗಿದೆ. ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ kernel patch ಅನ್ನು ಅನ್ವಯಿಸಿ ಮತ್ತು ಪ್ಯಾಚ್ ಮಾಡಲಾದ host ಗಳಲ್ಲಿ ಮಾತ್ರ nested virt ಅನ್ನು ಮತ್ತೆ ಎನೇಬಲ್ ಮಾಡಿ.

ನನ್ನ ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ ಇದನ್ನು ನನಗಾಗಿ ಸರಿಪಡಿಸಬಹುದೇ? ಪ್ರಮುಖ ಪ್ರೊವೈಡರ್‌ಗಳು ತಮ್ಮ ಕಡೆಯ host hypervisor ಅನ್ನು ಪ್ಯಾಚ್ ಮಾಡುತ್ತಾರೆ; ನಿಮ್ಮ ಸ್ವಂತ guest VMs ದುರ್ಬಲ ಘಟಕವಲ್ಲ. ಒಂದು ವೇಳೆ ನೀವು ಆಗಿದ್ದರೆ — ಅಂದರೆ ಪ್ರೊವೈಡರ್ ಆಗಿದ್ದು ಕಂಪ್ಯೂಟ್ ಅನ್ನು ಮರುಮಾರಾಟ ಮಾಡುತ್ತಿದ್ದರೆ ಅಥವಾ ಶೇರ್ಡ್ ರನ್ನರ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತಿದ್ದರೆ — ಜವಾಬ್ದಾರಿ ನಿಮ್ಮದಾಗಿರುತ್ತದೆ.

ಇದಕ್ಕೆ "Januscape" ಎಂದು ಏಕೆ ಹೆಸರಿಡಲಾಗಿದೆ? ಈ ಹೆಸರು ಎರಡು ಮುಖಗಳ ರೋಮನ್ ದೇವತೆಯಾದ Janus ಅನ್ನು ನೆನಪಿಸುತ್ತದೆ — x86 ಪ್ರಪಂಚದ Intel ಮತ್ತು AMD ಎರಡೂ ಮುಖಗಳನ್ನು ಆವರಿಸಿರುವ ದೋಷಕ್ಕೆ ಇದು ಸೂಕ್ತವಾಗಿದೆ.

ಟ್ಯಾಗ್‌ಗಳು

security, linux, virtualization, kvm, cve