1 puan yazan GN⁺ 2024-03-10 | 1 yorum | WhatsApp'ta paylaş
  • Apple’ın macOS ile birlikte sunduğu curl, --cacert seçeneğini açık kaynak derlemelerinden farklı işleyerek, yalnızca kullanıcının belirttiği CA’ya güvenileceği yönündeki TLS doğrulama beklentisini bozuyor
  • --cacert, sunucu sertifikasını yalnızca belirtilen CA sertifika kümesiyle doğrulatan bir seçenektir; doğrulama başarısız olursa curl’ün hata döndürmesi gerekir
  • Apple tarafından sağlanan curl, belirtilen CA ile doğrulama başarısız olsa bile ek olarak sistem CA deposunu kontrol ediyor gibi görünüyor; bu davranış ne istendi ne de belgelendi
  • Apple Product Security, Apple’ın OpenSSL’i olan LibreSSL’in yerleşik sistem güven deposunu varsayılan güven kaynağı olarak kasıtlı biçimde kullandığını ve bunun düzeltilecek bir durum olmadığını söyledi
  • Bu durum curl projesinin dağıttığı sürümlerdeki bir açık olmadığından CVE verilmedi, ancak macOS ile gelen curl’de CA doğrulama sonuçları belgelerdekinden farklı olabilir

12604 numaralı olayın başlangıcı

  • 28 Aralık 2023’te curl issue tracker’da bugreport 12604 kaydı açıldı
  • Sorun başlığı “flag --cacert behavior isn’t consistent between macOS and Linux” idi ve Yuedong Wu tarafından raporlandı
  • Aynı macOS makinede aynı curl sürümü çalıştırılsa bile, Apple’ın paketlediği curl ile açık kaynaktan derlenen curl ikilisinin davranışı farklıydı

--cacert seçeneğinin vaat ettiği güvence

  • curl komut satırı seçeneği --cacert, sonraki aktarımlarda curl’ün tam olarak belirtilen CA sertifika kümesine güvenmesini sağlamanın yoludur
  • TLS sunucusu bu sertifika kümesiyle doğrulanabilen bir sertifika sunamazsa, curl başarısız olmalı ve hata döndürmelidir
  • Bu seçenek curl’e Aralık 2000’de eklendi ve kullanıcının bildiği ve güvendiği sunucuyla iletişim kurduğunu doğrulamaya yarıyor
  • Sonuçta bu, TLS’nin sağlaması gereken temel işleve doğrudan temas ediyor

macOS ile gelen curl’ün istisnai davranışı

  • Apple’ın macOS için sağladığı curl, --cacert kullanıldığında belirtilen CA sertifika kümesiyle doğrulama başarısız olursa ek olarak sistem CA deposunu da kontrol ediyor gibi görünüyor
  • Bu yardımcı kontrol kullanıcının talep ettiği bir davranış değil ve belgelerde de yer almıyor, bu yüzden öngörülmesi zor
  • Kullanıcı daraltılmış, özel bir CA sertifika dosyasıyla doğrulama yapmak istese bile, sistem CA deposunda sunucuyu doğrulayabilecek bir sertifika varsa işlem başarısız olmuyor
  • Sonuç olarak geçmemesi gereken sertifika doğrulaması geçebilir; bu da bir güvenlik sorunu olarak değerlendiriliyor

Apple Product Security’nin yanıtı

  • 29 Aralık 2023 08:30 UTC’de Apple Product Security’ye bir güvenlik sorunu bildirimi e-postası gönderildi
  • Apple Product Security 8 Mart 2024’te yanıt verdi
  • Apple’ın yanıtı iki noktada özetlenebilir
    • Apple’ın OpenSSL’i olan LibreSSL, yerleşik sistem güven deposunu varsayılan güven kaynağı olarak kasıtlı biçimde kullanıyor
    • Sunucu sertifikası yerleşik sistem güven deposuyla başarıyla doğrulanabildiği için bunu Apple platformlarında ele alınması gereken bir sorun olarak görmüyor
  • Apple bu vakayı kapattı

curl projesinin değerlendirmesi ve kullanıcı etkisi

  • macOS’teki bu belgelenmemiş özellik, curl’ün CA sertifikası doğrulamasını belgelerle tutarsız hale getiriyor
  • Kullanıcılar --cacert ile belirtilen CA sertifika kümesinin yalnızca kendisinin kullanılmasını bekler, ancak Apple’ın sağladığı curl bu beklentiden farklı davranıyor
  • Bu sorun, curl projesinin dağıttığı curl sürümlerinde bir güvenlik açığı değil
    • curl projesi bu sorun için CVE vermedi
    • Sorun curl kodunun kendisinden değil, Apple’ın platformda sunduğu ve curl derlemesinde kullandığı LibreSSL sürümünden kaynaklanıyor
  • macOS’te Apple’ın sağladığı curl kullanıldığında, --cacert tabanlı doğrulama sonuçları açık kaynak derlenmiş curl’den farklı olabilir

