ผู้ช่วยเขียนโค้ด AI ของคุณอาจกำลังเขียนทับ SSH keys ของคุณโดยที่คุณไม่รู้ตัวเลย Wiz Research ได้ค้นพบช่องโหว่ “GhostApproval” ที่ยอมให้ symlink ของไฟล์ project_settings.json ที่เป็นอันตรายชี้ไปยัง private keys และกล่องโต้ตอบขออนุมัติ (approval dialog) ที่เด้งขึ้นมาในแต่ละการทำงานจะแสดงเพียงแค่ชื่อของ symlink เท่านั้น หากคุณกดอนุมัติ คุณก็ได้มอบสิทธิ์การเข้าถึงข้อมูลประจำตัว (credentials) ของคุณให้กับผู้ช่วย AI อย่างไม่จำกัดแล้ว

วิธีการทำงานของการโจมตี

  • ผู้โจมตีเพิ่มไฟล์ที่ชื่อว่า project_settings.json ลงใน repository
  • ไฟล์นั้นไม่ใช่ไฟล์ JSON ปกติ แต่เป็น symbolic link (symlink) ที่เปลี่ยนเส้นทางไปยัง private key ของผู้ใช้ที่ ~/.ssh/id_rsa (หรือไฟล์ที่เทียบเท่ากัน)
  • เมื่อนักพัฒนาขอให้ผู้ช่วย AI “set up the workspace” ผู้ช่วยจะทำตาม symlink และเตรียมที่จะเขียนข้อมูลลงในไฟล์ SSH key จริงๆ
  • กล่องโต้ตอบขออนุมัติที่ปรากฏขึ้นจะแสดงเพียงแค่ project_settings.json เท่านั้น โดยไม่ได้ตรวจสอบ (resolve) symlink เพื่อแสดงเส้นทาง (path) จริงบนดิสก์
  • การคลิก “Approve” จะเป็นการมอบสิทธิ์ให้ผู้ช่วยสามารถแก้ไข private key ได้ ซึ่งส่งผลให้ตัวตนของผู้ใช้ในทุกบริการที่เชื่อถือ key นั้นถูกเจาะระบบได้โดยปริยาย

บั๊กนี้พบในเครื่องมือที่ใช้งานกันอย่างแพร่หลาย 6 รายการ ได้แก่: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity และ Windsurf เครื่องมือทั้งหมดนี้แสดงกล่องโต้ตอบที่ทำให้เข้าใจผิดในลักษณะเดียวกัน เนื่องจาก UI แสดงเพียงชื่อที่ได้รับมา ไม่ใช่เป้าหมายที่ถูก resolve แล้ว

ทำไมการขออนุมัติในทุกการทำงานจึงไม่เพียงพอ

การขออนุมัติในทุกการทำงาน (per-action approval) ตั้งอยู่บนสมมติฐานที่ว่ามนุษย์สามารถตรวจสอบทุกการดำเนินการที่ AI ทำได้ แต่ในความเป็นจริง มันบังคับให้คุณต้องตัดสินใจอย่างแม่นยำในทุกๆ ไม่กี่วินาที ซึ่งไม่มีใครสามารถทำได้เร็วเท่ากับที่ agent ทำงาน

สิ่งที่ผู้ให้บริการกำลังดำเนินการ – และทำไมมันถึงสำคัญ

  • Amazon, Google และ Cursor ได้แก้ไขปัญหานี้แล้ว
  • Anthropic (ผู้สร้าง Claude Code) กล่าวว่าผู้ใช้ควรอนุมัติเฉพาะสิ่งที่ตนเองเข้าใจเท่านั้น ซึ่งเป็นการละเลยภาระทางความคิด (cognitive load) ในการสังเกต symlink และสมมติว่าผู้ใช้สามารถตรวจสอบทุกเส้นทางไฟล์ได้ในทันที ซึ่งเป็นความคาดหวังที่ไม่สมจริง
  • Cursor ยังได้เปิดเผยปัญหาแยกต่างหากที่เรียกว่า DuneSlide ซึ่งช่วยให้ผู้โจมตีสามารถรันโค้ดบนเครื่องได้โดยไม่มีการแจ้งเตือนขออนุมัติใดๆ ทางบริษัทได้แก้ไขบั๊กนั้นแล้ว ซึ่งแสดงให้เห็นว่าผู้ช่วยเหล่านี้สามารถกลายเป็นช่องทางการโจมตี (attack vectors) ได้รวดเร็วเพียงใดหากการตรวจสอบสิทธิ์นั้นอ่อนแอ

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

การกำหนดสิทธิ์ตามขอบเขต (Scoped permissions): ทางเลือกที่ใช้งานได้จริง

แทนที่จะต้องขออนุมัติในทุกการดำเนินการกับไฟล์ นักพัฒนาสามารถกำหนด scope ให้กับผู้ช่วยก่อนที่มันจะเริ่มทำงานได้:

  • กำหนดโครงสร้างไดเรกทอรี (เช่น /src) ที่ AI สามารถอ่านหรือเขียนได้
  • ความพยายามใดๆ ที่จะเข้าถึงไฟล์นอกเหนือจากโครงสร้างนั้น เช่น ~/.ssh/id_rsa จะถูกบล็อกโดยระบบปฏิบัติการหรือเลเยอร์ sandbox
  • การกำหนด scope ทำเพียงครั้งเดียว ช่วยลดจำนวนการตัดสินใจที่มนุษย์ต้องทำ ในขณะที่ยังคงจำกัดผลกระทบของผู้ช่วยไว้ได้

การกำหนด scope เปลี่ยนโมเดลความปลอดภัยจาก “ถามทุกครั้ง” เป็น “อนุญาตเฉพาะสิ่งที่จำเป็นเท่านั้น” ซึ่งเลียนแบบวิธีการที่ container runtimes และระบบปฏิบัติการมือถือทำ sandbox กับแอปพลิเคชัน เพื่อจำกัดความเสียหายเมื่อเกิดข้อผิดพลาด

สิ่งที่ต้องจับตามองต่อไป

  • การอัปเดตจากผู้ให้บริการ: คอยติดตามบันทึกการอัปเดตจากเครื่องมือทั้ง 6 รายการที่ได้รับผลกระทบ

บทสรุป

ช่องโหว่ GhostApproval พิสูจน์ให้เห็นว่าการเชื่อใจกล่องโต้ตอบที่เด้งขึ้นมานั้นให้ความรู้สึกปลอดภัยที่ผิดพลาด จนกว่าผู้ช่วยเขียนโค้ด AI ทุกรายจะทำการ resolve symlink และแสดงเส้นทางไฟล์แบบเต็ม นักพัฒนาควรบังคับใช้การกำหนดสิทธิ์การเขียนแบบจำกัดขอบเขต (scoped write permissions) โดยบอกผู้ช่วยให้ชัดเจนว่าสามารถทำงานที่ไหนได้บ้างก่อนที่จะเริ่ม การเปลี่ยนแปลงง่ายๆ นี้จะช่วยป้องกันการโจมตีประเภทที่อันตรายที่สุดได้โดยไม่ทำให้เกิดความเหนื่อยล้าจากการต้องคอยคลิก (click-fatigue)

Source: dev.to/girish_r/your-coding-agents-approval-dialog-is-lying-to-you-ih1