Yapay zekanın ürettiği curl güvenlik raporları

 (daniel.haxx.se)
1 puan yazan GN⁺ 2024-01-04 | 1 yorum | WhatsApp'ta paylaş
  • curl projesi bir bug bounty programı yürütüyor ve LLM ile hazırlanmış gibi görünen güvenlik raporlarının artması nedeniyle, gerçek açıkları ele almaktan çok sahte raporları doğrulamaya geliştirici zamanı harcanıyor
  • curl şimdiye kadar 70 bin doların üzerinde ödeme yaptı ve 415 rapor aldı; bunların yalnızca 64’ü gerçek güvenlik sorunu çıktı, 77’si ise informative olarak sınıflandırıldı
  • Sorunun özü, raporların ikna edici İngilizce, ayrıntılı açıklamalar ve hatta düzeltme önerileri içermesi nedeniyle inceleme maliyetini ciddi biçimde artırması
  • 2023’te CVE-2023-38545 kod değişikliklerinin sızdırıldığı iddiası ile bir WebSocket buffer overflow raporu geldi, ancak ilkinde gerçek bir sızıntı yoktu, ikincisinde ise buffer overflow bulunmadı
  • Yapay zeka çeviri, metin yazımı desteği veya açık tespit araçları olarak yararlı olabilir; ancak insan doğrulaması olmadan LLM çıktılarının gönderilmesi, açık kaynak güvenlik müdahalesinin maliyetini projelere yüklüyor

curl bug bounty programının karşı karşıya olduğu düşük kaliteli raporlar

  • curl projesi, güvenlik sorunlarını bildiren araştırmacılara gerçek para ödülü veren bir bug bounty programı yürütüyor
  • Ödül ihtimali, kaynak kodda kalıp aramak için grep kullanan ya da yalnızca temel güvenlik tarayıcılarını çalıştırıp yeterli analiz yapmadan sonuç gönderen “luck seekers” tipini çekiyor
  • Geçmişteki düşük kaliteli raporlar çoğunlukla hızlıca ayırt edilip elenebildiği için, proje zamanı kaybı büyük bir soruna dönüşmüyordu
  • curl bug bounty programının bugüne kadarki sonuçları:
    • 70 bin doların üzerinde ödül ödemesi
    • 415 adet açık raporu alındı
    • 64 adet gerçek güvenlik sorunu olarak doğrulandı
    • 77 adet genelde normal hata türü olarak informative sınıfına alındı
    • Tüm raporların %66’sı ne güvenlik sorunu ne de normal bir hataydı

İkna edici sahte raporlar neden daha tehlikeli?

  • Sahte raporlar ne kadar rafine olursa, onları elemek için o kadar fazla inceleme zamanı ve enerji gerekiyor
  • Tüm güvenlik raporları insanlar tarafından okunup gerçekten ne ifade ettiğine karar verilmek zorunda
  • Güvenlik işleri genelde yüksek öncelikli sayıldığından, sahte raporlar da diğer geliştirme işlerini geri plana itebiliyor
  • Gerçek güvenliği iyileştirmeyen raporlar, can sıkıcı hataları düzeltmek ya da yeni özellik geliştirmek için kullanılabilecek zamanı tüketiyor
  • Tekrarlanan düşük kaliteli raporlarla uğraşmak, geliştiricilerin enerji tüketimini de artırıyor

Yapay zeka tarafından üretilmiş gibi görünen güvenlik raporları

  • Yapay zeka genel amaçlı bir araç; iyi amaçlarla da kullanılabilir ama yanlış şekillerde kullanılması da çok kolay
  • Yapay zekanın güvenlik sorunlarını tespit etme ve raporlama işinde verimli şekilde kullanılma potansiyeli var, ancak curl projesi henüz iyi bir örnek görmedi
  • Şu anda görülen model, kullanıcıların curl kodunu bir LLM’e verip çıkan çıktıyı bir güvenlik açığı raporu olarak göndermesi
  • Kullanıcılar çoğu zaman yalnızca yapıştır-kopyala yapmıyor, kendi cümlelerini de araya kattıkları için tespit daha da zorlaşıyor
  • Raporun tamamı birebir yapay zeka metni olmasa bile, sonuçta yine geçersiz bir rapor ortaya çıkabiliyor

