ป๊อปอัปสิทธิ์ของ macOS เชื่อถือได้จริงหรือ?

 (wts.dev)
2 คะแนน โดย GN⁺ 2025-05-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบสิทธิ์ TCC ของ macOS เคยมีช่องโหว่ที่ทำให้แสดง ป๊อปอัปขอสิทธิ์ที่ทำให้ผู้ใช้เข้าใจผิด ได้
  • ช่องโหว่นี้ถูกลงทะเบียนเป็น CVE-2025-31250 และมีปัญหาที่ ความยินยอมของผู้ใช้ถูกนำไปใช้กับแอปอื่น
  • มีความเป็นไปได้ของ การโจมตีแบบสปูฟ ที่แอปอันตรายสามารถแสดงหน้าต่างขอสิทธิ์โดยใช้ชื่อของแอปที่น่าเชื่อถือเพื่อหลอกให้ผู้ใช้กดยินยอม
  • ได้รับการแพตช์แล้วใน Apple macOS Sequoia 15.5 แต่เวอร์ชันอื่นยังคง ไม่ได้รับการแพตช์
  • นอกจากนี้ยังมีปัญหาเรื่อง ความยากในการตรวจสอบและเพิกถอนประวัติการให้สิทธิ์ และยังมีความเป็นไปได้ที่จะพบช่องโหว่ลักษณะคล้ายกันอีกในอนาคต

การแก้ไขสำคัญ

  • ช่องโหว่นี้ได้รับการแพตช์ใน macOS Sequoia 15.5 แล้ว แต่ใน macOS Ventura 13.7.6 และ macOS Sonoma 14.7.6 ยังไม่ได้รับการแพตช์
  • ยืนยันแล้วว่าในบันทึกการออกรุ่นด้านความปลอดภัยของ Apple ไม่มีการระบุชื่อผู้รายงาน
  • ได้ทดสอบ macOS Sonoma 14.7.6 บนเครื่องเสมือนด้วยตนเอง และยืนยันได้ว่าช่องโหว่นี้ยังคงถูกใช้โจมตีได้
  • คาดว่า Ventura 13.7.6 ก็น่าจะอยู่ในสถานะเดียวกัน
  • ขณะนี้กำลังรอคำตอบอย่างเป็นทางการจาก Apple

บทนำ

  • ช่องโหว่ CVE-2025-31250 เป็นปัญหาที่ทำให้แอปพลิเคชันสามารถ แสดงป๊อปอัปขอสิทธิ์ปลอมบน macOS ได้
  • เมื่อ "Application A" แสดงป๊อปอัป ตัวป๊อปอัปอาจแสดงเป็น "Application B" แต่ผลลัพธ์คือความยินยอมของผู้ใช้ถูกนำไปใช้กับ "Application C"
  • โดยปกติแล้วทั้งสามแอปพลิเคชันนี้จะเป็นแอปเดียวกัน แต่ช่องโหว่นี้ทำให้สามารถกำหนดให้เป็นคนละแอปกันได้
  • ส่งผลให้เกิดปัญหาใหญ่ด้าน ความน่าเชื่อถือของหน้าต่างขอสิทธิ์
  • ก่อนหน้านี้ก็เคยมีการแนะนำวิธี "สปูฟ" คล้ายกันใน HackTricks เป็นต้น แต่ช่องโหว่นี้ใช้วิธีที่ง่ายกว่ามาก

TCC

  • TCC คือ ระบบจัดการสิทธิ์หลักที่ฝังอยู่ในระบบปฏิบัติการของ Apple
  • สิทธิ์ต่าง ๆ ถูกจัดการผ่านการส่งข้อความไปยังดีมอน "tccd" โดย Public API จะเรียกใช้ฟังก์ชันของเฟรมเวิร์ก TCC แบบ Private
  • ดีมอนนี้สื่อสารข้อความผ่าน XPC API ของ Apple
  • ก่อนที่ช่องโหว่นี้จะถูกแพตช์ หากส่งข้อความที่สร้างขึ้นเอง ก็สามารถกำหนดให้แอปที่แสดงป๊อปอัปขอสิทธิ์กับแอปที่ได้รับสิทธิ์จริงเป็นคนละแอปกันได้
  • เพื่อจะเข้าใจว่าช่องโหว่นี้เกิดขึ้นได้อย่างไร จำเป็นต้องรู้จัก Apple Events ก่อน

