นักวิจัยความปลอดภัยของ Snyk เผยแพร่แพ็กเกจ NPM อันตรายที่มุ่งเป้าไปยัง Cursor.com

 (sourcecodered.com)
1 คะแนน โดย GN⁺ 2025-01-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แพ็กเกจหลายรายการบน npm มี สคริปต์ติดตั้งที่ดูเหมือนมุ่งเป้าไปยัง Cursor.com และเมื่อมีการติดตั้งจะส่งข้อมูลระบบไปยังเว็บเซอร์วิสภายนอก
  • ผู้เผยแพร่คือผู้ใช้ npm ชื่อ sn4k-s3c และใช้ชื่อที่ชวนให้นึกถึงแพ็กเกจภายในของ Cursor เช่น cursor-retreival, cursor-always-local, cursor-shadow-workspace
  • เอาต์พุต env ที่แพ็กเกจดึงไปอาจมีตัวแปรสภาพแวดล้อมที่อ่อนไหว เช่น คีย์ AWS, โทเค็น npm, ข้อมูลยืนยันตัวตน GitHub ทำให้ขอบเขตความเสียหายอาจขยายใหญ่ขึ้น
  • OpenSSF package analysis scanner ระบุว่าแพ็กเกจเหล่านี้เป็นอันตราย และ OSV สร้างคำแนะนำ 3 รายการคือ MAL-2025-27, MAL-2025-28, MAL-2025-29
  • ในเมทาดาทาของ npm อีเมล snyk.io ของ Snyk Security Labs ปรากฏเป็นผู้เผยแพร่ และต่อมานักวิจัยของ Snyk ได้ถอดแพ็กเกจออก ก่อนที่ Snyk จะตอบสนองผ่านบล็อก

แพ็กเกจ npm ที่ดูเหมือนมุ่งเป้าไปยัง Cursor

  • ระหว่างกระบวนการตรวจจับแพ็กเกจอันตรายของ SourceCodeRed พบแพ็กเกจหลายรายการที่ถูกอัปโหลดขึ้น npm
  • ชื่อแพ็กเกจอยู่ในรูปแบบที่ชวนให้นึกถึงแพ็กเกจภายในที่เกี่ยวข้องกับ Cursor
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • ผู้เผยแพร่แสดงเป็นผู้ใช้ npm ชื่อ sn4k-s3c
  • มีการแจ้งว่าสามารถดูรายชื่อแพ็กเกจได้ที่ https://www.npmjs.com/~sn4k-s3c

พฤติกรรมที่เกิดขึ้นเมื่อติดตั้ง

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

ความเป็นไปได้ของ dependency confusion และผลการตรวจจับ

  • แพ็กเกจลักษณะนี้มักพบได้บ่อยในการโจมตีแบบ dependency confusion ที่มุ่งเป้าไปยังบริษัทใดบริษัทหนึ่ง
  • ยังไม่มีการยืนยันว่า Cursor.com มีโปรแกรม bug bounty หรือไม่ รวมถึงยังไม่ทราบบริบทโดยละเอียด
  • SourceCodeRed สงสัยว่า Cursor อาจมีแพ็กเกจ npm แบบ private เช่น cursor-always-local, cursor-retrieval, cursor-shadow-workspace
  • ผู้โจมตีอาจคาดหวังให้พนักงาน Cursor ติดตั้งแพ็กเกจสาธารณะโดยไม่ตั้งใจและส่งข้อมูลออกไป
  • OpenSSF package analysis scanner ระบุว่าแพ็กเกจเหล่านี้เป็นอันตราย และ OSV สร้างคำแนะนำมัลแวร์ 3 รายการ

เมทาดาทาของผู้เผยแพร่

  • ตามเมทาดาทาของแพ็กเกจ npm ผู้เผยแพร่ใช้อีเมลแอดเดรส snyk.io ของทีม Snyk Security Labs
  • มีการระบุว่าเมทาดาทาอีเมลผู้เผยแพร่นี้เป็นส่วนที่ไม่สามารถปลอมแปลงได้
  • ฟิลด์ author ระบุถึงพนักงาน Snyk คนหนึ่งอย่างเจาะจง
  • แม้ฟิลด์ author จะปลอมแปลงได้ แต่เนื่องจากผู้เผยแพร่เป็นอีเมล Snyk ที่ผ่านการยืนยัน จึงมีการเสนอข้อสันนิษฐานว่าแพ็กเกจมาจาก Snyk จริง

