Homebrew ऑडिट रिपोर्ट

 (blog.trailofbits.com)
1 पॉइंट द्वारा GN⁺ 2024-07-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Trail of Bits के ऑडिट में macOS डेवलपर ecosystem के de facto standard package manager Homebrew में अप्रत्याशित code execution और build integrity कमजोर होने की संभावनाएं पाई गईं, हालांकि निष्कर्ष critical स्तर के नहीं थे
  • scope में brew CLI वाला Homebrew/brew और Homebrew/actions, Homebrew/formulae.brew.sh, Homebrew/homebrew-test-bot शामिल थे; यानी local package manager और CI/CD boundaries को साथ में देखा गया
  • brew से जुड़ी समस्याएं sandbox configuration string injection, MD5-based namespace collision, घोषित न किए गए network resources को शामिल करना, macOS socket pivot, sudo token abuse, और non-local URL-based formula installation तक ले जा सकती थीं
  • CI/CD में pull_request_target trigger और बिना validate किए workflow_dispatch inputs bottle build tampering, credentials exposure, privilege escalation, और self-hosted GitHub Actions runner पर persistence हासिल करने के रास्ते बन सकते थे
  • Homebrew trusted formula को आधार मानता है, लेकिन formula खुद Ruby executable code होता है और API/CLI surface बड़ा है, इसलिए isolation और integrity boundaries को लगातार बनाए रखना मुश्किल है

ऑडिट का scope और target

  • Trail of Bits ने पिछली गर्मियों में Homebrew का ऑडिट किया
  • audit targets में brew CLI वाला Homebrew/brew और security के लिहाज से महत्वपूर्ण 3 adjacent repositories शामिल थीं
    • Homebrew/actions: Homebrew CI/CD में व्यापक रूप से इस्तेमाल होने वाली custom GitHub Actions repository
    • Homebrew/formulae.brew.sh: install किए जा सकने वाले packages के JSON index के लिए जिम्मेदार codebase
    • Homebrew/homebrew-test-bot: Homebrew की core CI/CD orchestration और lifecycle management routines
  • Open Tech Fund ने internet infrastructure के core components की security मजबूत करने वाली पहल के हिस्से के रूप में audit को sponsor किया
  • पूरी report Trail of Bits की publications repository में देखी जा सकती है

Homebrew महत्वपूर्ण क्यों है

  • Homebrew खुद को “macOS या Linux के लिए missing package manager” कहता है और macOS developers के लिए de facto standard package manager की भूमिका निभाता है
  • यह हर साल सैकड़ों मिलियन package installations handle करता है, जिनमें Golang, Node.js, OpenSSL जैसे core packages भी शामिल हैं
  • ऐसे packages की build integrity Homebrew से आगे downstream software ecosystem की security से जुड़ती है
  • Homebrew का core एक Ruby monolith है, जो brew CLI और reusable Ruby API उपलब्ध कराता है
  • 2009 में शुरू होने के बाद से Homebrew ने package reliability और usability बढ़ाने के लिए अपनी structure कई बार बदली
    • binary build bottle पेश किया
    • local source builds की जगह bottle को default installation method बनाया
    • compromised developer machine के प्रभाव को कम करने के लिए bottle को केवल CI/CD में build कराया जाने लगा
  • installation method धीरे-धीरे ज्यादा static हुआ है, लेकिन core codebase में user-controlled Ruby code से DSL-based formula को dynamically load करने वाली historical structure अब भी बची हुई है

ऑडिट में देखी गई attack boundary

  • जांचा गया कि कोई local actor explicit brew install के बिना formula DSL की unexpected execution trigger कर सकता है या नहीं
  • यह review किया गया कि user के सिर्फ brew tap चलाने पर भी tap के formula evaluation के unexpected रूप से होने की संभावना है या नहीं
  • देखा गया कि namespace confusion या collision पैदा करके brew install foo से expected से अलग formula install कराया जा सकता है या नहीं
  • यह भी जांचा गया कि locally installed formula Homebrew के build isolation mechanisms को गुपचुप bypass या weaken कर सकता है या नहीं
  • CI/CD में मुख्य सवाल था कि क्या low-privilege actor higher privilege में pivot कर सकता है, bottle build को contaminate कर सकता है, या persistence बना सकता है