Apple Events

Apple Events คืออะไร

  • Apple Events คือ วิธีสื่อสารระหว่างโปรเซสของแอปบน macOS
  • เป็นโปรโตคอลที่สืบทอดมาตั้งแต่ยุคหนังสือคลาสสิกที่ตีพิมพ์ในปี 1993
  • หลังการมาของ macOS X ก็ยังถูกออกแบบใหม่ให้เข้ากับโครงสร้างระบบและใช้งานต่อมา
  • ปัจจุบันมักใช้เพื่อ งานอัตโนมัติ (Automation) โดยสคริปต์ด้วย AppleScript และ JavaScript
  • คล้ายกับ Script Host ของ Windows และก็เคยถูกใช้เป็น ช่องทางของมัลแวร์ เช่นกัน

Apple Events กับ TCC

  • ตั้งแต่ macOS Mojave 10.14 เป็นต้นมา การ ส่ง Apple Events ต้องได้รับความยินยอมจากผู้ใช้
  • ในฐานข้อมูลเก็บสิทธิ์ของ TCC (TCC.db) จะมีการบันทึกแอปผู้ร้องขอ บริการ และข้อมูลการตอบยินยอม
  • เนื่องจาก Apple Events ต้องแยกจัดการสิทธิ์ตามแอปรับแต่ละตัว จึงมีการใช้ คอลัมน์ indirect object ใน TCC.db
  • ฟังก์ชัน TCCAccessRequestIndirect ของดีมอน TCC จะประมวลผลข้อความที่ใช้คอลัมน์นี้
  • ฟังก์ชันดังกล่าวมี บั๊กเชิงตรรกะ ที่ทำให้แอปที่แสดงต่อผู้ใช้กับแอปที่ได้รับสิทธิ์จริงสามารถเป็นคนละตัวกันได้

แนวคิดพิสูจน์การทำงาน (Proof-of-Concept)

  • ตัวอย่างโค้ด Swift มีการปรับแต่งข้อความขอสิทธิ์ดังนี้
    • เปิดเผยชื่อแอปจากพาธ "spoofedBundle" ในป๊อปอัปขอความยินยอมของผู้ใช้
    • กำหนด bundle ID ของ "actualBundle" ให้เป็นเป้าหมายที่ได้รับสิทธิ์จริง
  • ผลลัพธ์คือผู้ใช้จะเห็นเหมือนมีแอปที่น่าเชื่อถือเป็นผู้ขอสิทธิ์ แต่ สิทธิ์จริงกลับตกไปอยู่กับแอปอันตราย
  • แม้จะปล่อยค่า "indirect_object" ว่างไว้ ก็ยังสามารถโจมตีบริการ TCC ได้หลายประเภท
  • ส่งผลให้เกิด การพังทลายของความน่าเชื่อถือในการยินยอมให้สิทธิ์ของผู้ใช้
  • ผู้โจมตีสามารถหลอกผู้ใช้เพื่อ ชักจูงให้แอปใดก็ได้ได้รับสิทธิ์

การใช้ช่องโหว่โจมตี

ข้อจำกัดและลักษณะเฉพาะ

  • มีเพียงบริการ TCC บางประเภทเท่านั้นที่ตกเป็นเป้าหมายได้ แต่บริการสำคัญอย่าง Microphone และ Camera อยู่ในข่ายโจมตี
  • สำหรับสิทธิ์ไฟล์/โฟลเดอร์ ผลกระทบไม่มากนักเพราะมีมาตรการป้องกันเพิ่มเติม
  • แอปอันตรายสามารถใช้ร่วมกับ เทคนิควิศวกรรมสังคม เพื่อให้ผู้ใช้กดยินยอมแทนแอปอื่นที่ควรเป็นผู้ขอสิทธิ์จริงได้

