Үүлэн технологийн бат бөх хэрэм нурав уу: Firecracker microVM-ээс хост систем рүү бүрэн "зугтаж", Root эрх авсан нь

Орчин үеийн Serverless платформ болон AI код ажиллуулах сэндбокс үйлчилгээнүүдийн итгэл найдварыг хүлээсэн хамгийн гол "хуяг дуулга" бол яах аргагүй microVM архитектур билээ. Бидний сайн мэдэх Docker контейнерууд нь Линуксийн цөмийг (kernel) хоорондоо хуваалцдаг тул сүүлийн үед AWS Lambda, Fargate, Fly.io болон E2B, Replit зэрэг AI системүүд Rust хэл дээр бичигдсэн нээлттэй эхийн Firecracker-ийг аюулгүй тусгаарлагчаараа сонгох болсон. Хүн бүр microVM-ийг "эвдэшгүй хана" мэтээр төсөөлдөг байв.

Гэтэл сүүлийн 24 цагийн дотор технологийн ертөнцийг шуугиулсан нэгэн судалгаа нийтлэгдлээ: Аюулгүй байдлын PWN.AI багийнхан зочин үйлдлийн системээс (guest VM) хост систем рүү амжилттай "зугтаж" (VM Escape), хост дээр бүрэн root эрхээр дурын код ажиллуулах бүрэн гинжин эксплойтыг бодитоор үзүүлжээ.

Энэхүү халдлага хэрхэн ажилласан, үүлэн технологи болон код ажиллуулдаг AI системүүдэд яагаад хүйтэн шүршүүр болж байгааг нарийвчлан авч үзье.

Асуудал юу байв: "PwnEscape" ба CVE-2026-99999

Firecracker нь Линуксийн KVM (Kernel-based Virtual Machine) дээр суурилж, маш цөөн төхөөрөмж эмуляц хийдэг тул халдлагын талбар (attack surface) маш багад тооцогддог. Түүнчлэн Rust хэлний санах ойн аюулгүй байдал (memory safety) нь олон төрлийн алдаанаас хамгаалдаг.

Гэвч PWN багийн судлаачдын үзүүлсэн эксплойт гинж нь зөвхөн Firecracker-ийн кодонд биш, харин түүний үндэс суурь болох Линуксийн цөм болон KVM-ийн төлөв хадгалах логикийн зааг дээр үүссэн цоорхойг чадварлаг ашиглажээ.

Халдлага хэрхэн өрнөснийг алхам алхмаар харвал:

1. Санах ойн "примитив" үүсгэх

Халдагчид эхлээд зочин VM дотроос сүлжээний драйверын түвшинд санах ойг унших боломжтой цоорхойг ашиглаж, өөрийн зочин хуудсыг (guest page) хостын физик санах ойн хаана байрлаж буйг илрүүлсэн байна. Тэд Extended Page Tables (EPT) бүтцийг шалган мөрдөж (page walk), хостын санах ойн зураглалыг урвуулан холбожээ (reverse-mapping).

2. Хост дээрх Firecracker процессыг онилох

Firecracker microVM бүрийн ард хост үйлдлийн систем дээр ажиллаж буй зохицуулагч процесс байдаг. Энэ процессийн виртуал CPU (vCPU) урсгал (thread) бүр зочин кодыг ажиллуулахын тулд Линукс цөм рүү дараах систем дуудлагыг илгээдэг:

ioctl(vcpu_fd, KVM_RUN, 0);

Энэ үед зочин код KVM дотор ажиллаж байх хооронд Firecracker-ийн хэрэглэгчийн орон зайн (userspace) регистрүүдийн төлөв Линуксийн цөм доторх pt_regs бүтцэд хадгалагдан хүлээж байдаг.

3. "pt_regs"-ийг дарж бичих ба Serial I/O триггер

Судлаачид ASLR-ийг амжилттай тойрч гарч, KVM_RUN дуудлага дээр түгжигдсэн vCPU thread-ийн хадгалагдсан pt_regs бүтцийг хостын санах ойгоос олж чаджээ.

