Dirty Frag: Genel amaçlı Linux LPE (yerel yetki yükseltme) açığı

 (openwall.com)
2 puan yazan GN⁺ 1 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Dirty Frag, başlıca Linux dağıtımlarının genelinde root yetkisi elde etmeyi mümkün kılan genel amaçlı bir yerel yetki yükseltme açığıdır; sorumlu açıklama takvimi ve ambargo bozulduğu için henüz yama ve CVE yoktur
  • Dirty Pipe ve Copy Fail gibi aynı hata sınıfının bir uzantısıdır; deterministik bir mantık hatası olduğu için race condition gerekmez ve başarı oranı çok yüksektir
  • Açığın etkili ömrü yaklaşık 9 yıl olup Ubuntu, RHEL, Fedora, openSUSE gibi başlıca dağıtımlarda test edilmiştir
  • Mevcut Copy Fail azaltma önlemleri (algif_aead kara listesi) uygulanmış sistemler de hâlâ Dirty Frag'e karşı savunmasızdır
  • Geçici azaltma önlemi olarak, dağıtım yamaları çıkana kadar açığı tetikleyen esp4, esp6, rxrpc modüllerinin kaldırılması önerilir

Genel Bakış

  • sk_buff yapısındaki frag üyesini kirleten bir hata sınıfı olup, Dirty Pipe ve Copy Fail'in dahil olduğu aynı hata sınıfının bir uzantısıdır
  • xfrm-ESP Page-Cache Write açığı ile RxRPC Page-Cache Write açığını zincirleyerek başlıca Linux dağıtımlarında root yetkisi elde etmeyi mümkün kılar
  • Deterministik bir mantık hatası olduğundan zamanlama penceresine bağlı değildir ve race condition gerektirmez
  • Exploit başarısız olsa bile kernel panic oluşmaz ve başarı oranı çok yüksektir

İki açığın zincirlenme nedeni

  • xfrm-ESP Page-Cache Write, Copy Fail'e benzer şekilde güçlü bir keyfi 4 baytlık STORE primitive sağlar ve çoğu dağıtımda bulunur; ancak namespace oluşturma yetkisi gerektirir
  • Ubuntu'da AppArmor politikası, ayrıcalıksız kullanıcı namespace oluşturmayı engelleyebildiği için bu ortamda xfrm-ESP Page-Cache Write tetiklenemez
  • RxRPC Page-Cache Write namespace oluşturma yetkisi gerektirmez, ancak rxrpc.ko modülünün kendisi çoğu dağıtımda yer almaz
    • Ancak Ubuntu'da rxrpc.ko modülü varsayılan olarak yüklenir
  • İki açığı zincirlemek, her birinin zayıf noktalarını karşılıklı olarak telafi ederek tüm başlıca dağıtımlarda root yetkisi elde etmeyi mümkün kılar

Copy Fail ile ilişkisi

  • Copy Fail, bu araştırmayı başlatan motivasyondu
  • xfrm-ESP Page-Cache Write, Copy Fail ile aynı sink'i paylaşır ancak algif_aead modülünün kullanılabilir olup olmamasından bağımsız olarak tetiklenebilir
  • Açıklanmış Copy Fail azaltma önlemleri (algif_aead kara listesi) uygulanmış sistemler de Dirty Frag'e karşı hâlâ savunmasızdır

Etki kapsamı

  • xfrm-ESP Page-Cache Write: commit cac2661c53f3 (2017-01-17)'ten upstream'e kadar
  • RxRPC Page-Cache Write: commit 2dc334f1a63a (2023-06)'dan upstream'e kadar
  • Açığın etkili ömrü yaklaşık 9 yıldır
  • Test edilmiş dağıtım sürümleri:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

Azaltma önlemleri

  • Sorumlu açıklama takvimi ve ambargo bozulduğu için hiçbir dağıtım için yama mevcut değildir
  • Geçici azaltma önlemi olarak, açığın bulunduğu modülleri kaldıran şu komut sağlanmıştır: 
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    • esp4, esp6, rxrpc modüllerini /etc/modprobe.d/dirtyfrag.conf içine kara liste olarak kaydeder ve kaldırır
  • Her dağıtım yamayı backport ettikten sonra ilgili güncellemenin uygulanması gerekir