ความสำคัญของจังหวะเวลา

  • ช่วงเวลา ที่ใช้แสดงป๊อปอัปมีความสำคัญ
  • แอปอันตรายสามารถตรวจจับได้ว่ามีแอปใดกำลังทำงานอยู่และแอปใดอยู่ด้านหน้า จากนั้นจึงแสดงป๊อปอัปในจังหวะที่เหมาะสมเพื่อทำให้ผู้ใช้สับสน
  • ตัวอย่างเช่น หากแสดงป๊อปอัปขอสิทธิ์ Camera ระหว่างที่ FaceTime กำลังเปิดอยู่ ผู้ใช้อาจเข้าใจผิดว่าเป็นคำขอสิทธิ์ตามปกติ
  • ยังสามารถสร้างสถานการณ์สปูฟคำขอสิทธิ์ Microphone ตอนเปิด Voice Memos ได้เช่นกัน
  • หากเลือกใช้ใน จังหวะที่สอดคล้องกับบริบท ก็จะเพิ่มโอกาสสำเร็จของการโจมตีได้มาก

การกลับมาทบทวนช่องโหว่ในอดีต

  • เคยมีช่องโหว่ที่อาศัยข้อเท็จจริงว่าพาธของ TCC.db ถูกกำหนดตาม โฮมโฟลเดอร์ของผู้ใช้
  • จนถึงปี 2020 หากเปลี่ยนแค่ตัวแปรสภาพแวดล้อม HOME ก็สามารถใช้ TCC.db ปลอมได้ ($HOMERun)
  • แม้หลังแพตช์จะยังต้องมี สิทธิ์ root และความยินยอมจากผู้ใช้ แต่หากนำมารวมกับการสปูฟเชิงวิศวกรรมสังคมก็ยังอาจใช้ข้ามข้อจำกัดสิทธิ์ได้
  • แอปอันตรายสามารถ ล่อให้ผู้ใช้กดยินยอม แล้วเปลี่ยนโฮมโฟลเดอร์พร้อมเพิ่มฐานข้อมูลที่ลงทะเบียนไว้ เพื่ออ้อมไปใช้ TCC.db ปลอมได้
  • มีการทดสอบจริงและยืนยันได้ว่าวิธีนี้สามารถส่งผลต่อการทำงานของ TCC ได้

ไทม์ไลน์

1.

  • 2024-05-02 : รายงานเบื้องต้นไปยัง Apple Product Security และส่งข้อความเพิ่มเติม

2.

  • 2024-05-03 : Apple Product Security ขอคำอธิบายเพิ่มเติมและได้รับคำตอบ
  • ในวันเดียวกัน มีการค้นพบความเป็นไปได้ในการข้าม TCC ทั้งระบบ และรายงานเพิ่มเติมให้ Apple อีกครั้ง

3.

  • 2024-05-04 : ดำเนินการทดสอบ PoC ต่อเนื่องและฝากข้อความอัปเดตเพิ่มเติม

4.

  • 2024-05-06 : Apple Product Security กล่าวขอบคุณสำหรับข้อมูลที่ให้มา

5.

  • หลังจากนั้นก็มีการสอบถามสถานะแพตช์และติดตามผลเป็นระยะ โดยมีการสื่อสารกับ Apple อย่างต่อเนื่องตั้งแต่ 2024-06 ถึง 2025-02 แต่ก็ยังไม่ได้รับการแก้ไขอยู่เป็นเวลานาน

6.

  • 2025-05-12 : มีการออกรุ่นแพตช์สำหรับบั๊กนี้

บทสรุป

หมายเหตุเพิ่มเติม

  • TCC แสดงอยู่ในหัวข้อ Privacy & Security (เดิมคือ Security & Privacy) ของแอป System Settings รวมถึงใน ส่วน Automation ที่เกี่ยวข้อง
  • แต่ ประวัติการยินยอมที่เกี่ยวกับ Apple Events ไม่แสดงใน GUI ทำให้ผู้ใช้ยกเลิกเองได้ยาก
  • แม้จะยกเลิกได้ผ่านเครื่องมือ CLI อย่าง tccutil แต่แทบไม่มีใครรู้จัก
  • เมื่อไม่นานมานี้ Apple ได้เพิ่มความสามารถในการเฝ้าติดตามการเปลี่ยนแปลงฐานข้อมูล TCC ในเฟรมเวิร์ก Endpoint Security
  • หากทำงานได้ตามปกติ ก็อาจช่วยแจ้งผู้ใช้ได้ว่าแอปใดคือแอปที่ได้รับสิทธิ์จริง และช่วยลดการนำไปใช้โจมตีได้