Yalnızca yapay zeka izine bakarak elemek neden zor?

  • Bazı raporlayanlar İngilizceye akıcı hakim değil ve niyetlerini anlamak için birkaç tur soru-cevap gerekebiliyor
  • Dil ve kültür bariyerleri gerçekten var ve bu iletişim sürecinin kendisi doğal karşılanabilir
  • Bazı raporlayanlar yabancı dilde daha iyi iletişim kurmak için yapay zekayı ya da başka araçları çeviri ve metin yazımı desteği olarak kullanıyor
  • İngilizceyi iyi bilmeyen bir raporlayan da gerçek bir güvenlik sorunu bulup bildirebilir
  • Bu nedenle metnin bir bölümünde yapay zeka üretimi izleri var diye raporu hemen elemek zor; iyi yazılmış sahte raporları ayırt etmek ise daha uzun sürüyor

Örnek A: CVE-2023-38545 kod değişikliklerinin sızdırıldığı iddiası

  • 2023 sonbaharında curl topluluğuna, high şiddet derecesi verilen CVE-2023-38545 için planlı açıklama duyuruldu
  • Bu meselenin açıklanmasından bir gün önce, HackerOne’a “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet” başlıklı bir rapor geldi
  • Yalnızca başlığa bakıldığında, doğruysa büyük sorun olabilecek bir durumdu
  • Ancak rapor, tipik bir yapay zeka halüsinasyonu gibi görünüyordu; geçmiş güvenlik olaylarının gerçeklerini ve ayrıntılarını karıştırıp, gerçekle bağlantısı olmayan yeni bir içerik üretmişti
  • CVE-2023-38545 ile ilgili değişiklikler internete sızdırılmamıştı; internette görülen değişiklikler ise amaçlandığı gibi daha eski bir sorunla ilgiliydi
  • Raporlayan kişi bu sorunu Bard kullanarak bulduğunu söyleyince, hatayı anlamak ve raporu kapatmak kolaylaştı

Örnek B: WebSocket buffer overflow iddiası

  • 28 Aralık 2023 sabahı, HackerOne’a “Buffer Overflow Vulnerability in WebSocket Handling” başlıklı bir rapor geldi
  • Başlık ciddi görünse de, curl’ün WebSocket kodu henüz deneysel özellik olduğundan bug bounty kapsamına girmiyordu
  • Raporlayan kişi daha önce görülmemiş bir kullanıcıydı ama HackerOne itibarı fena değildi ve bu ilk güvenlik raporu da değildi
  • Rapor iyi düzenlenmişti; ayrıntılar, düzgün İngilizce cümleler ve önerilen bir düzeltme bile içeriyordu
  • İlk bakışta ortalama bir ilk rapordan daha iyi görünüyordu ve raporlayan kişinin sorunu anlayıp çözüm de önerdiği izlenimini veriyordu
  • 19 dakika sonra kod birkaç kez kontrol edilmesine rağmen iddia edilen buffer overflow bulunamadı
  • Tekrarlanan sorular ve birden fazla halüsinasyon içeren yanıtın ardından bunun gerçek bir sorun olmadığına karar verildi ve aynı gün öğleden sonra kayıt not applicable olarak kapatıldı
  • Bu yanıtların LLM ile üretilip üretilmediği kesin değil, ancak geride birçok belirti kalmıştı

HackerOne engelleme özelliği ve itibar yaptırımı

  • İlk başta HackerOne’da bir raporlayanı projeyle daha fazla iletişim kurmasını açıkça engelleyen bir özellik olmadığı düşünüldü
  • Böyle bir özellik olsaydı kullanılacağı belirtildi
  • Bir kayıt not applicable olarak kapatıldığında araştırmacının HackerOne itibarı düşüyor, ancak bunun tek bir projede bir kez yaşanması halinde caydırıcılığı çok düşük kalıyor
  • Daha sonra yapılan güncellemede, bu özelliğin aslında var olduğu ancak doğru yerde aranmadığı eklendi

