รายงานการตรวจสอบ Homebrew

 (blog.trailofbits.com)
1 คะแนน โดย GN⁺ 2024-07-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การตรวจสอบโดย Trail of Bits พบความเป็นไปได้ของ การรันโค้ดที่ไม่คาดคิด และการลดทอนความสมบูรณ์ของการบิลด์ใน Homebrew ซึ่งเป็นตัวจัดการแพ็กเกจมาตรฐานโดยพฤตินัยของระบบนิเวศนักพัฒนา macOS แต่สิ่งที่พบนั้นยังไม่ถึงระดับวิกฤต
  • ขอบเขตครอบคลุมทั้ง Homebrew/brew ที่มี brew CLI รวมถึง Homebrew/actions, Homebrew/formulae.brew.sh และ Homebrew/homebrew-test-bot โดยพิจารณาร่วมกันทั้งตัวจัดการแพ็กเกจฝั่งโลคัลและขอบเขต CI/CD
  • ปัญหาฝั่ง brew นำไปสู่ความเป็นไปได้ เช่น การฉีดสตริงในคอนฟิกแซนด์บ็อกซ์, การชนกันของเนมสเปซที่อิง MD5, การแทรกทรัพยากรเครือข่ายโดยไม่ประกาศ, การ pivot ผ่านซ็อกเก็ตบน macOS, การนำโทเคน sudo ไปใช้ในทางที่ผิด และการติดตั้ง formula จาก URL ที่ไม่ใช่โลคัล
  • ใน CI/CD นั้น trigger แบบ pull_request_target และอินพุต workflow_dispatch ที่ไม่ผ่านการตรวจสอบ อาจกลายเป็นช่องทางสำหรับ การดัดแปลงการบิลด์ bottle, การเปิดเผยข้อมูลรับรอง, การยกระดับสิทธิ์ และการคงอยู่บน self-hosted GitHub Actions runner
  • แม้ Homebrew จะตั้งอยู่บนสมมติฐานว่า formula นั้นเชื่อถือได้ แต่ตัว formula เองเป็นโค้ด Ruby ที่รันได้ และพื้นผิว API·CLI ก็มีขนาดใหญ่ ทำให้ยากต่อการรักษา ขอบเขตของการแยกและความสมบูรณ์ ให้สอดคล้องกัน

ขอบเขตและเป้าหมายของการตรวจสอบ

  • Trail of Bits ได้ทำการตรวจสอบ Homebrew เมื่อฤดูร้อนที่ผ่านมา
  • สิ่งที่อยู่ในขอบเขตการตรวจสอบคือ Homebrew/brew ที่มี brew CLI และรีโพซิทอรีข้างเคียงที่มีความสำคัญด้านความปลอดภัยอีก 3 แห่ง
    • Homebrew/actions: รีโพซิทอรี GitHub Actions แบบกำหนดเองที่ใช้ทั่วทั้ง CI/CD ของ Homebrew
    • Homebrew/formulae.brew.sh: โค้ดเบสที่ดูแลดัชนี JSON ของแพ็กเกจที่ติดตั้งได้
    • Homebrew/homebrew-test-bot: งาน orchestration และวงจรชีวิตหลักของ CI/CD ของ Homebrew
  • Open Tech Fund เป็นผู้สนับสนุนการตรวจสอบนี้ในฐานะส่วนหนึ่งของกิจกรรมเพื่อเสริมความปลอดภัยให้กับองค์ประกอบสำคัญของโครงสร้างพื้นฐานอินเทอร์เน็ต
  • รายงานฉบับเต็มสามารถดูได้จากรีโพซิทอรี publications ของ Trail of Bits