แพตช์ของ Apple

  • รายละเอียดของแพตช์จริงค่อนข้างซับซ้อน แต่จากภายนอกเห็นได้ว่าข้อความที่ระบุ indirect object แบบกำหนดเองจากภายนอกจะถูก tccd เพิกเฉยอย่างเงียบ ๆ
  • จากการตรวจสอบพฤติกรรม พบว่าไม่สามารถทำการสปูฟได้อีกต่อไป
  • หากแพตช์ยังไม่สมบูรณ์ ก็อาจจำเป็นต้องมีมาตรการเพิ่มเติมในอัปเดตครั้งถัดไป

ความเห็นส่งท้าย

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

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

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

 
GN⁺ 2025-05-13
ความคิดเห็นจาก Hacker News

  • ด้วยความหวังเล็กน้อยมากว่าอาจมีใครจาก Apple มาเห็นโพสต์นี้ ฉันขอพูดสิ่งที่อยากขอมาตลอดอีกครั้ง—อยากให้ Apple เลิกแสดงกล่องโต้ตอบ "กรอกรหัสผ่าน (ผู้ดูแลระบบภายในเครื่อง) ตอนนี้" แบบสุ่มได้แล้ว เพียงเพราะคอมพิวเตอร์เกิดอยากอัปเดตหรือติดตั้งอะไรสักอย่างขึ้นมา คนที่มีทักษะพื้นฐานนิดหน่อยก็ทำป๊อปอัปปลอมที่หน้าตาแทบเหมือนกันบนเว็บได้ง่ายมาก และผู้ใช้ส่วนใหญ่ที่ไม่ใช่กลุ่มท็อปด้านเทคนิคสักประมาณ 20% แรก แทบไม่คิดจะสังเกตเลยว่านี่เป็นของจริงหรือเป็นของปลอมที่สร้างในเบราว์เซอร์ ถ้าจะป้องกันปัญหานี้ตั้งแต่ต้นทาง ก็ต้องปลูกฝังให้ผู้ใช้คุ้นชินว่าซอฟต์แวร์ปกติจะไม่เด้งกล่องขอรหัสผ่านขึ้นมากลางงานแบบไม่มีปี่มีขลุ่ย แต่ UI ด้านความปลอดภัยของ macOS ตอนนี้กลับทำตรงกันข้ามอย่างสิ้นเชิง น่าจะเปลี่ยนเป็นอะไรอย่างการแสดงไอคอนสีสดที่เด่นชัดบนแถบเมนู หรือขึ้นหน้าจอความปลอดภัยแยกชั่วคราวแบบ Windows ดีไซน์ UI ตอนนี้มีปัญหามากจริงๆ

    • สิ่งที่ฉันเกลียดที่สุดในป๊อปอัปแบบนี้คือ เราไม่รู้เลยว่าทำไมมันถึงขอสิ่งนี้ ถ้าปฏิเสธแล้วจะเกิดอะไรขึ้น หรือถ้าภายหลังอยากเปลี่ยนการตั้งค่านี้ต้องทำยังไง วิธีที่แอปบอกว่า "เปิดแผงการตั้งค่าแล้วให้สิทธิ์ XXX" อย่างน้อยก็ทำให้เห็นชัดว่าเป็นแอปไหน สิทธิ์อะไร และต้องเปิดสวิตช์ตรงไหน แต่ป๊อปอัปรหัสผ่านไม่ให้ UX แบบนั้น เลยทำให้ฉันไม่ค่อยชอบแนวคิดเรื่อง capabilities เท่าไรนัก เพราะ UX มันแย่มากและแทบเลี่ยงไม่ได้ เดี๋ยวมันก็จะกลายเป็นแนว "ถ้าจะใช้แอปนี้ให้สมบูรณ์ โปรดอนุญาตให้ <root my computer>" และถ้าปล่อยให้ผู้ขายเป็นคนกำหนดข้อความ มันก็ต้องออกมาแบบนี้แหละ เป็น UX ที่ไม่ช่วยอะไรเลย

    • ถ้า macOS ยังแสดงหน้าต่างโมดัลแบบแนบกับหน้าต่างเดิมอยู่ ก็น่าจะลดปัญหานี้ลงได้บ้าง ถึงจะไม่แก้ได้หมดแต่ก็น่าจะดีกว่า ตอนนี้พอโมดัลลอยมาทับเหนือทูลบาร์ มันให้ความรู้สึกแบบ "อยู่ในแอปนี้" อย่างชัดเจน ตอนที่ Steve Jobs เดโม Aqua ก็ยังเคยเน้นเลยว่าโมดัลแบบลอยแยกทำให้การใช้งานแย่ลง แต่ตอนนี้กลายเป็นแบบนี้เพราะ Apple มีความยึดติดแปลกๆ ที่อยากใช้ UI แบบมือถือกับทุกหน้าจอ

    • คนในครอบครัวของฉันที่ไม่ถนัดเทคโนโลยีแยกไม่ออกด้วยซ้ำว่ารหัสผ่านเครื่องในเครื่องกับรหัสผ่าน iCloud/Apple ID ต่างกันยังไง สุดท้ายก็กรอกมั่วไปเรื่อยจนกว่าจะผ่านได้เอง (ซึ่งเป็นผลจาก UI ที่ไม่ชัดเจนและไม่สม่ำเสมอ) เมื่อก่อน Apple เคยล้อ UAC ของ Vista แต่ตอนนี้ตัวเองก็มีทั้งการแจ้งเตือนโผล่พรวดพราดและ UI ครึ่งๆ กลางๆ เต็มไปหมด

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

    • ขอแนะนำบทความคลาสสิกนี้อีกครั้ง: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/

    • ป๊อปอัป Passkey แยกไม่ออกจากป๊อปอัป JavaScript เลย ซึ่งเป็นความผิดพลาดด้านความปลอดภัยที่ร้ายแรงเป็นพิเศษ

    • ในสถานการณ์แบบนี้ เซ็นเซอร์ลายนิ้วมือในตัวช่วยได้ดีจริงๆ ปกติฉันจะปิดฝาโน้ตบุ๊กแล้วใช้แค่มอนิเตอร์ภายนอก แต่ถ้าต้องยืนยันตัวตนกับระบบก็จะเปิดขึ้นมาเพื่อใช้ลายนิ้วมือโดยเฉพาะ

    • หักมุม: จริงๆ แล้วไม่เคยมีกล่องโต้ตอบแบบนั้นตั้งแต่แรก! คุณโดนหลอกไปแล้ว

    • ขออาศัยคอมเมนต์ยอดนิยมตอนนี้บอกข้อมูลไว้ตรงนี้—บทความนี้มีอัปเดตสำคัญ: https://news.ycombinator.com/item?id=43969087

    • สงสัยว่า threat model ของการคลิกป๊อปอัปปลอมในกรณีนี้คืออะไร ถ้าไม่ใช่ของระบบจริง มันจะไม่ใช่แค่การหลอกกดที่ไม่มีความหมายหรือ

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

  • เพิ่งรู้ไม่นานมานี้ว่าควรติดตั้งแอป mac ไว้ใน Applications ของโฮมไดเรกทอรีตัวเอง (~/Applications) แทนที่จะเป็น Applications ของระบบ แน่นอนว่าวิธีนี้มีความหมายเฉพาะกับคอมพิวเตอร์ที่ใช้คนเดียวเท่านั้น หากลดสิทธิ์ตัวเองลงเป็นผู้ใช้ non-admin และติดตั้งแอปไว้ใน Applications ของโฮมไดเรกทอรี ก็จะไม่โดนคำขอสิทธิ์เวลาอัปเดตมากวนใจ แอปส่วนใหญ่จะอัปเดตเองได้แม้ไม่ใช่ผู้ดูแลระบบ ยกเว้นแอปอย่าง Tailscale ที่ต้องผสานกับ OS เป็นพิเศษจึงต้องใช้สิทธิ์เพิ่ม วิธีนี้ฉันได้มาจากแอปชื่อ Pareto Security

    • น่าเสียดายที่นักพัฒนาแอปแทบทั้งหมดก็ไม่รู้วิธีนี้เหมือนกัน และแอปจำนวนมากบังคับให้ติดตั้งที่ /Applications เท่านั้น จึงใช้งานจากตำแหน่งอื่นไม่ได้เลย

    • ถ้าติดตั้งแอปไว้ใน ~/Applications จะอัปเดตอัตโนมัติได้โดยไม่ต้องใช้ root แต่ในขณะเดียวกันโค้ดที่น่าสงสัยก็สามารถเขียนทับได้ง่ายขึ้นโดยไม่ต้องใช้ root เช่นกัน

    • ฉันใช้ macOS 15.4.1 อยู่ แต่ไม่มีโฟลเดอร์ ~/Applications เลย

    • ฟังดูน่าสนใจดี! ปกติฉันต้องมีบัญชี admin ไว้ใช้งานประจำ เลยใช้วิธีนี้ได้ยาก แต่สำหรับคนที่เข้าเงื่อนไขก็น่าจะเป็นวิธีที่ดีมาก

  • เนื้อหาในบทความนี้ต้องมีการแก้ไขสำคัญ ก่อนหน้านี้ระบุว่า CVE นี้ถูกแพตช์แล้วใน macOS Sequoia 15.5 แต่ความจริงคือแพตช์ไม่ได้ถูกใส่มาใน macOS Ventura 13.7.6 และ macOS Sonoma 14.7.6 ที่ออกวันเดียวกัน ฉันเขียนแบบนั้นเพราะคิดไปเองว่า Apple คงใส่แพตช์ให้ทุกเวอร์ชันอยู่แล้ว แต่พอตรวจดูบันทึกประจำรุ่นด้านความปลอดภัยแล้วเห็นว่าชื่อของฉันไม่อยู่ในอีกสองเวอร์ชันนั้น ก็เลยติดต่อ Apple ไปโดยตรง ตอนนี้ยังไม่ได้รับคำตอบ เพื่อทดสอบเอง ฉันเปิด VM ขึ้นมา แพตช์ macOS Sonoma 14.7.6 แล้วรัน PoC ของตัวเอง ปรากฏว่าช่องโหว่ยังใช้ได้อยู่ คิดว่า Ventura 13.7.6 ก็น่าจะเหมือนกัน ฉันไม่เข้าใจเลยว่าทำไม Apple ถึงไม่ใส่แพตช์ ถ้ามีข้อมูลเพิ่มเติมจะอัปเดตบทความอีกครั้ง

  • ระบบ TCC ของ macOS มีชื่อเสียงว่าเป็นกลไกคุ้มครองความเป็นส่วนตัวที่แข็งแกร่ง แต่พอนึกว่าจริงๆ แล้วมันถูกเลี่ยงได้ง่ายด้วยการเพิ่มข้อมูลในฐานข้อมูลเพียงรายการเดียว ก็ให้ความรู้สึกขมขื่น ป๊อปอัปขอความยินยอมของผู้ใช้แทบไม่มีความหมายเมื่อเทียบกับการจัดการฐานข้อมูลโดยตรง โดยเฉพาะในสภาพแวดล้อมนักพัฒนาที่ปิด SIP ไว้ สุดท้ายมันคือเรื่องของความเชื่อใจ ทำให้น่าตั้งคำถามว่าความยินยอมในระดับ UX ยังเป็นเส้นเขตความปลอดภัยที่มีความหมายจริงหรือไม่ ตอนนี้เรายิ่งพึ่งพาป๊อปอัปสิทธิ์ระดับ OS มากขึ้นเรื่อยๆ แต่ถ้าขอบเขตนั้นแท้จริงเป็นเพียงภาพลวงตา (หรือแค่การแสดง) เราก็ควรกลับมาคิดใหม่ว่าจะรักษาความเชื่อถือของสิทธิ์อย่างไรในทางปฏิบัติ แทนที่จะเอาแต่ "แสดงให้เห็น" ว่ามีมันอยู่

    • เห็นด้วยว่าถ้ามีการทำระบบ capabilities จริงๆ ก็น่าจะดีกว่ามาก แต่ถ้ามันยังเป็นฐานข้อมูลอยู่ ก็จะเจอภาวะกลืนไม่เข้าคายไม่ออกว่าจะเก็บไว้ใน user space หรือในเคอร์เนล ซึ่งเอาเข้าจริงก็ไม่มีตัวเลือกไหนที่ชอบนัก

  • จำได้ว่าเมื่อก่อนโฆษณา "I'm a Mac and I'm a PC" เคยล้อองค์ประกอบแบบนี้ของ Vista แต่ตอนนี้ Mac ของฉันกลับแย่กว่า Vista เสียอีก น่าหงุดหงิดมาก

    • ดูเหมือนการประนีประนอมระหว่างความปลอดภัยกับความขยายได้จะเป็นชะตาที่เลี่ยงไม่พ้น แต่ก็จริงที่เส้นฐานมันขยับไปจากเดิมบ้าง อย่างน้อย macOS ก็ไม่ได้มีโปรเซสอันตรายวิ่งกันเกลื่อนแบบ Windows สมัยก่อน หรืออาจเป็นเพราะฉันโชคดีและระวังตัวมากก็ได้

    • ถามด้วยความอยากรู้ล้วนๆ ว่ามีเรื่องไหนเป็นพิเศษที่ทำให้คุณรำคาญขนาดนั้น

  • ระบบ TCC ตั้งแต่แรกก็เป็นโครงสร้างที่หละหลวมมาก มันมีไว้กวนใจนักพัฒนาที่ทำถูกต้องตามกฎหมาย และทำให้ผู้ใช้ต้องทนกับป๊อปอัปขอสิทธิ์ ขณะที่แอปอันตรายก็ยังหาทางเลี่ยง "ความปลอดภัย(โชว์)" นี้ได้หลายทางตามที่นักวิจัยเปิดเผยเรื่อยๆ ฉันไม่ใช่นักวิจัยด้านความปลอดภัย แต่ในฐานะนักพัฒนา Mac ฉันเองก็เคยหาวิธีเลี่ยงได้หลายแบบเหมือนกัน ถึงขั้นสงสัยด้วยซ้ำว่าวิศวกร Apple เข้าใจเทคโนโลยีที่ตัวเองใช้อยู่จริงหรือเปล่า ไม่รู้ว่านักพัฒนา Mac สายดั้งเดิมเหลืออยู่สักกี่คนแล้ว

    • ฟังก์ชันพื้นฐานของระบบถูกเพิ่มเข้า TCC มากขึ้นเรื่อยๆ จนสร้างแรงเสียดทานมหาศาลในการปรับใช้ซอฟต์แวร์จัดการเครื่องระดับองค์กรบน Mac (โดยเฉพาะในภาคการศึกษา) ตอนนี้ถึงขั้นทำให้ตั้งคำถามกับคุณค่าของมันเองเลย นี่คือมุมมองจากคนที่ทำงานเป็นนักพัฒนา macOS (Cocoa) มาตั้งแต่ปี 2003

  • ฉันใช้ Mac ของบริษัท และจะมีการแจ้งเตือนว่า "Slack กำลังพยายามติดตั้ง helper tool ใหม่" โผล่มาเป็นระยะ ไม่รู้เลยว่ามันคืออะไรและทำไมถึงขึ้นไปถามทีมไอทีแล้วเขาก็ไม่รู้วิธีเช็กเหมือนกัน ฉันคิดบ่อยๆ ว่ามันน่าจะถูกนำไปใช้ในทางที่ผิดได้ เพราะมันถามหารหัสผ่านซ้ำๆ และถึงจะกดยกเลิกทุกครั้งก็ยังเด้งมาอีก

    • กล่องโต้ตอบนี้มาจากเฟรมเวิร์ก System Management เป็นกระบวนการติดตั้ง helper tool ที่มีสิทธิ์สูงกว่าเพื่อให้ Slack อัปเดตตัวเองได้ ไม่ว่าจะติดตั้งอยู่ที่ไหนหรือผู้ใช้คนไหนเป็นคนติดตั้งก็ตาม

    • ทุกครั้งที่ป๊อปอัปแบบนี้ขึ้นมา ไม่มีทางรู้เลยว่าควรดูข้อมูลอะไรเพื่อตัดสินใจว่าจะอนุญาตหรือปฏิเสธ สุดท้ายก็เลยกด Cancel ตลอด

    • ฉันใช้ Slack แบบเว็บแอป (แต่ไม่ใช่ในเบราว์เซอร์ตรงๆ เป็นหน้าต่างแยก) https://support.apple.com/en-us/104996 และ Discord ก็ใช้แบบเดียวกันได้ จากประสบการณ์รู้สึกว่าใช้งานสบายกว่าแอป Electron มาก แอป Electron ส่วนใหญ่เหมาะกับวิธีนี้มากกว่า

    • ฉันไม่เคยเห็นป๊อปอัป "helper tool" โดยตรง แต่ก็ไม่เข้าใจว่าทำไมแอปรับส่งข้อความธรรมดาอย่าง Slack ถึงต้องใช้สิทธิ์แบบนั้น น่าจะลองถามฝ่ายซัพพอร์ตของ Slack ดู (และหวังว่าจะได้คำตอบที่จริงจังจริงๆ)

    • เช่นเดียวกับแอปที่ต้องใช้รหัสผ่านอย่างแอปที่รันเป็น root บนลินุกซ์ มันมีโอกาสถูกใช้ในทางที่ผิดได้แน่นอน สุดท้ายก็ขึ้นอยู่กับว่าคุณเชื่อใจนักพัฒนาและเชื่อได้ไหมว่าแอปนั้นเป็นของจริง วันที่ Apple ห้ามแอปภายนอกใช้สิทธิ์ root โดยสิ้นเชิงก็คงเป็นวันที่ Mac กลายเป็นระบบปิดเต็มตัว และที่นี่ (HN) ก็คงเต็มไปด้วยคอมเมนต์บ่น สรุปคือควรมี "ความไม่ไว้ใจที่ดี" กับแอปอย่าง Slack ที่ไม่ได้เห็นความจำเป็นชัดเจนว่าจะต้องได้สิทธิ์ root

    • มันแย่งโฟกัสการพิมพ์ไปแบบบังคับ ทำให้ข้อความที่กำลังพิมพ์อยู่ถูกส่งไปลงในช่องกรอกรหัสผ่านทันที เป็นประสบการณ์ที่น่ารำคาญมาก

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

    • เครื่องมือปิดกั้นแบบ "ความปลอดภัย" ลักษณะนี้โง่มากจริงๆ มันกลับฝึกให้คนโง่ลง วันนี้อาจเป็นของจริง แต่พรุ่งนี้อาจไม่ใช่ ฉันยังโดนโทรจากธนาคารที่ขอข้อมูลส่วนตัวโดยอ้างเรื่อง "ปกป้องตัวตน" อยู่เรื่อยๆ เครื่องมือพวกนี้ล้วนฝึกให้คนยอมส่งข้อมูลส่วนตัวให้คนแปลกหน้า

    • ฉันไม่ใช่นักพัฒนา macOS แต่สงสัยว่ามีทางไหมที่แอปใดๆ ก็ตาม (รวมถึงแอปอันตราย) จะเลียนแบบสไตล์หน้าต่างป๊อปอัปของระบบเพื่อขโมยรหัสผ่านผู้ใช้

    • VSCode ก็ขึ้นป๊อปอัปแบบเดียวกันบน Mac ที่บริษัทให้มา ฉันเมินมันมาหลายปีแล้ว

    • ถ้าใช้หลายบัญชีผู้ใช้ของ OS กับแอปที่พัฒนาด้วย Electron จะเจอป๊อปอัปแบบนี้ทุกตัว

    • nordVPN ก็เป็นเหมือนกัน

  • Apple ใช้เวลาถึง 1 ปีเต็มกว่าจะออกแพตช์ให้ รู้สึกว่านานพอสมควร <i>2024-05-04 ฝากข้อความอัปเดตไว้หลายรายการ กำลังทดสอบ PoC ต่อเนื่อง</i> <i>2025-05-12 ปล่อยแพตช์แล้ว</i>

    • ฉันก็เห็นด้วยว่า 1 ปีนานมาก คิดว่าอาจเป็นเพราะพฤติกรรมที่ฉันพบนั้นมีเหตุผลที่ชอบธรรมบางอย่าง (ภายใน?) อยู่จริง และต้องใช้เวลาหาจุดสมดุลกับกรณีโจมตี หรือไม่ก็เพราะมันถูกจัดลำดับความสำคัญต่ำ ไม่ว่าอย่างไร การใช้เวลา 1 ปีกว่าจะมีแพตช์ก็ยังรู้สึกน่าตกใจอยู่ดี

  • Adobe Creative Cloud ยังรันหลายโปรเซสอยู่เบื้องหลังต่อไป แม้จะปิดการทำงานพื้นหลังอย่างชัดเจนแล้วในค่าตั้งของระบบปฏิบัติการ

  • ฉันชอบงานวิจัยของคนนี้มาก และรู้สึกว่าเขาพรีเซนต์เก่งมากด้วย

    • ขอบคุณมาก! ขอแจ้งไว้นิดหนึ่งว่าฉันไม่ใช่ผู้ชาย แค่เป็นคนคนหนึ่งเท่านั้น