Açıklanma süreci

  • Dirty Frag belgesi, linux-distros@vs.openwall.org bakımcılarıyla yapılan görüşmenin ardından, onların talebi üzerine yayımlandı
  • Ambargo dış etkenler nedeniyle bozulmuş durumda ve şu anda herhangi bir yama ya da CVE bulunmuyor
  • PoC, linux-distros ile yapılan görüşme sonrasında doğru bilgi sağlama amacıyla yayımlandı; yetkisiz sistemlerde kullanılması yasaktır

İlgili okumalar

2 yorum

 
GN⁺ 27 분 전
Hacker News yorumları

  • Bu, kök neden ve istismar biçimi açısından Copy Fail ile çok benzer
    Bence bu, LLM’lere çok fazla iş devredildiğinde kolayca kaybedilen şeyin, yani keşfin, iyi bir örneği. Yapay zekayla zafiyet araştırması yapınca yaratıcılığın epey köreldiği hissine kapılıyorum. Soru sorduğunuzda cevabın hemen geldiği akışta, çevrede başka neler olduğuna bakamıyorsunuz. Cin gibi tam olarak istediğinizi veriyor, ama fazlasını vermiyor
    Copy Fail’i bulan araştırmacı şüpheli bir şey gördükten sonra yapay zekaya büyük ölçüde dayanmış, ama kendisi doğrudan daha fazla kod kurcalasaydı böyle ikiz hataları bulma şansı daha yüksek olurdu. Aynı zamanda prompt’u biraz daha az yönlendirici verseydi, güncel LLM’ler de muhtemelen bu hataları bulabilirdi. Birlikte çalışıp performansı düşüren, oldukça ilginç bir negatif sinerji vakası

    • Yanlış okumadıysam bu benzer değil, aynı kök neden. IPsec’in Extended ESN üst 32 biti == authencesn modülü/şifre modu sorunu
      copy.fail’de yanlış şey düzeltildi ve insanlar suçu aceleyle AF_ALG’ye attı
      [düzenleme: Evet, bu aynı authencesn sorunu. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... kodunda authencesn sadece yorumda geçiyor ama yine de aynı sorun]
      [düzenleme2: RxRPC sorunu ayrı, burada ESP tarafını kastediyorum]
    • Sonraki prompt olarak “benzer türde hataları bul” da denebilirdi. Gerçek örnek bir kez ortaya konduktan sonra benzer hataları bulmak o kadar zor değil
      Yaratıcılık meselesini anlıyorum. Her araç gibi yapay zeka da bakış açısını daraltabilir. İş akışını tamamen ona bırakmayıp sadece yardımcı olarak kullanmak zor
    • Anlamıyorum. Bu hataları en başta bulan şey LLM’lerdi. Ama şimdi o keşif, LLM’lerin zafiyet bulmada kötü olduğuna dair bir işaretmiş gibi sunuluyor
    • Bunun dayanağı olan bir şey mi var, yoksa sadece o anda aklına geleni mi söylüyor merak ediyorum
    • Yapay zekanın bulduğuna benzer ama tamamen aynı olmayan temel bir zafiyetten, yapay zekanın keşif yapamadığı sonucunu çıkarmak bence çok zor
      Bu iki zafiyetin birlikte açıklandığı durum dışında, hangi karşıolgusal senaryoda “yeterince iyi keşif yaptı” denebilirdi merak ediyorum

  • “Ambargo bozulduğu için bu zafiyetler için yama ya da CVE yok”
    Bağlantı: https://github.com/V4bel/dirtyfrag
    Ayrıntılı analiz: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    Önemli kısım şu: “Copy Fail bu araştırmaya başlamamın motivasyonuydu. Özellikle Dirty Frag zafiyet zincirindeki xfrm-ESP Page-Cache Write, Copy Fail ile aynı sink’i paylaşıyor. Ancak algif_aead modülünün kullanılabilir olmasından bağımsız olarak tetikleniyor. Başka bir deyişle, herkese açık Copy Fail hafifletmesi olan algif_aead kara listesi uygulanmış sistemlerde bile Linux hâlâ Dirty Frag’e karşı savunmasız”
    Hafifletme şu şekilde, ama bizzat test etmedim ya da doğrulamadım: “Sorumlu açıklama takvimi ve ambargo bozulduğu için hiçbir dağıtımda yama yok. Aşağıdaki komutla zafiyeti tetikleyen modülleri kaldırın”
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    Hafifletme tartışmalarında yeniden başlatma gerekebileceği veya makine zaten istismar edildiyse yukarıdaki komuttan sonra şunun da çalıştırılması gerektiği söyleniyor: sudo echo 3 > /prox/sys/vm/drop_caches

    • sudo echo 3 > /prox/sys/vm/drop_caches komutunda sudo işe yaramaz. Çünkü sudo sadece echo’yu çalıştırır, gerçek yazma işlemini değil
      Ayrıca makine zaten istismar edildiyse, bunun için artık çok geçtir. Diskteki her şey bozulmuş olabilir; tüm disk imajını yeniden oluşturmak gerekir
    • sudo olmayan bir shell’de sudo echo ve yönlendirmeyi bu şekilde kullanamazsınız
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      veya
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      Ayrıca /proc yazım hatasını da düzelttim
    • Bu arada echo 1 > ... ile de hafifletilebilir. Her şeyi boşaltmaya gerek yok; sadece page cache’i temizleyen 1 yeterli
      Ubuntu 26.04 üzerinde yerel olarak test ettim: exploit’i çalıştırıp root aldım, hafifletmeyi ayarladım, sonra argümansız su komutunu tekrar çalıştırınca anında parolasız root oldum. Ardından page cache’i temizleyince su parola istemeye başladı

  • Yalnızca beyaz listedeki kernel modüllerinin yüklenmesini garanti edecek kolay bir yönteme ihtiyacımız var. Gerek bile olmayan modülleri sürekli kara listeye almaktan yoruldum

  • Tekrar soruyorum, copy.fail’de neden tüm suç algif_aead’ye yıkılıyor? Aptal olan authencesn
    authencesn düzeltilmedi ve şimdi sonucu ortaya çıkmış oldu. Normal ağ soketleri üzerinden aynı, muhtemelen de aynı out-of-bounds write durumuna erişilebildiği görülüyor
    Keşke bu akla gelseydi ama gelmedi
    [düzenleme: ESP üzerinden olan sorunu kastediyorum. RxRPC sorunu anladığım kadarıyla tamamen ayrı]

  • Eğer bu gerçekten tüm büyük dağıtımlarda çalışıyorsa, bakımcıların ne kadar sorumsuz olabildiğine yine şaşırıyorum. Muhtemelen kullanıcıların %0,1’inden azına yarayacak isteğe bağlı kernel özellikleri neden varsayılan olarak etkin?
    Bu, 1999’daki Linux dağıtımlarının varsayılan kurulumda internete açık onlarca ağ hizmetiyle gelmesi gibi hissettiriyor. Ama artık yıl 1999 değil

    • Dağıtım bakımcısının “buna ihtiyacın olmaz (YAGNI)” diye karar verip belirli özellikleri kara listeye alması oldukça büyük bir beklenti. Kimsenin ne kullandığını bilemezler. Kullanıcıların geri dönüp gerçekten istediklerine göre derlemeyi ayarlamaları her zaman mümkün
      Linux’un eski günlerinde make menuconfig çalıştırıp kernel’e tam olarak istediğimiz özellikleri seçtiğimiz zamanları hatırlıyorum. Dürüst olmak gerekirse o günlere dönmek istemem
      Ama burada kolay iyileştirilebilecek hedef RHEL. RHEL birçok modülü yüklenebilir modül olarak bırakmak yerine doğrudan kernel’e derleyip ekliyor; bu yüzden copy fail gibi hafifletmeler mümkün olmadı. Belki bunlar biraz azaltılabilir
    • Kullanıcının kullanmayacağı düşünülen bileşenleri kapatıp aynı zamanda sistemi kullanmayı aşırı zorlaştırmayan bir yol yok. Bu aptal işletim sistemini 25 yıldır kullanmama rağmen ben bile bir şey yapmak için neyi açıp neyi kapatmam gerektiğini bilmiyorum
      Linux dağıtım bakımcıları gezegendeki en sorumluluk sahibi yazılım bakımcıları. Güvenlik uygulamaları, saçma programlama dili paket yöneticilerinden çok daha iyi; seçilmiş paket listeleri tutuyorlar, değişiklikleri inceliyorlar, hataları yamalıyorlar, karmaşık paketleme sorunlarını çözüyorlar, düzeltmeleri backport ediyorlar, aşamalı sürümler kullanıyorlar, dosyaları dünya çapındaki mirror’lara dağıtıyorlar ve tüm dosyaları kriptografik olarak doğruluyorlar. Üstelik bütün bunları ücretsiz yapıyorlar; bunu da unutmayalım
    • Varsayılan olarak etkin değil. Gerektiğinde yüklenen isteğe bağlı modüller bunlar. Kernel’in genel mimarisi, kullanıcının ihtiyaç duyduğu çekirdek işlevleri derlenmiş olarak içerip geri kalan neredeyse her şeyi ihtiyaç anında yüklenen modüller olarak sunmak üzerine kurulu
    • Pek çok açıdan mobil olmayan bilgisayarlar hâlâ 1999’da yaşıyor. Android, çok daha genç olduğu ve tüm yığına zorunlu erişim denetimini entegre etme fırsatı bulduğu için diğer Linux sistemlerinden çok daha güvenli
    • Bunu istismar etmek için bilgisayara doğrudan erişim gerekir. Kötü niyetli bir USB aygıtı, tedarik zinciri saldırısı ya da kullanıcının isteyerek veya otomatik olarak kuracağı bilinen bir yazılımın istismarı gibi bir şey olmalı. Dahası, fiilen keyfi terminal komutları çalıştırabilmeniz gerekir; bu da o yazılımın izolasyonu açısından zaten ciddi bir ihlal demektir
      Saldırgan bunların hepsini başardıysa durum zaten kötüdür. Bununla root’a yükselmek artık o noktada dertlerin daha küçük olanıdır
      Aşağıda başka birinin paylaştığı gibi https://xkcd.com/1200/
      İnsanlar paniğe kapılmadan önce bu zafiyetin gerçekte ne olduğunu anlamalı

  • Yıllar sonra sonunda “yeterince çok göz olursa bütün hatalar sığdır” durumuna geldik ama pek iç açıcı değil. Bundan sonra haftada birkaç kez kernel güncellemesi mi yapacağız?

    • Birinin evine girip bir şekilde varsayılan kimlik bilgilerini bulacağını ve hatta root erişimi elde edeceğini mi varsayıyorsun?

  • Ambargonun nasıl bozulduğunu merak ediyorum. Bir sızıntı mı oldu, yoksa üçüncü bir taraf bağımsız olarak mı buldu?

    • Aslında ambargo diye bir şey yok, olamaz da
      Linux açık kaynak olduğu için güvenlik hatalarını düzelten tüm yamalar anında herkes tarafından görülebilir. Kernel geliştirme biçimi gereği bunu aşmanın bir yolu yok. İnsanların “ambargo” dediği şey, yama açıklamasına açıkça “THIS IS A LPE” yazmaz ve sessiz kalırsanız, mailing list’e “resmî” mesaj gidene kadar zafiyet sızmamış gibi davranabileceğiniz yönündeki oldukça aptalca fikir
      Eskiden bu yaklaşım bir ölçüde savunulabilir olabilir, ama LLM çağında mailing list diff’lerini otomatik bir pipeline ile en güncel modellere verip bunların güvenlik sorununu düzelten yamalar olup olmadığını ayırt ettirebildiğiniz için artık sadece aptalca değil, tehlikeli de
    • Yama bağlantısı birinin X hesabında paylaşıldı ve başka biri bunu görüp bir saatten kısa sürede çalışan bir exploit yayımladı. LLM kullanılarak istismar edilmiş olabilir ama hızlı dönüş süresi dışında bunu kanıtlayan bir iddia yok
      https://x.com/encrypted_past/status/2052409822998392962
    • Alakasız bir üçüncü taraf bunu kamuya açık şekilde yayımladı

  • Debian’ın savunmasız olup olmadığını bilen var mı? Debian 12 ve Debian 13 makinelerde exploit’i denedim ama kendim yeniden üretemedim

    • Debian 13, yani Trixie’nin 6.12.57+deb13-amd64 kernel’inde yeniden ürettim, ama Debian 12 Bookworm’un 6.1.0-42-amd64 kernel’inde başaramadım
      Bookworm’da Debian paket güvenlik akışını kullanmayanlar için 6.1.0-42-amd64 kernel’i aslında copy.fail’e karşı bağışık. dirtyfrag’e karşı da bağışık görünmesi şaşırtıcı. Güvenlik akışında henüz yamalanmadıysa commit 2b8bbc64b5c2’yi koruyan bir kernel sürümü seçilebilir. Aynı commit’in bazı Debian 12 kernel sürümlerini dirtyfrag’e karşı tesadüfen güvenli kılıyor olabileceğini düşünüyorum
    • DigitalOcean’daki yeni bir Debian 13 droplet üzerinde exploit’i az önce denedim ve çalıştı
    • Tamamen güncel Debian 13 üzerinde test ettim ve exploit çalışıyor. Hafifletmenin de işe yaradığını doğruladım

  • ubuntu:latest container’ında yeni bir varsayılan kullanıcıyla çalıştırdım
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    Sonuç: dirtyfrag: failed (rc=3)
    Bu iyi haber!

    • Container içinde çalıştırdığımda ben de aynı sonucu aldım, ama host üzerinde doğrudan çalıştırınca shell aldım. Bu sadece exploit’in container içinde çalışmadığını gösteriyor. Dolayısıyla ya container savunmasız değil ya da script’in container’da çalışması için ayarlanması gerekiyor
      copy fail container escape için kullanılabildiğinden (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), exploit’in yalnızca küçük değişiklikler gerektirdiğini tahmin ediyorum
    • Container’ları bu test için güvenilir bir platform olarak görmek zor. İster olması gerektiği için ister başka nedenle olsun, container içinde başarısız olan çok şey var
 