brew CLI में मिली समस्याएं

  • brew CLI codebase में ऐसी समस्याएं मिलीं जो formula-specific integrity और isolation properties को कमजोर कर सकती हैं
  • ऐसे paths भी पहचाने गए जिनसे formula remote URL जैसे unexpected sources से load हो सकता था
  • मुख्य findings इस प्रकार हैं
    • TOB-BREW-2: formula string injection के जरिए sandbox configuration बदल सकता है, जिससे sandbox escape हो सकता है
    • TOB-BREW-5: Homebrew synthetic namespace FormulaNamespace में collision-prone MD5 hash function का उपयोग करता है, जिससे attacker formulas के बीच runtime confusion करा सकता है
    • TOB-BREW-8: formula resource stanza में declare किए बिना भी build में network resources को stealthily शामिल कर सकता है
    • TOB-BREW-11: formula macOS पर socket pivot का उपयोग करके build sandbox से बाहर निकल सकता है
    • TOB-BREW-12: formula user के पहले से active sudo token के जरिए opportunistic privilege escalation कर सकता है
    • TOB-BREW-13: brew install को इस्तेमाल हो रहे curl version द्वारा supported SFTP, SCP जैसे सभी protocols के non-local URL से formula install कराने के लिए induce किया जा सकता है
  • Homebrew/brew की व्यापक testing होती है, लेकिन बड़े API/CLI surface और informal local behavior contracts के कारण attackers के लिए sandbox से बाहर local code execution paths खोजने की गुंजाइश रहती है
  • ये paths trusted formula को मानकर चलने वाली Homebrew की core security premise को जरूरी नहीं कि तोड़ते हों, लेकिन malicious formula या sufficiently sanitized न किए गए inputs के जरिए unexpected formula loading में exploit किए जा सकते हैं

Homebrew CI/CD में मिली समस्याएं

  • Homebrew CI/CD workflows और actions में भी ऐसी समस्याएं मिलीं जो CI/CD execution की integrity को कमजोर कर सकती हैं
  • low-privilege users के higher privilege positions में pivot करने या Homebrew के self-hosted GitHub Actions runner पर persistence हासिल करने की संभावना पहचानी गई
  • मुख्य findings इस प्रकार हैं
    • TOB-BREW-18: कई CI/CD workflows ने pull_request_target trigger का उपयोग किया, जिससे third-party pull requests Homebrew upstream repository context में code execute कर सकती थीं, और इससे credentials exposure या bottle build tampering हो सकता था
    • TOB-BREW-23: कई CI/CD workflows ने unvalidated workflow_dispatch inputs के जरिए shell injection की अनुमति दी, जिससे workflow modify नहीं कर सकने लेकिन उसे run कर सकने वाले low-privilege users की vertical movement हो सकती थी
  • CI/CD-specific समस्याओं के अलावा brew से जुड़ी कुछ findings CI/CD environment में महत्वपूर्ण थीं
    • TOB-BREW-6: archive extraction के दौरान sandboxing/isolation की कमी से low-privilege CI actor auto-loaded/executed होने वाले formula या executable code extract कराने के लिए induce कर सकता है और higher-privilege context में pivot कर सकता है
    • TOB-BREW-13: CI द्वारा preconfigured trusted context में मौजूद न होने वाले formula को brew install से install कराकर arbitrary code execution और privilege pivot में इस्तेमाल किया जा सकता है
  • Homebrew CI/CD package lifecycle में human intervention points घटाने में mature और effective है, लेकिन GitHub Actions workflows में आम misuse-prone patterns पर निर्भर करता है
    • risky workflow triggers
    • template expansion के जरिए configuration, code और data का mixing
  • ये patterns जरूरी नहीं कि पूरी तरह external actor को persistence या pivot हासिल करने दें, लेकिन rogue maintainer जैसे low-privilege insider इन्हें CI/CD की integrity/isolation assumptions कमजोर करने के लिए इस्तेमाल कर सकते हैं

package manager audit कठिन क्यों है

  • Homebrew जैसे package management ecosystems design के तौर पर arbitrary third-party code install और execute करते हैं, इसलिए audit boundaries मुश्किल होती हैं
  • expected code execution और unexpected code execution के बीच फर्क भी ज्यादातर informal और loosely defined होता है
  • Homebrew में package delivery format यानी formula खुद Ruby executable code है, इसलिए यह समस्या और उभरकर आती है
  • audit के दौरान Homebrew maintainers, Homebrew PLC, और Homebrew security manager Patrick Linnane के साथ close collaboration किया गया

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

