ช่องโหว่ที่ทำให้เข้าถึงเบราว์เซอร์ Arc ได้โดยไม่ต้องให้ผู้ใช้เข้าเว็บไซต์

 (kibty.town)
2 คะแนน โดย GN⁺ 2024-09-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ปัญหาจากการทำงานร่วมกันของ Boosts ใน Arc กับกฎ Firestore ทำให้ผู้โจมตีสามารถผูก Boost ที่มี JavaScript ตามต้องการเข้ากับบัญชีของเหยื่อได้
  • มีการยืนยันการใช้ Firebase Auth และ Firestore ด้วย การ hook ด้วย Frida และพบลำดับการเข้าถึงคอลเลกชัน preferences, users, user_referrals, boosts
  • ช่องโหว่เกิดจาก Arc ใช้ creatorID เป็นเกณฑ์ตัดสินว่า Boost จะถูกนำไปใช้กับใคร แต่ผู้โจมตีสามารถ เปลี่ยน creatorID ในเอกสาร Boost ของตัวเองเป็น ID ผู้ใช้อื่นได้
  • สามารถหา ID ของเหยื่อได้จาก user_referrals, boostSnapshots ของ Boost แบบสาธารณะ, และ Easels ที่แชร์ไว้ และเมื่อเหยื่อเข้าเว็บเป้าหมาย Boost อันตรายก็อาจถูกรันได้
  • The Browser Company ออกแพตช์พร้อมจ่ายรางวัล $2,000 และหลังได้รับการกำหนด CVE-2024-45489 ก็ประกาศว่าจะลดการใช้ Firebase, ทำ security audit, และเดินหน้าโปรแกรม bug bounty

ฟีเจอร์คลาวด์ของ Arc และการใช้ Firestore

  • Arc ต้องใช้ บัญชีผู้ใช้ จึงจะใช้งานได้ และยืนยันได้ว่ากระบวนการสมัครใช้ Firebase Auth
  • ในการสังเกตเครือข่ายช่วงแรกไม่เห็นคำขออื่นที่ชัดเจน แต่เมื่อดูฟีเจอร์แชร์ Easels ก็เริ่มเห็นความเป็นไปได้ว่าใช้งาน Firestore
  • Easels คืออินเทอร์เฟซลักษณะไวท์บอร์ดที่สามารถแชร์ให้คนอื่นดูบนเว็บได้
  • Firestore เป็นบริการ database-as-a-backend ที่สามารถสร้างฟีเจอร์ได้ด้วยกฎความปลอดภัยของฐานข้อมูลและการเข้าถึงโดยตรงจากไคลเอนต์ โดยไม่ต้องมีแบ็กเอนด์แยกต่างหาก
  • ตัวอย่างก่อนหน้าของกฎความปลอดภัย Firestore ที่หละหลวมเชื่อมโยงไปยัง Firewreck

วิธีที่ใช้ยืนยันการเรียก Firebase

  • เนื่องจาก Swift SDK ของ Firebase มักไม่ทำตามการตั้งค่า system proxy จึงใช้ สคริปต์ Frida dump การเรียกที่เกี่ยวข้องแทน mitmproxy
  • สคริปต์ทำการ hook การเรียก Firestore ของ Objective-C class
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • เมธอดที่ใช้รันจริง เช่น getDocuments, addSnapshotListener:, getDocument
    • เมธอดเขียนเอกสารตระกูล updateData, setData
  • ระหว่างรัน Arc พบเส้นทางและคิวรี Firestore ประเภทต่อไปนี้
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • คิวรี user_referrals ด้วยเงื่อนไข inviter_id == {userID}
    • คิวรี boosts ด้วยเงื่อนไข creatorID == {userID}
  • จากโครงสร้างนี้ Arc เก็บการตั้งค่าบางส่วน, ออบเจ็กต์ผู้ใช้พื้นฐาน, ข้อมูลการแนะนำ, และ Boosts ไว้ใน Firestore