LLM tarafından üretilen raporlar daha da artacak

  • Bu tür raporların zamanla daha yaygın hale gelmesi bekleniyor
  • Projeler, generated-by-AI sinyallerini daha iyi tespit etmeyi ve buna dayanarak raporları elemenin yollarını öğrenebilir
  • Ancak bu durum, yapay zekanın çeviri ya da cümle kurma desteği gibi uygun amaçlarla kullanıldığı vakaları da olumsuz etkileyebilir
  • İleride, yapay zekayı güvenlik sorunları bulmak için kullanan araçlardan gerçekten daha iyi çalışan bazıları ortaya çıkabilir
  • Çok küçük ölçekte bile olsa insan doğrulaması eklendiğinde, bu araçların kullanılabilirliği ve sonuçları çok daha iyi olabilir
  • Hızlı ödül peşinde koşan kestirme yol arayışı büyük olasılıkla sürecek ve güçlü LLM’lere kolay erişim nedeniyle HackerOne gelen kutusuna daha fazla düşük kaliteli rapor düşmesi bekleniyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-04
Hacker News yorumları

  • “Elbette! Triyaj sorumlusunun dile getirdiği endişeleri daha ayrıntılı açıklayacağım” gibi cümleler tipik LLM üslubu ve robot uşak gibi geliyor.
    Gerçekte böyle yazan insanlara neredeyse hiç rastlamadım; ayrıca “triyaj sorumlusu”ndan üçüncü tekil şahısla söz etmesi de yanıtı yönlendiren başka bir özne varmış gibi durduğu için tuhaf.
    LLM’lerin ayırt edilebilir, kendilerine özgü bir üsluba sahip olması sorun değil; beni endişelendiren LLM’lerin insan gibi konuşması değil, insanların LLM gibi konuşmaya başlaması.

    • Daniel Stenberg[1] iyi bir noktaya değinmiş: curl dünya çapında kullanılıyor, bu yüzden ana dili İngilizce olmayan birinin hata raporu yazarken LLM’den yardım alması hiç garip değil.
      Bu nedenle İngilizce cümlelerin LLM üretimi gibi görünmesi şeklindeki yüzeysel ipuçlarına bakarak raporun içeriğinin de LLM tarafından uydurulduğu sonucuna varılamaz.

      [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

    • Umarım bir yerlerde biri, robot efendilerin sürekli özür dileyip “nihayetinde teslim olup olmamanız, sizin özel ihtiyaçlarınıza ve tercihlerinize bağlıdır” gibi şeyler söylediği bir distopik bilimkurgu yazıyordur.

    • “Robot uşak gibi geliyor” sözünü görünce Butlerian Jihad ifadesi birden anlam kazandı.

    • Hindistan’da İngilizce bazen sömürge dönemindeki hizmetkâr sınıfına yönelik Britanya İngilizcesi, yani bir tür “uşak dili” olarak öğretiliyor.
      Şimdiye kadar böyle bir üslup görmediyseniz, sanırım Microsoft kurumsal teknik destek ile muhatap olmamışsınızdır.

    • Kesinlikle büyük bir uyarı işareti, ama o saçma içeriği gerçekten bir insan ilettiyse yalnızca o tek satırı silmesi yeterli olurdu.
      İçerik hâlâ şüpheli olurdu, ama bunu fark etmeyi sağlayan ipuçları çok daha az olurdu.

  • “Dilenci usulü ödül” peşindeki insanlar bug bounty programlarını yürütmeyi zaten epey baş ağrıtıcı hâle getirmişti.
    O zamanlar gerçek bir insanın zaman harcayıp aslında hiçbir şey olmayan bir “hata raporu” üretmesi gerekiyordu; ama LLM devreye girince sahte raporları neredeyse sıfır maliyetle üretmek mümkün olduğundan iş gerçekten kontrolden çıkabilir.
    Kişisel olarak bunun bug bounty programlarının sonu bile olabileceğini düşünüyorum.
    Ya da belki daha kapalı hâle getirmek gerekir: programa katılım başvurusu almak, başvuranın gerçek bir insan, gerçek bir güvenlik araştırmacısı ve etkili güvenlik açıkları bulmaya çalışan biri olduğunu düşük maliyetle doğrulamak, ardından yalnızca onaylanan kişilerin hata göndermesine ve para ödülü almasına izin vermek gibi.

    • Bu tür işlevler sunan platformlar zaten var.
      Bilinen araştırmacıları bir havuz içinde yönetip durumlarını takip ediyorlar ve programı ne kadar herkese açık yürüteceğinizi ayarlayabiliyorsunuz.
      Bazılarında triyaj sorumluları da var, ama başarı büyük ölçüde projenin ne kadar tipik olduğuna bağlı.
    • Gönderim ücreti koymak da bir yöntem olabilir.
      İşe yarar mı bilmiyorum, ama makinelerin topluca ürettiği çöp gönderimleri engellemek için caydırıcı olabilir.
      En kötü senaryo, yapay zeka çöpünün toplu hâlde gönderilmesi ve bunu “çözmek” için aynı derecede kötü yapay zeka filtrelemesi getirilerek iyi niyetle katılmak isteyen herkes için genel kalitenin düşürülmesi.

  • İlk başta bu yazının https://news.ycombinator.com/item?id=37904047 ile aynı şeyin tekrarı olduğunu sandım; meğer HackerOne’da curl’e karşı açılmış başka bir LLM üretimi sahte güvenlik açığı raporuymuş.

    • Neyse ki delirmiyormuşum.
      Okurken bunu kesin daha önce görmüştüm diye düşündüm; önceki olayla o kadar benzer ki tuhaf.
      Curl gibi popüler projelerde insanlar özgeçmişlerine bir satır ekleyebilmek için sürekli LLM tarafından yazılmış olay bildirimleri mi açıyor acaba?
    • HackerOne’ın müşterileri bug bounty programları yürüten şirketler.
      Müşterilerine yalnızca görünürlük peşinde koşan LLM çöp spam’i gönderebilen kişileri biraz daha dikkatli yönetmeleri gerekiyor gibi.
    • Daha önce böyle bir şey yaşandığından hiç haberim yoktu.
      O hâlde bu olay daha da net bir emsal oluyor.

  • En kaygı verici olan, birkaç sentlik LLM maliyetinin pahalı ve önemli mühendislik zamanının büyük kısmını boşa harcatmış olması.
    Şu anda üretilen onca sahte bilgiyi söküp atmak için ne kadar çaba gerekeceğini hayal edince, Brandolini yasasına benziyor.

    • Evet, LLM’lerin internetin devasa bir bölümünü mahvetme potansiyeli var ve bunun çözülebilir bir sorun olup olmadığından emin değilim.
      Mevcut modellerde kendini belli eden ipuçları var, ama gelecekteki modeller değişecek ve daha iyi olacak.
      Tespit ve engelleme bir silahlanma yarışına dönüşecek; üretken insanların ve pek çok platformun buna yetişmesi zorlaşabilir.

  • Eylemi ve emeği kanıtlamanın en düşük bant genişlikli aracı olan yazmayı, gerçekten bir eylem ya da emek olup olmadığını anlaması çok daha emek yoğun bir şeye dönüştürmüş olmamız ilginç.
    Bunun etkileri muhtemelen çok büyük olacak.
    Burada hem bildirim yapan kişi hem de yöneticiler daha yararlı işlere harcayabilecekleri zamanı boşa harcadı; ayrıca bug bounty ve kitle kaynaklı CVE süreçlerinin tamamı, düşen sinyal-gürültü oranı nedeniyle zarar görüyor.
    Sonuçta spam’e karşı koymak için gönderim eşiklerinin yükselme olasılığı artıyor; bu da daha az hatanın bulunup düzeltilmesine, daha fazla güvenlik açığına ve bunların beraberinde getirdiği tüm sorunlara yol açabilir.
    Aynı dinamik başka alanlarda da işliyor; ürün yorumlarına, mahkeme dilekçelerine, tariflere, kullanım kılavuzlarına, tıbbi tavsiyelere giderek güven atfedilemez hâle geliyor.
    İnternetin vaatlerinden biri, yayıncılığın demokratikleşmesi yoluyla içeriğin hızla genişlemesiydi; ama geriye kalan faydaların bile içinin oyulduğu bir süreci izliyor gibiyiz.

  • Burada uzunluk sınırı denetimini sorun etmek özellikle tuhaf.
    Çünkü kullanıcı tarafından sağlanan veri hiç kullanılmıyor ve tüm boyutlar derleme zamanında statik.
    curl, base64 ile kodlanmış 16 baytlık rastgele bir dizgeyi, yani 25 bayt ASCII ile null sonlandırıcı \0 birleşimini statik 40 baytlık bir tamponun içine koyuyor.

    https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

Ve sırf meraktan soruyorum: C’yi benden daha iyi bilen biri burada neden keyval yerel değişkeninin kullanıldığını açıklayabilir mi?
Sadece heads[3].val = randstr olarak ayarlayıp başlık verisi işlendikten sonra free() etmememiz için bir sebep var mı?
Bir de keyval neden 26 ya da 32 bayt değil de 40 bayt?

  • Muhtemelen free çağrılması gereken yerlerin sayısını azaltmak ve bunu unutma ihtimalini düşürmek amaçlanmıştır.
    580. satırda bunun yine de yaşanıp yaşanamayacağını merak ediyorum ama pratikte o durum hiç oluşmuyor da olabilir.

  • Öyleyse hem randstr hem de keyval kaldırılıp, zaten ayırma yapıldığı için doğrudan &heads[3].val içine encode edilebilir.
    Yine de işe yaramaz randlen’i geçirmek gerekiyor; yoksa çöküyor.
    C’nin çıkış parametrelerine yakışır bir güzellik.
    Bu “heap’ten stack değişkenine kopyalama” dansı temizlik işini de azaltmıyor.
    Çünkü encoding’den sonra zaten yalnızca tek bir dönüş var.
    Ama gereken değişkenleri başta “serip” sonradan Curl_base64_encode’un her zaman ayırma yaptığını fark ettiyseniz, mevcut kodun nasıl ortaya çıktığını anlamak mümkün.

  • Stack kullanmak neredeyse bedavadır; fonksiyon kurulumu sırasında alan zaten ayrılmıştır ve fonksiyon döndüğünde otomatik temizlenir.
    Heap kullanmak daha fazla iş gerektirir, başarısız olabilir ve elle temizlik ister.

  • Lisede öğrendiğim önemli derslerden biri, zarifçe ifade edilmiş yalan ile kaba saba ifade edilmiş hakikati ayırt etmeyi öğrenmekti.
    Ama bu zor olabilir.
    İnsanlar doğru dil bilgisi ve üslubu entelektüel tartışma için birincil filtre olarak kullanma eğiliminde; dilin biçimini inandırıcı şekilde tutturmakta ise LLM’ler çok ama çok iyi.

    • O dönemde bu dersin bana ve sınıf arkadaşlarıma ne kadar işlediğini merak ediyorum.
      Bu çok çetrefilli bir mesele ve çoğu yetişkinin bile bununla başa çıkmaya hazır olmadığını düşünüyorum.
      Ortalama bir insanın ikisini ayırt etme kapasitesi fazlasıyla var; sorun, metinleri sistemli biçimde okumaya alışmak ve bunun için çaba harcamak gerektiği.
      Gece geç saatte telefonda kaydırırken bunu yapmak çok zor.

  • Sinir bozucu ve zaman kaybı olmasaydı, dineshsec / dinesh_b’nin Daniel’a strncpy kullanmayı öğretmeye kalkması komik olurdu.
    Önce rastgele bir kullanıcı adıyla Daniel’ı etiketledi, sonra “sorunlu kod şu:” diyerek var olmayan bir kod uydurdu.

    • Bu, LLM kötüye kullanımının klasik bir sorunu.
      Kullanıcı bir şeyi analiz etmek istiyor ama çok uzun olduğu için birkaç isteğe bölerek yapıştırıyor.
      Sonra asıl noktaya gelindiğinde özgün kod parçası bağlamın dışına düşüyor ve model, gerçekte var olmayan ama makul görünen şeyleri kendinden emin şekilde ortaya döküyor.

  • strcpy ya da strncpy değil, doğrudan memcpy kullanılmalı.
    Özellikle strncpy, üçü içinde açık ara en kötü seçenek.
    Kod zaten kaynak buffer boyutunu biliyor ve hedef buffer’a sığıp sığmayacağını da kontrol etmiş; bu yüzden gereksiz yere string uzunluğunu yeniden ölçtürmek için strcpy çağırmanın anlamı yok.
    Açıkçası LLM’in önerisi aktif olarak caydırmak isteyeceğim düzeyde.
    Boyutu bilmiyorsanız, sessiz kırpılmayı umursamıyorsanız ve performansı da önemsemiyorsanız snprintf kullanabilirsiniz.
    strncpy, buffer’ın kalan kısmını gereksiz yere sıfırlarla doldurur.
    UI gibi bir şeyle uğraşmıyorsanız genelde kırpılmayı önemsemeniz gerekir; böyle durumlarda strncpy sizi kurtarmaz.

  • Bununla ilgili görünüyor: https://news.ycombinator.com/item?id=38840907