1 टिप्पणियां

 
GN⁺ 2024-07-31
Hacker News टिप्पणियां

  • मैं इस लेख का लेखक हूं और audit में शामिल लोगों में से एक भी, इसलिए सवालों के जवाब दे सकता हूं
    अगर audit report खुद ढूंढना मुश्किल हो तो वह indirect link है, इसलिए एक कॉपी यहां भी छोड़ रहा हूं: https://github.com/trailofbits/publications/blob/eb9344f2261...

  • शानदार काम है, और ऐसे open source solution में मैं जिस तरह की व्यवस्थित समीक्षा ढूंढ रहा था, यह ठीक वही है
    शायद यह code review का focus नहीं होगा, लेकिन open source package management platform में अंतर्निहित व्यापक supply chain lifecycle समस्याओं पर आपका नजरिया जानना चाहूंगा। मुख्य बातें ये हैं: क्या नया formula सही original source की ओर इशारा करता है, यह सुनिश्चित करने की verification process पर्याप्त है या नहीं; users कैसे भरोसा करें कि brew update अब भी भरोसेमंद original source को refer कर रहा है; domain hijack हो जाए तो क्या होता है; और formula के untrusted source पर team कितनी जल्दी respond कर सकती है
    ये सारी समस्याएं Homebrew को ही हल करनी हों, ऐसा नहीं है, लेकिन ecosystem के स्तर पर ये महत्वपूर्ण considerations हैं। winget और choco में भी यही समस्या है, और apt या yum जैसे commercially supported repositories में यह कम है। मेरे लिए व्यक्तिगत रूप से और कई administrators के लिए Windows Store से निपटते समय भी यह बड़ी चिंता है
    आखिर में, अगर Homebrew team यह देख रही है, तो npm-style vulnerability notifications हों तो वाकई बहुत अच्छा होगा

    • यह समस्या खासकर तब बहुत गंभीर हो जाती है जब package manager production environment या CI/CD pipeline में इस्तेमाल होता है
      ऐसे public मामले काफी हैं जहां Chinese Communist Party से जुड़े लोगों ने core packages पर pull request अधिकार हासिल कर लिए, और मेरा मानना है कि unpublished या दबा दिए गए मामले इससे भी ज्यादा होंगे। किसी प्रतिष्ठित entity से कम-जाने-माने व्यक्ति को package ownership का transfer होना ही अपने आप में चिंता की बात है
      software engineer/engineering manager से VC बने व्यक्ति के तौर पर, मैं सोचता हूं कि क्या ऐसे assurances देने वाले startups या commercial companies हैं। हालांकि मुझे यह भी चिंता है कि इस समस्या को हल करने का market size शायद independent business बनने लायक पर्याप्त न हो

  • Nix पर जाने से पहले मैं MacPorts इस्तेमाल करता था, क्योंकि उस समय Homebrew काफी अजीब तरह से काम करता था। यह multi-user setup में काम नहीं करता था, /usr/local को own करता था, और auto-update तथा version management की कमी के कारण “मेरी machine पर तो चलता है” वाली बहुत समस्याएं थीं
    Homebrew में मुझे हमेशा असहज लगने वाली बात यह थी कि Git नहीं, बल्कि GitHub URL को temporary package की तरह इस्तेमाल किया जा सकता था। मुझे जिज्ञासा है कि TOB-BREW-13 इसी तरह काम करता था या नहीं। वह feature हमेशा ऐसा लगता था जैसे कोई security incident होने का इंतजार कर रहा हो
    बहरहाल, मैं macOS पर Nix का audit भी देखना चाहूंगा। खासकर nix develop और संबंधित commands के काम करने के तरीके में flaws हैं या नहीं, यह जानना चाहूंगा

    • मजेदार है, मैं भी Homebrew -> MacPorts -> Nix के क्रम में ही गया
      Homebrew में analytics collection था और versions बहुत बार टूट जाते थे। MacPorts कहीं ज्यादा stable है, लेकिन कुछ niche packages ठीक से build नहीं होते थे और tmux में terminfo की समस्या थी
      Nix में इनमें से ज्यादातर चीजों को redefine किया जा सकता है, और Debian workstation के साथ home manager configuration share कर पाना अच्छा है
    • Nix macOS पर default रूप से build sandbox इस्तेमाल नहीं करता। nix.conf में sandbox = true डालकर आप इसे खुद enable कर सकते हैं, लेकिन इससे कई चीजें टूट सकती हैं
      Nix sandbox भी असल में security boundary के रूप में design नहीं किया गया है। sandbox escape रोकने की कोशिश इसमें नहीं की गई है, और host की बहुत-सी चीजें sandbox environment में leak हो जाती हैं। untrusted packages build करने के लिए gVisor या full VM जैसी चीज चाहिए
    • Nix भी github को allow करता है

  • मैंने sandbox escape bug और उससे जुड़े fixes पर एक नजर डाली: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7...
    मुझे संदेह है कि क्या यह सही है। लगता है कि यह sandbox profile में interpolate होकर problem पैदा करने से रोकने की कोशिश है, लेकिन इस character list को लेकर कितना भरोसा किया जा सकता है, पता नहीं

    • commit message उस सवाल का जवाब दे सकता था, लेकिन असल में वह सिर्फ वही दोहराता है जो diff पहले से दिखा रहा है: “sandbox rule path में special characters allow नहीं करता”
      यह नहीं बताता कि क्यों, या ban किए गए खास characters में क्या विशेष है। बेहतर message में कुछ ऐसा होता: “वरना ... के कारण path में कुछ characters रोकते हैं। इन characters पर ध्यान देने की जरूरत है लेकिन बाकी characters ठीक क्यों हैं, वजह है ...”
      अभी आप यह code लिख रहे हैं और जानते हैं कि यह क्या करता है, फिर भी 1 साल बाद इसे फिर देखेंगे तो सिर खुजलाएंगे कि यह change क्यों किया था
      अच्छे commit message का असली example यहां है: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
    • अगर वही fix है तो मुझे भी हैरानी होगी। blacklist के बजाय allow list बेहतर नहीं होगी?

  • कुछ समय पहले मैंने brew को nix से replace कर दिया था, और text UI में end-user friendliness और बेहतर हो सकती है
    इसलिए brew की तरह आसानी से ixnay install करने के लिए मैंने “ixnay” नाम का wrapper भी बनाया था(https://github.com/pmarreck/ixnay), लेकिन कुल मिलाकर मिलने वाली guarantees इसकी कीमत के लायक हैं

    • मुझे भी nix command line झुंझलाहट भरी लगती है। इसे एक बार आजमाना पड़ेगा। built-in #help docs मुझे पसंद हैं
    • काश ixnay के बारे में पहले पता होता। मैं भी user experience से परेशान होकर आखिरकार अपना tool बना बैठा, उसका नाम hdn है: https://github.com/seasonedfish/hdn
      README में ixnay का उल्लेख कर दिया है

  • लगभग सभी Linux और *BSD package managers से तुलना करें तो Homebrew की बड़ी low-skill attack surface, यानी supply chain integrity, पर ज़्यादा चर्चा न होना थोड़ा हैरान करता है
    Homebrew maintainers आम तौर पर commits/packages पर sign नहीं करते, review/merge पर sign नहीं करते, compile time पर author/reviewer signatures verify नहीं करते, अलग controlled CI में builds reproduce नहीं करते, और GitHub पर hardware 2FA भी enforce नहीं करते
    brew users की security का स्तर सैकड़ों brew maintainers में से आज जिस व्यक्ति की operational security सबसे खराब है, उसी स्तर से बंध जाता है
    इसके अलावा dependabot अपने-आप commits बनाता है, इसलिए कोई अपने control वाले external project में malicious commit डाल सकता है, फिर dependabot के Homebrew में upgrade commit बनाने का इंतज़ार करके खुद उसे merge भी कर सकता है। Homebrew maintainer बनने के लिए असल में बहुत कम verification है और बस कुछ आसान bugs ठीक करने होते हैं
    किसी maintainer का expired email domain कब्ज़े में लेकर password reset mail अपने पास मंगाया जा सकता है, और छुट्टी पर या inactive व्यक्ति का account hijack किया जा सकता है
    किसी के ध्यान देने से पहले हज़ारों companies compromise हो सकती हैं
    सच कहूँ तो जिन company machines पर privileges हैं, उन पर मैं Brew को कभी allow नहीं करूँगा। यह सैकड़ों random लोगों और उनकी कमज़ोर operational security का फायदा उठाने वाले किसी भी व्यक्ति को user systems पर arbitrary code चलाने की क्षमता देने जैसा है
    प्रमुख Linux package managers भी review signing जैसी चीज़ों में उतनी दूर नहीं गए हैं, लेकिन उनमें से ज़्यादातर कम से कम author-level package signing, human review, और कई packages के लिए independent reproducible builds तो करते हैं
    यह देखते हुए कि company sysadmins जैसे high-value targets अक्सर अपने computers पर brew allow करते हैं, Brew कमजोर supply chain management से होने वाले नुकसान के मामले में कभी भी Crowdstrike से आगे निकलने की राह पर है

  • अगर Mac पर Pacman की तरह PKGBUILD समान performance के साथ support हो और core program packages ठीक से maintain हों, तो Mac इस्तेमाल करते समय convenience के लिए करने पड़ने वाले compromises काफी कम हो जाएँगे
    Homebrew शानदार है और formula भी सचमुच अच्छी तरह maintain होते हैं, लेकिन PKGBUILD की सरलता, तेज़ synchronization, और अलग-अलग package managers के लिए कई arguments और flags याद रखने की कम cognitive load की वजह से काश pacman Mac पर बस चल जाता

    • default pacman macOS पर उम्मीद के मुताबिक काम नहीं करता, लेकिन थोड़े modification/hacking से उसे चलाने की कोशिशें हुई हैं: https://github.com/liudongmiao/pacman, https://github.com/kladd/pacman-osx
    • ऐसी कोशिशें कुछ बार हुई हैं। उनमें से कुछ शायद सच में काम भी कर रही हों
    • क्या MacPorts वही चीज़ नहीं है? सच में जानना चाहता हूँ

  • मेरे हिसाब से मुख्य attack vector बस यह है कि नया formula contribute करके malicious नया package चुपके से डाला जा सकता है
    maintainer team इतनी छोटी है कि नए contribute होने वाले हर formula का audit नहीं कर सकती। हैरानी है कि यह attack vector audit में शामिल नहीं था

    • मौजूदा Homebrew core formula reviewers शायद अपनी team को incoming formula requests पर्याप्त रूप से review करने के लिए बहुत छोटी नहीं मानेंगे
      भले ही ऐसा हो, यह packaging की उन ambiguities में से एक है जिनका लेख में स्पष्ट रूप से ज़िक्र है। 1st-party और 3rd-party execution की boundary मूल रूप से धुंधली है, और जब जानबूझकर 3rd-party code चलाया जाए तो होने वाली स्वाभाविक चीज़ों को सब गिनाने की बजाय, security value अपेक्षाकृत ज़्यादा उन जगहों को खोजने में है जहाँ 3rd-party execution unexpected places में हो सकता है
      फिर भी मुझे लगता है कि पूरे packaging ecosystem को ऐसी approval processes के लिए review किया जाना चाहिए। लेकिन यह people process से जुड़ा है, इसलिए software audit की बजाय red team style audit के ज़्यादा करीब है
    • उस हिस्से को लिखा गया था, और formula को trustworthy माना गया था
      “... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...”
    • मैं भी कुछ दिन पहले यह देखकर घबरा गया कि कोई “Cmder” नाम का console emulator डाउनलोड कर रहा था। यह कई FOSS tools का संग्रह था, जिसमें PowerShell scripts, Perl scripts, Python scripts, shell scripts, DLL, EXE आदि malicious हो सकने वाली सचमुच करीब 1,000 files थीं
      अंत में वह harmless निकला, लेकिन लोगों का ऐसे Git repositories को बस clone कर लेना और उम्मीद करना कि सब ठीक होगा, सच में डरावना है

  • TOB-BREW-n कई जगह listed थे, तो लगा कि क्या ये इस project के लिए CVE numbers जैसे हैं
    edit: आह, “Trail Of Bits - homeBREW” था। फिर भी शायद यही सही है

    • सही है। audit results में TOB-$PRODUCT-$XXXX convention इस्तेमाल करते हैं। $PRODUCT audit target होता है और $XXXX हर finding का unique increasing counter होता है
      मेरी जानकारी में कई audit companies ऐसा ही तरीका इस्तेमाल करती हैं

  • इस blog post की wording थोड़ी confusing है। इसमें कहा गया है कि यह audit Homebrew के साथ किया गया, लेकिन नाम परिचित लगा तो Homebrew README चेक किया और https://github.com/Homebrew/brew में maintainer list में William Woodruff दिखे
    जानना चाहता हूँ कि blog post में यह बात mention न करने की कोई वजह है क्या। शायद इससे बड़ा फर्क नहीं पड़ता, लेकिन clear करना चाहता हूँ

    • audit करते समय मैं maintainer नहीं था :-)
      मैं लंबे समय तक project का non-maintainer “member” था, जो उन former maintainers के लिए एक तरह की अर्ध-मानद position है जो internal conversations और governance में शामिल रहना चाहते हैं। बाद में audit खत्म होने के कुछ महीनों बाद, Homebrew से जुड़े एक अलग काम की वजह से फिर membership offer की गई, जो audit planning से पहले मौजूद भी नहीं था और planned भी नहीं था
      यह बात company और Homebrew maintainers दोनों को की गई conflict of interest disclosure में शामिल थी, लेकिन मैं सहमत हूँ कि blog post में भी इसे स्पष्ट किया जा सकता है। आज इसे जोड़ने की कोशिश करूँगा
      संक्षेप में, audit करते समय मैं maintainer नहीं था, लेकिन पहले maintainer था और अभी भी maintainer हूँ। audit मैंने और मेरे colleagues ने professional work के रूप में किया था