เหตุใด Boosts จึงกลายเป็นเส้นทางโจมตี

  • Arc Boosts คือฟีเจอร์ที่ให้ผู้ใช้ปรับแต่งเว็บไซต์ได้
    • บล็อกองค์ประกอบ
    • เปลี่ยนฟอนต์
    • เปลี่ยนสี
    • CSS แบบกำหนดเอง
    • JavaScript แบบกำหนดเอง
  • Boosts ถูกเก็บไว้ใน Firestore และเบราว์เซอร์ Arc จะคิวรีด้วยฟิลด์ creatorID เพื่อดูว่าควรใช้ Boost ใด
  • ผู้โจมตีสร้าง Boost สำหรับ Google.com จากบัญชีของตัวเอง แล้วทดลองแก้พารามิเตอร์บางส่วนในเอกสาร Firestore
  • แม้จะคิวรี Boost ของผู้ใช้อื่นโดยตรงไม่ได้เพราะใช้เงื่อนไข creatorID แต่ผู้โจมตีสามารถ เปลี่ยน creatorID ในเอกสาร Boost ของตัวเองเป็น ID ผู้ใช้ของบัญชีอื่นได้
  • เมื่อลองกับอีกบัญชีหนึ่ง พบว่าเมื่อเครื่องของเหยื่อเข้า Google.com Boost ที่ผู้โจมตีสร้างไว้จะถูกนำไปใช้

สายโซ่การโจมตีและการหา user ID

  • ลำดับการโจมตีสุดท้ายเป็นดังนี้
    • หา user ID ของเหยื่อ
    • สร้าง Boost อันตรายที่มี payload ตามต้องการจากบัญชีของผู้โจมตี
    • เปลี่ยนฟิลด์ creatorID ของเอกสาร Boost ให้เป็น ID ของเหยื่อ
    • เมื่อเหยื่อเข้าเว็บไซต์เป้าหมาย Boost อันตรายจะทำงาน
  • ช่องโหว่นี้เกิดขึ้นได้เพราะ Arc Boosts สามารถมี JavaScript ตามต้องการได้, ถูกเก็บไว้ใน Firestore, และการตัดสินว่าจะใช้กับใครอิงจากฟิลด์ creatorID
  • มีหลายวิธีในการหา user ID ของเหยื่อ
    • user_referrals: หากมีการเชิญหรือได้รับคำเชิญให้ใช้ Arc ก็สามารถหา user ID ของอีกฝ่ายได้จากตาราง user_referrals
    • Boosts แบบสาธารณะ: Boost ที่ไม่มี JavaScript สามารถแชร์ได้ และ boostSnapshots บน เว็บไซต์สาธารณะของ Arc Boosts มี user ID ของผู้สร้างรวมอยู่ด้วย
    • Easels: ฟีเจอร์ไวท์บอร์ดที่แชร์ได้ก็เป็นอีกช่องทางในการหา user ID

แพตช์และไทม์ไลน์การเปิดเผย

  • โดยปกติ The Browser Company ไม่ค่อยมี bug bounty แต่สำหรับช่องโหว่นี้ได้จ่าย $2,000 USD
  • ไทม์ไลน์ของช่องโหว่มีดังนี้
    • 25 สิงหาคม 5:48pm: ติดต่อ Hursh ผู้ร่วมก่อตั้ง Arc ครั้งแรกผ่าน Signal
    • 25 สิงหาคม 6:02pm: รัน PoC ของช่องโหว่บนบัญชี Arc ของ Hursh
    • 25 สิงหาคม 6:13pm: แชร์รายละเอียดในรูปแบบเข้ารหัสแล้วถูกเพิ่มเข้า Slack channel
    • 26 สิงหาคม 9:41pm: แพตช์ช่องโหว่และจ่ายเงินรางวัล
    • 6 กันยายน 7:49pm: ได้รับการกำหนด CVE-2024-45489
  • หลังจากนั้น Arc ก็เผยแพร่บทความของตัวเองเกี่ยวกับประเด็นนี้ที่ CVE-2024-45489 incident response

การรันบนหน้าที่มีสิทธิ์และความขัดแย้งด้านความเป็นส่วนตัว

  • แม้จะไม่สามารถสร้าง Boosts จากฝั่งไคลเอนต์ได้ แต่ก็ยังสามารถรันบนโปรโตคอลอื่นได้
  • หากสร้าง Boost โดยกำหนดเป้าหมายเป็นหน้า settings ก็จะไปรันบน chrome://settings และอาจนำไปสู่ การยกระดับสิทธิ์
  • เมื่อมีการเข้าเว็บไซต์ จะเกิดคิวรี Firestore ดังนี้
    • คิวรีคอลเลกชัน boosts ด้วยเงื่อนไข creatorID == {userID} และ hostPattern == "www.google.com";
  • ในที่นี้ hostPattern หมายถึงเว็บไซต์ที่เข้าใช้งาน ซึ่งขัดกับ นโยบายความเป็นส่วนตัวของ Arc ที่ระบุว่า Arc ไม่ทราบว่าผู้ใช้เข้าเว็บไซต์ใด

