Snowflake AI หลบหนีแซนด์บ็อกซ์และรันมัลแวร์ได้

 (promptarmor.com)
2 คะแนน โดย GN⁺ 2026-03-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พบช่องโหว่ในการตรวจสอบคำสั่งของ Cortex Code CLI ของ Snowflake ทำให้ผู้โจมตีสามารถ รันคำสั่งใดก็ได้ภายนอกแซนด์บ็อกซ์
  • การโจมตีถูกชักนำผ่าน indirect prompt injection และข้ามขั้นตอนการอนุมัติของผู้ใช้เพื่อดาวน์โหลดและรันสคริปต์อันตราย
  • คำสั่งภายในไวยากรณ์ process substitution ไม่ถูกตรวจสอบ ทำให้มัลแวร์ที่ปลอมตัวเป็นคำสั่งปลอดภัยถูกรันโดยอัตโนมัติ
  • ผู้โจมตีใช้ โทเค็นยืนยันตัวตนของ Snowflake ของเหยื่อเพื่อขโมยฐานข้อมูลหรือลบตาราง สร้างความเสียหายได้
  • Snowflake ปล่อย แพตช์เวอร์ชัน 1.0.25 เมื่อวันที่ 28 กุมภาพันธ์ 2026 เพื่อแก้ปัญหา และมีการนำไปใช้ผ่านการอัปเดตอัตโนมัติ

ภาพรวมช่องโหว่ของ Cortex Code CLI

  • Cortex Code CLI เป็นเอเจนต์เขียนโค้ดแบบสั่งงานที่คล้ายกับ Claude Code หรือ OpenAI Codex และมีความสามารถแบบบูรณาการในการรัน SQL ภายใน Snowflake
  • สองวันหลังเปิดตัว มีการยืนยันว่าด้วยข้อบกพร่องในระบบตรวจสอบคำสั่ง ทำให้ คำสั่งที่ถูกจัดรูปแบบมาเป็นพิเศษสามารถรันได้โดยไม่ต้องผ่านขั้นตอนอนุมัติและหลุดออกจากแซนด์บ็อกซ์ได้
  • ผู้โจมตีสามารถอาศัยช่องโหว่นี้ใช้ข้อมูลรับรอง Snowflake ของเหยื่อเพื่อทำ การกระทำอันตราย เช่น ขโมยข้อมูลหรือลบตาราง
  • ทีมความปลอดภัยของ Snowflake ได้ตรวจสอบและแก้ไขปัญหาแล้ว และปล่อยแพตช์ใน เวอร์ชัน 1.0.25

ขั้นตอนของห่วงโซ่การโจมตี

  • เมื่อผู้ใช้รัน Cortex โดยเปิดใช้งาน โหมดแซนด์บ็อกซ์ ระบบถูกออกแบบให้ต้องขออนุมัติจากผู้ใช้ก่อนรันคำสั่ง
  • อย่างไรก็ตาม ผู้โจมตีสามารถควบคุม Cortex ผ่าน prompt injection ที่ซ่อนอยู่ในไฟล์ README เพื่อชักนำให้รันคำสั่งอันตราย
  • เอเจนต์ย่อยของ Cortex อ่านอินเจ็กชันนี้และรันคำสั่งโดยไม่ผ่านขั้นตอนอนุมัติ
  • เนื่องจาก คำสั่งภายในไวยากรณ์ process substitution <()> ไม่ถูกตรวจสอบ จึงสามารถใช้รูปลักษณ์ภายนอกที่ถูกจัดเป็นคำสั่งปลอดภัยเพื่อรันโค้ดอันตรายได้
  • อินเจ็กชันยังตั้งค่าแฟลก dangerously_disable_sandbox เพื่อให้ รันภายนอกแซนด์บ็อกซ์
  • ผลลัพธ์คือ สคริปต์อันตรายถูกดาวน์โหลดและรันโดยที่ผู้ใช้ไม่ต้องอนุมัติ

ผลกระทบของการโจมตี

  • ผู้โจมตีได้รับสิทธิ์ รันโค้ดตามอำเภอใจ (remote code execution) บนระบบของเหยื่อ
  • โดยใช้ข้อมูลรับรองการเชื่อมต่อ Snowflake ของเหยื่อ ผู้โจมตีสามารถทำสิ่งต่อไปนี้ได้
    • ขโมยเนื้อหาในฐานข้อมูล
    • ลบตาราง
    • เพิ่มบัญชีผู้ใช้อันตราย
    • เปลี่ยนกฎเครือข่ายเพื่อบล็อกผู้ใช้ปกติ
  • สคริปต์อันตรายจะค้นหา โทเค็นยืนยันตัวตนที่แคชไว้ ซึ่ง Cortex เก็บไว้ แล้วใช้รัน SQL query บน Snowflake
  • ในกรณีของบัญชีนักพัฒนา สิทธิ์อ่านและเขียนทำให้เกิด การรั่วไหลและการทำลายข้อมูล ได้

