Copy Fail – CVE-2026-31431

 (copy.fail)
9 puan yazan GN⁺ 2026-04-30 | 5 yorum | WhatsApp'ta paylaş
  • 2017’den bu yana tüm Linux dağıtımlarında root yetkisi elde etmeyi mümkün kılan bir konteyner kaçışı / yetki yükseltme açığı
  • Linux çekirdeğinin kriptografi modülündeki (authencesn) basit bir mantık hatasından yararlanıyor; karmaşık zamanlama ayarı (race condition) ya da çekirdek sürümüne göre ince ayar gerektirmeden yalnızca 732 baytlık tek bir Python betiğiyle çalıştırılabiliyor
  • Temel mekanizma, Linux’un dosya çalıştırırken başvurduğu bellek içi önbelleğin (page cache) manipüle edilmesi; AF_ALG (çekirdek kripto soketi) ile splice() (veri kopyalama sistem çağrısı) birleştirilerek setuid ikilisinin önbellekteki kopyasının 4 baytı üzerine yazılıyor
    • Disk üzerindeki gerçek dosya değiştirilmediği için adli disk imajında iz bırakmayan gizli bir saldırı
    • Yeniden başlatma ya da belleğin serbest bırakılması sonrası önbellek özgün haline döndüğünden, geleneksel dosya bütünlüğü kontrolleriyle olay sonrası tespit zor
  • Page cache tüm host genelinde paylaşıldığı için, Kubernetes ortamında tek bir pod bu açıktan yararlanırsa host düğümü ele geçirip diğer kiracıların konteynerlerine de sıçrayabilen bir konteyner kaçışı mümkün
  • Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 ve SUSE 16 üzerinde doğrudan doğrulandı; ayrıcalıksız bir yerel kullanıcı hesabı yeterli ve ağ erişimi ya da çekirdek hata ayıklama özellikleri olmadan anında çalışıyor
  • Mevcut Linux yerel yetki yükseltme (LPE) açıkları deneme başına genelde %30~80 başarı oranına sahip olup yalnızca belirli çekirdek aralıklarında çalışırken, Copy Fail tek denemede %100 başarıyla 9 yıl boyunca (2017~2026) tüm dağıtımları hedefleyebiliyor
  • Aynı page cache manipülasyonu ailesindeki Dirty Pipe (pipe buffer flag istismarı) ve Dirty Cow’dan (zamanlama yarışı gerekir) farklı olarak; race condition olmaması, dağıtıma özgü offset gerektirmemesi ve yeniden derleme istememesi nedeniyle çok daha basit ve güçlü
  • En acil risk altındaki ortamlar: çok kiracılı Linux host’ları, Kubernetes/konteyner kümeleri, CI runner’ları (GitHub Actions self-hosted, GitLab runner vb.), kullanıcı kodu çalıştıran bulut SaaS’leri — güvenilmeyen kodun paylaşılan bir çekirdek üzerinde çalıştığı tüm ortamlar
  • Birinci öncelik çekirdek yaması uygulamak (a664bf3d603d mainline commit’i) — 2017’de eklenen kriptografi modülündeki in-place optimizasyon geri alınarak page cache sayfalarının kriptografik işlemlerin yazma hedefi olmasının önüne geçiliyor
  • Yama öncesi geçici önlem olarak algif_aead modülü devre dışı bırakılabilir; dm-crypt/LUKS, kTLS, IPsec ve SSH gibi yaygın şifreleme işlevleri etkilenmez
  • Konteyner, sandbox ve CI runner gibi güvenilmeyen iş yükü ortamlarında, yama durumundan bağımsız olarak seccomp ile AF_ALG soketi oluşturulmasının engellenmesi öneriliyor
  • Xint’ten Taeyang Lee, "splice()ın page cache sayfalarını kriptografi alt sistemine aktarma yapısının keşfedilmemiş bir hata sınıfı" olduğuna dair ilk içgörüyü ortaya koydu; Xint Code ise çekirdeğin crypto/ alt sistemini yaklaşık 1 saat içinde otomatik tarayarak bunun yapay zeka destekli güvenlik açığı tespiti örneği olmasını sağladı

İlgili okumalar

5 yorum

 
popopo 2026-05-04

Rocky Linux için henüz bir yama çıkmamış gibi görünüyor

RHEL

Almalinux

Rocky Linux

Rocky Linux kullanıyorsanız ve sistemi yeniden başlatamıyorsanız, https://github.com/wgnet/wg.copyfail.patch içindeki bpftool ile engelleme yapmak işe yarar.
 
popopo 2026-05-04

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