มาตรการติดตามผลของ Arc

  • Arc ปรับทิศทาง ออกจาก Firebase โดยอาศัยโอกาสจากทั้งช่องโหว่นี้และการเพิ่มฟีเจอร์ใหม่
  • ในสรุปของ Arc เองมีมาตรการดังต่อไปนี้
    • ยืนยันการแก้ไขปัญหา
    • เพิ่มฟีเจอร์ปิดใช้งาน Boosts จากฝั่งไคลเอนต์
    • ตรวจสอบภายในเกี่ยวกับกฎ Firebase ACL ที่ใช้อยู่ในปัจจุบัน
    • จัดทำโปรโตคอลรับมือประเด็นด้านความปลอดภัย
  • มาตรการเพิ่มเติมที่แชร์จากการหารือภายใน Arc มีดังนี้
    • แก้ปัญหาด้านความเป็นส่วนตัวในอัปเดต v1.61.1
    • หยุดใช้ Firebase ในฟีเจอร์และผลิตภัณฑ์ใหม่
    • ทำ external security audit สำหรับเวอร์ชันดังกล่าว
    • เริ่มโปรแกรม bug bounty สำหรับช่องโหว่ในอนาคต

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

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

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

  • ผมคือ Hursh ผู้ร่วมก่อตั้งและ CTO ของ The Browser Company ผู้พัฒนา Arc แม้จะไม่มีผู้ใช้ที่ได้รับผลกระทบจริงและเราแพตช์ทันที แต่เรามองว่า ความร้ายแรงที่อาจเกิดขึ้นได้ ของช่องโหว่นี้เป็นสิ่งที่ยอมรับได้ยาก
    รายละเอียดทางเทคนิค แผนการปรับปรุงในอนาคต การย้ายออกจาก Firebase และการจัดทำ โปรแกรมบั๊กบาวน์ตี อย่างเป็นทางการ สรุปไว้ที่นี่: https://arc.net/blog/CVE-2024-45489-incident-response
    ขออภัยอย่างจริงใจทั้งเรื่องช่องโหว่เองและการสื่อสารที่ล่าช้า ฟีดแบ็กทั้งความผิดหวัง ความโกรธ และกำลังใจทำให้เรารู้สึกมีความรับผิดชอบที่จะทำให้ดียิ่งขึ้น

    • สงสัยว่าบทความนี้เขียนไว้ให้ผู้ใช้ HN อ่านเท่านั้นหรือเปล่า เพราะไม่เห็นในรายการบล็อก (https://arc.net/blog) และก็ไม่ได้โพสต์บน Twitter
      การตอบสนองทั้งหมดดูเหมือนจะเกิดขึ้นก็ต่อเมื่อเรื่องดังมากพอเท่านั้น
    • เพื่อนหลายคนชอบ Arc จนผมเคยพิจารณาจะเปลี่ยนไปใช้เอง แต่ตอนนี้คิดว่าจะไม่ใช้แล้ว ไม่ใช่เพราะตัวช่องโหว่เองเท่าไร แต่เพราะบั๊กที่สามารถยึดครองผู้ใช้ทั้งหมดอย่างอันตรายได้กลับได้ บาวน์ตีแค่ $2k
      ผมไม่อยากใช้เบราว์เซอร์ที่ทำโดยบริษัทที่มองความปลอดภัยของผู้ใช้เบาแบบนี้ ถึงจะไม่แน่ใจ แต่ถ้าร้ายแรงระดับนี้ก็น่าจะขายในตลาดมืดได้แพงกว่านี้มาก
    • ในคอมเมนต์ข้างล่างมีความกังวลว่า ทุกครั้งที่โหลดหน้าเว็บ อาจมีการส่ง URL และ ID ผู้ใช้ที่ระบุตัวตนได้ไปยัง TBC คนที่ใช้เบราว์เซอร์ที่ไม่ใช่ Chrome โดยทั่วไปน่าจะอ่อนไหวกับเรื่อง ความเป็นส่วนตัว ด้วย ดังนั้นควรตอบประเด็นนี้
      ช่องโหว่เกิดขึ้นได้ แต่การส่งข้อมูลการท่องเว็บดูเหมือนเป็นการเลือกออกแบบโดยตั้งใจ
    • หลังเห็นเรื่องนี้แล้ว ดูเหมือนไม่มีทางโน้มน้าวได้ว่าทีมมีความเชี่ยวชาญพอจะดูแลเบราว์เซอร์ต่อไปได้ แม้จะแก้แล้วก็ตาม แต่ตอนนี้และในอนาคตก็ดูไม่มีศักยภาพพอจะสร้าง เบราว์เซอร์ที่ปลอดภัย
      ผมคิดว่านี่เป็นกรณีที่ CTO ควรลาออก
    • อยากรู้ว่ามีแผนจะเพิ่มเงินบั๊กบาวน์ตีหรือไม่ $2,000 ถือว่าน้อยมากเมื่อเทียบกับมูลค่าของบั๊กนี้ และหวังว่าผู้ค้นพบจะได้รับรางวัลที่เหมาะสม
      ถือว่าได้รับโอกาสทองในการกำหนดทิศทางที่ถูกต้องแล้ว

  • หลายคอมเมนต์ที่นี่โทษ Firebase กันมาก แต่ดูเหมือนพูดตาม ๆ กันในเรื่องที่จริง ๆ แล้วไม่ค่อยรู้ ผมไม่ได้ใช้ Firebase แต่จากที่เคยใช้มาก่อน เรื่องนี้ไม่ใช่เคสชายขอบและไม่ใช่ปัญหาที่แก้ยากเลย แต่เป็น พื้นฐานสุด ๆ
    ปัญหาจริงคือ API ถูกทำให้เชื่อค่าที่ไคลเอนต์ส่งมาว่า “ฉันคือใคร” สุดท้ายคือความผิดพลาดแบบมือสมัครเล่น และอาจแก้ได้ด้วยการแก้เพียงบรรทัดเดียวด้วยซ้ำ แค่ดูเอกสารที่ https://firebase.google.com/docs/rules/rules-and-auth#cloud-... ก็จะเห็นว่า request.auth ให้ ID ผู้ใช้ที่ต้องการ (request.auth.uid)

    • ในฐานะคนที่ดูแลแอปที่สร้างด้วย Firebase เห็นด้วย ตามที่ผู้เขียนชี้ไว้ การตั้งค่าผิดทำได้ง่ายมากก็จริง แต่ แนวทางปฏิบัติด้านความปลอดภัยพื้นฐาน แบบนี้ถูกเน้นไว้ในเอกสาร Firebase ด้วยคำเตือนตัวหนาที่เห็นชัดเจน
      กฎความปลอดภัยต้องถูกปฏิบัติอย่างจริงจัง และแทบจะเป็นแนวป้องกันเพียงอย่างเดียว
    • น่าสนใจที่วิศวกรซอฟต์แวร์เคยไปสร้างระบบยืนยันตัวตนเอง แล้วก็หันไปไม่สร้างเอง และตอนนี้กลับดูเหมือนแม้แต่ปัญหาความปลอดภัยที่โจ่งแจ้งแบบนี้ก็ยังสังเกตไม่ออก
      ไม่ว่าจะสร้างระบบยืนยันตัวตนเองหรือไม่ หลักสำคัญมีอย่างเดียว: อย่าเชื่อใจไคลเอนต์เด็ดขาด
    • ถ้า “สุดท้ายคือความผิดพลาดแบบมือสมัครเล่น” ได้ก็คงดี เพื่อนร่วมงานของผมก็เคยทำพลาดแบบเดียวกันหลายครั้งในแอปฟรอนต์เอนด์ภายในบริษัท
    • แผนความปลอดภัย ที่อาศัยสมมติฐานว่าไม่ว่าใครก็จะไม่มีวันทำพลาดแบบมือสมัครเล่นนั้น ตัวมันเองคือความผิดพลาดแบบมือสมัครเล่น
    • ถ้าเข้าใจถูก การแก้ปัญหานี้น่าจะเป็นแค่การใส่กฎต่อไปนี้ในคำสั่ง match ของ firestore.rules ซึ่งเป็นเนื้อหาที่มีอยู่ตรง ๆ ในเอกสารระดับเริ่มต้นด้านความปลอดภัยของ Firebase Firestore 
      
// Allow create new object if user is authenticated

allow create: if request.auth != null;

// Allow update or delete document if user is owner of document

allow update, delete: if request.auth.uid == resource.data.ownerUID

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

    • ฝั่งผมไม่เห็น แต่ดูเหมือนนักพัฒนาจะเคารพ prefers-reduced-motion เลยไม่แสดงถ้ามีการตั้งค่านั้นไว้ เป็นการจัดการที่ดีมาก ให้ความสนุกกับคนที่อยากได้ และไม่รบกวนคนที่ไม่ชอบ
    • สำหรับแมวอายุ 35 ปีแล้ว ยังเคลื่อนไหวได้ดีมาก
      https://en.wikipedia.org/wiki/Neko_(software)
    • บน Debian สามารถติดตั้งและรันแมวได้ด้วยคำสั่งต่อไปนี้
      sudo apt install oneko
      oneko &
      เหมาะเป็นของขวัญให้คอมพิวเตอร์ของเพื่อนร่วมงานที่ไม่อยู่ที่โต๊ะ
    • ก็น่ารักดี แต่พอรู้ว่าแมวจะขยับทุกครั้งที่เลื่อนเมาส์หรือสกรอลล์ ผมก็ไม่มีสมาธิอ่านบทความเลย เลยเปิดคอนโซลแล้วลบมันทิ้ง ขอโทษนะ เจ้าแมว
    • บนมือถือมันบังข้อความตลอด เลยกำลังหาวิธีเอาออก สุดท้ายแก้ได้ด้วยโหมดอ่านของ Firefox

  • ตามบทความนี้ Arc บังคับให้มีบัญชี และส่งชื่อโฮสต์ของทุกหน้าที่ผู้ใช้เข้าเยี่ยมชมพร้อมกับ ID ผู้ใช้ไปยัง Google Firebase ถ้าอย่างนั้น Arc ก็อาจเป็น เบราว์เซอร์ที่มีความเป็นส่วนตัวอ่อนแอที่สุด ในบรรดาเบราว์เซอร์ที่ใช้งานกันอยู่ตอนนี้ไม่ใช่หรือ

    • พอรู้ทันทีหลังติดตั้งว่า ต้องมีบัญชี ผมก็ลบ Arc ทิ้งเลย มันดูไร้สาระเหมือนแปรงสีฟันที่ต้องใช้ Wi‑Fi แต่ตอนนี้ดูเหมือนจะหนักกว่านั้นอีก
    • รางวัลนั้นน่าจะตกเป็นของ OperaGX มากกว่า
    • ก็อยากรู้เหมือนกันว่าถ้า Firebase ล่ม Arc จะพังแค่ไหน
    • ตอนดาวน์โหลดมาลองเมื่อไม่กี่เดือนก่อน พอเห็นว่าต้องมีบัญชีถึงจะใช้ได้ ก็มีลางสังหรณ์ว่าคงใช้ Firefox ต่อไปดีกว่า
    • ข้อมูลที่ส่งไป Firebase ไม่ได้เข้ารหัสหรือเปล่า? ถ้าเป็นข้อมูลอ่อนไหว Google เองก็น่าจะแนะนำให้ทำแบบนั้น

  • เป็นบั๊กที่เจ๋งจริง ๆ บริการแบ็กเอนด์อย่าง Firebase มีค่าเริ่มต้นแปลก ๆ ในกฎความปลอดภัยที่อธิบายได้ยาก ถ้าสร้าง API เอง userId ของเรคอร์ดอย่าง boost ในกรณีนี้ ผมจะไม่รับจาก request payload แต่จะตั้งจาก ID ผู้ใช้ใน session
    นักพัฒนาระดับหนึ่งขึ้นไปแทบจะไม่คิดให้ไคลเอนต์ส่งค่าที่อ้างว่าเป็น userId ของตัวเองเข้ามาในเส้นทาง API ที่ถูกป้องกันอยู่แล้ว ในทางกลับกัน สำหรับกฎความปลอดภัย คุณต้องจินตนาการทุกวิธีที่ระบบอาจถูกนำไปใช้ผิด ๆ โดยไม่ขึ้นกับวิธีใช้งานที่โปรแกรมไว้จริง

    • ถ้าเข้าหาด้วยวิธีนั้น พูดตรง ๆ คือกำลังทำผิดอยู่ เริ่มจาก ปฏิเสธโดยปริยาย แล้วคุณก็แค่ต้องจินตนาการวิธีใช้งานที่ถูกต้องตามกฎหมายเท่านั้น
    • สำหรับการ insert นั้นใช่ แต่ในการ update ผมเห็นบ่อยว่ามีการยัด request ทั้งก้อนเข้า ORM หรือ document store ตรง ๆ คนมักคิดว่า “เจ้าของแก้ไขเอกสารได้” แต่พลาดได้ง่ายว่าบางฟิลด์ที่ไคลเอนต์ทางการไม่ได้ตั้ง เช่น เจ้าของหรือเวลาสร้าง ไม่ควรถูกเปลี่ยน
      วิธีแก้ที่ถูกน่าจะเป็นการตั้ง สิทธิ์ปฏิเสธโดยปริยาย ให้ทุกฟิลด์ อย่างน้อยก็จะบังคับให้ต้องระบุชัดเจนว่าฟิลด์เจ้าของเขียนได้ และทำให้ต้องคิดถึงผลกระทบของการโอนอ็อบเจกต์นี้ให้ผู้ใช้อื่น

  • น่าทึ่งว่าช่องโหว่นี้โง่แบบเหลือเชื่อแค่ไหน ถ้าจะรันโค้ดตามอำเภอใจ ก็แค่ส่ง ID ผู้ใช้ของคนอื่นเข้าไปตามตัวอักษร และ ID นั้นก็หาได้ค่อนข้างง่าย
    ผมไม่ได้ทำงานที่ FAANG ด้วยซ้ำ แถมทำงานในบริษัทที่ทำผลิตภัณฑ์ห่วย ๆ ซึ่งจริง ๆ ก็ไม่จำเป็น แต่ถึงเป็นผมก็ไม่ทำบั๊กแบบนี้ แล้วคนพวกนี้จะมาทำเบราว์เซอร์ และรับทั้งความเชี่ยวชาญด้านความปลอดภัยกับความรับผิดชอบทางจริยธรรมที่ตามมาด้วยจริงหรือ

    • ช่วยอธิบายได้ไหมว่าจะได้ ID ผู้ใช้ของคนอื่นมาได้อย่างไร? ผมเข้าใจว่านี่เป็นช่องโหว่ใหญ่ แต่อยากเข้าใจว่าส่วนนั้นเกิดขึ้นได้ยังไง

  • อยากให้ใส่ Arc ไว้ในชื่อโพสต์ เพื่อให้คนที่ใช้ Arc หรือมีคนรู้จักใช้ Arc สังเกตเห็นได้ดีกว่านี้

    • เห็นด้วยสุด ๆ เมื่อวานตอนเห็นครั้งแรก ผมไม่รู้เลยว่านี่เกี่ยวกับผมด้วย และเพิ่งคลิกหลังจากชื่อเรื่องถูกเปลี่ยน
      พูดตรง ๆ ผมรู้สึกแรงมากว่าชื่อเรื่องควรเป็นประมาณ “บั๊กพื้นฐานในเบราว์เซอร์ Arc (CVE 123-4567)”

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

    • อีกด้านหนึ่ง ความเร็วในการตอบสนองเองก็น่าประทับใจทีเดียว
      aug 25 5:48pm: ติดต่อ Hursh ผู้ร่วมก่อตั้ง Arc ครั้งแรกผ่านช่องทางเข้ารหัสของ Signal
      aug 25 6:02pm: รัน proof of concept ของช่องโหว่บนบัญชี Arc ของ Hursh
      aug 25 6:13pm: เปิดเผยรายละเอียดในรูปแบบเข้ารหัส แล้วถูกเพิ่มเข้า Slack channel
      aug 26 9:41pm: แพตช์ช่องโหว่และจ่าย bounty
      sep 6 7:49pm: ได้รับการกำหนด CVE (CVE-2024-45489)
      จากการติดต่อครั้งแรกแบบกะทันหันจนถึงการปล่อยแก้ไขใน 4 ชั่วโมง ถือว่าดีทีเดียว แม้จะคำนึงว่าการแก้อาจเรียบง่ายก็ตาม แก้ไข: วันที่เปลี่ยนไปแล้ว ดังนั้นจริง ๆ คือ 28 ชั่วโมง ถึงอย่างนั้นก็ยังใช้ได้ และการตอบกลับภายใน 30 นาทีหลังติดต่อครั้งแรกว่า “เข้ามาใน Slack channel ของเรา” นั้นเร็วมาก
    • การที่ต้องมี บัญชีบังคับ แม้แต่เพื่อจะลองใช้ Arc ก็เป็นสัญญาณอันตรายใหญ่ตั้งแต่แรกแล้ว ผมเลยไม่ได้ลองใช้เลย ตอนนี้ดีใจที่ไม่ได้ใช้
    • พูดตรง ๆ ผมมอง Arc โดยเฉพาะด้านความเป็นส่วนตัวว่าเป็น หมาป่าในคราบแกะ มาตลอด
      สำหรับผลิตภัณฑ์ที่สำคัญและเป็นส่วนตัวอย่างเบราว์เซอร์ การที่ได้รับเงินสด 50–60 ล้านดอลลาร์และมูลค่าประเมิน 500 ล้านดอลลาร์ แต่ไม่มีโมเดลธุรกิจ ถือเป็นสัญญาณอันตรายใหญ่ นี่ไม่ใช่งานการกุศล ดังนั้นต้องมีใครสักคนจ่ายต้นทุนในทางใดทางหนึ่ง
    • โดยปกติเราย่อมคิดว่าบริษัทที่แจกจ่ายเบราว์เซอร์น่าจะใส่ใจเรื่องกฎความปลอดภัยมากกว่านี้สักหน่อย
      น่าเสียดายที่ Firebase ก็ทำให้มันกันพลาดมากกว่านี้ไม่ได้ และจริง ๆ ให้แค่ $2,500 เองหรือ? ตามตัวอักษรคือสามารถยึดผู้ใช้ Arc ทั้งหมดได้เลย ถ้าเป็น NSA คงเติมศูนย์เพิ่มอีกหลายตัว
    • แถมยังเป็น Firebase อีก จริงหรือเนี่ย บริษัทที่ถึงขั้นจ้างวิศวกรซอฟต์แวร์ระดับล่าง ยังใช้แบ็กเอนด์ CRUD สำเร็จรูปแบบกล่อง ต้นทุนคงคุ้มค่าดี แต่ถ้าผมออกแบบอะไรแบบนี้ Firebase คงไม่อยู่แม้แต่ในรายชื่อผู้สมัครแบ็กเอนด์อันยาวเหยียด
      โดยเฉพาะเมื่อคู่แข่งด้านฟีเจอร์อย่าง Supabase เป็นการห่อหุ้ม DBMS ทั่วไปกับโมเดลการยืนยันตัวตน

  • ขอบคุณที่แชร์ ผมใช้ Arc มาตั้งแต่สัปดาห์แรกของเบต้า
    แต่ข้อเท็จจริงที่ว่าไม่มีการพูดถึงบั๊กนี้และสิ่งที่แก้ไขบนโซเชียลมีเดียที่ไหนเลยนั้นค่อนข้างน่ากังวล ช่วงเวลาที่ใช้ Arc สนุกดี แต่เห็นวิธีจัดการแบบนี้แล้วคงใช้ต่อไม่ไหว

    • การยอมรับปัญหาและแก้ภายใน 28 ชั่วโมงยังไม่เพียงพอหรือ? การตอบสนองแบบนั้นทำให้ผมคิดว่ายังใช้ Arc ต่อได้

  • $2,000 สำหรับช่องโหว่ใหญ่ขนาดนี้เป็นจำนวนเงินที่ดูถูกกันมาก

    • จากบล็อกโพสต์บน HN ดูเหมือนช่องโหว่แบบนี้มักไม่ได้รับรางวัลเลย หรือได้แค่น้อยมาก จนดูเหมือนบริษัทกำลังอ้อนวอนให้แฮกเกอร์เอา exploit ไปขาย
      อาจเป็นเพราะหน่วยงานกำกับดูแลไม่ได้ลงโทษบริษัทจากเหตุละเมิดก็ได้
    • ใช่ ปฏิกิริยาแรกของผมก็เป็นแบบนั้นเหมือนกัน ผมแปลกใจจริง ๆ ที่ประหยัดเงินกันขนาดนี้
    • ต้องมีมโนธรรมที่หนักแน่นมากทีเดียว ถึงจะไม่ขายให้ฝ่ายประสงค์ร้ายที่ยอมจ่ายมากกว่านี้ 20–50 เท่า