ทำไม Homebrew จึงสำคัญ

  • Homebrew นิยามตัวเองว่าเป็น “ตัวจัดการแพ็กเกจที่ขาดหายไปสำหรับ macOS หรือ Linux” และทำหน้าที่เป็นตัวจัดการแพ็กเกจมาตรฐานโดยพฤตินัยสำหรับนักพัฒนา macOS
  • รองรับ การติดตั้งแพ็กเกจนับร้อยล้านครั้งต่อปี และแพ็กเกจที่ติดตั้งก็รวมถึงแพ็กเกจสำคัญอย่าง Golang, Node.js และ OpenSSL
  • ความสมบูรณ์ของการบิลด์แพ็กเกจเหล่านี้เชื่อมโยงกับความปลอดภัยของระบบนิเวศซอฟต์แวร์ปลายน้ำ ไม่ได้จำกัดอยู่แค่ Homebrew
  • แกนหลักของ Homebrew คือ Ruby monolith ที่ให้ทั้ง brew CLI และ Ruby API ที่สามารถนำไปใช้ต่อได้
  • นับตั้งแต่เริ่มต้นในปี 2009 Homebrew ได้ปรับโครงสร้างหลายครั้งเพื่อเพิ่มความเชื่อถือได้และการใช้งานของแพ็กเกจ
    • มีการนำ bottle ซึ่งเป็นไบนารีบิลด์มาใช้
    • ใช้ bottle เป็นวิธีติดตั้งเริ่มต้นแทนการบิลด์ซอร์สบนเครื่องโลคัล
    • เพื่อจำกัดผลกระทบจากเครื่องนักพัฒนาที่อาจถูกเจาะ bottle จึงถูกบิลด์เฉพาะใน CI/CD
  • แม้วิธีติดตั้งจะค่อย ๆ กลายเป็นแบบคงที่มากขึ้น แต่ในโค้ดเบสหลักยังคงมีโครงสร้างทางประวัติศาสตร์ที่โหลด formula แบบ DSL แบบไดนามิกด้วยโค้ด Ruby ที่ผู้ใช้ควบคุมได้

ขอบเขตการโจมตีที่พบในการตรวจสอบ

  • ตรวจสอบว่าผู้กระทำการในเครื่องสามารถกระตุ้นให้เกิด การรันที่ไม่คาดคิด ของ formula DSL ได้โดยไม่ต้องสั่ง brew install อย่างชัดเจนหรือไม่
  • ทบทวนว่าการที่ผู้ใช้รันเพียง brew tap จะทำให้เกิดการประเมิน formula ของ tap แบบไม่คาดคิดได้หรือไม่
  • พิจารณาว่า brew install foo จะถูกทำให้ติดตั้ง formula ที่ต่างจากที่ผู้ใช้คาดผ่านความสับสนหรือการชนกันของเนมสเปซได้หรือไม่
  • ตรวจสอบด้วยว่า formula ที่ติดตั้งในเครื่องจะสามารถหลบเลี่ยงหรือลดทอนกลไกการแยกการบิลด์ของ Homebrew ได้อย่างแนบเนียนหรือไม่
  • สำหรับ CI/CD คำถามสำคัญคือผู้มีสิทธิ์ต่ำจะสามารถ pivot ไปยังสิทธิ์ที่สูงกว่า, ทำให้ bottle build ปนเปื้อน หรือสร้าง persistence ได้หรือไม่

ปัญหาที่พบใน brew CLI

  • ในโค้ดเบสของ brew CLI พบปัญหาที่อาจลดทอน คุณสมบัติด้านความสมบูรณ์และการแยก ของแต่ละ formula
  • ยังพบเส้นทางที่ formula อาจถูกโหลดจากแหล่งที่ไม่คาดคิด เช่น URL ระยะไกล
  • ประเด็นสำคัญที่พบมีดังนี้
    • TOB-BREW-2: formula สามารถเปลี่ยนคอนฟิกแซนด์บ็อกซ์ผ่านการฉีดสตริง ซึ่งอาจนำไปสู่การหลบหนีออกจากแซนด์บ็อกซ์
    • TOB-BREW-5: Homebrew ใช้ฟังก์ชันแฮช MD5 ที่อาจชนกันได้สำหรับ FormulaNamespace ซึ่งเป็นเนมสเปซสังเคราะห์ ทำให้ผู้โจมตีอาจก่อให้เกิดความสับสนระหว่าง formula ระหว่างรันไทม์
    • TOB-BREW-8: formula สามารถแทรกทรัพยากรเครือข่ายเข้าไปในการบิลด์อย่างแนบเนียนได้โดยไม่ต้องประกาศไว้ใน resource stanza
    • TOB-BREW-11: formula สามารถใช้การ pivot ผ่านซ็อกเก็ตบน macOS เพื่อออกจาก build sandbox ได้
    • TOB-BREW-12: formula สามารถยกระดับสิทธิ์แบบฉวยโอกาสผ่านโทเคน sudo ที่ผู้ใช้เคยเปิดใช้งานไว้ก่อนหน้า
    • TOB-BREW-13: brew install อาจถูกชักจูงให้ติดตั้ง formula จาก URL ที่ไม่ใช่โลคัลผ่านทุกโปรโตคอลที่ curl เวอร์ชันที่ใช้งานรองรับ เช่น SFTP และ SCP
  • แม้ Homebrew/brew จะมีการทดสอบอย่างกว้างขวาง แต่ด้วยพื้นผิว API·CLI ที่ใหญ่และข้อตกลงพฤติกรรมโลคัลที่ไม่เป็นทางการ ผู้โจมตียังมีช่องให้ค้นหาเส้นทางรันโค้ดโลคัลนอกแซนด์บ็อกซ์ได้มาก
  • เส้นทางเหล่านี้ไม่ได้ทำลายสมมติฐานความปลอดภัยหลักของ Homebrew ที่ถือว่า formula เชื่อถือได้เสมอไป แต่สามารถถูกใช้ในทางที่ผิดได้ผ่าน formula อันตรายหรือการโหลด formula ที่ไม่คาดคิดผ่านอินพุตที่ยังไม่ได้กรองดีพอ