1 yorum

 
GN⁺ 2024-03-10
Hacker News yorumları
  • Bu davranış tamamen saçma. Eğer CA’yı ben özellikle belirtiyorsam bunun iki nedeni olabilir: CA’m işletim sistemi paketinde yoktur ya da yalnızca belirli bir CA’ya göre doğrulama yapmak istiyorumdur.
    Yani Apple’ın bu “özelliği” ya gereksiz hesaplama ekliyor ya da beklediğim doğrulama modelini bozuyor. İkisi de beklenir sonuçlar değil.

    • Küçük bir düzeltme: İlk kontrol başarısız olduğunda Apple CA deposuna geri dönüyor. Bu yüzden muhtemelen gereksiz hesaplama eklemiyor.
      Yine de beklenen sonuç olmadığı için kötü bir davranış olduğuna katılıyorum. Apple’ın genelde geriye dönük uyumluluğu bozan değişiklikleri sevdiğini ve bu özelliğin curl’e eklendiğini düşününce, Apple’ın açıklamadığı başka bir durum var gibi görünüyor. Geliştirici tanılama araçlarında ya da App Store doğrulamasında kullanılıyor olabilir.
    • Aptallıkla açıklanabilecek şeyleri kötü niyete yormamak gerektiği söylenir; ama kötü niyetli bir aktör Hanlon’un usturasını savunma argümanı olarak kullanıyorsa özellikle dikkatli olmak gerekir.
  • Ne yazık ki Apple cihazlarının “sahibi” ne yapmaya çalışırsa çalışsın Apple politikalarının her zaman önce geldiği bu tür davranışlar şaşırtıcı değil; Apple’da her zaman beklenmesi gereken bir şey.

    • Bu yüzden Apple kullanmayı bıraktım. Cihazlar gerçekten çok iyi yapılmış gibi duruyor ve işletim sistemi de cilalı, ama kendi yöntemine ve ekosistemine hapsetmesi, hatta kendi donanımına erişimi bile engellemesi, HN anlamında bir hacker olarak yaşamakla uyuşmuyor.
      En azından dijital hayatımın o kısmında uyuşmuyor; fiyatı düşününce yanına ek bir cihaz olarak almak da zor. Apple ürünlerini denesem mi diye sürekli düşündüm; son dönemde AR başlığı için de böyleydi, ama şimdiye kadar geliştiricilere ve kurcalamayı sevenlere fazla düşmanca göründü.
    • Açık kaynak curl çalıştırırsanız istediğiniz davranışı elde edebilirsiniz.
    • Ne yazık ki düşük seviyeli teknik kararları kendi önyargılarını “kanıtlamak” için aşırı yorumlamaya çalışan insanlar her zaman var.
      Apple kadar büyük bir şirketin, “kullanıcı cihazlarına sahip olma” yönündeki daha büyük vizyonu için böyle bir karar aldığını düşünmek, Apple’a inanılmaz düzeyde örgütsel ve koordinasyon yeteneği atfetmek demek. Apple’ın onda biri büyüklüğündeki kuruluşlarda bile duymadığım bir seviye bu. Ama Apple ya, değil mi!?
    • Sahibi Apple, sen sadece kullanıcısın ;)
  • Belki bunu Apple ayarlıyordur?[0] Vurgu bana ait.
    CURLSSLOPT_NATIVE_CA
    libcurl’e sertifika doğrulaması için işletim sisteminin varsayılan CA deposunu kullanmasını söyler. Bu seçenek ayarlanmışken bir CA sertifika dosyası ya da dizini de ayarlanırsa, doğrulama sırasında bu sertifikalar da varsayılan CA deposuyla birlikte aranır.
    --cacert ile bu seçenek birleşince libcurl ikisini de dikkate almaya çalışıyor gibi görünüyor. Bunların birbirini dışlaması gerekmez mi?

    • Hayır, bu o durum değil. curl ikilisi libcurl kütüphanesini nasıl çağırması gerektiğini biliyor.
  • Bu bir arka kapı.
    Bilinçli ya da kötü niyetli demiyorum. Ama fiilen arka kapı. Kullanıcının sertifika sistemine anahtar eklemeye başladıysanız arka kapı eklemişsiniz demektir.

    • NSA’in ABD’deki büyük teknoloji şirketlerine yaptırmak isteyeceği şeye tam olarak benziyor.
  • Varsayılan davranış şüpheli olsa da bu değerlendirmeye tamamen katılmıyorum. Aslında bu bir curl dokümantasyonu sorunu.
    curl çok protokollü bir kütüphane olduğu için tüm protokolleri doğrudan kendisi uygulamaz; çoğu durumda düşük seviyeli bit yorumlamasını dışarıya bırakan geçişli bağımlılık “arka uçlarına” dayanır. Bazı protokoller, makul nedenlerle birden fazla alternatif kütüphane desteği içerir.
    Bu yaklaşımın dezavantajı, bağımsız arka uçlar arasında ortak davranışı garanti etmenin zor ya da imkânsız olmasıdır. Hepsi aynı özellikleri sunmayabilir, API’ları eksik olabilir veya bu örnekte olduğu gibi varsayılan davranışın bazı kısımlarını yamamak için bir yol sağlamayabilirler. LibreSSL, OpenSSL’in bit düzeyinde yeniden uygulanmış hâli değildir ve onun API’sını tamamen taklit etmek zorunda da değildir.
    Böyle durumlarda upstream düzeltmeye isteksizse curl’ün önünde iki seçenek kalır: ilgili kütüphane desteğini kesmek ya da bu özel davranışı belgelemek. İlki kullanıcı kodunu bozabileceği için en azından ikincisi yapılmalı.
    Yine de bu yaklaşımın LibreSSL güvenliği açısından bir kusur olduğu yönündeki genel görüşe katılıyorum; muhtemelen bir CVE açmak için gerekçe olabilir. Ancak hedef LibreSSL olmalı.

    • Temel neden sistem SSL kütüphanesindeyse, curl’ü kaynaktan derlemenin bu sorunu nasıl aştığını pek anlayamıyorum.
  • SQLite’taki F_BARRIERFSYNC meselesini hatırlatıyor.
    Basitçe umursamıyorlar.
    https://bonsaidb.io/blog/acid-on-apple/

    • Apple’ın birlikte dağıttığı eski Unix araçlarından birini geçmişte bir seçeneği özensizce iliştirerek bozduğu bir olayı hatırlıyorum.
      Bakım anlayışları, Debian’daki birinin OpenSSL’i bozmasından yaklaşık iki seviye daha aşağıda.
  • Daniel sizin curl’ünüz bozuk diyorsa düzeltin, Apple. Bu kadar basit.

    • Daniel de yanılabilir. Hatta curl konusunda bile yanılabilir.
      Burada 2 dakikalık kontrolüme göre muhtemelen haklı gibi, ama “Daniel olduğu için doğrudur” en kötü mantık yürütme biçimi.
      C’nin tarihini, özellikle Eric S. Raymond’ın “katkıları” etrafındaki eski tartışmayı hatırlatıyor: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...
  • Uyarı için teşekkürler. Bu arada ben macOS ile birlikte gelen araçların önemli bir kısmını MacPorts ile değiştirmiş olarak kullanıyorum. curl de bunlardan biri.
    Paketle gelen araçlar genelde eski ya da başka şekillerde bozuk. Apple’ın paketlediği yazılıma güvenimi uzun zaman önce kaybettim.

  • Apple’ın önemli bir şeyde bu davranışa güveniyor olup olmadığını merak ediyorum.

    • Alaycı mı söylüyorsun bilmiyorum ama bu açıkça çok önemli.
      Birinin yalnızca dahili özel CA’yı kullanacak şekilde script yazması tamamen makul. Bu komutu çalıştırdığında, dahili şirket CA’sı olduğu için yalnızca dahili şirket kaynaklarıyla iletişim kurduğunu bilirsin.
      Fakat Apple buraya alan adı doğrulaması kadar büyük bir arka kapı ekliyor.
      Dahası, sahte bir ad kullanıp yalnızca şirket CA’sı tarafından imzalanmış olmasına dayanarak şirket sunucusuna bağlandığını doğrulamak da gayet geçerli. Ama Apple bu son derece makul varsayımı bozarak bir güvenlik açığı yaratmış. İyi değil.
    • Kurumsal/devlet TLS dinlemesini kolaylaştırmak için olabilir.
    • Ya aşırı aptalca bir iş ya da kötü niyetli.
  • Apple’ın kullanıcı güvenliğini önemsediği iddiası da bu kadarmış.