GN⁺ 1 시간 전
Lobste.rs yorumları

  • Linux sunucularını yönetmek için epey olaylı bir hafta oldu. Yine de bu duyuru lafı dolandırmadan doğrudan konuya girdiği için iyi
    Ama hafifletme yönergelerinde neden herkesin stderr'ı gizlediğini anlamıyorum
    Düzeltme: Bunun copy.fail'den “ilham alınarak” 30 Nisan'da bildirildiği söyleniyorsa, bir günden kısa sürede mi bulunmuş oluyor? Etkileyici
    Oldukça büyük bir paylaşımlı sunucuda sudo yetkisine sahip biri olarak, mümkün olduğunca az modül içerecek şekilde çekirdeği kendim derlemek iyi bir fikir olur mu diye de merak ediyorum. Artılarını ve eksilerini derinlemesine tartmış değilim ama bu haftaki iki yerel yetki yükseltme açığının ikisinden de kaçınmayı sağlayabilirdi gibi görünüyor
    Düzeltme 2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    Vay, bunun için setuid gerekmiyormuş. Bunu eklemiş olmaları güzel

    • Ben bakımını yaptığım çok kullanıcılı sistemlerde bunu uyguluyorum ve bu haftaki iki yerel root exploit'inden gerçekten kaçınabildim

  • Çalışan bir sistemde yüklenmiş çekirdek modülleri listesini alıp bunu o sistemin modprobe izin listesi olarak ayarlamak mümkün ve makul olur mu?
    CopyFail ve DirtyFrag, baktığım hiçbir sistemde yüklü olmayan çekirdek modüllerini istismar ediyor gibi görünüyordu. Öyleyse açıkça gerekmeyen modülleri engellemek bazı saldırıları önceden hafifletmeye yardımcı olmaz mı?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    Bunun nasıl mümkün olabildiğini anlamıyorum. Bu ölçekteki bilginin bu kadar güvenilmez bir ortama girmiş olması gerçekten akıl almaz geliyor

    • Buradaki “ilgisiz üçüncü tarafın yayımladığı” şeyin bu vakaya işaret edip etmediğinden emin değilim ama not olarak, Brad Spengler önce düzeltme commit'inin yayınlandığını fark edip commit mesajının ima ettiği güvenlik açığını çıkarmış, ardından yanıtlarda biri vibe coding ile bir exploit üretmiş
      Linux commit'lerini izleyen herhangi bir üçüncü tarafın da aynı ipuçlarını yakalayıp bir exploit geliştirmiş olması mümkün
    • “İlgisiz üçüncü taraf” ifadesi, o hatanın embargo altında olduğunu bilmedikleri anlamına geliyor gibi
      Buradaki “güvenilmez ortam” internetin tamamı ve fiilen yalıtılmış sayılabilecek pek bir şey yok. Aslında hep böyleydi; sadece artık daha görünür hale geldi. Apache httpd hatalarının düzeltilmeden önce iki kez yeniden keşfedilmesini anlatan Stefan Eissing'in yakın tarihli yazısı da buna dair iyi bir örnek

  • Etkilenen modüllerin gerçekten yüklenemediğini test etmenin bir yolu var mı?
    CopyFail sırasında ilk hafifletmeyi uygularken hata yapmıştım. /etc/modprobe.d/ içindeki dosya adım .conf ile bitmiyordu ve bunu https://news.ycombinator.com/item?id=47954159 adresindeki test komutunu çalıştırana kadar fark etmemiştim. esp4/esp6/rxrpc modülleri için de benzer komutlar var mı?

    • Üç modülün üçünü de modprobe ile yüklemeyi denedim ve geçen seferkiyle aynı hatayı aldım
      Eklenmiş bir kavram kanıtı kodu da var ama onu henüz denemedim