AWS Lambda болон Cloud платформуудын суурь тулгуур дахь хагарал: Firecracker microVM-ээс Host руу гарч Root эрх авах "PwnEscape" илчлэгдлээ

Орчин үеийн Cloud computing болон Serverless дэд бүтцийн хамгийн гол амлалт бол "тусгаарлалт" (isolation) билээ. Бид AWS Lambda, AWS Fargate, Fly.io зэрэг платформууд дээр итгэмжлэгдээгүй кодуудыг эсвэл AI агент-уудын үүсгэсэн скриптүүдийг секунд хүрэхгүй хугацаанд асах бичил виртуал машинд (microVM) ажиллуулахдаа "хэзээ ч үндсэн систем рүүгээ нэвтрэхгүй" гэдэгт итгэдэг.

Гэвч аюулгүй байдлын pwn.ai судалгааны баг саяхан "Firecracker VM Escape: PwnEscape Part 2" тайлангаа нийтэлж, Firecracker microVM-ийн хилийг зочны (guest) талаас нь давж, host машин дээр бүрэн root эрхээр код ажиллуулах (Remote Code Execution) боломжтойг бодитоор үзүүллээ.

Энэхүү халдлага хэрхэн хийгдсэн бөгөөд cloud хөгжүүлэгчид, DevOps инженерүүдэд ямар дохио өгч байгааг нарийвчлан авч үзье.

Firecracker яагаад чухал систем бэ?

Amazon Web Services (AWS)-ийн хөгжүүлсэн Firecracker нь Rust хэл дээр бичигдсэн, хэт хөнгөн нээлттэй эхийн Virtual Machine Monitor (VMM) юм. Уламжлалт QEMU шиг нүсэр, хэдэн арван драйвертай биш, ердөө 5 миллисекундийн дотор асах чадвартай, хамгийн бага санах ой ашигладаг тул өнөөдөр дэлхийн олон сая serverless функц, AI code execution sandbox-уудын зүрхэнд ажиллаж байна.

Firecracker нь Линуксийн цөмийн KVM (Kernel-based Virtual Machine) модулийг ашиглан тусгаарлагдсан орчин үүсгэдэг бөгөөд хост дээр ганц л Firecracker процесс болж явдаг. МикроVM бүрийн виртуал процессор (vCPU) нь хост дээрх тусдаа нэг thread-ээр зохицуулагддаг бүтэцтэй.

"PwnEscape" халдлагын гинжин хэлхээ (Exploit Chain)

Судлаачдын дэлгэсэн халдлагын дараалал нь Линукс цөмийн санах ойн удирдлага болон процессорын регистрийн механизмуудыг гайхалтай нарийн ашигласан урлаг байв.

1. Линукс цөмийн сүлжээний алдаа (Эхний шат)

Судалгааны эхний шатанд (Part 1) судлаачид Linux сүлжээний стек дэх CHECKSUM_PARTIAL төлөвтэй холбоотой логик алдааг (CVE-2026-99999) ашиглан хост системийн санах ойг 32 байтаар унших боломжтойг харуулсан байв. Энэхүү санах ойн цоорхой нь виртуал машинаас гарах анхны гишгүүр болжээ.

2. Хост дээрх өөрийн санах ойн хуудсыг олох

Зочин систем (Guest VM) нь өөрийн санах ойд өвөрмөц маркер бүхий 8 байтын тэмдэглэгээ бичээд, Extended Page Tables (EPT) бүтцийг "мөлхөн" (walk) шалгаснаар тэрхүү хуудас хост машины бодит physical memory дээр хаана байрлаж байгааг тодорхойлж авчээ.

3. ASLR-ийг тойрч Firecracker процессыг илрүүлэх

Хост санах ойн page table-үүдийг урвуугаар зураглаж (reverse-mapping), хост дээр тухайн микроVM-ийг удирдан ажиллаж байгаа Firecracker процессын санах ойн хаягуудыг олж авсан байна. Үүний тусламжтайгаар ASLR (Address Space Layout Randomization) хамгаалалтыг нэвт гарч, санах ой дахь Firecracker-ийн бинарийн үндсэн хаягийг тооцоолон гаргажээ.

4. `KVM_RUN` ба `pt_regs` регистрүүдийг онилох

Энэхүү халдлагын хамгийн чухал хэсэг нь энд оршино. Firecracker-ийн vCPU thread нь микроVM-ийн кодыг ажиллуулахын тулд Linux kernel-д:

