Skip to content

VirtualBox shared-folder escape (cooperating VMs)

İki işbirlikçi guest'in tek bir shared folder'a write erişimiyle host'un path-traversal kontrolünü (vbsfPathCheckRootEscape) race ettiği bir VirtualBox guest-to-host sorunu; bir rename, çözülen path'i desync eder ve bir guest'in host filesystem'inde shared folder dışındaki dosyaları açmasına izin verir.

Mechanism

Note

Bir shared folder, guest'in bir host directory subtree'sini okumasına/yazmasına izin verir. Isolation invariant'ı, host'un guest-supplied bir path'i normalize etmesi ve açmadan önce shared-folder root'unun altında kaldığını kanıtlamasıdır — yani base/a/b/c/../../../foo, base altında çözülmeli, asla ondan kaçmamalıdır. Host kontrolü vbsfPathCheckRootEscape(), component'leri dolaşırken directory hiyerarşisinin statik olduğunu varsayar, yani base/a/b/c/../../..'in base'e eşdeğer olduğunu. Bu varsayım bir TOCTOU'dur: Linux'ta eşzamanlı bir rename, kontrol ile asıl open arasında bir directory'yi taşıyabilir, böylece .. segment'leri validate edilenden farklı bir tree'ye karşı çözülür — shared-folder sınırını aşıp host filesystem'in geri kalanına geçen bir path-resolution race condition'ı. Exploitation, aynı shared folder'a yazan iki işbirlikçi guest (ya da iki thread) gerektirir: biri dolaşır, diğeri rename eder.

Walkthrough

Public referans: Exploit-DB 41597 "Cooperating VMs can Escape from Shared Folder". Kavramsal, zaten-public yol:

  1. İki guest (VM A ve VM B), base'de köklenmiş aynı host shared folder'a write erişimine sahiptir.
  2. VM A, dışarı tırmanmak için tasarlanmış .. segment'leriyle derin bir path'i tekrar tekrar açar, ör. base/a/b/c/../../../foo.
  3. VM B eşzamanlı olarak bir ara directory'yi rename eder, ör. tam VM A'nın isteği çözülürken base/a/b/c'yi base/c_'ye taşır.
  4. Host, path'i eski hiyerarşiye karşı validate etti, ama .. artık yeni olana karşı çözülür, böylece VM A'nın open'ı base/../../foo'ya iner — yani shared folder dışındaki foo, host filesystem'inde VM process'inin erişebildiği herhangi bir yerde.
  5. Host process'inin ayrıcalıkları dahilinde keyfi host dosyalarını okumak/yazmak için race'i tekrar tekrar kazan.

Warning

Bug sınıfı için dokümante edilmiş, public ve patch'lenmiş bir sorun. Bu bir logic/TOCTOU race condition'ıdır, memory corruption değil; host offset'leri işin içinde değildir.

Statik-hiyerarşi varsayımı neden güvensiz 
check:  base / a / b / c / ../ ../ ../ foo   ==>  proven under base   (time T0)
rename:           base/a/b/c  ->  base/c_                              (time T1)
open:   base / a / b / c / ../ ../ ../ foo   ==>  base/../../foo       (time T2)

Detection

  • Host tarafı: shared root dışında çözülen shared-folder open'ları; açılan her dosyanın realpath'ini configure edilmiş root'a karşı denetleme.
  • Davranışsal: işbirlikçi guest'lerden eşzamanlı rename fırtınaları ile derin ..-yüklü path open'ları, normal dosya erişimi için anormaldir.

Mitigation

  • Oracle'ın, shared-folder path'ini atomik olarak çözen / open sonrası yeniden kontrol eden (ya da openat/O_NOFOLLOW-tarzı component-bazlı resolution ile açan) VirtualBox fix'ini uygula ki rename'ler kontrolü desync edemesin.
  • Güvenilmez (ya da karşılıklı güvenilmez, işbirlikçi) guest'lere bir shared folder'a write erişimi verme; read-only ya da hiç shared folder olmamasını tercih et.
  • Shared folder'larda symlink oluşturmayı devre dışı tut (varsayılan) ve VM process'ini deprivileged çalıştır.

References

  • Exploit-DB 41597 — "Oracle VM VirtualBox - Cooperating VMs can Escape from Shared Folder": https://www.exploit-db.com/exploits/41597