Yama var ama... yalnızca abonelik hizmeti deposu üzerinden sağlanıyor. CE sürümü yamalanmamış. (9.7, 10.1 doğrulandı)
 
popopo 28 일 전

2026-05-05 yaması çıktı.

2026-05-10 tarihinde yeni bir güvenlik seçeneği var.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

Güvenlik deposunu eklerseniz, görünüşe göre RHEL kaynaklarının yansıtılmasından bağımsız olarak güvenlik önlemleri almak mümkün.
 
sukso96100 2026-05-02

Ubuntu kullananlar için uygulanacak yöntemlere dair bir rehber yayımlandı; isterseniz ona göz atabilirsiniz.

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
Hacker News görüşleri

  • Linux çekirdeği crypto kodu ile uğraşan biri olarak, periyodik olarak patlayan AF_ALG exploit'leri gerçekten sinir bozucu
    AF_ALG, yeterli inceleme olmadan uzun zaman önce çekirdeğe girdi; yapısı gereğinden fazla karmaşık ve ayrıcalıksız userspace programlarına devasa bir saldırı yüzeyi açıyor
    Üstelik neredeyse gereksiz. userspace tarafında zaten kendi şifreleme kodları var ve çekirdekteki crypto kodu aslında dm-crypt gibi çekirdek içi kullanım senaryoları için tasarlanmıştı
    Bu exploit'teki authencesn de esasen IPsec'in iç implementasyon detaylarından biri; bunu genel amaçlı bir userspace şifreleme/şifre çözme API'si olarak dışarı açmak baştan hataymış gibi geliyor
    Linux çekirdek yapılandırmasını yönetiyorsanız, tüm CONFIG_CRYPTO_USER_API_* seçeneklerini kapatmanızı şiddetle tavsiye ederim
    Sadece bunu yapmak bile bu hatanın yanı sıra geçmişteki ve gelecekteki AF_ALG açıklarının önemli bir kısmını istismar edilemez hale getirirdi
    Eğer bir userspace programı bozulursa, onu userspace crypto koduna taşımaya yardımcı olmak daha doğru olur; nitekim bazıları zaten bu şekilde değişti
    Zaten AF_ALG'nin exploit dışında pek fazla kullanım alanı yoktu
    Eskiden bu tür userspace API'leri bir şekilde tolere ediliyor olabilirdi ama syzbot ve LLM destekli hata tespiti çağında bunu sürdürmek artık zor

    • AF_ALG'nin ne olduğunu bilmediğim için araştırdım ve https://www.chronox.de/libkcapi/html/ch01s02.html karşıma çıktı; orada varlık sebebine dair bazı gerekçeler yazıyordu
      Yalnızca çekirdek modundan erişilebilen donanım hızlandırıcıları userspace'ten kullanabilmek, anahtarları uygulama belleğinde uzun süre tutmak yerine çekirdeğe aktarabilmek ve gömülü sistemler gibi belleğin kısıtlı olduğu ortamlarda userspace crypto kütüphanelerine kıyasla footprint'i azaltabilmek bunlar arasında sayılmış
      Bunun yeterince güçlü bir gerekçe olup olmadığını değerlendiremiyorum ama en azından ortada bir sebep var
    • Bunun çekirdeğe nasıl girdiğini gerçekten merak ediyorum
      Linus'un çekirdeğe neyin gireceği konusunda oldukça seçici olduğu bilindiğinden, böyle bir API'nin kabul edilme hikâyesi ilginç olurdu
    • AF_ALG, çekirdeğin crypto API'sini dosya tanımlayıcıları üzerinden dışa açan bir Linux socket arayüzü
      Hash ve şifreleme işlemlerini sıradan read(2)/write(2) çağrılarıyla ele almayı sağlıyor
    • Bu çekirdek seçeneği kapatıldığında hangi yazılımların bozulacağını en çok merak ediyorum

  • Açıklama sürecinde bir tür karışıklık yaşanmış gibi görünüyor
    Vendor'lar bu zafiyeti pek ciddiye almıyor gibi ve bu yüzden birçok dağıtımda hâlâ yamasız durumda kalmış
    https://access.redhat.com/security/cve/cve-2026-31431 sayfasında "Moderate severity", "Fix deferred" yazıyordu; Debian, Ubuntu ve SUSE takip sayfaları da benzer görünüyordu

    • Yama çekirdeğe girdiği andan itibaren saldırganlar veya gözlemciler için fiilen haftalardır görünür durumdaydı
      Ama upstream bunu açıkça bir zafiyet olarak iletmedi ve Linus ile Greg çekirdekte bu tür sınıflandırmaları kavramsal olarak çok da önemsemiyor gibi görünüyor
    • Dağıtımların bunu orta seviye risk olarak değerlendirmesinin nedeni, bunun uzaktan kod çalıştırma değil yerel erişim gerektirmesi olabilir
      Yine de yerelden root yetkisi yükseltmeye imkân verdiği için, genel olarak yüksek öncelikli görülmesi daha doğru olur gibi duruyor
      https://ubuntu.com/security/cves/about#priority
    • RedHat şimdi bunu Important severity ve Affected olarak değiştirmiş durumda
    • Ubuntu'nun kendi yönergelerine bakınca bunun aslında high priority olması gerekiyor gibi görünüyor ama pratikte medium olarak işaretlenmiş; bu da tutarsız duruyor

  • Hangi çekirdek sürümlerinin etkilendiği ve hangi sürümlerde düzeltildiği ana yazıda doğrudan belirtilmemiş; bu biraz eksik kalmış
    Özellikle bunun builtin bir modül olması ve rmmod ile kolayca çıkarılamaması nedeniyle
    Fedora 44'ün kernel 6.19.14 sürümünün etkilenip etkilenmediğini anlamaya çalışırken linux-cve-announce posta listesinde şu iletiyi buldum: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    Orada sırasıyla 6.18.22, 6.19.12 ve 7.0 sürümlerinde ilgili commit ile düzeltildiği yazıyor; referans olarak faydalı

  • Önerilen azaltma yöntemine uygun olarak çekirdek modülü algif_aead modprobe yapılandırmasıyla engellenmiş mi diye kontrol etmek istiyorsanız, karartılmış shell kodunu olduğu gibi çalıştırmaya gerek yok
    Aşağıdaki gibi birkaç satır Python ile modülün gerçekten yüklenip yüklenmediğini daha okunaklı biçimde kontrol edebilirsiniz
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    Azaltma önlemi doğru uygulandıysa modprobe algif_aead komutu da hata verip başarısız olmalı

  • Etkilenen işletim sistemlerinde tam otonom yapay zeka ajanlarını normal kullanıcı yetkileriyle çalıştıran kimse yoktur herhalde
    Zero-day prompt injection ile birleşirse oldukça felaket olabilir

    • Benim ajanım zaten root olarak çalışıyor, o yüzden böyle bir sorun görmüyorum
    • Neyse ki curl | sh ile kurulum yapmayı sektör standardı haline getirmedik

  • LPE, local privilege escalation anlamına geliyor
    Güvenlik tarafında çok fazla kısaltma var; bağlamdan tahmin etmek mümkündü ama yine de ilk geçtiğinde açık yazılması iyi olurdu

    • LPE, güvenlik topluluğu içinde oldukça yaygın bilinen bir kısaltma; bu yüzden açmadan kullanılması çok büyük bir sorun sayılmaz
      Yine de daha geniş bir okur kitlesine yönelik bir metinde açıkça tanımlanmasının daha iyi olacağına katılıyorum
      Üstelik bu yazının tamamı da biraz AI üretimi gibi görünüyor
    • Geniş kitleye yönelik yazımda kısaltmaları önce açık yazmak temel bir kuraldır ama LLM'ler bu tür rehberleri pek iyi takip etmiyor

  • Bu biraz komik
    Sayfada RHEL 14.3 üzerinde çalıştığı yazıyor ama böyle bir sürüm yok
    Şu anda RHEL 10.x seviyesinde, o yüzden sanki bir TARDIS'e binilmiş gibi hissettirdi

    • 14.3 muhtemelen RHEL sürümü değil, Red Hat tarafındaki GCC sürüm numaralandırmasından gelmiş
      Bazen gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2) gibi görünüyor ve aşağıdaki örneklerde de benzer izler var
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • Aynı satırda 6.12.0-124.45.1.el10_1 de yazıyor; bu ise açıkça RHEL 10 çekirdeği
      Bu tür hataları aslında insanlar daha sık yapar
      Uzun ve kopyala-yapıştır sayı dizileri doğru kalır ama kolay sayılar elle yazılırken yanlış girilir
    • Kusura bakmayın, bu düzeltilecek
      Sorunu anlatmak için bilgileri aceleyle topladığımız bir süreç oldu ve evet, işin biraz pazarlama tarafı da vardı
      Bu yüzden birkaç küçük hata girdi; işaret ettiğiniz için teşekkürler
    • Evet, "doğrudan doğrulanan dağıtım: RHEL 14.3" ifadesini gördüğüm anda en azından açılış sayfası bana AI slop gibi geldi
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      Sayfanın altındaki "Talk to our security experts" kısmını da görünce, o güvenlik uzmanının adının acaba Claude olup olmadığını düşünmeden edemedim

  • RHEL 9/10'da algif_aead modül değil builtin olduğu için unload edilemedi
    Bu yüzden ikinci en iyi çözüm olarak systemd üzerinden AF_ALG'yi engellemenin bir yolunu aradım ve maruz kalan her servis için ayrı bir drop-in gerekiyor
    Genellikle kritik olan sshd ve user@ için hazırlanmış bir Ansible playbook'u da var
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • RHEL 9/10'da çekirdek önyükleme parametresi olarak initcall_blacklist=algif_aead_init ekleyip yeniden başlatmak da mümkündü
      Bunu yaptıktan sonra exploit artık çalışmadı
    • Ben de benzer bir yaklaşım düşündüm ama bunu servis bazında engellemek biraz köstebek vurma oyunu gibi geliyor
      cronjob, slurmjob gibi diğer çalıştırma yolları ne olacak diye endişeleniyorum; tek tek servis eklemek yerine systemd düzeyinde tüm süreçlere kalıtılacak bir mekanizma olsa iyi olurdu

  • Bu exploit'in, bir SUID binary'yi değiştirip PID 0 olarak çalışacak hale getirmeye dayandığı anlaşılıyor
    Ama site Kubernetes / container clusters ve CI runners & build farms ortamlarından kaçışı da iddia ediyor; buna rağmen konteynerden, özellikle de user namespace'ten çıkışı destekleyen gerçek bir açıklama göremedim
    Rootless Podman üzerinde denedim ve beklendiği gibi konteyner dışına çıkamadı
    Ayrıca "2017'den bu yana çıkan tüm Linux dağıtımlarını root yapar" iddiasında bulunuyor ama fiili test sayısı dörtle sınırlı ve Alpine üzerinde çalışmamış

    • Site tarafı da ayrıntılı açıklamanın yakında geleceğini söylediğine göre, muhtemelen ek adımlar veya düzeltmeler part 2'de paylaşılacak
      "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform." diye duyurmuşlar
    • Bu açık, okunabilir dosyaların bellek baytlarını üzerine yazabildiği için farklı ortamlardan kaçış ihtimalini hayal etmek zor değil
    • 2017 sonrası tüm dağıtımlar iddiası muhtemelen açığın 2017'nin ikinci yarısındaki bir commit ile gelmiş olmasına dayanıyor
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      Ama pratikte istismar edilebilirlik, güncel büyük sürümler ile eski bakım çekirdekleri arasında farklılık gösterecektir
    • Bu yazı kendi güvenilirliğine epey zarar vermiş
      Yine de PoC'yi 24.04 instance üzerinde bizzat çalıştırınca açığın gerçek olduğu ve ciddi bir konu gibi göründüğü anlaşılıyor
      Ancak etkilenen dağıtım sayısı iddia edilenden çok daha az gibi duruyor ve 2017'den beri tüm dağıtımlar söylemiyle pek uyuşmuyor
      Örneğin benim yorumum doğruysa Ubuntu'da 16.04 EOL bile bir miktar etkileniyor, ama asıl belirgin etki son dönemde dağıtılmaya başlayan linux-gcp, linux-oracle-6.7 gibi 6.17 serisi vendor çekirdeklerinde görünüyor
    • Rootless bir konteyner içinde bile gerçek UID 0 seviyesine çıkılabiliyorsa, sonraki adımda kaçış mümkün olabilir
      Yine de bunun için ek adımlar gerekir ve Alpine'de de temel açık bulunuyor olabilir; sadece betiğin uyarlanması gerekiyordur
      Sonuçta bu, tamamlanmış genel amaçlı bir exploit değil, bir PoC

  • Sayfanın kendisi biraz vibecoded ve reklam kokuyor ama açık gerçek ve risk seviyesi de yüksek görünüyor
    Bugün gelen büyük güvenlik güncellemesinin nedenini açıklıyor; güncelleme önceliğini yükseltmek gerekecek

    • Bu aslında oldukça açık bir reklam, ama kişisel olarak kötü bir reklam olduğunu düşünmüyorum
      Gerçek bir bug bulup yamalayarak OSS ekosistemine anlamlı katkı sağlıyorlar ve aynı zamanda kendi güvenlik araçlarını satıyorlar
    • Bu insanların reklama ihtiyaç duymadan da zaten fazlasıyla işi varmış gibi görünüyor
      Yine de artık kim web sayfasını elle tek tek hazırlıyor ki; hele çekirdek geliştiricileri söz konusuysa daha da öyle