CVE-2026-31431 (Copy Fail) - Bunu Nasıl Hafiflettik

Geçen hafta ciddi bir Linux kernel yerel yetki yükseltme açığı açıklandı: CVE-2026-31431, takma adıyla "Copy Fail". Modern Linux dağıtımlarında geniş bir kernel sürümü aralığını etkiliyor ve açıklamadan kısa süre sonra herkese açık bir exploit ortaya çıktı.

Ne olduğunu, bunun Appbox için ne anlama geldiğini ve bu konuda ne yaptığımızı açıkça paylaşmak istiyorum. Kısa versiyon: container'larımızın inşa edilme biçimi sayesinde, kullanıcı namespace yeniden eşlemesiyle çalışan uygulamalar, yamalı kernel'ler kullanıma alınmadan önce bile bunun host root erişimine dönüşmesine karşı zaten korunuyordu. Dün (4 Mayıs 2026) ayrıca her sunucuyu yamalı bir kernel'e yükseltmek için acil bakım gerçekleştirdik; bu nedenle hata artık filomuzdan tamamen kaldırıldı.

"Copy Fail" Nedir?

CVE-2026-31431, kernel'in AF_ALG kriptografik API'sinde bulunan bir açıktır. Belirli bir cipher'a (authencesn(hmac(sha256),cbc(aes))) bağlanarak ve kernel'in sayfaları geçici bir tampona ekleme biçimini kötüye kullanarak, yetkisiz yerel bir kullanıcı değiştirme izni olmaması gereken dosyaların page cache'ine doğrudan keyfi 4 baytlık parçalar yazabilir; buna /usr/bin/su gibi SUID binary'leri de dahildir.

su dosyasının page cache kopyası küçük bir kötü amaçlı ELF ile üzerine yazıldığında, bir sonraki çalıştırma saldırganın kodunu UID 0 olarak çalıştırır. Host için oyun biter.

Ayrıntılı teknik detaylar (shellcode ayrıştırması, syscall izleri ve tüm geri kalanlar) için Andrea Veri'nin yazısı mükemmel: CVE-2026-31431: Copy Fail vs. rootless containers. Ayrıca bir sonraki bölümde konuşacağımız şeyi, yani user namespace'lerin bu exploit'i etkisiz hale getirdiğini, eBPF ve uid_map kanıtlarıyla göstermiş.

Appbox Uygulamaları Neden Zaten Hafifletilmişti?

Exploit, setuid(0) çağrısının gerçekten host root yetkisi vermesine dayanır. User namespaces etkin olan bir container'da olan şey bu değildir.

User namespace'ler container'ın UID alanını host üzerinde farklı (yetkisiz) bir UID aralığına eşler. Bu nedenle exploit container içinde başarılı olduğunda ve setuid(0) başarı döndürdüğünde, ortaya çıkan "root" shell gerçek root'a değil, normal yetkisiz bir host kullanıcısına eşlenir. Shellcode çalışır, istem # olarak değişir, ancak host üzerinde:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

Hepsi bu. Host dosyalarına erişim yok, /etc/shadow yok, host root yok. Container'ın namespace sınırı bunun bir host-root kaçışına dönüşmesini durdurur.

Platform düzeyinde her Appbox, kullanıcı namespace yeniden eşlemesi etkin başlatılan kendi Docker daemon'una sahiptir. Sözde kodda daha çok şöyle görünür:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Bu eşleme host üzerinde ayrılmış özel bir subordinate UID/GID aralığıyla desteklenir:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

Bunun yanında, uygulama tanımları bir uygulamanın özel işlem gerektirmesi durumunda UsernsMode değerini hâlâ açıkça override edebilir:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

Bu yüzden bunu doğru tarif etmenin yolu şudur: kullanıcı namespace yeniden eşlemesi platform varsayılanının bir parçasıdır ve uygulama bazındaki istisnalar açıkça belirtilir. Ek yetenekler gerektiren işlevler sundukları için farklı ayarlara ihtiyaç duyan az sayıda uygulama vardır ve bu durumlar ayrı şekilde ele alınır.

Başka bir deyişle: normal yeniden eşlenmiş kurulumla çalışan uygulamalarda Copy Fail, bir container ihlalini host root erişimine dönüştüremezdi.

Yine de Neyi Düzeltmek İstedik?

User namespace'ler host kaçışını durdurur, ancak hatayı container içinde ortadan kaldırmaz. Bir saldırgan uygulama sınırı içinde hâlâ "container root" yetkisine yükselebilirdi; bu sınırlandırılmış olsa da yine de iyi bir durum değildir. Kernel'in kendisi savunmasızdı ve bunun ortadan kalkmasını istedik.

Hatadan haberdar olur olmaz maruziyetimizi değerlendirmeye başladık. Kullanıcı namespace yeniden eşlemesi normal uygulama kurulumumuz için sorunun host-escape tarafını zaten engelliyor olsa da altta yatan kernel hatasının mümkün olduğunca hızlı şekilde kaldırılmasını istedik.

Dün Ne Yaptık?

Pazar gecesi, filo genelinde kernel yükseltmesini kullanıma alabileceğimiz en erken pencere olan 4 Mayıs 2026 Pazartesi için acil bakım planladık.

Bu pencere sırasında:

• Her host, "Copy Fail" düzeltmesini içeren resmi Debian kernel paketleriyle yükseltildi.
• Hedef basitti: yalnızca mevcut namespace izolasyonumuza güvenmek değil, savunmasız kernel yolunu tamamen kaldırmak.

Bakım tamamlandı. Her Appbox host'u artık yamalı bir kernel çalıştırıyor.

Bu Sizin İçin Ne Anlama Geliyor?

• Hiçbir şey yapmanız gerekmedi. Uygulamalarınız çalışmaya devam etti ve bakım penceresi sırasında yaşanabilecek kısa kesintiler müşterinin görebileceği tek etkiydi.
• Dünkü yamadan önce bile kullanıcı namespace yeniden eşlemesi, bu hatanın normal bir uygulama ihlalini host root erişimine dönüştüremeyeceği anlamına geliyordu. Bu izolasyon modelinin var olma sebebi tam olarak bu tür senaryolardır.
• Bundan sonra politikamız değişmiyor: user namespace'ler varsayılan olarak açık kalacak ve çok az sayıdaki istisna ek güvenlik incelemesinden geçecek.

Büyük Resim

Bu, başlığı ("yerel yetki yükseltme, herkese açık exploit, etkilenen her modern kernel") felaket gibi görünen CVE'lerden biri ve pek çok paylaşımlı kiracı ortamı için gerçekten de öyleydi. Bizim için felaket olmamasının nedeni, yıllar önce bazen bize biraz uyumluluk maliyeti çıkaran mimari kararları almamızla aynı neden: uygulamaları en az ayrıcalık ilkesini container katmanına sonradan eklemek yerine oraya en baştan yerleştirerek çalıştırıyoruz.

Derinlemesine savunma gerçekten işe yarıyor. Kernel katmanında hata mı var? Namespace katmanı yakaladı. Namespace katmanında hata mı var? Capability düşürmeleri ve seccomp çoğunu yakalar. Tek bir katmanın kusursuz olduğunu iddia etmiyoruz; yalnızca her zaman bir sonraki katman olduğundan emin oluyoruz.

Bu konuda veya belirli uygulamalarınızın nasıl yapılandırıldığı hakkında sorularınız varsa lütfen bize ulaşın.

Sorularınız mı var? support@appbox.co adresinden bize ulaşın veya billing.appbox.co üzerinden bir ticket açın.