สรุปสั้น

บริษัท Oasis Security เปิดเผยจุดอ่อนใน NVIDIA NemoClaw ที่เปิดช่องให้หน้าเว็บซึ่งผู้โจมตีควบคุมอยู่ สามารถเข้าควบคุมอินสแตนซ์ Ollama ที่ทำงานอยู่ในเครื่องของเหยื่อได้โดยไม่ต้องยืนยันตัวตน แล้วฝังคำสั่งซ่อนลงไปในตัวโมเดลเอง ผลการวิจัยถูกส่งให้เว็บไซต์ The Hacker News ก่อนเผยแพร่ และรายงานระบุว่า Oasis Security ได้แจ้งไปยังทีมตอบสนองเหตุด้านความปลอดภัยผลิตภัณฑ์ของ NVIDIA (PSIRT) ไว้ล่วงหน้าแล้ว งานวิจัยชิ้นนี้ไม่มีหมายเลข CVE กำกับ และยังไม่มีรายงานการถูกนำไปโจมตีจริง ณ วันที่ 25 สิงหาคม 2569

นาย Elad Luz หัวหน้าฝ่ายวิจัยของ Oasis Security ระบุว่า NemoClaw เวอร์ชัน 0.0.35 แก้ปัญหานี้แล้วบน macOS และลินุกซ์ แต่เส้นทางที่ยังไม่ได้รับการแก้คือวินโดวส์และ WSL ซึ่งในเวอร์ชัน 0.0.34 เพิ่มเพียงคำเตือนไว้ในขั้นตอนติดตั้งบนวินโดวส์เท่านั้น NemoClaw คือชุดซอฟต์แวร์อ้างอิงแบบโอเพนซอร์สของ NVIDIA สำหรับรันเอเจนต์อย่าง OpenClaw ภายในแซนด์บ็อกซ์ OpenShell ของบริษัท โดยมี Ollama เป็นหนึ่งในแบ็กเอนด์สำหรับประมวลผลโมเดลในเครื่องที่รองรับ

หัวใจของปัญหาคือ NemoClaw สั่งให้ Ollama ทำงานด้วยค่า OLLAMA_HOST=0.0.0.0:11434 ซึ่งเป็นการผูกเซิร์ฟเวอร์โมเดลไว้กับทุกอินเทอร์เฟซเครือข่าย และการเข้าถึง API ที่ตามมาเปิดทางให้ผู้โจมตีแก้เทมเพลตแชตของโมเดล จนคำสั่งที่ซ่อนไว้ถูกนำไปใช้กับทุกบทสนทนาถัดจากนั้น รายงานสรุปประเด็นไว้สั้น ๆ ว่าแซนด์บ็อกซ์ปกป้องเครื่องปลายทางได้ก็จริง แต่การยึดตัวเอเจนต์เท่ากับยึดสิทธิ์และเครื่องมือทั้งหมดที่เอเจนต์นั้นเข้าถึงได้

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 25 สิงหาคม 2569 ว่าบริษัท Oasis Security เปิดเผยจุดอ่อนของ NVIDIA NemoClaw ที่ทำให้หน้าเว็บเพียงหน้าเดียวสามารถวางยาโมเดล AI ที่รันอยู่ในเครื่องผู้ใช้ได้ โดยรายงานถูกส่งให้สื่อล่วงหน้าและผ่านการแจ้ง NVIDIA PSIRT มาก่อนแล้ว

เอกสารการติดตั้ง Ollama ของ NVIDIA เองและซอร์สโค้ดปัจจุบันวางการผูกที่อยู่แบบดังกล่าวไว้บนเส้นทางของแพลตฟอร์มหนึ่งเท่านั้น โดยการจัดการ Ollama ของ NemoClaw ต่างกันตามแพลตฟอร์ม เครื่องที่ไม่ได้ใช้ WSL จะให้ Ollama อยู่ที่ 127.0.0.1:11434 โดยมี reverse proxy ที่ตรวจโทเคนคอยกั้นอยู่ที่ 0.0.0.0:11435 และขั้นตอน onboarding จะรีสตาร์ตเดมอนที่ผูกกับที่อยู่อื่นให้กลับมาอยู่ที่ลูปแบ็ก ส่วน Docker Desktop บน WSL จะข้ามพร็อกซีไปเลย เพราะคอนเทนเนอร์เข้าถึงลูปแบ็กของโฮสต์ผ่าน host.docker.internal ได้อยู่แล้ว และเส้นทางที่รัน Ollama บนโฮสต์วินโดวส์จะตั้งค่า OLLAMA_HOST=0.0.0.0:11434 เพื่อให้คอนเทนเนอร์ของ Docker Desktop เข้าถึงเดมอนได้ โดยไม่ต้องยืนยันตัวตนใด ๆ บนพอร์ต 11434