ioctl(vcpu_fd, KVM_RUN, 0);

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

Судлаачид хост санах ойг засварлах эрхээ ашиглан яг тэр хадгалагдсан pt_regs бүтцийг олж, Instruction Pointer (IP) буюу гүйцэтгэх дараагийн хаягийг халдагчийн дурын функц рүү зааж өөрчилжээ.

5. Сериал портоор өдөөх (Trigger)

Эцэст нь, виртуал машин дотроос өөрийн Virtual Serial Port руу ердөө 1 байт бичих үйлдлийг хийхэд vCPU нь KVM_RUN төлөвөөс гарч хэрэглэгчийн орон зай руу буцахаар хандана.

Энэ үед Линуксийн цөм хуурамчаар засварлагдсан pt_regs-ийг ачаалж, Firecracker процесс нь хост машины бүрэн эрхээр (root) халдагчийн заасан кодыг шууд ажиллуулсан байна!

Хамгийн хачирхалтай нь, халдлага амжилттай болсны дараа судлаачид өөрчилсөн стекийн утгуудаа эргүүлэн цэвэрлэж сэргээсэн тул Firecracker микроVM унаж унтраагүй бөгөөд SSH холболт нь ч тасралгүй хэвийн ажиллаж үлджээ.

Практик дээр энэ хэр аюултай вэ?

Уг нийтлэл цацагдмагц олон нийтийн болон хөгжүүлэгчдийн дунд маш том маргаан өрнөв.

Судлаачдын өөрсдийн тэмдэглэснээр:

"Энэхүү халдлагыг туршсан тохиргоонд Firecracker-ийн нэмэлт хамгаалалтын jailer ашиглагдаагүй байсан."

Firecracker-ийг production түвшинд (жишээ нь AWS Lambda дээр) ашиглахдаа зөвхөн VMM-д найдалгүй, jailer гэх тусгай багажаар Линуксийн namespaces, chroot болон seccomp шүүлтүүрийг тохируулж, процессын эрхийг хамгийн доод түвшинд (drop privileges) аваачдаг. Хэрэв jailer ажиллаж байсан бол VMM дотор код гүйцэтгэсэн ч хост систем дээр бүрэн root эрх шууд авах боломжгүй байх магадлалтай.

Гэсэн хэдий ч энэ нь дараах хоёр чухал үнэнийг хөгжүүлэгчдэд сануулж байна:

Firecracker VMM-ийн хил нь туйлын биш: Хэрэв линукс цөмийн түвшинд алдаа гарвал микроVM-ийн тусгаарлалт хэдхэн шат дамжлагаар нурж болно.
AI Sandbox-уудын эрсдэл: Өнөөдөр олон стартапууд AI агентуудад өөрийн дэд бүтцэд дурын код (arbitrary python/bash script) ажиллуулах эрх өгч байгаа. Ийм үед sandbox-ийг зөвхөн KVM тусгаарлалттайгаар тохируулах нь үхлийн аюултай болохыг уг халдлага нотлов.

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

Хэрэв та өөрийн системд Firecracker эсвэл KVM ашиглан олон хэрэглэгчийн код тусгаарлан ажиллуулдаг бол:

Jailer-ийг заавал ашигла: Firecracker-ийг хэзээ ч шууд root эрхтэй процессоор битгий ажиллуул. Seccomp профайлаар системийн дуудлагуудыг хатуу шүү.
Linux Kernel-ийн шинэчлэлтийг хойшлуулж болохгүй: Виртуалчлалын хамгаалалт нь өөрөө Линуксийн цөм дээр тулгуурладаг тул цөмийн сүлжээний болон санах ойн засваруудыг цаг алдалгүй суулгах шаардлагатай.
Defense in Depth зарчим: Нэг давхарга (KVM) нэвт цохигдсон ч дараагийн давхарга (AppArmor/SELinux, cgroups) халдлагын хүрээг хязгаарлах ёстой.

Виртуалчлалын ертөнц дэх "хэзээ ч эвдэгдэшгүй хана" гэж байдаггүй бөгөөд аюулгүй байдал нь олон давхар хамгаалалтын хатуу зохион байгуулалт дээр тогтдог гэдгийг "PwnEscape" дахин баталлаа.

Эх сурвалж: PWN.AI Security Research Blog ("Firecracker VM Escape: PwnEscape Part 2" - CVE-2026-99999)