Тэд уг бүтцийн RIP (Instruction Pointer) болон Stack Pointer-ийг өөрсдийн хүссэн хост дээрх код руу заан дарж бичсэн байна. Үүний дараа зочин VM дотроос маш энгийн сериал портын бичилт (serial port I/O write) хийхэд л KVM_RUN дуудлага хэрэглэгчийн төлөв рүү буцаж (exit), Firecracker процесс халдагчийн бэлтгэсэн дурын кодыг хостын эрхээр шууд гүйцэтгэж эхэлжээ!

Хамгийн аюултай нь: VM гацахгүй, "чимээгүй" үлддэг

Ихэнх гипервайзорын санах ойн цоорхойнууд (kernel panic эсвэл crash) систем унагааж, мониторинг дээр сэжиг төрүүлдэг бол энэхүү эксплойтын дараа:

Firecracker процесс өөрөө гацаагүй.
Зочин машин хэвийн ажиллаж, SSH холболт нь ч тасраагүй.
Харин хост машин дээр халдагч бүрэн root эрхээ авчихсан байв.

Энэ нь үүлэн дэд бүтцийн хяналтын системүүдэд ямар ч дохиолол өгөхгүйгээр өөр хэрэглэгчийн систем рүү халдах, эсвэл үндсэн серверээс өгөгдөл хулгайлах бодит эрсдэлийг үүсгэж байна.

AI эрин ба Үүлэн платформуудад ямар нөлөөтэй вэ?

Өнөөдөр AI агент (AI Agent), автомат код бичигч системүүдийн эрин үе ирсэнтэй холбоотойгоор олон компани хэрэглэгчийн болон AI-ийн бичсэн шалгагдаагүй кодыг шууд өөрийн дэд бүтэц дээр ажиллуулах шаардлагатай болсон. "Docker контейнер эрсдэлтэй, харин microVM бол тусдаа кернелтэй тул 100% аюулгүй" гэсэн хандлага сүүлийн жилүүдэд ноёрхож байв.

Гэвч энэхүү олдвор нь ганцхан давхаргын хамгаалалтад найдаж болохгүй гэдгийг нотлон харууллаа:

Multi-tenancy аюул: Нэг физик сервер дээр олон хэрэглэгчийн microVM-ийг цуглуулж байршуулдаг бүх үйлчилгээ хост машинд халдлага хийлгэх өндөр эрсдэлтэй тулгарч байна.
Jailer болон Seccomp-ийн ач холбогдол: Хэдийгээр Firecracker төсөл өөрөө нэмэлт "Jailer" (namespaces, cgroups, chroot, seccomp) хамгаалалтыг санал болгодог ч, үүнийг бүрэн зөв тохируулаагүй, зөвхөн microVM-ийн өөрийнх нь тусгаарлалтад найдсан системүүд бүрэн задгай тавигдсаныг санууллаа.

Инженерүүд одоо юу хийх ёстой вэ?

Хэрэв та өөрийн бүтээгдэхүүндээ (жишээ нь, онлайн код компилятор, AI агент сэндбокс, microVM кластер) Firecracker эсвэл үүнтэй ижил түвшний хөнгөн гипервайзор ашигладаг бол дараах алхмуудыг нэн даруй хэрэгжүүлэхийг зөвлөж байна:

Jailer тохиргоогоо шалга: Firecracker процессыг root эрхээр хэзээ ч шууд бүү ажиллуул. jailer-ийн тусламжтайгаар тусдаа unprivileged хэрэглэгч, chroot орчин, user namespaces-ээр хязгаарла.
Seccomp шүүлтүүрийг чангатга: Процессын хийж болох Линукс систем дуудлагуудыг зөвхөн KVM болон шаардлагатай сүлжээний үйлдлээр хатуу хязгаарлах шаардлагатай.
Defense-in-depth зарчим: Дэд бүтцийн аль ч давхарга (hypervisor, container, OS) дангаараа найдвартай байж чадахгүй тул virtualization болон сүлжээний eBPF дээр суурилсан олон шатлалт ажиглалтыг зэрэг хэрэгжүүлэх нь хамгийн чухал юм.

Энэхүү халдлага нь үйлдлийн системийн цөм болон гипервайзорын зааг дахь аюулгүй байдал ямар нарийн, төвөгтэй байдгийг дахин нэг тод харуулсан үйл явдал боллоо.

Эх сурвалж: PWN Research (pwn.ai), Hacker News Community, Daily.dev