Cloudflare Containers-ийн хуучин блок 18/24 туршилтад өгөгдөл задруулжээ

Cloudflare-ийн есдүгээр сарын 24-ний техникийн тайланд судлаачид Containers-ийн 24 байршуулалтын 18-д, 22 үндсэн зангилааны 20-д өмнөх хэрэглэгчийн дискний өгөгдлийн үлдэгдэл илрүүлсэн бөгөөд Containers болон түүнд суурилсан Sandboxes-ийн эмзэг байдлыг бүрэн зассан гэжээ. Шинэ контейнерт дахин оноосон хадгалах сангийн блокийг цэвэрлээгүйгээс уг өгөгдөл уншигдсан; засварыг Cloudflare дэд бүтцийнхээ түвшинд хийсэн тул хэрэглэгч тохиргоо өөрчлөх шаардлагагүй.

Accomplish-ийн судлаач Орен Йомтов асуудлыг есдүгээр сарын 4-нд мэдээлсэн бөгөөд багийн нийтлэлд лавлахын жагсаалт, SQLite өгөгдлийн сан, Chromium хөтчийн профайл, .env болон нэвтрэх мэдээлэл хадгалдаг файлууд олдсоныг дурджээ. Эдгээр нь ажиллаж буй өөр хэрэглэгчийн дискийг шууд нээж уншсан хэрэг биш: өмнөх контейнер чөлөөлсний дараа дараагийн контейнерт очсон блокоос сэргэсэн материал юм. Cloudflare хадгалж үлдсэн дискний үйлдлийн бүртгэлээс хорлонт ашиглалтын нотолгоо олоогүй гэж мэдээлсэн.

Ямар өгөгдөл өртсөн бэ

Эмзэг байдал нь өмнөх хэрэглэгчийн файлын системийн үлдэгдлийг дараагийн хэрэглэгчийн контейнерт харагдуулах боломж олгожээ. Лавлахын бүтэц нь өмнө ямар файл, хавтас байсныг илтгэж болох бол өгөгдлийн сангийн хуудас болон бүтцийн хувьд бүрэн SQLite сан нь зөвхөн хоосон зай харагдаагүйг харуулна. Судлаачдын нэрлэсэн профайл, .env, нэвтрэх мэдээллийн файлууд нь тухайн блокт хэрэглээний эмзэг мэдээлэл хадгалагдаж болохыг тодорхой болгож байна.

Гэхдээ нийтлэгдсэн баримт тодорхой хэрэглэгчийн ямар нууц үг, түлхүүр эсвэл мэдээлэл уншигдсаныг тогтоох боломж өгөхгүй. Судлаачид сэргээсэн блокуудыг шалгасан ч Cloudflare-д хүргүүлсэн материалдаа гуравдагч этгээдийн файлын нэр, таних мэдээлэл, нэвтрэх мэдээлэл болон файлын агуулгыг оруулаагүй. Тэдний ашигласан шинжилгээний программ агуулгыг хэвлэхийн оронд тоо, хэмжээ, файлын бүтцийн шалгалтын үр дүн гаргасан байна.

Cloudflare Sandboxes нь Containers дээр ажилладаг учраас хадгалалтын ижил алдаанд өртсөн. Контейнер өөрт нь оноосон дискийг унших эрхтэй байх нь хэвийн; асуудал нь тэр дискт өмнөх хэрэглэгчийн цэвэрлээгүй байтууд дагалдан орсонд байв. Ингэснээр үйлчилгээний өөр өөр хэрэглэгчийн өгөгдлийг тусгаарлах ёстой зааг хадгалах сангийн блок дахин хуваарилах үед алдагдсан.

Жижиг бичилт яагаад хуучин өгөгдлийг үлдээв

Containers контейнер бүрт бичих боломжтой үндсэн диск олгодог. Linux-ийн dm-thin механизм дискт шаардлагатай үед нь физик блок оноодог бөгөөд контейнерын диск устахад ашиглаж байсан блокууд олон хэрэглэгчийн ачаалалд үйлчилдэг нийтлэг санд буцдаг. Дараагийн хэрэглэгчид блокийг өгөхөөс өмнө хуучин агуулгыг тэглэх нь энэ зохион байгуулалтын тусгаарлалтад чухал.

