Apple curl सुरक्षा घटना 12604

 (daniel.haxx.se)
1 पॉइंट द्वारा GN⁺ 2024-03-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS में Apple द्वारा bundle किया गया curl --cacert विकल्प को open source build से अलग तरीके से हैंडल करता है, जिससे यह TLS verification की उस अपेक्षा को तोड़ देता है कि केवल यूज़र द्वारा निर्दिष्ट CA पर ही भरोसा किया जाएगा
  • --cacert ऐसा विकल्प है जो सर्वर certificate को निर्दिष्ट CA certificate set से ही verify करने के लिए मजबूर करता है, और verification विफल होने पर curl को error लौटाना चाहिए
  • Apple द्वारा दिया गया curl, निर्दिष्ट CA से verification विफल होने पर भी, संभवतः system CA store को अतिरिक्त रूप से जांचता है; यह व्यवहार न तो अनुरोध किया गया था और न ही documented है
  • Apple Product Security ने जवाब दिया कि Apple का OpenSSL, यानी LibreSSL, built-in system trust store को default trust source के रूप में जानबूझकर इस्तेमाल करता है, इसलिए इसे fix किए जाने वाला issue नहीं माना गया
  • यह curl project distribution की vulnerability नहीं है, इसलिए CVE जारी नहीं किया गया, लेकिन macOS के bundled curl में CA verification का परिणाम documentation से अलग हो सकता है

Issue 12604 की शुरुआत

  • 28 दिसंबर 2023 को curl issue tracker में bugreport 12604 दर्ज की गई
  • issue का शीर्षक था “flag --cacert behavior isn’t consistent between macOS and Linux”, और इसे Yuedong Wu ने रिपोर्ट किया
  • एक ही macOS मशीन पर एक ही curl version चलाने पर भी, Apple bundled curl और open source से built curl binary का व्यवहार अलग था

--cacert से बनने वाली अपेक्षित गारंटी

  • curl command-line option --cacert ऐसा तरीका है जिससे बाद के transfer में curl ठीक उसी CA certificate set पर भरोसा करे जिसे निर्दिष्ट किया गया है
  • अगर TLS server ऐसा certificate पेश नहीं कर पाता जिसे उस certificate set से verify किया जा सके, तो curl को fail होना चाहिए और error लौटानी चाहिए
  • यह विकल्प दिसंबर 2000 में curl में जोड़ा गया था, ताकि यूज़र यह सुनिश्चित कर सके कि वह उसी server से बात कर रहा है जिसे वह जानता है और जिस पर भरोसा करता है
  • अंततः यह TLS की उस बुनियादी भूमिका से सीधे जुड़ा है जो उसे प्रदान करनी चाहिए

macOS bundled curl का असामान्य व्यवहार

  • Apple द्वारा दिया गया macOS curl, --cacert इस्तेमाल करने पर, यदि निर्दिष्ट CA certificate set से verification विफल हो जाए तो संभवतः system CA store को अतिरिक्त रूप से जांचता है
  • यह सहायक जांच यूज़र द्वारा मांगा गया व्यवहार नहीं है, और documentation में भी नहीं है, इसलिए इसका अनुमान लगाना मुश्किल है
  • भले ही यूज़र किसी सीमित, समर्पित CA certificate file से verification करना चाहे, अगर system CA store में ऐसा certificate मौजूद है जो server को verify कर सकता है, तो यह विफल नहीं होता
  • नतीजतन, जो certificate verification पास नहीं होनी चाहिए, वह पास हो सकती है, इसलिए इसे सुरक्षा समस्या माना जाता है

Apple Product Security का जवाब

  • 29 दिसंबर 2023 को 08:30 UTC पर Apple Product Security को security issue report ईमेल भेजा गया
  • Apple Product Security ने 8 मार्च 2024 को जवाब दिया
  • Apple का जवाब दो बिंदुओं में संक्षेपित किया जा सकता है
    • Apple का OpenSSL, यानी LibreSSL, built-in system trust store को default trust source के रूप में जानबूझकर इस्तेमाल करता है
    • क्योंकि server certificate built-in system trust store से सफलतापूर्वक verify किया जा सकता है, इसलिए Apple इसे Apple platform पर संबोधित किए जाने वाला issue नहीं मानता
  • Apple ने इस केस को बंद कर दिया