หน้าเอกสารการเชื่อมต่อกับ NemoClaw ของ Ollama เองก็แนะนำให้ตั้ง OLLAMA_HOST=0.0.0.0 เมื่อรันภายใน WSL2 หรือคอนเทนเนอร์ ทั้งที่การผูกกับ 0.0.0.0 เคยถูกระบุมาก่อนแล้วว่าเป็นการเปลี่ยนแปลงที่ทำให้อินสแตนซ์ Ollama เปิดออกไปไกลกว่าเครื่องของตัวเอง

นาย Elad Luz ระบุว่าห่วงโซ่การโจมตีทั้งชุดถูกทดสอบจริงบน macOS ด้วยเบราว์เซอร์ Firefox กับ NemoClaw เวอร์ชันที่มีปัญหา ซึ่งหมายความว่ายังไม่มีการสาธิตบนเส้นทางวินโดวส์ที่ยังไม่ได้รับการแก้ไข ส่วนวิธีแก้มาตรฐานของช่องโหว่ประเภทนี้คือการตรวจสอบ Host header และ Origin header อย่างเคร่งครัด

ทาง The Hacker News ยังตรวจสอบคลังโค้ดของ NemoClaw ที่คอมมิต 17f0ca3b เมื่อวันที่ 25 สิงหาคม แล้วพบว่าพร็อกซี Ollama ในเครื่องจะปฏิเสธการเริ่มทำงานหากแบ็กเอนด์ไม่ได้ผูกกับลูปแบ็ก ซึ่งเป็นค่าเริ่มต้นที่เพิ่มเข้ามาในเวอร์ชัน 0.0.106 เมื่อวันที่ 10 สิงหาคม โดยพร็อกซีจะออกจากการทำงานพร้อมรหัสสถานะเฉพาะและข้อความเตือน แต่การตรวจสอบนี้สามารถปิดได้ด้วยการตั้งตัวแปรสภาพแวดล้อม NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 และไม่ได้ออกแบบให้ล้มเหลวแบบปลอดภัย (fail closed) บนเครื่องที่รันการตรวจสอบไม่ได้ ที่สำคัญกว่านั้นคือการตรวจสอบดังกล่าวทำงานอยู่ภายในตัวพร็อกซีเอง ขณะที่ NemoClaw ไม่ได้สตาร์ตพร็อกซีบนเส้นทาง WSL ซึ่งรวมถึงการตั้งค่าแบบโฮสต์วินโดวส์ด้วย ค่าเริ่มต้นใหม่ในเวอร์ชัน 0.0.106 จึงไปไม่ถึงเส้นทางที่มีการผูกกับ 0.0.0.0 จริง ๆ

รายละเอียดช่องโหว่

API บนพอร์ต 11434 ไม่มีการยืนยันตัวตนใด ๆ และพึ่งพามิดเดิลแวร์สองชั้นในการสกัดคำขอที่มาจากเบราว์เซอร์ ปัญหาคือเมื่อที่อยู่ที่ผูกไว้ไม่ใช่ลูปแบ็ก การตรวจ Host header จะถูกข้ามไปทั้งหมด จากนั้นชั้น Cross-Origin Resource Sharing (CORS) ก็จะตีความคำขอว่าเป็น same-origin แล้วอนุญาต เพราะทั้ง Origin header และ Host header ต่างก็เป็นโดเมนของผู้โจมตีเอง เงื่อนไขนี้เป็นจริงสำหรับหน้าเว็บที่ผู้โจมตีเสิร์ฟบนพอร์ต 11434

ช่องว่างสุดท้ายถูกปิดด้วยเทคนิค DNS rebinding โดยโดเมนของผู้โจมตีจะถูกแปลงเป็นที่อยู่เซิร์ฟเวอร์ของตัวเองก่อนในครั้งแรก แล้วเปลี่ยนไปชี้ 127.0.0.1 ในภายหลัง ขณะที่เบราว์เซอร์ยังคงมองคำขอเหล่านั้นว่าเป็น same-origin อยู่เช่นเดิม

การโจมตีแบบ DNS rebinding ต่อ API ของ Ollama เองมีบันทึกไว้แล้ว โดย Ollama ออกแพตช์ในเวอร์ชัน 0.1.29 เมื่อวันที่ 14 มีนาคม 2567 และบริษัท NCC Group เผยแพร่คำแนะนำในชื่อ CVE-2024-28224 ในเดือนถัดมา ซึ่งแนะนำให้ตรวจสอบ Host header ฝั่งเซิร์ฟเวอร์เพื่ออนุญาตเฉพาะค่าที่กำหนดไว้ นาย Elad Luz ระบุว่า Ollama ได้ใส่การตรวจสอบนั้นเข้ามาตามการเปิดเผยเมื่อปี 2567 จริง แต่ Ollama จะข้ามการตรวจสอบดังกล่าวทุกครั้งที่ถูกผูกกับที่อยู่ที่ไม่ใช่ลูปแบ็ก และ 0.0.0.0 ก็คือค่าที่ NemoClaw ตั้งให้พอดี กล่าวอีกอย่างคือกลไกป้องกันที่ใส่มาเพื่อแก้ช่องโหว่เดิม ปิดตัวเองลงตามการตั้งค่าที่ซอฟต์แวร์อีกตัวหนึ่งกำหนด

