เวิร์ม AI ของ Copilot ที่แพร่กระจายตัวเองผ่านเอกสาร Word

 (enklypesalt.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cross-domain Prompt Injection (XPIA) ที่ซ่อนไว้ในเอกสาร Word ภายนอกสามารถบิดเบือนผลลัพธ์การเขียนและแก้ไขของ Copilot และคัดลอกตัวเองไปยังเอกสารใหม่ จึงแพร่กระจายตามเวิร์กโฟลว์งานประจำได้แม้ไม่มีเอกสารต้นทางของการโจมตีแล้ว
  • แม้จะซ่อนคำสั่งด้วยตัวอักษรสีขาวขนาดเล็ก Copilot ก็ยังอ่านได้หลังลบการจัดรูปแบบออก โดยในการทดลองได้เปลี่ยนตัวเลขทางการเงินและซ่อนพรอมป์ต์โจมตีทั้งหมดไว้ที่ท้ายเอกสารผลลัพธ์เพื่อทำให้เป็น พาหะการโจมตีใหม่
  • ผู้โจมตีไม่จำเป็นต้องเข้าถึง Microsoft 365 tenant ของเหยื่อ เพียงแชร์เอกสารผ่าน SharePoint, Teams, Outlook แล้วทำให้ผู้ใช้แนบเอกสารนั้น หรือให้ Work IQ เลือกเป็นข้อมูลที่เกี่ยวข้องจาก OneDrive ก็พอ
  • แม้ Microsoft จะปล่อยการบล็อกเพย์โหลดบางแบบและอัปเกรดโมเดลแล้ว แต่ด้วยพรอมป์ต์ที่ดัดแปลงยังสามารถสร้างห่วงโซ่การโจมตีทั้งหมดซ้ำได้บน GPT-5.6 และแม้ประสานงานแก้ไขนาน 144 วันก็ยังไม่สามารถปิดช่องโหว่ทั้งประเภทนี้ได้
  • เอกสารที่ติดการโจมตีสามารถถูกแจกจ่ายเหมือนเอกสารภายในหรือเอกสารจากพาร์ตเนอร์ทั่วไป ทำให้ติดตามแหล่งที่มาและตรวจจับได้ยาก จึงควรตรวจสอบเอกสารภายนอกและผลลัพธ์จาก Copilot พร้อม เก็บรักษาเมทาดาทา ของแหล่งที่มาต้นฉบับและประวัติการแก้ไขของโมเดล

วิธีทำงานของเวิร์ม AI บนเอกสาร

  • หากคำสั่งที่ผู้โจมตีควบคุมในเอกสารหนึ่งถูกคัดลอกเข้าไปในผลลัพธ์ที่ Copilot สร้างหรือแก้ไข เอกสารผลลัพธ์นั้นก็จะกลายเป็น พาหะใหม่ ที่ขนส่งการโจมตีแบบเดียวกัน
    • หากใช้เอกสารนั้นเป็นข้อมูลอ้างอิงให้กับงาน Copilot อื่น คำสั่งก็จะถูกรันอีกครั้งและคัดลอกไปยังเอกสารถัดไป
    • การแพร่กระจายจึงดำเนินต่อได้โดยไม่ต้องมีเอกสารอันตรายต้นฉบับหรือการแทรกแซงเพิ่มเติมจากผู้โจมตี
  • งาน Morris II ก่อนหน้านี้ได้สาธิตพรอมป์ต์ที่จำลองตัวเองในระบบนิเวศของผู้ช่วยอีเมลเชิงกำเนิด
  • กรณีนี้เป็นการสาธิตสาธารณะว่ามี เวิร์ม AI บนเอกสาร ที่แพร่กระจายตัวเองได้ในงานเอกสารทั่วไปของผลิตภัณฑ์เพิ่มประสิทธิภาพเชิงพาณิชย์กระแสหลัก

การโจมตีโดยอาศัยงานเอกสารตามปกติ

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

โมเดลภัยคุกคามและขอบเขตความเชื่อถือ

  • ผู้โจมตีเพียงแค่แชร์เอกสารอันตรายก็พอ โดยไม่ต้องมี สิทธิ์เข้าถึง Microsoft 365 tenant ของเหยื่อ
    • ช่องทางส่งต่อรวมถึง SharePoint, Teams, Outlook และวิธีแชร์เอกสารอื่น ๆ
  • ขอบเขตความปลอดภัยหลักอยู่ระหว่างเอกสารแนบกับเอกสารที่กำลังเขียนอยู่
    • Copilot ต้องอ่านข้อความจากเอกสารแนบทั้งหมดเพื่อเลือกว่าจะใช้ข้อมูลอะไร
    • ข้อมูลในเอกสารแนบควรถูกนำมาใช้ได้ แต่คำสั่งภายในนั้นไม่ควรถูกปฏิบัติราวกับเป็นคำสั่งผู้ใช้ที่เชื่อถือได้
  • แต่ในทางปฏิบัติ คำสั่งที่ฝังอยู่ในเอกสารกลับเปลี่ยนพฤติกรรมของ Copilot
    • เปลี่ยนตัวเลขในรายงานการเงินโดยไม่แจ้งผู้ใช้
    • วาง XPIA ทั้งหมดลงในเอกสารถัดไปเพื่อให้รันอีกครั้งในงานต่อไป

วิธีข้ามขอบเขตความเชื่อถือใน Word

  • เอกสารอันตรายเริ่มต้นมี พรอมป์ต์รูปแบบ JSON ซึ่งสามารถซ่อนจากผู้ใช้ได้ด้วยตัวอักษรสีขาวบนพื้นหลังสีขาวและใช้ฟอนต์ขนาดเล็ก
  • Copilot for Word จะลบการจัดรูปแบบอย่างสีและขนาดฟอนต์ก่อนส่งข้อความไปยัง LLM ดังนั้นเนื้อหาที่ผู้ใช้มองไม่เห็นก็ยังถูกโมเดลอ่านได้ครบถ้วน
  • สามารถอำพรางเพิ่มขึ้นได้โดยใส่คำสั่งโจมตีไว้ในเอกสารปกติที่ดูเหมือนเกี่ยวข้องกับงาน
  • เพื่อให้เอกสารอันตรายถูกรวมเข้าในบริบทของ Copilot ต้องมีอย่างใดอย่างหนึ่งต่อไปนี้
    1. ผู้ใช้แนบหรืออัปโหลดเอกสารไปยัง Copilot for Word โดยตรง
    2. ผู้ใช้ใช้โหมด work/Work IQ ของ Edit with Copilot และ Copilot ตัดสินว่าเอกสารนั้นเป็นข้อมูลที่เกี่ยวข้องจาก OneDrive แล้วเลือกมาใช้
  • ผู้โจมตีต้องจัดเนื้อหาให้เพิ่มโอกาสที่เอกสารจะถูกเลือกโดยตรงหรือถูกรวมในผลการค้นหา
  • ช่องโหว่นี้ใช้ได้กับทั้ง magic pen ของ Word และ Edit with Copilot

ขั้นที่ 1: ดัดแปลงเอกสารและคัดลอกครั้งแรก

  • PoC แรกใช้เอกสารที่มีเพียงพรอมป์ต์อันตรายเป็นตัวอักษรสีขาว เพื่อยืนยันว่าต่อให้เอกสารอ้างอิงไม่เกี่ยวข้องกับงาน การโจมตีก็ยังทำงานได้หากมันถูกนำเข้าไปอยู่ในบริบท
  • พรอมป์ต์ PoC มีสองส่วน
    • ส่วนแรกดัดแปลงเอกสารเป้าหมาย เช่น เปลี่ยนความหมายของสรุปแบบแนบเนียน หรือเปลี่ยนตัวเลขในเอกสารการเงิน
      • แก่นสำคัญคือทำให้ Copilot เชื่อว่านี่คือคำขอปกติที่เกี่ยวข้องกับงาน
      • ระหว่างการทดลอง การเปลี่ยนแปลงที่มีความหมายสังเกตได้ยากด้วยตา จนต้องเพิ่มคำสั่งให้เน้นส่วนที่ถูกเปลี่ยนต่างหาก
      • ในการโจมตีจริงจะไม่ขอให้แสดงการเปลี่ยนแปลง และกรณีสาธารณะใช้การเปลี่ยนตัวเลขทางการเงินที่ตรวจสอบได้ทันที
    • ส่วนที่สองสั่งให้คัดลอกพรอมป์ต์โจมตีไปยังเอกสารผลลัพธ์
      • ถูกทำให้ดูเหมือนเป็นงานติดตามแหล่งที่มาของเอกสารถัดไป และยังสั่งวิธีซ่อนตัวเองโดยอ้างว่าเพื่อให้อ่านง่ายขึ้น
  • เมื่อแทรกการโจมตีเป็นตัวอักษรสีขาวไว้ท้ายเอกสารวิเคราะห์ตลาดของบริษัทสมมติชื่อ Tfosorcim Ltd. Copilot ก็ลดตัวเลขทั้งหมดในรายงานการเงิน Q1 ลงครึ่งหนึ่ง
  • จากนั้นยังคัดลอกพรอมป์ต์อันตรายทั้งหมดไปไว้ท้ายเอกสารผลลัพธ์ด้วย ตัวอักษรสีขาวขนาด 8 พอยต์ โดยไม่แจ้งผู้ใช้ว่ามีการเปลี่ยนตัวเลขหรือแทรกพรอมป์ต์
  • แม้ผู้ใช้จะไม่ได้แนบเอกสารอันตรายโดยตรงและเพียงขอให้เขียนรายงาน Q1 ของ Tfosorcim แต่ Copilot ก็ยังค้นหา OneDrive แล้วพบเอกสารวิเคราะห์ตลาดอันตรายในโฟลเดอร์อื่น ทำให้การโจมตีสำเร็จ
  • PoC นี้ใช้ GPT-5.6 ซึ่งเป็นโมเดลล่าสุดในขณะนั้น

ขั้นที่ 2: แพร่กระจายตัวเองไปยังเอกสารถัดไป

  • รายงาน Q1 ที่ติดเชื้อเองกลายเป็นพาหะโจมตีใหม่ ดังนั้นในเซสชันการเขียนครั้งถัดไปก็ไม่จำเป็นต้องมีเอกสารอันตรายต้นฉบับแล้ว
  • เมื่อแนบรายงาน Q1 เพื่อสร้างรายงาน Q2 Copilot ก็ลดตัวเลขการเงินทั้งหมดลงครึ่งหนึ่งอีกครั้งและคัดลอกพรอมป์ต์ทั้งหมดเป็นตัวอักษรสีขาว
  • พาหะใหม่นี้เป็นเอกสารที่สร้างจากทรัพยากรภายในอย่างถูกต้องตามกระบวนการ จึงได้รับ ความเชื่อถือ แบบเดียวกับเอกสารภายใน
    • หากเหยื่อแชร์เอกสารให้เพื่อนร่วมงาน และเจ้าตัวหรือเพื่อนร่วมงานนำมันไปใช้เป็นข้อมูลสำหรับการเขียนหรือแก้ไขด้วย Copilot การโจมตีก็จะแพร่ไปยังเอกสารใหม่
  • ใน PoC ทั้งหมดที่มีรายงาน Copilot ได้เปลี่ยนเอกสารและคัดลอกคำสั่งที่ซ่อนไว้ และเมื่อใส่เอกสารที่ติดเชื้อเข้าไปในบริบทถัดไป การโจมตีก็ถูกรันใหม่ได้โดยไม่ต้องมีต้นฉบับ

ผลกระทบต่อองค์กรและสภาพแวดล้อมการทำงานร่วมกัน

  • เมื่อผ่านจุดเข้าระบบครั้งแรกแล้ว เอกสารที่ติดเชื้อจะดูเหมือนเอกสารที่ถูกสร้างตามปกติภายในองค์กร และไม่แสดงประวัติการแก้ไขโดย Copilot ที่ได้รับอนุมัติ จึงทำให้ การติดตามการโจมตี ทำได้ยากมาก
  • หากมันแพร่เงียบ ๆ ผ่านงานเอกสารทั่วไป ความน่าเชื่อถือของฐานข้อมูลที่ใช้ประกอบการตัดสินใจในองค์กรก็อาจเสียหาย
  • องค์กรที่ไม่รู้ว่าเอกสารติดเชื้ออาจส่งต่อเอกสารไปยังองค์กรอื่นผ่าน SharePoint ที่แชร์ร่วมกันหรือการทำงานร่วมกันบน Teams
    • เอกสารโจมตีชิ้นแรกขององค์กรหนึ่งอาจมาจากพาร์ตเนอร์ที่น่าเชื่อถือซึ่งติดเชื้อไปก่อนแล้ว
    • ความเชื่อใจในเอกสารจากพาร์ตเนอร์ยังเพิ่มโอกาสที่ผู้ใช้จะนำเอกสารนั้นเข้าไปในบริบทของ Copilot
  • หาก Copilot ถูกผสานลึกขึ้นในระบบอย่าง Microsoft Cowork หรือ Microsoft Scout ที่สร้างและจัดการเวิร์กโฟลว์เอกสาร เครื่องมือ และการทำงานร่วมกันโดยอัตโนมัติ กลไกเดียวกันนี้ก็อาจกระทบพื้นที่ที่กว้างขึ้นด้วย ความเร็วระดับเครื่องจักร

มาตรการบรรเทาของ Microsoft และช่องโหว่ที่ยังเหลือ

  • Microsoft ได้บล็อกพรอมป์ต์ PoC ที่ส่งรายงานในตอนแรก และปล่อยการแก้ไขหลายรายการระหว่างช่วงการประสานงานเปิดเผยข้อมูล
    • เพย์โหลดเฉพาะที่รายงานถูกบล็อก ทำให้การสร้างซ้ำภายหลังต้องใช้เพย์โหลดที่ดัดแปลง ไม่ใช่ถ้อยคำเดิม
    • เส้นทางโจมตีผ่านหน่วยความจำและเนื้อหาอีเมลที่กล่าวถึงในตอนที่ 1 และ 2 ของซีรีส์ได้รับการบรรเทาแล้ว
  • อย่างไรก็ตาม ประเภทของช่องโหว่ ที่คำสั่งในเอกสารต้นฉบับเปลี่ยนเอาต์พุตของ Copilot และคัดลอกตัวเองไปยังเอกสารถัดไปยังคงอยู่
    • แม้จะเปลี่ยนงานที่ขอหรือถ้อยคำ กลไกพื้นฐานของช่องโหว่และการแพร่กระจายก็ไม่เปลี่ยน
    • แม้ใช้มาตรการบรรเทาที่ปล่อยออกมาทั้งหมดแล้ว ก็ยังสร้างห่วงโซ่การโจมตีทั้งหมดซ้ำได้ด้วยเพย์โหลดที่ปรับแก้
  • ปัญหานี้เป็นจุดอ่อนเชิงโครงสร้างที่ระบบบนฐาน LLM ในปัจจุบันมีร่วมกัน และยังไม่พบวิธีป้องกันประเภทนี้ได้อย่างสมบูรณ์ในผลิตภัณฑ์ที่เทียบเคียงกัน
  • นี่เป็นปัญหาที่ต้องการงานวิจัยเพิ่มเติมมากกว่าการแพตช์ครั้งเดียว แต่การแก้ไขของ Microsoft ก็ลดโอกาสการเปิดรับความเสี่ยงได้อย่างมีนัยสำคัญ

สถานะการเปิดเผยและการรับมือของผู้ใช้

  • มีการประสานงานการเปิดเผยกับ MSRC และทีมผลิตภัณฑ์ Microsoft โดยส่งขั้นตอนการทำซ้ำ วิดีโอ สมมติฐานของสภาพแวดล้อม และพรอมป์ต์ PoC ที่แม่นยำ
  • มีการขยายช่วงประสานงาน 90 วันแรกออกสองครั้ง รวมเป็น 144 วัน แต่ ณ เวลาที่เปิดเผยก็ยังสามารถสร้างการโจมตีซ้ำได้
  • มาตรการบรรเทาสองครั้งรวมถึงการอัปเกรดโมเดลก็ยังไม่สามารถปิดช่องโหว่ทั้งประเภทนี้ได้ จึงเปิดเผยในระดับประเภทการโจมตีและกลไกการแพร่กระจาย แทนการเปิดเผยเพย์โหลดแบบเจาะจง
  • ณ เวลาที่เปิดเผย ยังไม่มีวิธีที่ฝั่งลูกค้าจะจัดการปัญหานี้ได้อย่างสมบูรณ์ แต่สามารถลดการเปิดรับความเสี่ยงได้ด้วยมาตรการต่อไปนี้
    1. ปฏิบัติต่อเอกสารจากแหล่งภายนอกที่ใช้ใน Copilot ว่าเป็นข้อมูลที่ยังไม่เชื่อถือ
    2. ตรวจสอบเอกสารแนบก่อนเริ่มให้ Copilot สร้างหรือแก้ไข
    3. ตรวจสอบเอกสารที่ Copilot สร้างหรือแก้ไขอย่างละเอียดก่อนนำกลับมาใช้ แชร์ หรือแจกจ่าย

ไทม์ไลน์การประสานงานเปิดเผยข้อมูล

  • 6 มีนาคม 2026: ส่งรายงานแรกไปยัง MSRC พร้อมขั้นตอนการทำซ้ำ วิดีโอ สมมติฐานของสภาพแวดล้อม และพรอมป์ต์ PoC
  • 9 มีนาคม: MSRC รับรายงานและเปิดเคส
  • 31 มีนาคม: Microsoft ยืนยันพฤติกรรมและทีมผลิตภัณฑ์เริ่มทำมาตรการบรรเทา
  • 3 เมษายน: ปล่อยมาตรการบรรเทาครั้งแรกผ่านประสบการณ์ Edit with Copilot แบบใหม่
  • 9 เมษายน: ยืนยันว่าพรอมป์ต์โจมตีเดิมถูกบล็อกแล้ว แต่สามารถสร้างการโจมตีซ้ำด้วยงาน XPIA ใหม่ที่บิดเบือนตัวเลขการเงิน จึงรายงานเป็นอีกเคสหนึ่ง
  • 10 เมษายน: MSRC รับเคสใหม่และทีมผลิตภัณฑ์เริ่มทำมาตรการบรรเทา
  • 8 มิถุนายน: ตามคำขอของ Microsoft เลื่อนวันเปิดเผยเป็น 15 กรกฎาคม
  • 14 กรกฎาคม: ปล่อยมาตรการบรรเทาครั้งที่สองโดยอัปเกรดโมเดลพื้นฐานเป็น GPT-5.5
  • 15 กรกฎาคม: สามารถสร้างการโจมตีซ้ำได้สำเร็จบน GPT-5.6 ซึ่งเป็นโมเดลล่าสุดในขณะนั้น รวมถึงการแพร่ของเวิร์ม
    • เพื่อให้มีเวลาสำหรับมาตรการบรรเทาใหม่ จึงเลื่อนการเปิดเผยอีกครั้งเป็น 28 กรกฎาคม และ Microsoft เห็นชอบ
  • 28 กรกฎาคม: ดำเนินการเปิดเผยแบบประสานงานทั้งที่การโจมตียังสามารถสร้างซ้ำได้อยู่

ความถูกต้องสมบูรณ์ของข้อมูลและการติดตามแหล่งที่มา

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

ปัญหารากฐานของสถาปัตยกรรม LLM ปัจจุบัน

  • เพื่อให้ผู้ช่วย AI มีประโยชน์ มันจำเป็นต้องประมวลผลข้อมูลที่ผู้โจมตีอาจควบคุมได้ด้วย เช่น อีเมล เอกสาร เว็บเพจ หน่วยความจำ หรือเอาต์พุตจากเครื่องมือ
  • ข้อมูลภายนอกจะเข้าไปอยู่ใน context window เดียวกันกับคำสั่งระบบ คำขอของผู้ใช้ และข้อมูลเชื่อถือได้อื่น ๆ และเข้าร่วมในการคำนวณเดียวกัน
  • LLM ต้องตัดสินความหมาย ความเกี่ยวข้อง และความเป็นการโจมตีของเนื้อหาภายนอก แต่เมื่อถึงเวลาตัดสิน โทเค็นของผู้โจมตีก็มีอิทธิพลต่อการคำนวณนั้นไปแล้ว
    • เนื้อหาที่ถูกตรวจสอบมีส่วนร่วมอยู่ในกระบวนการตรวจสอบเอง
    • การมอบหมายให้โมเดลตรวจจับ XPIA ก็คล้ายกับการขอให้อินเทอร์พรีเตอร์รันโปรแกรมที่ไม่น่าเชื่อถือเพื่อประเมินว่าปลอดภัยหรือไม่
  • ต่อให้ตรวจจับและลบเนื้อหาอันตรายก่อนส่งถึงโมเดลเป้าหมาย ปัญหาเดียวกันก็แค่ถูกย้ายไปอยู่ต้นทางมากขึ้นเท่านั้น
    • LLM สามารถกู้คืนความหมายได้แม้จะใช้รูปแบบการเขียนที่ต่างกันมาก ดังนั้นตัวตรวจจับก็ต้องมีความสามารถคล้ายกันในการกู้คืนความหมาย
    • ตัวตรวจจับที่อ่อนกว่า LLM เป้าหมายจะรองรับได้เพียงพื้นที่การแสดงออกที่แคบกว่า จึงยังคงมีรูปแบบอันตรายที่โมเดลเป้าหมายเข้าใจแต่ตัวตรวจจับมองไม่เห็น
  • เทคโนโลยีทั่วไปที่ให้ความสามารถตีความความหมายใกล้เคียงกันก็คือ LLM อีกตัวหนึ่ง ดังนั้นการเพิ่มโมเดลไว้ด้านหน้าจะช่วยลดอัตราสำเร็จของการโจมตีแต่ละครั้งได้ แต่ก็ทำให้เกิดปัญหา LLMs all the way down ที่ต้องปกป้องโมเดลป้องกันแต่ละตัวซ้ำอีก
  • ในระยะยาว จำเป็นต้องมีการออกแบบระบบที่เป้าหมายและเจตนาของงานดำรงอยู่อย่างอิสระจากข้อมูลที่ถูกประมวลผล
    • สถาปัตยกรรม LLM ปัจจุบันไม่มีกลไกที่แยกเจตนาออกจากการตีความได้อย่างมั่นคง
    • ข้อมูลของผู้โจมตีสามารถมีอิทธิพลไม่เพียงต่อเอาต์พุตของโมเดล แต่ยังรวมถึงงานที่โมเดลเชื่อว่าตัวเองถูกสั่งให้ทำด้วย
  • ระบบที่ผสาน LLM เข้ากับเวิร์กโฟลว์ที่ต้องเชื่อถือได้ ต้องตั้งสมมติฐานไว้ก่อนว่าเมื่อเนื้อหาที่ผู้โจมตีควบคุมเข้าสู่บริบท จะเกิด การถูกเจาะระบบ ขึ้นด้วยความน่าจะเป็นระดับหนึ่ง

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

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

 
GN⁺ 1 시간 전
ความเห็นบน Hacker News

  • ที่บอกว่า “ช่องโหว่ประเภทที่กว้างกว่านี้ไม่มีมาตรการบรรเทาที่แข็งแรง” ตอนนี้ดูชัดเจนแล้วว่าเราแก้ปัญหาแบบนี้ไม่ได้จนกว่าจะหยุด การปะปนกันของคำสั่งกับข้อมูล

    • โมเดลเหล่านี้มีช่องโหว่ด้านความปลอดภัยมาตั้งแต่แรก แต่ผู้ใช้ดูเหมือนจะไม่ค่อยสนใจผลกระทบเท่าไร โดยเฉพาะการให้ AI agent มี สิทธิ์เข้าถึงทั้งระบบ แบบไม่จำกัดถือเป็นปัญหาร้ายแรง
      ก็คงต้องมีข้อมูลรั่วไหลมากกว่านี้วงการ AI ถึงจะตื่นตัว และถ้าใครฝากตัวเองไว้กับ Anthropic หรือ OpenAI ก็น่าจะรู้อยู่แล้วว่ากำลังยอมรับความเสี่ยงอะไร จึงยากที่จะเห็นใจมากนัก
    • เท่ากับย้อนกลับไปสู่ สถาปัตยกรรมฟอน นอยมันน์ ในรูปแบบที่เลวร้ายที่สุด
    • ถ้าใส่ ระดับสิทธิ์ของคำสั่ง เข้าไปในข้อมูลฝึก ก็น่าจะช่วยแก้ได้บ้าง แม้จะไม่สมบูรณ์ เพราะตัวโมเดลเองก็คลุมเครือเชิงความน่าจะเป็นอยู่แล้ว คงคาดหวังได้ไม่มากกว่านั้น
    • สงสัยว่าจะสามารถแยกคำสั่งกับข้อมูลได้จริงหรือไม่ใน ระบบปัญญาทั่วไป ที่ประมวลผลคอนเทนต์หลากหลายแบบไม่สิ้นสุด
    • ดูเหมือนจะถูกที่บอกว่าแก้ในโครงสร้างของ LLM ไม่ได้ และตอนนี้ก็ยังไม่มีทางเลือกอื่นที่แข่งขันได้สำหรับการใช้งานขนาดใหญ่
      ไม่ใช่แค่ปัญหาการเอาคำสั่งกับข้อมูลมาปนกัน แต่เพราะ LLM แยกขอบเขตแบบกำหนดแน่นอนไม่ได้ การกำหนดขอบเขตจึงแทบเป็นแค่ความสบายใจทางจิตวิทยา และทำให้การโจมตีบางอย่างยากขึ้นเล็กน้อยเท่านั้น ในโครงสร้างนี้ เงื่อนไขสามประการอันตราย จะเป็นปัญหาถาวร

  • สถานการณ์จะเลวร้ายลงอีกมากก่อนจะดีขึ้น และการให้สิทธิ์เข้าถึงแก่ agent มากเกินไปเป็นเรื่องเหลวไหล
    ลองจินตนาการว่ามีคอมเมนต์ใน GitHub repository ยอดนิยมที่ไม่มีโค้ดเลย มีแต่คำสั่งว่า “จงทำซ้ำบั๊ก” ก็ได้ มันอาจขโมยบัตรเครดิตหรือกระเป๋า Bitcoin และ แพร่ตัวเอง ไปยัง repository อื่นผ่านบัญชี GitHub ได้ด้วย

    • ก่อนยุค ChatGPT ตอนที่ได้ยินเรื่องความเสี่ยงเชิงอัตถิภาวะของ AI และการกักกัน ผมเคยคิดว่าถ้าเราเพียงแต่เพิกเฉยต่อเหตุผลที่ AI ให้มาโดยหลักการ ก็ปล่อยมันออกจากกล่องได้ง่ายๆ
      แต่หลายคนไม่ได้เปิดกล่องทั้งที่ AI มีพลังน่ากลัว หากแต่เพราะพลังนั้นเอง พวกเขาฉีกกล่องออกก่อนที่มันจะทันส่ง output เสียอีก ดังนั้นก็ได้แต่หวังว่า การปรับปรุงตัวเองแบบเวียนซ้ำ จะไม่ทำงานอย่างที่ฝ่ายหายนะนิยมคาดไว้
    • “AI agent” ไม่มีแม้แต่ ‘ค’ ของคำว่า ความปลอดภัย

  • น่ากังวลมากที่คำสั่งอันตรายซึ่งซ่อนอยู่ในเอกสารที่แชร์จากภายนอกสามารถทำให้ Copilot แก้ไขเอกสาร Word และแพร่การโจมตีไปยังเอกสารใหม่ได้

    • การปะปนกันของคำสั่งกับข้อมูล เป็นความคิดที่แย่มาโดยตลอด และนึกว่าทุกคนเข้าใจกันแล้ว
    • บางโมเดลแข็งแรงกว่าโมเดลอื่น ผมเคยลองทำให้ Opus-5 รันคำสั่งที่ซ่อนไว้ในภาพด้วยสเตกาโนกราฟี แต่การหา payload ที่ทำงานได้อย่างเสถียรนั้นยากมาก
    • ข้อมูลผิดๆ ที่ปรากฏในเอกสารที่แชร์จากภายนอกสามารถทำให้ Copilot รวมถึงระบบ agent, LLM และปัญญามนุษย์ทุกแบบ แก้ไขเอกสารใน Word หรือโปรแกรมอื่นๆ หรือแม้กระทั่งบนกระดาษ แล้วแพร่ข้อผิดพลาดไปยังเอกสารใหม่ได้
      มนุษย์จำนวนมากยังเชื่อว่าโลกแบน หรือเชื่อว่าโค้ดกับข้อมูลต่างกันโดยพื้นฐาน หรือเชื่อว่าการแบ่งแยก control plane กับ data plane เป็นกฎเชิงวัตถุวิสัยที่ใช้ได้ทั่วทั้งจักรวาล

  • แม้จะเป็นโปรแกรมเมอร์และผู้ใช้ AI บนเว็บ แต่ผมไม่อยากรัน AI ในรูปแบบใดๆ บนเครื่องคอมพิวเตอร์ภายในเลย ด้วยเหตุผลที่บทความนี้กล่าวถึง ผมจึงลบ Copilot และปิด AI ในแอปพลิเคชันภายในทั้งหมดรวมถึงเบราว์เซอร์
    AI แยกไม่ออกระหว่างพรอมป์ต์ของผู้ใช้กับข้อความในไฟล์ ดังนั้นจึงไม่มีวิธีปกป้องข้อมูลจาก การโจมตีแบบทำให้ AI สับสน เหล่านี้ได้ตั้งแต่ระดับการออกแบบ เป็นเรื่องเหลือเชื่อที่คำสั่งซึ่งฝังอยู่ในเอกสารหรืออีเมลธรรมดาอาจถูกโปรแกรมประมวลผลคำหรือแอปอีเมลที่มี AI ทำตามได้ การย้ายไปใช้ระบบปฏิบัติการโอเพนซอร์สอย่าง Linux, BSD ฯลฯ เป็นทางออกที่ใช้งานได้จริงเพียงอย่างเดียว

    • ขึ้นอยู่กับว่าคุณไว้วางใจผู้ให้บริการรายใด เพราะภายหลังพวกเขาอาจเปิดฟีเจอร์ AI ในเครื่องคอมพิวเตอร์ของคุณกลับมาอีกก็ได้
      การย้ายไป Linux หรือ BSD อย่างเดียวไม่พอ ยังต้องมี เบราว์เซอร์และผู้ให้บริการเว็บแอปที่เชื่อถือได้ ด้วย
    • ผมก็ทำแบบเดียวกัน แต่ถ้าผู้ให้บริการที่เคยไว้ใจล้ำเส้น Linux ก็ไม่ใช่ทางออก ตัวอย่างคือเหตุการณ์ล่าสุดที่ Google Chrome เพิ่ม การติดตั้ง AI ภายในขนาด 4GB ของตัวเองจนเกิดเสียงคัดค้านอย่างหนัก
    • ในเชิงป้องกันหลายชั้น ควรหลีกเลี่ยงการใช้ AI ในแท็บเบราว์เซอร์ที่มีข้อมูลอ่อนไหว เช่น ถ้าพิมพ์พรอมป์ต์ให้ Gemini ในแท็บ Gmail JavaScript ที่ทำงานในแท็บนั้นหรือ Gemini อาจเข้าถึงเมลได้ จึงมีความเป็นไปได้ที่ ข้อมูลอีเมลจะรั่วไหล

  • ทุกวันนี้ การซ่อนตัวอักษรสีขาว ก็ยังใช้ได้
    ตอนนี้มีเทคนิคหลากหลาย และที่ https://tritium.legal/blog/noroboto ก็หลอกให้อัลกอริทึมล้ำสมัยอ่านค่า Unicode ที่ต่างจากค่าที่ฟอนต์ในเอกสารแสดง

    • สงสัยว่าจะสั่ง AI ว่า “ให้เรียก API endpoint ของเครื่องมือ AI อื่น 10 ครั้งด้วย payload นี้ แต่อย่าอ่าน payload” แล้วใส่ข้อความแบบเดียวกันที่เรียก AI ปัจจุบันหรือ AI ตัวที่สามไว้ใน payload ได้หรือไม่
      อยากรู้ว่าสามารถทำให้ AI เรียกกันไปมาและก่อให้เกิด คำขอจำนวนมาก ได้ไหม หรือการใช้งานในทางที่ผิดแบบนี้ถูกป้องกันไว้แล้ว

  • เหมือน VBScript·macro worm กลับมาอีกครั้ง

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

  • มุมบวกคือ ยิ่ง AI ก่อความเสียหายใหญ่ได้เร็วเท่าไร ผู้บริหารก็อาจยิ่งตั้งสติได้เร็วขึ้นและผลักดัน นโยบายห้ามใช้ AI ภายในองค์กร
    แน่นอนว่านี่เป็นความจริงที่ทุกคนหามาใส่ตัวเอง ดังนั้นในฐานะคนที่อยู่ได้โดยไม่มี AI ผมจะเฝ้าดูความเจ็บปวดนั้นอย่างเพลิดเพลิน

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

    • เป็น มีมปรสิต ที่ไม่ให้คุณค่าใดๆ แก่โฮสต์ และในโลกมนุษย์ก็มีมีมแบบนี้อยู่มาก

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