การรับมือของผู้ใช้และอัปเดตหลังจากนั้น

  • SourceCodeRed แจ้ง npm แล้ว แต่ระบุว่าในขณะนั้นแพ็กเกจเหล่านี้ยังไม่ถูกทำเครื่องหมายว่าเป็นอันตราย
  • เครื่องมือรักษาความปลอดภัยซัพพลายเชนซอฟต์แวร์จำนวนมากจะบล็อกได้ก็ต่อเมื่อรู้ว่าแพ็กเกจนั้นเป็นอันตราย
  • แนะนำว่าไม่ควร ติดตั้งแพ็กเกจ npm แบบสุ่มสี่สุ่มห้า
  • แพ็กเกจเหล่านี้มีเพียงสองไฟล์คือ package.json และ index.js หรือ main.js ซึ่งถือเป็นหนึ่งในสัญญาณน่าสงสัยได้
  • ตามอัปเดตวันที่ 15 มกราคม 2025 นักวิจัยของ Snyk ได้ถอดแพ็กเกจที่เกี่ยวข้องกับ Cursor ออกในวันถัดจากการเผยแพร่บล็อก
  • วันที่ 14 มกราคม 2025 The Register เผยแพร่บทความที่เกี่ยวข้อง: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • ในวันเดียวกัน Snyk โพสต์คำตอบบนบล็อก และยืนยันในทำนองว่าตนไม่ได้ทำผิด: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

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

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

 
GN⁺ 2025-01-14
ความคิดเห็นบน Hacker News

  • [แก้ไข: ดูจากคำตอบของนักพัฒนา Cursor ด้านล่างแล้ว ดูเหมือนว่า Cursor ไม่ได้อนุมัติ] ฟังดูเหมือนว่าภายใน Cursor มี private NPM registry ที่มีแพ็กเกจเหล่านี้อยู่ และด้วยวิธีการทำงานของ NPM จึงอยู่ในสถานการณ์ที่ผู้โจมตีหลอกให้ไปดึงแพ็กเกจชื่อเดียวกันจาก public registry ได้ง่าย
    บางทีพนักงาน Snyk อาจพบหรือสงสัยว่าบางส่วนของ build ของ Cursor ถูกตั้งค่าผิดแบบนี้ จึงอัปโหลดแพ็กเกจเป็น proof of concept ดูจากคำอธิบายแพ็กเกจที่ว่า “for Cursor” แล้ว ผมนึกว่าเขาถูกจ้างมาเพื่อจุดประสงค์นี้
    ถ้าเป็นแบบนั้นก็ไม่ใช่เรื่องใหญ่โตมาก และถ้าประเด็นหลักคือการแสดงให้เห็น misconfiguration ที่ข้าม private registry ไป นักวิจัยด้านความปลอดภัยก็คงใช้ private NPM registry ใน proof of concept ไม่ได้
    โดยเฉพาะอย่างยิ่ง proxy จำนวนมากจะเลือก public registry แทน private registry หากเวอร์ชันล่าสุดของแพ็กเกจสูงกว่า: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • ผมเป็นนักพัฒนา Cursor การคาดเดานี้สมเหตุสมผล แต่ความจริงต่างออกไปเล็กน้อย แพ็กเกจของ Snyk เป็นเพียงชื่อของ extension ที่เราบันเดิลไว้เท่านั้น และเราไม่ได้แพ็กเกจมันหรืออัปโหลดไปยัง registry ใดๆ
      เราจัดการแบบเดียวกับ VS Code: https://github.com/microsoft/vscode/tree/main/extensions
      เราไม่ได้จ้าง Snyk และหลังจากเห็นเรื่องนี้แล้วได้ติดต่อไป ก็ได้รับคำขอโทษมา ผมยังไม่ได้รับการยืนยันแน่ชัดว่าเขาตั้งใจจะทำอะไร แต่คำอธิบายที่ว่ามีใครบางคนสงสัยเรื่อง ช่องโหว่ dependency confusion นั้นฟังดูเป็นไปได้ อย่างไรก็ตาม การทำให้มันส่ง environment variables จริงๆ จาก public NPM ออกไปนั้น ผมมองว่าค่อนข้างขาดความรับผิดชอบ
    • proof of concept สามารถทำได้โดยไม่ต้องส่งข้อมูลโฮสต์ที่ติดตั้งและ environment variables ทั้งหมดออกไปภายนอก นั่นดูเหมือนจะล้ำเส้นไปแล้ว
    • การอนุญาตให้ใครบางคนเข้าถึงสภาพแวดล้อมทั้งหมดของผม หรือก็คือผลลัพธ์ทั้งหมดของคำสั่ง env น่าจะเป็น ปัญหาใหญ่ สำหรับคนส่วนใหญ่
    • ผมดูแล DevRel & SecRel ที่ Snyk เพิ่งเผยแพร่บทความเพื่อเคลียร์ข่าวลือ และมีข้อมูลเชิงลึกค่อนข้างมากเกี่ยวกับสถานการณ์นี้: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • เรื่องนี้ไม่ควรถูกแก้ใน NPM ไปแล้วหรือ? ผมจำได้ว่านักวิจัยจาก PortSwigger เคยนำเสนอเรื่องนี้ และจำได้ว่าแทบทุกบริษัทในกลุ่ม FAANG อย่าง Apple, Microsoft, Meta ก็มีช่องโหว่ในตอนนั้น

  • น่าสนใจที่ ผู้ร่วมก่อตั้ง Snyk ไปเริ่มบริษัทคู่แข่งของ Cursor
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    หวังว่าจะไม่มีการเล่นสกปรก

    • จากทุกครั้งที่ผมมีปฏิสัมพันธ์กับพวกเขาเป็นไปในทางลบมาก ผมจึงคิดว่ามีความเป็นไปได้ค่อนข้างสูงว่าจะมีการเล่นสกปรก

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

    • ความนิยมของ Vagrant ดูจะลดลงเพราะ Docker container แต่ในฐานะวิธีสร้างสภาพแวดล้อมสำหรับพัฒนา ผมยังชอบ Vagrant มากที่สุด
      ที่ทำงานเมื่อหลายปีก่อนเคยห้ามใช้เว็บเบราว์เซอร์และเครื่องมือพัฒนาบนแล็ปท็อป ถ้าต้องใช้เบราว์เซอร์ก็ต้องใช้ผ่าน Citrix และถ้าต้องเขียนโค้ดก็ต้องใช้ VDI หรือรันเครื่องมือใน VM
      ตอนนั้นวิธีนั้นดูแทบจะบ้าไปแล้ว แต่ผมค่อย ๆ เข้าใจมากขึ้น
    • ปัญหาจริง ๆ คือ ประสิทธิภาพด้านภาพ ของ VM ยังแย่อยู่ดี ถ้ารัน Cinnamon ใน VM การทำให้ GL acceleration ทำงานได้ถูกต้องแทบเป็นไปไม่ได้
      NVIDIA ล็อกความสามารถ GPU virtualization ไว้หลังการ์ดระดับองค์กร ทำให้ต้องพึ่งการแปลงคำสั่งที่ไม่ค่อยได้ผล
      overhead อื่น ๆ ของ VM แทบทั้งหมดพอทนได้ แต่ GUI ที่กระตุกและไม่ตอบสนองส่งผลเสียต่อสรีรศาสตร์มากกว่าที่คิด และแปลกที่มันฉุดประสิทธิภาพด้านอื่นลงไปด้วย
      ถ้าแก้ปัญหานี้ได้แม้แค่กรณี virtualize Linux บน Linux ตัวเลือกที่จะ virtualize ทุกอย่างก็คงเป็นจริงได้มากขึ้นมาก
    • น่ากลัวที่ความเชื่อใจพังทลายมาถึงขนาดนี้ และการที่ระบบปฏิบัติการมีอัปเดตระดับ GB ทุกเดือนก็ไม่ได้ทำให้อุ่นใจเลย ผมชอบแนวคิดการมี VM แยกที่เสถียรสำหรับแต่ละโปรเจกต์ มี เครื่องมือโอเพนซอร์สมาตรฐาน สำหรับเรื่องนี้ไหม?
      รายละเอียดคือกำลังย้ายสภาพแวดล้อมพัฒนา Go และ Zig จาก Mac เก่าไปยัง Asahi Linux บน M1 แต่ก็ติดตั้งแต่การหาตัวแทน TrueCrypt และ Little Snitch เครื่องมือ VM พวกนี้รองรับ VM ที่เข้ารหัสและกฎไฟร์วอลล์ไหม? มีคนพูดถึง Vagrant ที่นี่ และดูเหมือนจะแก้เรื่องการแยกเครือข่ายได้ระดับหนึ่ง แล้วนอกจากนั้นมีอะไรแนะนำอีกไหม?
    • เข้าใจความรู้สึกนะ และผมก็คิดเรื่องนี้มาหลายครั้ง ตอนนี้ผมไม่อยากทำ แต่เหตุผลหลักไม่ใช่เพราะยุ่งยาก
      VM อาจปกป้องผมได้ แต่ไม่ได้ปกป้องผู้ใช้ซอฟต์แวร์ที่ผมสร้าง ผมจะส่งผลิตภัณฑ์ที่ตัวเองต้องใส่ชุดป้องกันถึงจะจับต้องได้ไปให้ลูกค้า แล้วคาดหวังให้พวกเขาใช้อย่างปลอดภัยโดยไม่มีการป้องกันได้อย่างไร?
      สภาพแวดล้อมที่ผมต้องการไม่ใช่แบบนั้น
      ทางออกตอนนี้คือเลือก dependency อย่างเข้มงวดสุด ๆ พูดให้ชัดคือผมคิดว่าไม่ควรเชื่อโปรเจกต์หรือบริษัท แต่ควรเชื่อเฉพาะคนเท่านั้น มันไม่ง่าย แต่ตอนนี้ผมยังไม่เห็นทางเลือกที่ดีกว่านี้
    • ผมพัฒนาหลายโปรเจกต์บน Linux ส่วนใหญ่กังวลว่าเครื่องมือ สคริปต์ build และการทดสอบอาจอ่านข้อมูลอ่อนไหวหรือเผลอทำลายข้อมูล จึงจำกัดการเข้าถึงไฟล์ระหว่างทำงานโปรเจกต์ด้วย Linux namespace และ bubblewrap
      ผมใส่ filesystem bind ไว้ในไฟล์ dot ง่าย ๆ แยกตามโปรเจกต์ และเมื่อเปิดเทอร์มินัลใหม่ระหว่างทำงาน ก็จะแยกสภาพแวดล้อมอัตโนมัติตามไฟล์ dot นั้น ภาระทางความคิดต่ำมากและผสานเข้ากับงานได้แทบไร้รอยต่อ คิดว่านักพัฒนาหลายคนน่าจะมีสคริปต์คล้าย ๆ กัน เคยลองหาโปรเจกต์แบบนี้มาก่อนแต่หาไม่เจอ ไม่รู้ว่าเพราะมันง่ายเกินกว่าจะทำเป็นโปรเจกต์ หรือเพราะไม่รู้ว่าคนอื่นเรียกสิ่งนี้ว่าอะไร ถ้ามีอะไรให้อ้างอิงก็คงดี
      ผมไม่ได้จำกัดการเข้าถึงเครือข่าย เคยทดลองบันทึกทราฟฟิกทั้งหมดและตั้งค่า man-in-the-middle proxy อัตโนมัติ แต่ยังไม่สะดวกพอสำหรับใช้งานทั่วไป แน่นอนว่า attack surface ของเคอร์เนลยังคงอยู่ แต่ความกังวลหลักคือไฟล์ถูกอ่านหรือถูกทำลาย

  • ส่วนที่ไม่เห็นด้วยในบทความคือท่อนที่ว่า “ไม่ควรติดตั้งแพ็กเกจ NPM แบบหลับหูหลับตา และมีสัญญาณให้ดูได้ว่าแพ็กเกจน่าสงสัยหรือไม่ แพ็กเกจเหล่านี้มีแค่สองไฟล์คือ package.json กับ index.js หรือ main.js ซึ่งเป็นหนึ่งในธงบ่งชี้ว่าปกติหรือไม่”
    เรื่องนี้อาจใช้ได้บ้างกับแพ็กเกจระดับบนสุด แต่การตรวจ transitive dependency ทั้งหมดแทบเป็นไปไม่ได้
    ถ้าดึงแพ็กเกจที่มี dependency 400 ตัวมาใช้ จะตรวจให้ดีได้อย่างไรแม้แต่ 10% ของพื้นที่เสี่ยงนั้น? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • คำแนะนำด้านความปลอดภัยที่ควรใช้ในกรณีนั้นต่างออกไป คืออย่าดึงแพ็กเกจที่มี dependency 400 ตัว มาใช้
    • ตรงจุดนี้ทิศทางใหญ่ของ SELinux ถูกต้องแล้ว หากจัดประเภทไฟล์ไว้ล่วงหน้าตามข้อมูลที่มีความอ่อนไหว แล้วปฏิเสธการเข้าถึงตามนั้น ก็แก้ปัญหานี้ได้พอสมควร เช่น ป้องกันไม่ให้การติดตั้ง NPM เข้าถึง id_rsa
    • คอมโพเนนต์ carousel ของ React มันมี dependency เกิน 400 ตัว ได้อย่างไรกัน…
    • บริษัทเราใช้เครื่องมือความปลอดภัยยอดเยี่ยมชื่อ Snyk อยู่ แนะนำให้ลองดูจริง ๆ /s

  • Snyk ยังเป็นบริษัทที่ไม่ได้ rotate public key แต่เปลี่ยนไปเลยโดยไม่แจ้งล่วงหน้าด้วย: https://github.com/snyk/cli/pull/5649
    ถ้าโปรเจกต์ย้ายไปใช้บริการโฮสต์ repository อื่นที่ไม่ใช่ GitHub ก็จะถูกติดป้ายว่า “abandoned” และแม้จะมี release ใหม่บน npm/PyPI ก็ยังคงถูกมองว่าเป็นโปรเจกต์ที่ถูกทิ้งอยู่
    ผมคิดว่าความสามารถของเขาไม่ได้มากเท่าชื่อเสียง
    อีกอย่าง พนักงานขายของ Snyk เคยดูถูกผมทางอีเมลด้วย ดูเหมือนว่าการไม่สนใจซื้อผลิตภัณฑ์ของเขาหมายความว่าผมเป็นนักพัฒนาที่ไร้ความสามารถซึ่งใช้ได้แต่ซอฟต์แวร์เต็มไปด้วยช่องโหว่

    • ไลบรารีที่พัฒนาเสร็จแล้วและต้องการแค่บำรุงรักษาขั้นต่ำก็ถูกหักคะแนนด้วย
      มันดูเหมือนซอฟต์แวร์ที่กลับหัวกลับหางโดยสิ้นเชิง ซึ่งบริษัทต่าง ๆ ซื้อเพราะบริษัทประกันสั่งให้กรอกเช็กลิสต์ด้านความปลอดภัย
    • การติดป้าย “abandoned” นั้นน่าเสียดายเป็นพิเศษ ผมเองก็เพิ่งพยายามออกจาก GitHub อยู่เหมือนกัน และรู้สึกว่า GitHub มีอำนาจควบคุมมากเกินไป
      Codeberg ดูน่าสนใจ และถ้ารับภาระบำรุงรักษาไหว ตัวเลือก self-hosted อย่าง Forejo ก็ดูดี
    • แค่ย้ายไป repository อื่นที่ไม่ใช่ GitHub ก็ถูกถือว่า “abandoned” และถึงจะมี release ใหม่บน npm/PyPI ก็ยังเป็นแบบเดิม นี่เป็นสัญญาณของทีมที่ดีจริง ๆ /s
      ผมไม่ค่อยได้ยินเรื่อง Snyk มากนัก นอกจากประมาณว่าหยิ่งในศักดิ์ศรีสูง แต่นี่เป็นมุมมองที่น่าสนใจทีเดียว
    • คุณน่าจะให้เนื้อหาอีเมลฉบับนั้นในรูปแบบที่ปิดบังข้อมูลอย่างเหมาะสมได้ใช่ไหม?

  • หากไม่มีบริบทเพิ่มเติม เรื่องนี้ก็ดูไม่ดีสำหรับ Snyk เช่นกัน หมายความว่าพนักงานใช้ NPM ทดสอบบริการของบริษัทเองในสภาพแวดล้อมจริง หรือขาด การควบคุมและขั้นตอน เพื่อไม่ให้ใช้ทรัพยากรสาธารณะระหว่างทำการตรวจสอบ Cursor อย่างถูกต้องตามกฎหมาย

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

  • ดูเหมือนเป็น การตรวจสอบแบบ white-hat ของ Snyk เพราะ oastify.com เป็นเซิร์ฟเวอร์เริ่มต้นของ Burp Collaborator จึงน่าจะถูกตรวจพบ
    การทดสอบควรใช้ npm registry ส่วนตัว และการ override ในเครื่องก็ไม่ใช่เรื่องยาก ควรใช้เซิร์ฟเวอร์ Collaborator ของตัวเองด้วย

    • ไม่ใช่ white-hat เพราะมีการดึงข้อมูลออกไปอย่างจริงจัง ถ้าแค่ต้องการพิสูจน์ว่าใช้งานได้ การพิมพ์ console.log ทำให้ npm install ล้มเหลว หรือใช้วิธีที่ไม่ดึง payload ออกไปก็น่าจะเพียงพอแล้ว

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

    • ไม่ใช่ปัญหาเฉพาะของ NPM แต่เป็นปัญหาโดยรวมเรื่อง ความเชื่อถือในไลบรารีของบุคคลที่สาม แม้จะพบได้น้อยกว่ามาก แต่แพลตฟอร์มอย่าง NuGet ก็มี exploit เช่นกัน และ JSR ก็จะมีด้วย ความไม่เปลี่ยนรูปทำให้ปลอดภัยกว่า แต่ไม่ได้ป้องกันการดาวน์โหลดแพ็กเกจอันตรายก่อนที่มันจะถูกเปิดเผย
      กลับกัน กฎระเบียบอย่าง DORA และ NSIS มีแนวโน้มจะบังคับให้มีการ audit แพ็กเกจบุคคลที่สามมากขึ้นเรื่อย ๆ ซึ่งจะบีบให้อุตสาหกรรมสำคัญเปลี่ยนวิธีพัฒนา อีกทั้งในยุค LLM ผมคิดว่าการใช้แพ็กเกจภายนอกจะลดลงมาก ทำไมต้องดึงแพ็กเกจภายนอกมาเพื่อทำอย่างการสร้างสเปก OpenAPI? LLM สามารถเขียน CLI script ที่ต้องการให้ได้ด้วยการตั้งค่าแค่หนึ่งหรือสองชั่วโมง ในทำนองเดียวกัน แม้ไม่ใช้ LLM เพื่อสร้างส่วนที่น่าเบื่อของโค้ดโดยตรงโดยอัตโนมัติ ก็สามารถให้มันสร้างเครื่องมือ CLI ที่ทำงานเหล่านั้นได้ แบบนั้นก็ไม่ต้องพึ่งพาปัจจัยภายนอก และแทบรับประกันได้ว่าเครื่องมือ CLI เหล่านั้นอาจเป็น cowboy code ที่เละเทะ แต่ผลลัพธ์สามารถปรับแต่งเครื่องมือให้ได้รูปแบบที่ต้องการได้
      เมื่อดูภาษาที่ใส่สิ่งจำเป็นเข้าไปในแพ็กเกจมาตรฐานอย่าง Go จะเห็นโลกที่ทำหลายอย่างได้ง่ายมากด้วย standard library เพียงอย่างเดียว

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

    • Snyk เป็นบริษัทที่ก่อตั้งโดยคนจาก Unit 8200 ของกองทัพอิสราเอล
      ต่อให้จ่ายเงินให้ ผมก็คิดว่าคงไม่ติดตั้ง Unit 8200 ผลิตผู้ก่อตั้งออกมาเรื่อย ๆ และสนับสนุนเงินทุน ทำให้รู้สึกเหมือนเป็นโครงสร้างแบบ NSA ที่ยื่นเท้าเข้ามาในประตูแล้ว
    • ได้ผลลัพธ์ที่ดีกว่าด้วย Syft
    • จากประสบการณ์ของผม มี false positive เยอะ

  • Snyk Research Labs มีส่วนร่วมกับชุมชนเป็นประจำผ่านการทดสอบและวิจัยแพ็กเกจซอฟต์แวร์ที่พบได้ทั่วไป งานวิจัย Cursor ครั้งนี้ไม่ได้มีเจตนาร้าย และในแพ็กเกจมีข้อมูลติดต่อของ Snyk Research Labs และนักวิจัยอยู่ด้วย เรากำลังตรวจสอบ dependency confusion ในส่วนขยาย VS Code บางตัวอย่างเฉพาะเจาะจงมาก และแพ็กเกจเหล่านั้นไม่ใช่สิ่งที่นักพัฒนาจะติดตั้งเองโดยตรง
    Snyk ปฏิบัติตามนโยบายการเปิดเผยอย่างรับผิดชอบ ไม่มีใครดึงแพ็กเกจเหล่านี้ไป แต่ถ้ามีใครดึงไป เราก็คงดำเนินการติดตามทันที

    • การหว่านการโจมตีไว้ในพื้นที่สาธารณะแล้วหวังว่าจะโดนเป้าหมาย เป็นสิ่งตรงข้ามกับพฤติกรรมที่รับผิดชอบโดยสิ้นเชิง ส่วนเดียวที่ “ดี” คือถูกจับได้คาที่ก่อนที่คนอื่นจะโดนลูกหลง
      คำตอบแบบนี้ฟังเหมือนจะส่งจดหมายขอโทษไปที่งานศพของคนที่โดนยิง ต่อให้เป็น “เจตนาดี” แต่ถ้าละเมิด credential ของคนคนนั้น เขาก็ถูกละเมิดไปแล้ว และต้องรับมือเหมือนโดนผู้โจมตีที่มีเจตนาร้ายเล่นงานทุกประการ
      เรื่องนี้ใกล้เคียงกับความมุ่งร้ายจนแทบรู้สึกแยกไม่ออก
      นอกจากนี้ ทุกคนควรจำไว้ด้วยว่าผู้มีส่วนได้ส่วนเสียของ Snyk กำลังจะเปิดตัวผลิตภัณฑ์คู่แข่งกับ Cursor อยู่ในขณะนี้ ทำให้การสันนิษฐานว่าเป็นเจตนาดียากขึ้นมาก
    • ดี แล้วทำไมถึงส่ง environment variables ของผู้ใช้กลับบ้าน? การยืนยันช่องโหว่ส่งแค่ค่าจำลองก็เพียงพอแล้ว ไม่จำเป็นต้องเป็นค่าจากสภาพแวดล้อมจริง
    • อย่างดีที่สุดนี่ก็เป็น gray-hat เจตนาอาจดี แต่ทีมนี้สร้างและเผยแพร่ซอฟต์แวร์ที่เข้าถึงและรั่วไหลข้อมูลโดยไม่ได้รับอนุญาต ซึ่งผิดกฎหมายอย่างมาก ควรปรึกษาทีมกฎหมายก่อนโพสต์แบบนี้ในฟอรัมสาธารณะ
    • ฟังดูมีเหตุผลอยู่ แต่ทำไมถึงส่ง environment variables กลับไปด้วย POST? ต่อให้เป็นเจตนาดีทั้งหมด ผมก็ไม่อยากให้แพ็กเกจสุ่ม ๆ มีผลลัพธ์ env ของผม
    • มีความเป็นไปได้ว่าจริง ๆ แล้วเป็น CTO ของ Snyk และคนควรได้เห็นคำตอบอย่างเป็นทางการ จึงขอโหวตขึ้นให้ แต่เรื่องนี้ให้ความรู้สึกไร้ความรับผิดชอบจริง ๆ สามารถทำ proof of concept ได้โดยไม่ต้องขโมย credential ของนักพัฒนาที่ไม่รู้อิโหน่อิเหน่จริง ๆ
      ยิ่งกว่านั้น เมื่อมีผลประโยชน์ทับซ้อนกับผลิตภัณฑ์คู่แข่ง Cursor ก็ควรระมัดระวังมากกว่านี้ ทั้งการตัดสินใจและการตอบสนองแย่มาก