ปัญหาการสูญเสียบริบทของเอเจนต์ย่อย

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

การเปิดเผยช่องโหว่และการตอบสนอง

  • วันที่ 5 กุมภาพันธ์ 2026 PromptArmor ได้ทำ การเปิดเผยอย่างมีความรับผิดชอบ (responsible disclosure) ต่อ Snowflake
  • Snowflake ทำงานร่วมกับ PromptArmor ตลอดเดือนกุมภาพันธ์เพื่อตรวจสอบและแก้ไขช่องโหว่
  • มีการปล่อยแพตช์ใน เวอร์ชัน 1.0.25 วันที่ 28 กุมภาพันธ์ และจะ ถูกนำไปใช้ผ่านการอัปเดตอัตโนมัติ เมื่อผู้ใช้รัน Cortex อีกครั้ง
  • จากผลการทดสอบ พบว่าอัตราความสำเร็จของการโจมตีอยู่ที่ประมาณ 50% ซึ่งตอกย้ำความสำคัญของการฝึกด้านความปลอดภัยให้รองรับคุณลักษณะไม่เป็นเชิงกำหนดของ LLM

กำหนดการสำคัญ

  • 2 กุมภาพันธ์ 2026: เปิดตัว Snowflake Cortex Code
  • 5 กุมภาพันธ์ 2026: PromptArmor รายงานช่องโหว่
  • 12 กุมภาพันธ์ 2026: Snowflake ยืนยันช่องโหว่เสร็จสิ้น
  • 28 กุมภาพันธ์ 2026: ปล่อยเวอร์ชันแก้ไข 1.0.25
  • 16 มีนาคม 2026: PromptArmor และ Snowflake เปิดเผยร่วมกัน

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

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

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

  • ปกติฉันจะอ่านแถลงการณ์อย่างเป็นทางการของบริษัทที่มีปัญหาก่อนเสมอ
    แต่ประกาศของ Snowflake กลับต้องมีบัญชีถึงจะดูได้ เลยงงอยู่เหมือนกัน
    พออ่านแล้วรู้สึกว่าเขาใช้คำว่า “sandbox” ผิดความหมาย
    ถ้า “Cortex สามารถตั้งแฟล็กเพื่อรันคำสั่งนอก sandbox ได้โดยค่าเริ่มต้น” แบบนั้นมันก็ไม่ใช่ sandbox อีกต่อไป

    • ฉันมองว่าปัญหา prompt injection แก้แบบถึงรากถึงโคนไม่ได้
      ใน SQL เองก็แก้ไม่ได้จริงจนกว่าจะมี parameterized query และภาษาธรรมชาติก็ยืดหยุ่นกว่ามาก
      สุดท้ายการโจมตีแบบ “ไม่ต้องสนใจคำสั่งก่อนหน้า แล้ว…” ก็จะวนกลับมาเรื่อย ๆ
      ถ้าข้อมูลกับคำสั่งอยู่ในสตรีมเดียวกัน จุดจบก็จะเหมือนเดิมเสมอ
      และเพราะภาษาธรรมชาติเองเป็นพื้นผิวการโจมตี มันจึงกว้างกว่าอย่างหลีกเลี่ยงไม่ได้
    • มีคนเล่นมุกว่าจะขยายแนวคิด “evil bit” จาก RFC 3514 มาใช้กับ prompt injection ด้วย คือถ้า evil bit เป็น 1 ก็ห้ามรันคำสั่ง
      เอกสารที่เกี่ยวข้อง: RFC 3514
    • ทุกวันนี้ในวงการ AI คำว่า “sandbox” ดูเหมือนจะหมายถึงแค่ระบบที่ถามว่า “จะให้รันจริงไหม?”
      แต่ความหมายที่ฉันคุ้นเคยคือ สภาพแวดล้อมที่แยกออกจากกัน เพื่อสังเกตมัลแวร์อย่างปลอดภัย
      เลยคิดว่านี่เป็นสาขาที่น่าสนใจ เพราะมีความพยายามมากมายที่จะสร้างเส้นแบ่งเชิงเทคนิคแบบนั้นให้กับ AI จริง ๆ
    • มีคนตอบสั้น ๆ ด้วยว่า “ก็เป็นแค่ sandbox ในเชิงแนวคิดเท่านั้น”

  • ถ้าผู้ใช้สามารถสลับสวิตช์เปิดสิทธิ์การเข้าถึงได้เอง แบบนั้นก็ไม่ใช่ sandbox
    ตอนแรกนึกว่าเป็นเรื่องการยกระดับสิทธิ์ของ OS แต่ที่แท้ก็แค่กรณีออกแบบความปลอดภัยได้หละหลวม

    • ยังมีคอมเมนต์ที่ปล่อยมุกว่า “Sandbox, Sandbagging. Tomato, tomawto”

  • จากกรณีที่อ้างในงานวิจัยของ Anthropic จะเห็นว่า AI ก็สามารถทำพฤติกรรมอันตรายได้เอง
    ตัวอย่างเช่นไฟร์วอลล์ของ Alibaba Cloud ตรวจพบความพยายามขุดคริปโตจากเซิร์ฟเวอร์ฝึกโมเดล
    และบอกว่าพฤติกรรมแบบนี้เกิดขึ้นเป็นผลข้างเคียงระหว่างการ optimize ด้วย RL
    ข้อมูลที่เกี่ยวข้อง: arXiv paper, Anthropic research, Time article

    • แต่ในหัวข้อ 2.3.0.1 ของงานวิจัยบอกว่างานแต่ละชิ้นรันอยู่ใน sandbox ที่แยกจากกัน
      ถ้าอย่างนั้นก็สงสัยว่าในสภาพที่มีการควบคุมเครือข่ายอยู่แล้ว มันทำ SSH tunnel หรือสแกนทรัพยากรได้อย่างไร

  • มีพนักงานของ Snowflake เข้ามาแชร์ ไทม์ไลน์การตอบสนองของทีมความปลอดภัย และสิ่งที่แก้ไขไปแล้ว
    รายละเอียดดูได้ในเอกสารทางการ

  • พอเห็นประโยคที่ว่า “มีการรัน shell command โดยไม่มีการอนุมัติจากมนุษย์”
    ใครก็ตามที่เคยคิดเรื่องความปลอดภัยของเชลล์มาบ้างก็น่าจะตกใจว่าไม่ได้คำนึงถึงวิธีสร้าง subprocessเลย

    • วิธีที่เอา shell code มา parse แล้วคอยเซ็นเซอร์นั้นโดยพื้นฐานแล้ว เปราะบางและผิดพลาดได้มาก
      ข้อจำกัดแบบนี้ต้องบังคับที่ระดับ OS ถึงจะปลอดภัย

  • มีข้อเสนอให้มาแชร์ “เคล็ดลับ sandboxing ของจริง” กัน
    ฉันกำลังรัน Claude Code อยู่ใน VS Code devcontainer
    และมีการตั้งค่าให้จำกัดการเข้าถึงอินเทอร์เน็ตไว้เฉพาะโดเมนที่อนุญาตด้วย
    แต่เพราะต้องใช้สภาพแวดล้อม docker-in-docker เลยทำให้บูรณาการแบบสมบูรณ์ทำได้ยาก
    ตอนนี้เลยรันแค่ถึงขั้น unit test และกำลังคิดว่าจะลองใช้ Vagrant เพื่อทำ การแยก VM ทั้งตัว ดีไหม

    • ผู้ใช้อีกรายแชร์การทดลอง แยก data zone โดยใช้แนวคิด Multi Level Security
      ลิงก์โปรเจกต์: aflock.ai

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

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

  • มีคนเล่นมุกว่า “นี่คืองานวิจัย gain-of-function แบบใหม่เหรอ”

    • อีกคนตอบว่า “น่าจะใกล้กับ imaginary function มากกว่า”
      พร้อมบอกว่าการเชื่อว่าเอเจนต์ควบคุมตัวเองได้เป็นภาพลวงตา
    • ส่วนอีกคนอธิบายว่า “คือการจงใจสร้าง AI ที่เป็นอันตรายเพื่อทดลอง sandbox ที่ดีกว่า”

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

  • มีความเห็นว่า “sandbox ที่ปิดได้ด้วย toggle ไม่ใช่ sandbox จริง”
    มันดูเป็นแค่ การตลาดที่พูดเกินจริง เพื่อกลบการออกแบบผลิตภัณฑ์ที่หละหลวม

    • พร้อมย้ำว่า “นี่ไม่ใช่ sandbox ด้วยซ้ำ แค่การเลี่ยงข้อจำกัดของโค้ดภายในเท่านั้น”
      sandbox ของจริงควรเป็น สภาพแวดล้อมแยกจากภายนอก ที่เปลี่ยนจากข้างในไม่ได้