curl project का आकलन और यूज़रों पर प्रभाव

  • macOS की यह undocumented feature curl के CA certificate verification को documentation के साथ असंगत बना देती है
  • यूज़र अपेक्षा करता है कि --cacert से निर्दिष्ट CA certificate set ही इस्तेमाल होगा, लेकिन Apple का दिया हुआ curl इस अपेक्षा से अलग व्यवहार करता है
  • यह समस्या curl project द्वारा वितरित curl version की security vulnerability नहीं है
    • curl project ने इस issue के लिए CVE जारी नहीं किया
    • समस्या curl code में नहीं, बल्कि Apple द्वारा platform पर दिए गए और curl build में उपयोग किए गए LibreSSL version से उत्पन्न होती है
  • macOS पर Apple का दिया हुआ curl इस्तेमाल करते समय --cacert आधारित verification परिणाम open source build curl से अलग हो सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-10
Hacker News की राय

  • यह व्यवहार पूरी तरह बेवकूफी भरा है। अगर मैं खुद CA निर्दिष्ट कर रहा हूँ, तो वजह दो में से एक होगी: मेरा CA ऑपरेटिंग सिस्टम के bundle में नहीं है, या मैं सिर्फ किसी खास CA के खिलाफ ही verification करना चाहता हूँ
    यानी Apple का यह “feature” या तो बेकार की computation जोड़ता है, या अपेक्षित verification model को तोड़ देता है। इनमें से कोई भी अपेक्षित नतीजा नहीं है

    • छोटी-सी सुधार: जब पहली जांच fail होती है, तब यह Apple CA store पर fallback करता है। इसलिए शायद यह बेकार की computation नहीं जोड़ेगा
      फिर भी यह अपेक्षित नतीजा नहीं है, इसलिए मैं मानता हूँ कि यह खराब व्यवहार है। Apple आम तौर पर backward compatibility तोड़ने वाले बदलाव पसंद करता है, और यह feature curl में जोड़ा गया है, इसे देखते हुए लगता है कि Apple के पास कुछ अनकही वजहें और हैं। शायद यह developer diagnostic tools या AppStore verification में इस्तेमाल होता हो
    • कहा जाता है कि जिसे मूर्खता से समझाया जा सकता है, उसे दुर्भावना पर मत डालो, लेकिन अगर कोई दुर्भावनापूर्ण actor Hanlon's razor को defense logic की तरह इस्तेमाल करे, तो खास तौर पर सावधान रहना चाहिए

  • अफसोस की बात है, लेकिन Apple devices का “owner” चाहे जो भी करना चाह रहा हो, हमेशा Apple policy को प्राथमिकता देने वाला ऐसा व्यवहार चौंकाने वाला नहीं है; Apple में इसकी उम्मीद हमेशा रखनी चाहिए

    • इसी वजह से मैंने Apple इस्तेमाल करना छोड़ दिया। devices सच में बहुत अच्छे बने लगते हैं और operating system भी polished है, लेकिन अपने तरीके और ecosystem में बंद कर देना और अपने hardware access तक रोकना, HN वाले अर्थ में hacker बनकर जीने से मेल नहीं खाता
      कम से कम digital life के उस हिस्से में तो नहीं, और कीमत देखते हुए इसे साथ में रखने वाले extra device के तौर पर खरीदना भी मुश्किल है। मैं Apple products आजमाने के बारे में लगातार सोचता रहा, हाल में AR headset को लेकर भी ऐसा ही था, लेकिन अब तक ये developers या tinkers के लिए बहुत hostile लगे हैं
    • open source curl चलाएँ तो आपको मनचाहा व्यवहार मिल सकता है
    • अफसोस, हमेशा कुछ लोग होते हैं जो low-level technical decisions को अपनी पूर्वधारणाएँ “साबित” करने के लिए जरूरत से ज्यादा पढ़ लेते हैं
      यह मानना कि Apple जितनी बड़ी कंपनी ने “user devices का owner बनना” जैसे बड़े vision के लिए यह फैसला लिया, Apple को संगठनात्मक और coordination क्षमता का जबरदस्त श्रेय देना है। Apple के दसवें हिस्से जितने संगठनों में भी मैंने ऐसा स्तर कभी नहीं सुना। लेकिन Apple है, तो ऐसा ही होगा, है न!?
    • owner Apple है, आप तो बस user हैं ;)

  • शायद Apple यही set कर रहा है?[0] emphasis मेरा है
    CURLSSLOPT_NATIVE_CA
    libcurl को certificate verification के लिए operating system के default CA store का इस्तेमाल करने को कहता है। अगर यह option set हो और साथ में CA certificate file या directory भी set की गई हो, तो verification के दौरान उन certificates को भी default CA store के साथ search किया जाता है
    --cacert और इस option के combination में लगता है कि libcurl दोनों का सम्मान करने की कोशिश करता है। क्या दोनों mutually exclusive नहीं होने चाहिए?

    • नहीं, यह वह case नहीं है। curl binary जानता है कि libcurl library को कैसे call करना है

  • यह backdoor है
    मैं यह नहीं कह रहा कि यह intentional या malicious है। लेकिन practically यह backdoor ही है। अगर आपने user के certification system में keys जोड़ना शुरू कर दिया, तो आपने backdoor जोड़ दिया

    • यह बिल्कुल वैसा दिखता है जैसा NSA किसी बड़ी अमेरिकी tech company पर करने का दबाव डाल सकती है

  • default behavior संदिग्ध जरूर है, लेकिन मैं इस assessment से पूरी तरह सहमत नहीं हूँ। असल में यह curl documentation issue है
    curl एक multi-protocol library है, इसलिए सभी protocols को खुद implement नहीं करता, और अधिकतर मामलों में low-level bits की interpretation बाहर सौंपने वाले transitive dependency “backends” पर निर्भर करता है। कुछ protocols के लिए अच्छे कारणों से कई alternative libraries का support शामिल है
    इस approach की कमी यह है कि independent backends के बीच common behavior guarantee करना मुश्किल या असंभव है। वे शायद समान features न देते हों, API incomplete हो सकती है, और इस case की तरह default behavior के कुछ हिस्सों को patch करने का तरीका भी न देते हों। LibreSSL, OpenSSL का bit-by-bit reimplementation नहीं है, और उसकी API को पूरी तरह mimic करने की कोई बाध्यता भी नहीं है
    ऐसे मामलों में अगर upstream fix करने से हिचकता है, तो curl के पास दो choices बचती हैं: उस library का support हटाना, या उस unusual behavior को document करना। पहला user code तोड़ सकता है, इसलिए कम से कम दूसरा तो करना चाहिए
    फिर भी मैं broadly सहमत हूँ कि यह LibreSSL security perspective से defect है, और शायद CVE खोलने की वजह हो सकती है। लेकिन target LibreSSL होना चाहिए

    • अगर root cause system SSL library में है, तो source से curl build करने पर यह issue कैसे bypass हो जाता है, यह मुझे ठीक से समझ नहीं आता

  • SQLite वाली F_BARRIERFSYNC घटना याद आ गई
    वे बस परवाह नहीं करते
    https://bonsaidb.io/blog/acid-on-apple/

    • पहले याद आता है कि Apple ने वास्तव में साथ में ship होने वाले पुराने Unix tools में से एक में कोई option बेढंगे तरीके से ठूंसकर उसे तोड़ दिया था
      उनका maintenance attitude उस Debian व्यक्ति द्वारा OpenSSL तोड़ने से भी करीब दो पायदान नीचे है

  • Daniel कहता है कि तुम्हारा curl broken है, तो उसे fix कर दो, Apple। बात इतनी सरल है

    • Daniel भी गलत हो सकता है। curl के बारे में भी गलत हो सकता है
      यहाँ 2 मिनट की जांच के मुताबिक शायद वह सही लगता है, लेकिन “Daniel है इसलिए सही है” सबसे खराब logic है
      C का इतिहास, खासकर Eric S. Raymond के “contributions” के इर्द-गिर्द पुरानी बातचीत याद आती है: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

  • warning के लिए धन्यवाद। संदर्भ के लिए, मैं MacPorts से macOS में bundled काफी tools को replace करके इस्तेमाल करता हूँ। curl भी उनमें से एक है
    bundled tools आम तौर पर पुराने होते हैं या किसी और तरह broken होते हैं। Apple bundled software पर भरोसा मैंने बहुत पहले खो दिया था

  • मुझे wonder है कि क्या Apple किसी important चीज़ के लिए इस behavior पर depend कर रहा है

    • पता नहीं आप sarcastic हैं या नहीं, लेकिन यह निश्चित रूप से बहुत important है
      किसी का सिर्फ internal private CA इस्तेमाल करने के लिए script बनाना पूरी तरह reasonable है। यह command चलाने पर आप जानते हैं कि यह internal company CA है, इसलिए यह सिर्फ internal company resources से ही communicate कर रहा है
      लेकिन Apple ने इसमें domain verification जितना बड़ा backdoor जोड़ दिया
      आगे बढ़कर dummy name इस्तेमाल करना, और सिर्फ इस fact से कि company CA ने sign किया है, यह verify करना कि आप company server से connect हो रहे हैं, भी बिल्कुल valid है। लेकिन Apple ने इस बेहद reasonable assumption को तोड़कर security vulnerability बना दी। अच्छा नहीं है
    • यह enterprise/government TLS interception को आसान बनाने के लिए हो सकता है
    • यह या तो बेहद dumb चीज़ है, या evil

  • Apple users की security की परवाह करता है—तो बात बस इतनी ही थी