Нөлөөлсөн хадгалах сангийн тохиргоонд skip_block_zeroing идэвхтэй байснаар шинээр оноосон блокийг тэглэх үйлдэл алгасагджээ. Блокийг бүхэлд нь шинэ өгөгдлөөр дарвал өмнөх агуулга солигдоно. Харин блокийн зөвхөн нэг хэсэгт бичвэл бусад хэсэгт байсан байтууд хэвээр үлдэх боломжтой болсон.

Туршилтад 64 КиБ хэмжээтэй блокийн 4 КиБ хэсгийг шинэ өгөгдлөөр дарж, үлдсэн 60 КиБ хэсгээс өмнөх контейнерын байтуудыг уншсан. Судлаачид эхлээд файлын систем дотор сул гэж тэмдэглэгдсэн талбайг сонгож, тэнд жижиг бичилт хийснээр нийтлэг сангаас физик блок оноолгожээ. Дараа нь дискийг блокийн түвшинд уншихад өөрсдийн бичээгүй хэсгийн өгөгдөл харагдсан.

Энэ дараалал чухал: шинэ дискний огт ашиглаагүй хэсгийг шууд уншихад dm-thin тэг утга буцаадаг. Жижиг бичилт физик блок оноолгосны дараа л түүний үлдсэн хэсэг уншигдах боломжтой болсон. Иймээс алдаа нь контейнерууд нэг сервер хуваалцсанд бус, өмнөх эзэмшигчээс чөлөөлөгдсөн блокийг цэвэрлэлгүй дахин оноосонд байв.

18/24 гэсэн үр дүнгийн хүрээ

Үлдэгдэл олон байршуулалтад илэрсэн нь энэ аргыг бодит орчинд давтан хэрэгжүүлж болсныг харуулдаг. Харин байршуулалтын тоо Cloudflare-ийн нийт хэрэглэгчдийн хэдэн хувь өртсөнийг хэмжээгүй. Контейнерыг аль сервер дээр ажиллуулахыг үйлчилгээ өөрөө шийддэг тул судлаачид хүссэн хэрэглэгч, контейнер эсвэл серверээ сонгож онилох боломжгүй байв.

Уншигдах материал нь тухайн серверийн нийтлэг санд өмнө ямар блок буцсан, дараа нь тэр блок шинэ дискт оноогдсон эсэхээс хамаарчээ. Судлаачид олдсон лавлахын блокуудыг өөрсдийн туршилтын файлын системээс ялгахын тулд ext4-ийн шалгах нийлбэрийг ашигласан. Ингэснээр шинэ контейнер өөрөө үүсгэсэн өгөгдлийг өмнөх хэрэглэгчийн үлдэгдэл гэж андуурах эрсдэлийг багасгасан.

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

Засварыг хэрхэн дуусгав

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

Бэлэн контейнерын дүрсний кешэд өмнөх тохиргоогоор үүссэн давхаргууд мөн үлдэж болох байв. Шинэ контейнер тэдгээр давхаргыг дахин ашиглавал шинэ блок оноох үеийн цэвэрлэгээ хэрэгжихгүй. Тиймээс компани ажиллаж байсан контейнеруудын дискийг хэрэглээнээс гаргаж, хуучин кешийг арилан, зангилаануудыг дахин эхлүүлсэн.

The Hacker News-ийн мэдээлснээр судлаачид есдүгээр сарын 14-нд туршилтын арга нь ажиллахаа больсныг шалгаж, Cloudflare хуучин кешийн цэвэрлэгээг есдүгээр сарын 19-нд дуусгажээ. Иймээс шинэ блокт хийх өөрчлөлт болон өмнө үүссэн диск, кешийг цэвэрлэх ажил хоёулаа бүрэн засварт багтсан.

Cloudflare-ийн шалгасан дискний үйлдлийн бүртгэлд судлаачид болон компанийн инженерүүдийн зөвшөөрөгдсөн туршилтаас өөр ижил хэв шинжтэй үйл ажиллагаа илрээгүй. Одоо Containers эсвэл Sandboxes ашигладаг хэрэглэгч энэ эмзэг байдлыг хаахын тулд өөрийн талд шинэ тохиргоо хийх шаардлагагүй; өмнө ямар өгөгдөл үлдэгдэл блокт орсныг нийтлэгдсэн мэдээллээр хэрэглэгч тус бүрээр тогтоох боломжгүй байна.