ปัญหาที่พบใน CI/CD ของ Homebrew

  • ในเวิร์กโฟลว์และแอ็กชัน CI/CD ของ Homebrew ก็พบปัญหาที่อาจลดทอนความสมบูรณ์ของการรัน CI/CD ได้เช่นกัน
  • ยืนยันได้ถึงความเป็นไปได้ที่ผู้ใช้สิทธิ์ต่ำจะ pivot ไปยังจุดที่มีสิทธิ์สูงกว่า หรือได้รับ persistence บน self-hosted GitHub Actions runner ของ Homebrew
  • ประเด็นสำคัญที่พบมีดังนี้
    • TOB-BREW-18: เวิร์กโฟลว์ CI/CD หลายตัวใช้ trigger แบบ pull_request_target ทำให้ pull request จากบุคคลที่สามสามารถรันโค้ดในบริบทของรีโพซิทอรี upstream ของ Homebrew ได้ ซึ่งอาจนำไปสู่การเปิดเผยข้อมูลรับรองหรือการดัดแปลง bottle build
    • TOB-BREW-23: เวิร์กโฟลว์ CI/CD หลายตัวเปิดให้เกิด shell injection ผ่านอินพุต workflow_dispatch ที่ไม่ผ่านการตรวจสอบ ส่งผลให้ผู้ใช้สิทธิ์ต่ำที่แม้จะแก้ไขเวิร์กโฟลว์ไม่ได้ แต่สามารถรันได้ อาจไต่ระดับสิทธิ์ขึ้นไปได้
  • นอกเหนือจากปัญหาเฉพาะของ CI/CD แล้ว บางประเด็นที่เกี่ยวกับ brew ก็สำคัญในสภาพแวดล้อม CI/CD ด้วย
    • TOB-BREW-6: การขาด sandboxing·isolation ที่เพียงพอระหว่างการแตกไฟล์ archive ทำให้ผู้กระทำการ CI ที่มีสิทธิ์ต่ำสามารถชักจูงให้มีการแตก formula หรือโค้ดรันได้ที่ถูกโหลดและรันโดยอัตโนมัติ แล้ว pivot ไปยังบริบทสิทธิ์ที่สูงกว่า
    • TOB-BREW-13: สามารถใช้ brew install เพื่อติดตั้ง formula ที่อยู่นอกบริบทความเชื่อถือที่ CI ตั้งค่าไว้ล่วงหน้า และนำไปใช้เพื่อรันโค้ดตามอำเภอใจและ pivot สิทธิ์ได้
  • CI/CD ของ Homebrew มีความเป็นผู้ใหญ่และมีประสิทธิภาพในการลดจุดที่มนุษย์ต้องแทรกแซงในวงจรชีวิตแพ็กเกจ แต่ก็ยังพึ่งพาแพตเทิร์นที่มักถูกใช้งานผิดจนเกิดช่องโหว่ใน GitHub Actions workflow
    • workflow trigger ที่มีความเสี่ยง
    • การผสมคอนฟิก โค้ด และข้อมูลผ่าน template expansion
  • แพตเทิร์นเหล่านี้อาจไม่ได้ทำให้ผู้โจมตีภายนอกแบบสมบูรณ์สามารถสร้าง persistence หรือ pivot ได้เสมอไป แต่ผู้มีสิทธิ์ภายในระดับต่ำ เช่น rogue maintainer อาจใช้เพื่อลดทอนสมมติฐานด้านความสมบูรณ์และการแยกของ CI/CD ได้