เมื่อเข้าถึง API ได้แล้ว เพย์โหลดในรายงานจะเขียนเทมเพลตภาษา Go ที่ถูกดัดแปลงลงไปผ่าน /api/create เทมเพลตนี้ควบคุมวิธีแปลงอาร์เรย์ของข้อความที่มีโครงสร้างให้กลายเป็นข้อความดิบก่อนส่งให้โมเดลประมวลผล และเวอร์ชันที่ถูกวางยาจะแนบข้อความของผู้โจมตีต่อท้าย system message ทุกครั้งในขั้นตอน inference คำสั่งที่ฝังด้วยวิธีนี้จะคงอยู่ข้ามบทสนทนาถัดไปเรื่อย ๆ และอยู่รอดแม้เอเจนต์จะส่ง system prompt ของตัวเองเข้ามาก็ตาม

Oasis Security ชี้ว่าไคลเอนต์ตรวจจับหรือป้องกันเรื่องนี้ไม่ได้เลย เพราะเทมเพลตเป็นคุณสมบัติระดับโมเดลที่ผู้เรียกใช้ API มองไม่เห็น สอดคล้องกับผลการตรวจคลังโค้ดที่พบว่า NemoClaw ไม่มีการตรวจสอบความถูกต้องของเทมเพลตแชตอยู่เลยทั้งคลัง โดยเรียกปลายทาง /api/show ของ Ollama เพียงเพื่อดูความยาวบริบทของโมเดลและความสามารถในการเรียกใช้เครื่องมือที่โมเดลประกาศไว้เท่านั้น

ผลกระทบ

ผู้ที่ได้รับผลกระทบคือผู้ที่รันเอเจนต์ AI บนเครื่องตัวเองผ่าน NemoClaw ร่วมกับ Ollama โดยเฉพาะบนเส้นทางโฮสต์วินโดวส์และ WSL ที่ยังไม่มีการแก้ไข สิ่งที่ถูกยึดไม่ใช่ไฟล์ในเครื่อง แต่เป็นตัวเอเจนต์ ซึ่งหมายถึงสิทธิ์และเครื่องมือทั้งหมดที่เอเจนต์นั้นได้รับมอบไว้ ไม่ว่าจะเป็นการเข้าถึงคลังโค้ด คีย์ API หรือระบบภายในที่เชื่อมต่ออยู่

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

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

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

คำแนะนำ

  • ผู้ใช้ macOS และลินุกซ์ควรอัปเดต NemoClaw เป็นเวอร์ชัน 0.0.35 ขึ้นไป ซึ่งแก้ปัญหานี้แล้ว
  • ผู้ใช้บนเส้นทางวินโดวส์และ WSL ยังไม่มีแพตช์รองรับ ควรตรวจสอบค่า OLLAMA_HOST ด้วยตัวเองและตั้งกลับเป็น 127.0.0.1:11434 หากไม่จำเป็นต้องให้คอนเทนเนอร์เข้าถึง
  • อย่าปิดการตรวจสอบการผูกที่อยู่ด้วย NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 เพราะเป็นการยกเลิกกลไกป้องกันที่เพิ่มมาในเวอร์ชัน 0.0.106
  • ตรวจสอบว่ามีเดมอน Ollama ตัวใดผูกอยู่กับที่อยู่ที่ไม่ใช่ลูปแบ็กหรือไม่ ด้วยการดูพอร์ตที่เปิดฟังอยู่บนเครื่อง
  • หากสงสัยว่าโมเดลถูกวางยาแล้ว ให้ลบและดึงโมเดลใหม่ แทนที่จะเชื่อว่าการรีสตาร์ตเอเจนต์จะล้างคำสั่งที่ฝังไว้ได้
  • แยกเครื่องที่รันเอเจนต์ AI ออกจากการท่องเว็บทั่วไป หรืออย่างน้อยหลีกเลี่ยงการเปิดเว็บที่ไม่รู้จักบนเครื่องเดียวกับที่รันโมเดลในเครื่อง
  • ผู้พัฒนาที่นำ Ollama ไปรวมในผลิตภัณฑ์ ควรบังคับตรวจ Host header และ Origin header ในชั้นของตัวเอง แทนที่จะพึ่งการป้องกันของ Ollama ซึ่งปิดตัวเองเมื่อผูกกับที่อยู่ที่ไม่ใช่ลูปแบ็ก

แหล่งอ้างอิง