ทำไมการตรวจสอบตัวจัดการแพ็กเกจจึงยาก

  • ระบบนิเวศตัวจัดการแพ็กเกจอย่าง Homebrew ถูกออกแบบมาให้ติดตั้งและรันโค้ดของบุคคลที่สามได้ตามใจอยู่แล้ว จึงทำให้การกำหนดขอบเขตการตรวจสอบเป็นเรื่องยาก
  • การแยกความต่างระหว่างการรันโค้ดที่คาดไว้กับการรันโค้ดที่ไม่คาดคิดก็โดยมากยังเป็นเรื่องไม่เป็นทางการและกำหนดไว้อย่างหลวม ๆ
  • ใน Homebrew ปัญหานี้ยิ่งเด่นชัด เพราะ formula เองเป็นโค้ด Ruby ที่รันได้ ซึ่งเป็นรูปแบบการขนส่งแพ็กเกจไปด้วยในตัว
  • ระหว่างการตรวจสอบ มีการทำงานร่วมอย่างใกล้ชิดกับ Homebrew maintainers, Homebrew PLC และ Patrick Linnane ผู้ดูแลความปลอดภัยของ Homebrew

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-31
ความคิดเห็นจาก Hacker News

  • ผมเป็นผู้เขียนบทความนี้และเป็นหนึ่งในผู้ที่เข้าร่วมการตรวจสอบ จึงตอบคำถามได้
    ถ้าหาตัวรายงานการตรวจสอบได้ยากเพราะเป็นลิงก์อ้อม ผมฝากสำเนาไว้ที่นี่ด้วย: https://github.com/trailofbits/publications/blob/eb9344f2261...

  • งานยอดเยี่ยมมาก และสำหรับ โซลูชันโอเพนซอร์ส แบบนี้ สิ่งที่ผมอยากเห็นก็คือการตรวจทานอย่างเป็นระบบในลักษณะนี้นี่เอง
    แม้อาจไม่ใช่จุดโฟกัสของการรีวิวโค้ด แต่ผมอยากทราบมุมมองต่อประเด็น วงจรชีวิตของซัพพลายเชน โดยรวมที่มีอยู่ในแพลตฟอร์มจัดการแพ็กเกจโอเพนซอร์ส ว่ากระบวนการตรวจสอบเพื่อให้มั่นใจว่า formula ใหม่ชี้ไปยังต้นทางที่ถูกต้องนั้นเพียงพอหรือไม่ ผู้ใช้จะมั่นใจได้อย่างไรว่า brew update ยังคงอ้างอิงต้นทางที่เชื่อถือได้ จะเกิดอะไรขึ้นหากโดเมนถูกยึด และทีมจะตอบสนองได้เร็วแค่ไหนเมื่อ formula อ้างอิงต้นทางที่ไม่น่าเชื่อถือ
    ปัญหาเหล่านี้ไม่ใช่ทั้งหมดที่ Homebrew ต้องแก้เอง แต่เป็นเรื่องสำคัญในระดับระบบนิเวศ winget และ choco ก็มีปัญหาเดียวกัน ส่วนคลังแพ็กเกจที่มีการสนับสนุนเชิงพาณิชย์อย่าง apt หรือ yum จะเจอน้อยกว่า สำหรับผมเองและผู้ดูแลระบบอีกหลายคน นี่ก็เป็นความกังวลใหญ่เวลาใช้งาน Windows Store เช่นกัน
    สุดท้าย ถ้าทีม Homebrew กำลังอ่านอยู่ คงดีมากถ้ามี การแจ้งเตือนช่องโหว่ แบบเดียวกับ npm

    • ปัญหานี้ยิ่งร้ายแรงมากเมื่อ package manager ถูกใช้ใน สภาพแวดล้อม production หรือใน CI/CD pipeline
      มีกรณีที่เปิดเผยต่อสาธารณะมากพอแล้วว่าผู้เกี่ยวข้องกับพรรคคอมมิวนิสต์จีนได้สิทธิ์ทำ pull request บนแพ็กเกจหลัก และผมเชื่อว่ายังมีกรณีที่ไม่ถูกเปิดเผยหรือถูกปกปิดอีกมาก แค่การที่ความเป็นเจ้าของแพ็กเกจย้ายจากหน่วยงานที่มีชื่อเสียงไปยังบุคคลที่ไม่ค่อยเป็นที่รู้จัก ก็เป็นเรื่องที่น่ากังวลโดยธรรมชาติอยู่แล้ว
      ในมุมของคนที่เคยเป็นวิศวกรซอฟต์แวร์/ผู้จัดการวิศวกรรมแล้วผันตัวมาเป็น VC ผมสงสัยว่ามีสตาร์ตอัปหรือบริษัทเชิงพาณิชย์ที่ให้การรับประกันแบบนี้อยู่หรือไม่ แต่ก็ยังกังวลว่าขนาดตลาดสำหรับการแก้ปัญหานี้อาจไม่มากพอจะทำเป็นธุรกิจเดี่ยวได้

  • ก่อนจะย้ายไป Nix ผมใช้ MacPorts เพราะตอนนั้น Homebrew ทำงานค่อนข้างแปลก ไม่รองรับการตั้งค่าแบบหลายผู้ใช้ ยึด /usr/local ไว้ และด้วยการอัปเดตอัตโนมัติกับการไม่มีการจัดการเวอร์ชัน เลยทำให้เกิดปัญหา "ใช้ได้บนเครื่องฉัน" บ่อยมาก
    สิ่งที่ผมรู้สึกไม่สบายใจกับ Homebrew มาตลอดไม่ใช่ Git แต่เป็นการที่มันใช้ GitHub URL เป็นเหมือนแพ็กเกจชั่วคราวได้ ผมสงสัยว่า TOB-BREW-13 ทำงานในลักษณะนั้นหรือเปล่า ฟีเจอร์นั้นฟังดูเหมือนรอวันเกิดเหตุด้านความปลอดภัยอยู่เสมอ
    ยังไงก็ตาม ผมก็อยากเห็นการตรวจสอบ Nix บน macOS เช่นกัน โดยเฉพาะอยากรู้ว่ามีข้อบกพร่องในวิธีทำงานของ nix develop และคำสั่งที่เกี่ยวข้องหรือไม่

    • น่าสนใจดี เพราะผมก็ย้ายตามลำดับ Homebrew -> MacPorts -> Nix เหมือนกัน
      Homebrew มีการเก็บ analytics และเวอร์ชันก็พังบ่อยเกินไป MacPorts เสถียรกว่ามาก แต่แพ็กเกจเฉพาะทางบางตัว build ไม่ค่อยผ่าน และมีปัญหา terminfo ใน tmux
      Nix ดีตรงที่นิยามสิ่งเหล่านี้ใหม่ได้เกือบทั้งหมด และสามารถแชร์ การตั้งค่า home manager กับเวิร์กสเตชัน Debian ได้
    • บน macOS นั้น Nix ไม่ได้ใช้ build sandbox เป็นค่าเริ่มต้น สามารถเปิดเองได้โดยใส่ sandbox = true ใน nix.conf แต่บางอย่างอาจพังได้
      ตัว sandbox ของ Nix เองก็ไม่ได้ถูกออกแบบให้เป็นขอบเขตด้านความปลอดภัยจริง ๆ ไม่มีความพยายามในการป้องกันการหนีออกจาก sandbox และหลายอย่างจากโฮสต์ก็รั่วไหลเข้ามาในสภาพแวดล้อม sandbox ถ้าจะ build แพ็กเกจที่ไม่น่าเชื่อถือ ก็ควรใช้ gVisor หรือ VM เต็มรูปแบบมากกว่า
    • Nix ก็อนุญาต github เช่นกัน

  • ผมลองไล่ดูบั๊กการหนีออกจาก sandbox และการแก้ไขที่เกี่ยวข้อง: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7...
    ผมไม่แน่ใจว่านี่ใช่แนวทางที่ถูกต้องหรือเปล่า ดูเหมือนกำลังพยายามกันไม่ให้มีการแทรกค่าเข้าไปใน sandbox profile จนเกิดปัญหา แต่ผมไม่มั่นใจเลยว่าเราจะเชื่อถือ รายการตัวอักษร นี้ได้แค่ไหน

    • ถ้าข้อความใน commit อธิบายให้ดีกว่านี้ก็คงตอบคำถามนั้นได้ แต่ในความเป็นจริงมันแค่พูดซ้ำจาก diff ว่า “ไม่อนุญาตอักขระพิเศษใน path ของกฎ sandbox” เท่านั้น
      มันไม่ได้อธิบายว่าทำไม หรืออักขระที่ถูกห้ามมีอะไรพิเศษ ถ้าเป็นข้อความที่ดีกว่านี้ก็ควรประมาณว่า “ไม่เช่นนั้นจะต้องบล็อกอักขระบางตัวใน path เพราะ ... อักขระเหล่านี้ต้องระวัง แต่ตัวอื่นไม่เป็นปัญหาเพราะ ...”
      ต่อให้ตอนนี้คุณเป็นคนเขียนโค้ดนี้และรู้ว่ามันทำอะไร อีก 1 ปีข้างหน้าพอกลับมาดูอีกทีก็คงยังเกาหัวว่าทำไมถึงเปลี่ยนแบบนี้
      ตัวอย่างจริงของ ข้อความ commit ที่ดีอยู่ที่นี่: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
    • ถ้านี่คือวิธีแก้จริง ๆ ผมก็แปลกใจเหมือนกัน การใช้ allowlist ไม่น่าจะดีกว่า blacklist เหรอ?

  • เมื่อสักระยะก่อนผมเปลี่ยนจาก brew ไปเป็น nix และแม้ text UI จะยังปรับให้เป็นมิตรกับผู้ใช้ปลายทางได้อีก
    ถึงขั้นทำ wrapper ชื่อ “ixnay” ขึ้นมาเพื่อให้สั่ง ixnay install ได้ง่ายเหมือน brew (https://github.com/pmarreck/ixnay) แต่โดยรวมแล้ว การรับประกัน ที่ได้ก็คุ้มค่า

    • ผมก็รู้สึกว่า command line ของ nix น่าหงุดหงิดเหมือนกัน ต้องลองตัวนี้ดู เอกสาร #help ที่มีมาให้ในตัวน่าสนใจดี
    • เสียดายที่ไม่รู้จัก ixnay ให้เร็วกว่านี้ ผมเองก็หงุดหงิดกับประสบการณ์ใช้งานเหมือนกัน สุดท้ายเลยทำเครื่องมือขึ้นมาเองชื่อ hdn: https://github.com/seasonedfish/hdn
      ผมใส่การอ้างอิงถึง ixnay ไว้ใน README แล้ว

  • เมื่อเทียบกับตัวจัดการแพ็กเกจของ Linux และ BSD เกือบทั้งหมด น่าแปลกใจเล็กน้อยที่ประเด็นความสมบูรณ์ของซัพพลายเชนซึ่งเป็น พื้นผิวการโจมตีที่ใช้ทักษะต่ำ ขนาดใหญ่ของ Homebrew แทบไม่ได้รับการพูดถึง
    ผู้ดูแล Homebrew โดยทั่วไปไม่ได้ลงนามคอมมิต/แพ็กเกจ, ไม่ได้ลงนามการรีวิว/การรวม, ไม่ได้ตรวจสอบลายเซ็นของผู้เขียน/ผู้รีวิวตอนคอมไพล์, ไม่ได้ทำบิลด์ซ้ำได้ใน CI ที่ควบคุมแยกต่างหาก และไม่ได้บังคับใช้การยืนยันตัวตนสองขั้นตอนด้วยฮาร์ดแวร์บน GitHub
    ระดับความปลอดภัยของผู้ใช้ brew จึงผูกอยู่กับระดับของคนที่มีความปลอดภัยในการปฏิบัติการแย่ที่สุดในวันนั้นในบรรดาผู้ดูแล brew หลายร้อยคน
    อีกทั้ง dependabot ยังสร้างคอมมิตอัตโนมัติด้วย จึงสามารถใส่คอมมิตอันตรายลงในโปรเจ็กต์ภายนอกที่ตัวเองควบคุมอยู่ รอให้ dependabot สร้างคอมมิตอัปเกรดให้ Homebrew แล้วค่อยรวมเองก็ได้ การจะเป็นผู้ดูแล Homebrew นั้นแทบไม่มีการตรวจสอบอะไรเลย แค่แก้บั๊กง่าย ๆ ไม่กี่ตัวก็พอ
    ยังสามารถเข้าครอบครองโดเมนอีเมลที่หมดอายุของผู้ดูแลสักราย ส่งเมลรีเซ็ตรหัสผ่านมาหาตัวเอง และยึดบัญชีของคนที่กำลังลาพักร้อนหรือพักงานอยู่ได้
    มีโอกาสสูงที่จะเจาะบริษัทได้เป็นพันแห่งก่อนที่ใครจะทันสังเกต
    พูดตรง ๆ คือคงไม่มีวันยอมให้ Brew อยู่บนอุปกรณ์บริษัทที่มีสิทธิ์เข้าถึงสำคัญ เท่ากับให้คนสุ่มหลายร้อยคนและใครก็ตามที่ฉวยใช้ความปลอดภัยในการปฏิบัติการอันเปราะบางของพวกเขา มีความสามารถรันโค้ดใดก็ได้บนเครื่องผู้ใช้
    ตัวจัดการแพ็กเกจหลักของ Linux เองก็ยังไปไม่ไกลพอในเรื่องอย่างการลงนามรีวิว แต่ส่วนใหญ่อย่างน้อยก็มีการลงนามแพ็กเกจในระดับผู้เขียน, การรีวิวโดยมนุษย์ และการทำบิลด์ซ้ำได้อย่างอิสระสำหรับแพ็กเกจจำนวนมาก
    เมื่อดูจากการที่เป้าหมายมูลค่าสูงอย่างผู้ดูแลระบบบริษัทมักยอมให้ brew อยู่บนคอมพิวเตอร์ของตัวเอง Brew จึงอยู่บนเส้นทางที่จะสร้างความเสียหายจาก การจัดการซัพพลายเชน ที่บกพร่องได้หนักกว่ากรณี Crowdstrike เมื่อใดก็ได้

  • ถ้าบน Mac มีการรองรับ PKGBUILD แบบ pacman พร้อมประสิทธิภาพใกล้เคียงกัน และมีการดูแลแพ็กเกจโปรแกรมหลักอย่างเหมาะสม ก็น่าจะลดการประนีประนอมที่ต้องยอมรับเพื่อแลกกับความสะดวกเวลาใช้ Mac ลงได้มาก
    Homebrew ยอดเยี่ยมมากและ formula ก็ได้รับการดูแลดีจริง ๆ แต่เพราะความเรียบง่ายของ PKGBUILD, การซิงก์ที่รวดเร็ว และภาระทางความคิดที่น้อยกว่าเพราะไม่ต้องจำอาร์กิวเมนต์กับแฟล็กหลายแบบของตัวจัดการแพ็กเกจแต่ละตัว เลยอยากให้ pacman ใช้งานบน Mac ได้ตรง ๆ

    • pacman แบบปกติไม่ได้ทำงานบน macOS อย่างที่คาด แต่มีความพยายามจะทำให้ใช้ได้ด้วยการปรับแต่ง/แฮ็กเล็กน้อย: https://github.com/liudongmiao/pacman, https://github.com/kladd/pacman-osx
    • เคยมีความพยายามแบบนี้อยู่หลายครั้ง บางอันอาจใช้งานได้จริงในตอนนี้ด้วยซ้ำ
    • MacPorts ก็ไม่ใช่แบบเดียวกันหรือ? ถามจริง ๆ นะ

  • ผมมองว่าเวกเตอร์การโจมตีหลักก็คือการแค่ส่ง formula ใหม่เข้ามาแล้วแอบสอดแพ็กเกจอันตรายตัวใหม่เข้าไปได้
    ทีมผู้ดูแลมีขนาดเล็กเกินกว่าจะตรวจสอบ formula ใหม่ทั้งหมดที่มีคนส่งเข้ามาได้อย่างครบถ้วน น่าแปลกใจที่ เวกเตอร์การโจมตี นี้ไม่ถูกรวมอยู่ในการตรวจสอบ

    • ปัจจุบันผู้รีวิว Homebrew core formula คงไม่คิดว่าทีมของตัวเองเล็กเกินไปจนตรวจคำขอ formula ใหม่ที่เข้ามาได้ไม่เพียงพอ
      ถึงอย่างนั้น นี่ก็เป็นหนึ่งในความกำกวมของงานแพ็กเกจจิงที่บทความกล่าวถึงอย่างชัดเจนอยู่แล้ว เส้นแบ่งระหว่างการรันโดยบุคคลที่หนึ่งกับบุคคลที่สามนั้นโดยเนื้อแท้แล้วพร่าเลือน และในแง่คุณค่าด้านความปลอดภัย ผมคิดว่าการหาจุดที่การรันโดยบุคคลที่สามอาจเกิดขึ้นใน ที่ที่ไม่คาดคิด มีความสำคัญเชิงเปรียบเทียบมากกว่าการชี้ทุกสิ่งที่เป็นผลตามธรรมชาติจากการตั้งใจรันโค้ดของบุคคลที่สาม
      แต่ผมก็คิดว่าระบบนิเวศการแพ็กเกจโดยรวมควรถูกทบทวนเรื่องกระบวนการอนุมัติแบบนี้ อย่างไรก็ตาม นั่นเป็นเรื่องของกระบวนการคน จึงใกล้เคียงกับการตรวจแบบ red team มากกว่าการตรวจซอฟต์แวร์
    • ส่วนนั้นมีเขียนไว้แล้ว และตั้งสมมติฐานว่า formula เชื่อถือได้
      “... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...”
    • ผมเองก็เพิ่งตกใจกับการเห็นใครสักคนดาวน์โหลดคอนโซลอีมูเลเตอร์ชื่อ “Cmder” เมื่อไม่กี่วันก่อน มันเป็นการรวมเครื่องมือ FOSS หลายตัวเข้าด้วยกัน และมีไฟล์ที่อาจเป็นอันตรายอยู่ตามตัวอักษรราว 1,000 ไฟล์ ไม่ว่าจะเป็นสคริปต์ PowerShell, สคริปต์ Perl, สคริปต์ Python, เชลล์สคริปต์, DLL, EXE ฯลฯ
      สุดท้ายมันไม่เป็นอันตราย แต่การที่ผู้คนแค่ clone Git repository แบบนี้แล้วหวังว่ามันจะโอเคนี่น่ากลัวจริง ๆ

  • มี TOB-BREW-n เรียงอยู่หลายรายการ เลยสงสัยว่าเป็นเหมือน หมายเลข CVE สำหรับโปรเจ็กต์นี้โดยเฉพาะหรือเปล่า
    แก้ไข: อ้อ มันคือ “Trail Of Bits - homeBREW” นี่เอง ถึงอย่างนั้นก็น่าจะใช่อยู่ดี

    • ใช่ รายงานการตรวจใช้ธรรมเนียม TOB-$PRODUCT-$XXXX โดย $PRODUCT คือสิ่งที่ถูกตรวจ และ $XXXX คือตัวนับเพิ่มขึ้นแบบไม่ซ้ำของแต่ละประเด็นที่พบ
      เท่าที่ผมรู้ บริษัทตรวจหลายแห่งก็ใช้แนวทางคล้ายกัน

  • ถ้อยคำในบล็อกโพสต์นี้ชวนสับสนเล็กน้อย มันบอกว่าทำการตรวจนี้ร่วมกับ Homebrew และเพราะชื่อนี้คุ้น ๆ เลยไปดู README ของ Homebrew แล้วก็พบว่าใน https://github.com/Homebrew/brew มี William Woodruff อยู่ในรายชื่อผู้ดูแล
    เลยสงสัยว่ามีเหตุผลอะไรไหมที่บล็อกโพสต์ไม่ได้พูดถึงจุดนี้ คงไม่ได้เปลี่ยนอะไรใหญ่โต แต่ก็อยากให้ชัดเจน

    • ตอนทำการตรวจตอนนั้นผมยังไม่ได้เป็นผู้ดูแล :-)
      ผมเป็น “สมาชิก” ที่ไม่ใช่ผู้ดูแลของโปรเจ็กต์มานาน ซึ่งเป็นตำแหน่งกึ่งกิตติมศักดิ์ที่มอบให้ผู้ดูแลเก่าบางคนที่ยังอยากมีส่วนร่วมในการพูดคุยภายในและธรรมาภิบาล หลังจากนั้นหลายเดือนเมื่อการตรวจเสร็จไปแล้ว ผมก็ได้รับการเสนอสมาชิกภาพอีกครั้งเพราะงานอื่นที่เกี่ยวข้องกับ Homebrew ซึ่งไม่ได้มีอยู่หรือถูกวางแผนไว้ก่อนแผนการตรวจเลย
      เรื่องนี้ถูกรวมอยู่ในการเปิดเผย ผลประโยชน์ทับซ้อน ที่ผมทำกับทั้งบริษัทและผู้ดูแล Homebrew แล้ว แต่ผมก็เห็นด้วยว่าน่าจะระบุไว้ในบล็อกโพสต์ด้วย จะลองเพิ่มวันนี้
      สรุปคือ ตอนทำการตรวจผมไม่ได้เป็นผู้ดูแล แต่เคยเป็นมาก่อนและตอนนี้ก็เป็นอยู่ การตรวจนี้เป็นงานวิชาชีพที่ผมกับเพื่อนร่วมงานดำเนินการ