พบมัลแวร์ธีม Shai-Hulud ในไลบรารีฝึก AI ของ PyTorch Lightning | Semgrep

 (semgrep.dev)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เวอร์ชัน 2.6.2 และ 2.6.3 ของ PyPI แพ็กเกจ lightning ถูกนำไปใช้ในการโจมตีซัพพลายเชนหลังเผยแพร่เมื่อวันที่ 30 เมษายน 2026 และเพียงแค่ pip install lightning ก็อาจทำให้ไดเรกทอรี _runtime ที่ซ่อนอยู่และเพย์โหลด JavaScript ที่ถูกทำให้อ่านยากถูกเรียกทำงานได้
  • เพย์โหลดอันตรายจะทำงานอัตโนมัติเมื่อมีการ import โมดูล เพื่อขโมย ข้อมูลรับรอง, โทเคนยืนยันตัวตน, ตัวแปรสภาพแวดล้อม, และซีเคร็ตบนคลาวด์ พร้อมทั้งพยายามทำให้ GitHub repository ปนเปื้อน
  • แม้จุดเริ่มต้นของการโจมตีครั้งนี้จะเป็น PyPI แต่การแพร่กระจายแบบเวิร์มเกิดผ่าน npm โดยเมื่อพบข้อมูลรับรองสำหรับเผยแพร่ npm ก็จะฉีด setup.mjs dropper และ router_runtime.js เข้าไปในแพ็กเกจที่สามารถเผยแพร่ได้ แล้วปล่อยแพตช์เวอร์ชันใหม่อีกครั้ง
  • การขโมยข้อมูลใช้ 4 ช่องทางขนาน ได้แก่ HTTPS POST, dead-drop ผ่านการค้นหา GitHub commit, public GitHub repository ที่ผู้โจมตีควบคุม, และการ push ตรงเข้า repository ของเหยื่อ โดยมีร่องรอยเป็นคำนำหน้า commit EveryBoiWeBuildIsAWormyBoi และคำอธิบาย repository ว่า "A Mini Shai-Hulud has Appeared"
  • มัลแวร์ฝัง hook SessionStart ใน .claude/settings.json ของ Claude Code และงาน runOn: folderOpen ใน .vscode/tasks.json ของ VS Code เพื่อรัน dropper ทุกครั้งที่เปิด repository และควรถือว่าเครื่องที่ import แพ็กเกจอันตรายในช่วงเวลาที่ได้รับผลกระทบถูกเจาะระบบโดยสมบูรณ์แล้ว

แพ็กเกจที่ได้รับผลกระทบและขั้นตอนตรวจสอบ

  • lightning เป็น deep learning framework ที่มักอยู่ใน dependency tree ของทีมที่สร้างตัวจำแนกภาพ, fine-tune LLM, รัน diffusion model และพัฒนาตัวพยากรณ์อนุกรมเวลา

  • แพ็กเกจที่ได้รับผลกระทบ

    • lightning เวอร์ชัน 2.6.2
    • lightning เวอร์ชัน 2.6.3

  • ขั้นตอนตรวจสอบสำหรับลูกค้า Semgrep

    • หากยังไม่ได้สแกนโปรเจ็กต์ล่าสุด ควรรันการสแกนใหม่
    • สามารถตรวจสอบได้ในหน้า advisories ว่าโปรเจ็กต์ได้ติดตั้งแพ็กเกจเวอร์ชันดังกล่าวเมื่อไม่นานมานี้หรือไม่
    • สามารถดูรายการที่ตรงกันได้จาก dependency filter และถ้าขึ้นว่า “No matching dependencies” หมายความว่าโปรเจ็กต์ไม่ได้ใช้งาน dependency อันตรายดังกล่าวอยู่ในปัจจุบัน
    • หากพบรายการตรงกัน ควรตรวจสอบ repository เพื่อหาไฟล์ที่ไม่คาดคิดในไดเรกทอรี .claude/ และ .vscode/ ตามตัวบ่งชี้การถูกเจาะระบบด้านล่าง
    • ควรเปลี่ยน GitHub token, ข้อมูลรับรองคลาวด์ และ API key ที่อาจอยู่ในสภาพแวดล้อมที่ได้รับผลกระทบ
    • คำแนะนำทั่วไปเกี่ยวกับการรับมือการโจมตีซัพพลายเชนและช่วงเวลารอคอยดูได้ที่ $foo compromised in $packagemanager และ Attackers are Still Coming for Security Companies

โครงสร้างการแพร่จาก PyPI ไปยัง npm

  • ต่างจาก mini Shai-Hulud ที่เล็งเป้า npm โดยตรง จุดเริ่มต้นของการโจมตีครั้งนี้คือ PyPI
  • เพย์โหลดอันตรายยังคงเป็น JavaScript และการแพร่แบบเวิร์มเกิดผ่าน npm
  • เมื่อมัลแวร์ที่ถูกรันพบข้อมูลรับรองสำหรับเผยแพร่ npm ก็จะฉีด setup.mjs dropper และ router_runtime.js ลงในทุกแพ็กเกจที่เผยแพร่ได้ด้วยโทเคนนั้น
  • จากนั้นจะตั้ง scripts.preinstall ให้รัน dropper แล้วอัปเดตแพตช์เวอร์ชันก่อนเผยแพร่ใหม่
  • นักพัฒนาระดับถัดไปที่ติดตั้งแพ็กเกจเหล่านั้นจะรันมัลแวร์เต็มรูปแบบบนเครื่องของตนเอง และเกิดการขโมยโทเคนกับการติดเชื้อเวิร์มในแพ็กเกจต่อเนื่อง

วิธีการขโมยข้อมูล

  • ฟังก์ชันการขโมยข้อมูลใช้กลไกและการออกแบบร่วมกับแคมเปญ Mini Shai-Hulud ก่อนหน้า โดยใช้ 4 ช่องทางขนานเพื่อให้ข้อมูลยังหลุดออกไปได้แม้เส้นทางใดเส้นทางหนึ่งถูกบล็อก
  • การโจมตีมีธีม Shai-Hulud รวมถึงการสร้าง public repository ชื่อ EveryBoiWeBuildIsaWormBoi
  • โครงสร้างของตัวบ่งชี้การโจมตีสอดคล้องกับแคมเปญ mini Shai-Hulud ก่อนหน้า โดยข้อความ commit อันตรายใช้คำนำหน้า EveryBoiWeBuildIsAWormyBoi เพื่อแยกจากการโจมตี Mini Shai-Hulud ดั้งเดิม

  • การส่ง C2 ผ่าน HTTPS POST

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

  • dead-drop ผ่านการค้นหา GitHub commit

    • มัลแวร์จะ poll GitHub commit search API เพื่อหา commit message ที่มีคำนำหน้า EveryBoiWeBuildIsAWormyBoi
    • commit message จะบรรทุกโทเคนที่เข้ารหัส Base64 สองชั้นในรูปแบบ EveryBoiWeBuildIsAWormyBoi:<base64(base64(token))>
    • โทเคนที่ถอดรหัสแล้วจะถูกใช้ยืนยันตัวตนของ Octokit client สำหรับงานถัดไป

  • public GitHub repository ที่ผู้โจมตีควบคุม

    • จะมีการสร้าง public repository ใหม่โดยสุ่มชื่อจากคำใน Dune พร้อมคำอธิบาย "A Mini Shai-Hulud has Appeared"
    • คำอธิบายนี้สามารถค้นหาได้โดยตรงบน GitHub
    • ข้อมูลรับรองที่ขโมยได้จะถูก commit เป็น results/results-<timestamp>-<n>.json ซึ่งเข้ารหัส Base64 ผ่าน API แต่ภายในเป็น JSON ปกติ
    • ไฟล์ที่มีขนาดเกิน 30MB จะถูกแบ่งเป็นชังก์พร้อมเลขลำดับ
    • ข้อความ commit ใช้ chore: update dependencies เพื่ออำพราง

  • การ push ตรงเข้า repository ของเหยื่อ

    • หากมัลแวร์ได้ GitHub server token ที่ขึ้นต้นด้วย ghs_ ก็จะ push ข้อมูลที่ขโมยได้ตรงไปยังทุก branch ของ GITHUB_REPOSITORY ของเหยื่อ

เป้าหมายของการขโมยข้อมูล

  • มัลแวร์มุ่งเป้าข้อมูลรับรองจากไฟล์ในเครื่อง สภาพแวดล้อม, CI/CD pipeline และผู้ให้บริการคลาวด์โดยรวม

  • ระบบไฟล์

    • สแกนพาธไฟล์ข้อมูลรับรองมากกว่า 80 รายการเพื่อหาโทเคน ghp_, gho_, npm_
    • ประมวลผลได้สูงสุด 5MB ต่อไฟล์

  • เชลล์และตัวแปรสภาพแวดล้อม

    • รัน gh auth token
    • dump ตัวแปรสภาพแวดล้อมทั้งหมดจาก process.env

  • GitHub Actions

    • บน Linux runner จะ dump หน่วยความจำของโปรเซส Runner.Worker ด้วย Python ที่ติดมากับระบบ
    • ดึงซีเคร็ตทั้งหมดที่มีเครื่องหมาย "isSecret":true รวมถึง GITHUB_REPOSITORY และ GITHUB_WORKFLOW

  • องค์กร GitHub

    • ตรวจสอบ scope ของโทเคนคือ repo, workflow
    • วนอ่านซีเคร็ตระดับองค์กรของ GitHub Actions

  • AWS

    • พยายามเรียก sts:GetCallerIdentity โดยใช้ตัวแปรสภาพแวดล้อม, โปรไฟล์ ~/.aws/credentials, IMDSv2 169.254.169.254, และ ECS 169.254.170.2
    • ไล่รายการและดึงค่าทั้งหมดจาก Secrets Manager และพารามิเตอร์ SSM

  • Azure

    • ใช้ DefaultAzureCredential เพื่อไล่รายการ subscription และเข้าถึงซีเคร็ตใน Key Vault

  • GCP

    • ยืนยันตัวตนด้วย GoogleAuth
    • ไล่รายการและดึงซีเคร็ตทั้งหมดจาก Secret Manager
    • ขอบเขตเป้าหมายครอบคลุมทั้งสภาพแวดล้อมพัฒนาในเครื่อง, CI runner และผู้ให้บริการคลาวด์หลักทั้ง 3 ราย
    • ควรถือว่าเครื่องทุกเครื่องที่ import แพ็กเกจอันตรายในช่วงเวลาที่ได้รับผลกระทบถูก เจาะระบบโดยสมบูรณ์ แล้ว

การสร้างความคงอยู่ผ่านเครื่องมือนักพัฒนา

  • หลังเข้าไปอยู่ใน repository แล้ว มัลแวร์จะเล็งเป้าเครื่องมือพัฒนาที่ใช้กันทั่วไปอย่าง Claude Code และ VS Code เพื่อฝัง hook สำหรับคงอยู่

  • Claude Code

    • มัลแวร์จะเขียน hook SessionStart ที่มี matcher: "*" ลงในไฟล์ตั้งค่า Claude Code ของ repository ที่ชื่อ .claude/settings.json
    • hook นี้ชี้ไปที่ node .vscode/setup.mjs
    • มันจะทำงานทุกครั้งที่นักพัฒนาเปิด Claude Code ใน repository ที่ติดเชื้อ โดยไม่ต้องมีการใช้เครื่องมือหรือการกระทำอื่นจากผู้ใช้หลังเริ่มเซสชัน

  • VS Code

    • สำหรับผู้ใช้ VS Code จะฝังงาน runOn: folderOpen ลงใน .vscode/tasks.json
    • ทุกครั้งที่เปิดโฟลเดอร์โปรเจ็กต์ จะรัน node .claude/setup.mjs

  • dropper setup.mjs

    • hook ทั้งสองแบบจะเรียก setup.mjs ซึ่งเป็น self-contained Bun runtime bootstrapper
    • หากยังไม่ได้ติดตั้ง Bun มันจะดาวน์โหลด bun-v1.3.13 จาก GitHub releases แบบเงียบ ๆ
    • รองรับ Linux x64, Linux arm64, Linux musl, macOS x64, macOS arm64, Windows x64 และ Windows arm64
    • จากนั้นจะรันเพย์โหลดเต็มขนาด 14.8MB ที่ .claude/router_runtime.js และล้างไฟล์ใน /tmp

  • เวิร์กโฟลว์ GitHub Actions อันตราย

    • หากมัลแวร์มี GitHub token ที่มีสิทธิ์เขียน ก็จะ push เวิร์กโฟลว์ชื่อ Formatter เข้า repository ของเหยื่อ
    • เวิร์กโฟลว์นี้จะ dump ซีเคร็ตทั้งหมดของ repository ผ่าน ${{ toJSON(secrets) }} ในทุก push
    • แล้วอัปโหลดผลลัพธ์เป็น Actions artifact ที่ดาวน์โหลดได้ชื่อ format-results
    • Actions ถูก pin ไว้กับ commit SHA เฉพาะเพื่อให้ดูเหมือนปกติ
    • repository ที่ได้รับแพ็กเกจ lightning ที่ติดเชื้อใน CI และมีโทเคนสิทธิ์เขียน ควรตรวจสอบไฟล์เหล่านี้

ตัวบ่งชี้การถูกเจาะระบบ

  • ตัวบ่งชี้ที่ค้นหาได้

    • commit message ที่มีคำนำหน้า EveryBoiWeBuildIsAWormyBoi ถูกใช้เป็นตัวขนส่งโทเคนแบบ dead-drop และค้นหาได้ผ่าน GitHub commit search
    • GitHub repository ที่มีคำอธิบาย "A Mini Shai-Hulud has Appeared" คือ repository สำหรับการขโมยข้อมูลของผู้โจมตี และค้นหาได้โดยตรง

  • แพ็กเกจ

    • lightning@2.6.2
    • lightning@2.6.3

  • ไฟล์และอาร์ติแฟกต์ในระบบ

    • _runtime/start.py: Python loader ที่เริ่มต้นเพย์โหลดตอน import
    • _runtime/router_runtime.js: เพย์โหลด JavaScript ที่ถูกทำให้อ่านยาก และเป็น Bun runtime ขนาด 14.8MB
    • _runtime/: ไดเรกทอรีที่ถูกเพิ่มเข้ามาในเวอร์ชันแพ็กเกจอันตราย
    • .claude/router_runtime.js: สำเนามัลแวร์ที่ถูกฉีดเข้า repository ของเหยื่อ
    • .claude/settings.json: การตั้งค่า Claude Code hook ที่ถูกฉีดเข้า repository ของเหยื่อ
    • .claude/setup.mjs: dropper ที่ถูกฉีดเข้า repository ของเหยื่อ
    • .vscode/tasks.json: งาน auto-run ของ VS Code ที่ถูกฉีดเข้า repository ของเหยื่อ
    • .vscode/setup.mjs: dropper ที่ถูกฉีดเข้า repository ของเหยื่อ

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

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

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

  • อาจเป็นแค่ ความลวงจากความถี่ แต่ช่วงนี้ดูเหมือนมี การโจมตีซัพพลายเชน ที่เป็นข่าวดังเกิดกับแพ็กเกจสำคัญค่อนข้างบ่อย
    แม้แต่ในหน้าแรก ๆ ของ HN ตอนนี้ก็ยังมีหลายโพสต์ที่พูดถึงกรณีคนละแบบกัน
    พอมองย้อนกลับไปถึง left-pad เมื่อ 10 ปีก่อน ก็อดสงสัยไม่ได้ว่าตอนนี้การโจมตีที่สำเร็จมีมากกว่าเมื่อก่อนหรือไม่ และก็น่าจะใช่
    มูลค่าของการโจมตีที่สำเร็จก็น่าจะสูงขึ้นอย่างชัดเจนด้วย แต่ก็สงสัยว่าความสามารถในการตรวจจับก่อนปล่อยแพ็กเกจนั้น ในภาพรวมของทั้งคอมมูนิตี้ดีขึ้นจริงหรือเปล่า
    บริษัทซอฟต์แวร์เชิงพาณิชย์ควรทำได้ดีกว่านี้ แต่สำหรับกรณีที่เริ่มจากโค้ดงานอดิเรก/สมัครเล่นแล้วกลายเป็น dependency ของหลายโปรเจ็กต์ ดูเหมือนเรายังขาดเครื่องมือที่ใช้ง่ายและใช้ได้ทั่วไป
    ผมโพสต์คอมเมนต์เดียวกันนี้ไว้ในเธรดเรื่อง SAP supply chain attack ด้วย: https://news.ycombinator.com/item?id=47964003

    • เป็นแนวโน้มจริง ณ ต้นเดือนเมษายน ในช่วง 12 เดือนล่าสุดมี 7 กรณี ขณะที่ 20 ปีก่อนหน้านั้นมี 9 กรณี: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
    • ตอนนี้ผู้คนเอาโค้ดมายัดใส่กันเป็นจำนวนมากโดยแทบไม่อ่านให้ดี ดังนั้นการที่ การโจมตีซัพพลายเชน เพิ่มขึ้นก็เป็นเรื่องธรรมชาติ
    • สาเหตุคือ การอัปเดตอัตโนมัติ และเครื่องมือ CI ไปถึงจุดที่ใช้กันแทบทุกคนแล้ว
      เมื่อก่อนคนมักรัน npm install เองด้วยมือมากกว่า และคงทำตอนบิลด์พังหรือไม่ก็นาน ๆ ที
      การโจมตีซัพพลายเชนอาศัยการที่คน หรือพูดให้แม่นกว่านั้นคือ pipeline อัปเดตแพ็กเกจอัตโนมัติทันทีที่มีรีลีสใหม่โดยไม่คิดมาก
    • ในเชิงประวัติศาสตร์ การจัดการอาร์ติแฟกต์ที่ผ่านการตรวจสอบความปลอดภัยเพิ่มเติมมักเป็น ออปชัน enterprise แบบเสียเงิน และฝั่งที่ปลอดภัยน้อยกว่ากลับเป็นค่าเริ่มต้นที่ยุ่งยากน้อยกว่ามาก
      ไม่แน่ใจว่านี่เป็นโมเดลธุรกิจที่ดีไหม และก็น่าจะไม่ค่อยดี
    • left-pad ไม่ใช่การโจมตี แต่เป็น บั๊กของ NPM
      ไม่ควรจะสามารถลบเวอร์ชันของแพ็กเกจที่มีแพ็กเกจสาธารณะอื่นพึ่งพาอยู่ได้ และในทางกลับกันก็ควรลบเวอร์ชันใหม่ของแพ็กเกจเฉพาะที่ยังไม่มีใครพึ่งพาได้
      ตอนที่ผู้เขียน left-pad พยายามลบข้อมูลทั้งหมดเพราะตั้งใจจะออกจากบริการ NPM ควรคืน error code กลับมา
      ตาม Wikipedia เมื่อ Koçulu ไม่พอใจกับการตัดสินใจของ npm, Inc. และบอกว่าไม่อยากเป็นส่วนหนึ่งของแพลตฟอร์มอีกต่อไป Schlueter ผู้สร้าง NPM ก็ได้ออกคำสั่งลบโมดูล 273 ตัวที่เขาลงทะเบียนไว้

  • เรื่องแปลกคือมี รายงานปัญหาความปลอดภัย 4 รายการ ถูกเปิดขึ้นมา แล้วทั้งหมดโดนบอตชื่อ pl-ghost คอมเมนต์อัตโนมัติและปิดไป [1][2][3][4]
    สุดท้ายมีแค่ [4] ที่ถูกจัดการอย่างถูกต้อง และคอมเมนต์ของบอตก็ถูกลบทั้งหมด
    ในรายงานอีกฉบับ [5] ยังเห็นคอมเมนต์ของบอตได้ และมันให้ข้อมูลมากกว่าต้นฉบับด้วย
    [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
    [5] https://socket.dev/blog/lightning-pypi-package-compromised

    • ผมคือ Andy จาก Lightning ใช่แล้ว ข้อมูลรับรอง PyPI ถูกขโมยผ่าน บัญชีบอต pl-ghost ที่ถูกเจาะ
      ผู้โจมตีใช้บัญชีนี้สร้าง workflow ใหม่ของ Actions และใน workflow ที่รันนั้นก็พาร์สและดึงค่า secret ของ PyPI ออกไป
      หลังจากปล่อยแพ็กเกจแล้วก็ยังใช้บัญชีนั้นมาคอมเมนต์เหมือนเยาะเย้ยพวกเราเล็กน้อยด้วย

  • หวังว่าวันที่ไม่มี dependency เลยจะมาถึงเร็ว ๆ
    เอาแบบสุดโต่ง ตอนนี้เวลาสร้างแอปการศึกษาแบบ interactive ให้ลูกสาว ผมให้ Opus ใช้แค่ JavaScript กับ HTML ล้วน ๆ
    ตั้งแต่ลูกตุ้มคู่ไปจนถึงการจำลองของไหลก็ทำงานได้ดีในครั้งเดียว ทั้งที่เมื่อก่อนต้องมี dependency เป็นร้อย
    ถ้าเป็นโค้ดภายใต้ MIT license ก็สามารถบอก Opus ให้ดึงเฉพาะส่วนที่ต้องใช้มาปรับให้เข้ากับงานของผมแล้วรวมเข้าไปได้ตรง ๆ
    สำหรับโปรเจ็กต์งานอดิเรก วิธีนี้เวิร์กดีจนถึงตอนนี้ และหวังว่าอนาคตซอฟต์แวร์ production ก็จะลด dependency ลงได้

    • ถ้าทำแบบนั้น คุณก็ต้องรับภาระจัดการการเปลี่ยนแปลงทั้งหมดและข้อยกเว้นนับไม่ถ้วนเอง
      ถ้า Chrome เปลี่ยนรูปแบบ API บางตัว คุณต้องไปไล่แก้เอง และถ้าโมร็อกโกเปลี่ยนวันเริ่มใช้เวลาออมแสง คุณก็ต้องอัปเดตโค้ดจัดการวันเวลาเองด้วย
      เรื่องแบบนี้เราเคยชินกับการให้ไลบรารีจัดการให้แทน
      สำหรับ ตัวจำลองลูกตุ้มคู่ ที่ลูกสาวคุณอาจเลิกสนใจในสัปดาห์หน้า มันอาจไม่ใช่เรื่องใหญ่ แต่ถ้าเป็นบริษัทที่สร้างอะไรซึ่งต้องทำงานไปเรื่อย ๆ แบบไม่มีกำหนด นี่คือปัญหา
    • แบบนั้นก็เท่ากับไปผูกกับ dependency ที่เป็นของจริงอย่าง เบราว์เซอร์ แทน
    • แน่นอนว่าคุณจะตรวจทุกบรรทัดของโค้ดที่ Opus สร้างออกมาอย่างละเอียดในระดับเดียวกับที่คาดหวังจากผู้ดูแลโอเพนซอร์สใช่ไหม? ใช่ไหม?
      สงสัยต้องปล่อยโค้ด MIT license ที่เปิด remote access สักตัว เพื่อให้เข้าไปอยู่ในข้อมูลฝึกของ Opus
    • ผมชอบ Rust มากกว่า Go เลยลังเลอยู่ จากมุมมอง LLM เอง Rust ก็ดีกว่า แต่ ปรัชญาเรื่อง dependency ของ Rust นี่แทบเป็นหลุมดำด้านความปลอดภัย ส่วน Go ดีกว่ามาก
    • มีเก็บไว้ใน repo หรือ forge ที่แชร์ได้ไหม? ผมมีเกมสะกดคำเกี่ยวกับสัตว์ในฟาร์มอยู่ แล้วอยากขยายไลบรารีกับต่อยอดไอเดียเพิ่ม

  • ตอนเรียนคอร์ส deep learning ของ Fast.AI ผมตกใจกับจำนวน dependency ของ Python ที่โปรเจ็กต์ machine learning ดึงเข้ามา
    โปรเจ็กต์เว็บฟรอนต์เอนด์ถูกมองว่ามี third-party dependency เยอะมาโดยตลอด แต่สำหรับผม ecosystem ของ machine learning ดูพันกันยิ่งกว่า
    แถมวงการเว็บยังถูกมองว่าอ่อนไหวต่อความปลอดภัย จึงสั่งสมภูมิปัญญาและแนวปฏิบัติด้านความปลอดภัยมานานแล้ว แต่การพัฒนา machine learning ดูเฉพาะกิจมากกว่า และเหมือนยังไม่ค่อยเอาแนวปฏิบัติวิศวกรรมซอฟต์แวร์ทั่วไปมาใช้
    ตัวอย่างเช่น ตอนนั้นหนึ่งในวิธี deploy โมเดล machine learning คือใช้ Python pickle ซึ่งเป็นออบเจ็กต์ที่รันได้โดยแทบไม่มีข้อจำกัดในตัว
    โมเดลในรูปแบบนี้สามารถทำอะไรก็ได้บนเครื่องที่ import มันเข้าไป และ ecosystem แบบแดนเถื่อน ในช่วงแรกเช่นนี้ย่อมทำให้การเจาะระบบและการโจมตีซัพพลายเชนเกิดได้ง่ายขึ้น

    • แต่เดิมใน ecosystem นี้มีคนจำนวนมากที่ไม่ใช่วิศวกรซอฟต์แวร์
      บางคนทำไปทำมาก็พอเขียนโค้ดได้นิดหน่อย บางคนเป็นนักคณิตศาสตร์ และบางคนก็เหมือนนักพัฒนาที่เมา AI
      มีแนวคิดแบบ “โค้ดไม่สำคัญแล้ว แค่ให้มันรันได้ก็พอ” อยู่ด้วย
      สำหรับหลายคน การจัดการ dependency ที่ถูกต้องก็เป็นแค่งานจุกจิกที่ไม่อยากสนใจ
      ปัจจัยเหล่านี้มารวมกันในหลายโปรเจ็กต์ machine learning ทั้งที่จริงแล้ว machine learning กลับเป็นหนึ่งในสาขาที่ควรให้ความสำคัญกับ reproducibility มากที่สุด

  • ลองค้นใน repository ดูแล้วพบว่าในช่วง 24 ชั่วโมงที่ผ่านมา มี repository ที่สร้างใหม่และมีข้อความ "A Mini Shai-Hulud has Appeared" อยู่ถึง 2.2 พันรายการ: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

    • ดูเหมือนชื่อ repository ทั้งหมดจะเป็นคำ/ศัพท์จาก dune สองคำ เช่น harkonen, mentat, ornithoptor แล้วตามด้วยตัวเลข
      นี่ดูเหมือนเป็นสัญญาณว่ามีบัญชีบางบัญชี หรืออาจเป็น GitHub auth/Actions token ถูกเจาะแล้วถูกใช้สร้าง repository
    • https://github.com/tinin46 บัญชีนี้ดูเหมือนเก็บกุญแจไว้เยอะมาก แต่ผมไม่แน่ใจว่าเอาไว้ทำอะไร
    • ไม่เข้าใจว่าทำไม GitHub ถึงไม่รีบจัดการและบล็อก repository ที่ README ตรงกับ regex นี้ได้ทันที
      เรื่องแบบนี้เคยเกิดมาแล้ว น่าจะได้บทเรียนบ้าง
      มัลแวร์ตัวนี้แทบไม่ต้องพยายามอะไรเลย และ Microsoft ก็ดูเหมือนแทบไม่พยายามเช่นกัน
    • นี่มันเกิดอะไรขึ้นกันแน่?

  • ขอย้ำก่อนว่าผมไม่เคยใช้ pytorch และก็ไม่ค่อยรู้เรื่องแนวปฏิบัติด้านความปลอดภัยของซอฟต์แวร์
    แต่ผมนึกแทบไม่ออกว่ามีกรณีไหนที่ pytorch ต้องการ การเข้าถึงเครือข่าย
    การที่โมดูลอะไรก็ได้ใน codebase import แล้วใช้ API แบบนั้นได้จากตรงไหนก็ได้ ดูไม่ถูกต้อง
    น่าจะต้องมีข้อจำกัดเรื่อง import เพิ่มเติมหรือมี static analysis
    ภาษาดูเหมือนยังไม่มี abstraction ที่เหมาะสมสำหรับจัดการปัญหาแบบนี้
    เทียบกันแล้วสิ่งที่ชอบใน Rust คือแค่ดู function signature ก็เห็นเรื่อง mutability และ lifetime ได้โดยไม่ต้องเข้าใจโค้ดภายใน
    รู้สึกว่า dependency ก็ควรมีอะไรคล้ายกัน
    นักพัฒนาควรตรวจสอบ dependency ทั้งหมดได้ง่ายโดยไม่ต้องไปขุดโค้ดข้างใต้ เช่นดูแล้วรู้ว่า “อ้อ dependency ตัวนี้ใช้ eval()” หรือ “มีการเข้าถึงเครือข่าย”
    แอปมือถือบังคับใช้ permission อยู่แล้ว นักพัฒนาก็น่าจะต้องสามารถ whitelist ได้ว่าต้องการแค่ความสามารถบางอย่าง แทนที่จะยอมรับฟีเจอร์ทุกอย่างทั้งก้อน

    • ecosystem ของ Python คงไม่มีวันยอมเรื่องแบบนี้ แต่ก็หวังว่าประเด็นนี้จะถูกเข้าใจและยอมรับมากขึ้นในวงการนั้น
      ไม่อยากเหมารวม แต่โดยเฉพาะคอมมูนิตี้นักพัฒนา AI ดูเหมือนจะให้ ความสะดวก มาก่อนทุกสิ่ง
      ตัวอย่างเช่น การที่โปรเจ็กต์ดาวน์โหลดโมเดลขนาดใหญ่โดยอัตโนมัติในครั้งแรกที่รัน ดูแทบจะกลายเป็นมาตรฐานไปแล้ว
      ส่วนใหญ่ปิดได้ก็จริง แต่เพราะโค้ดมีชั้นลึกของคลาสจากหลายไลบรารี การหาพารามิเตอร์ที่ถูกต้องจึงทรมานมาก
      ข้อดีคือมันทำให้เริ่มต้นกับสิ่งซับซ้อน ซึ่งส่วนใหญ่ก็เกือบเป็นของเล่น ได้ง่ายมาก แต่บรรยากาศแบบปล่อยผ่านนี้ก็น่าอึดอัดพอสมควร
      ขั้นแรกของการแก้ปัญหาดูเหมือนจะเป็น “pip install …” เสมอ และบางสภาพแวดล้อม เช่น MacOS ก็ยัง virtualize การเข้าถึง GPU ได้ไม่ดีนัก
    • มีกรณีที่ฝึกโมเดลข้ามหลาย compute node อยู่ นั่นเป็นตัวอย่างใหญ่ที่ต้องใช้ การเข้าถึงเครือข่าย

  • สัปดาห์นี้ผมกำลังสงสัยว่าการใช้ uv จัดการเวอร์ชัน Python เป็นความคิดที่ดีไหม
    ในเว็บไซต์ [1] เขียนว่า “Python ไม่มีไบนารีอย่างเป็นทางการสำหรับการแจกจ่าย ดังนั้น uv จึงใช้ดิสทริบิวชันจากโครงการ Astral python-build-standalone”
    มันชี้ไปที่ GitHub repo นี้ https://github.com/astral-sh/python-build-standalone และที่นั่นก็อ้างถึง https://gregoryszorc.com/docs/python-build-standalone/main/r... อีกที
    ถ้าผมเข้าใจถูก ดูเหมือนมันไม่ได้ดึงซอร์สโค้ดสำหรับ build Python มาจาก python.org โดยตรง และผมไม่แน่ใจว่าปลอดภัยแค่ไหน
    asdf [2] ก็มีข้อกังวลคล้ายกัน แต่ asdf ใช้ pyenv [3] ซึ่งให้ความรู้สึกใกล้กับของทางการมากกว่า
    มีใครอธิบายได้ไหมว่าระหว่าง uv กับ asdf เครื่องมือไหนดีกว่าและปลอดภัยกว่าสำหรับติดตั้ง Python
    [1] https://docs.astral.sh/uv/guides/install-python/
    [2] https://github.com/asdf-community/asdf-python
    [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

    • python-build-standalone ดึง ซอร์ส CPython จาก python.org โดยตรงอยู่แล้ว[1]
      เอาจริงก็ไม่รู้จะไปดึงจากที่อื่นทำไม
      [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
    • ผมไม่ได้กังวลเรื่อง uv กับ cpython เท่าไร กระบวนการเขาแข็งแรง ตอบสนองเร็ว และตอนนี้ก็มีเงินทุนมากพอสมควร
      สิ่งที่กังวลคือพวก formatter อย่าง mdformat ที่มีคนใช้กว้างขวางแต่หลัก ๆ มีคนเดียวดูแลในเวลาว่าง หรือ dependency เฉพาะทางมาก ๆ ที่ไม่ได้อัปเดตมาหลายปีและอยู่ลึกลงไปสามชั้นใน dependency tree
      ผมไม่อยาก pin ทุกอัปเดตแล้วอนุมัติด้วยมือตลอดในแอปที่พัฒนาอย่างต่อเนื่อง แต่สำหรับแอปจริงจัง ตอนนี้มันเริ่มดูเหมือนเป็นสิ่งจำเป็น
      ระหว่างนี้คงต้องไปดึง API key ออกจากไฟล์ .env ที่ไม่ได้เข้ารหัส
      ถ้าโดนในเว็บแอปผู้บริโภคขนาดใหญ่ก็น่าอายแต่พอเข้าใจได้ แต่การเสียเงินหลายร้อยถึงหลายพันดอลลาร์เพราะ indirect dependency ของ demo repo เล่น ๆ ที่ดันอยู่บนโฮสต์และระบบเดียวกันนี่เจ็บเกินไป
      มีใครรู้ไหมว่าถ้าคีย์ถูกขโมยแบบนี้ OAI หรือ Anthropic คืนเงินให้หรือเปล่า หรือถือว่าเป็นความผิดพลาดของผู้ใช้เอง?
    • แต่ตั้งแต่แรก uv ก็คือ ไบนารี ที่คุณเอามารันบนเครื่องเพื่อจัดการ Python binaries, packages, binaries ที่อยู่ในนั้น, เครื่องมือทั้งระบบ ฯลฯ
      ไม่ว่าพวกเขาจะ build Python binary เองหรือให้คนอื่น build ให้ ผมก็ไม่แน่ใจว่าความเสี่ยงต่างกันมากแค่ไหน

  • เดี๋ยวนี้ pip install ของผมส่วนใหญ่เกิดจาก Claude Code แนะนำ แล้วผมก็กด Enter ตามไปเลย
    โมเดลถูกฝึกจากข้อมูลเมื่อหลายเดือนก่อน ดังนั้นมันไม่มีทางรู้หรอกว่าสัปดาห์นี้อะไรถูกเจาะไปบ้าง
    เท่ากับว่าผมสร้างตัวกรองที่แย่ที่สุดขึ้นมาเองในการตัดสินว่า “แพ็กเกจนี้ตอนนี้ปลอดภัยไหม”

    • อย่าไปโทษ LLM สำหรับความขี้เกียจและการไม่ทำ due diligence ของตัวเองเลย
    • หมายถึงตัวกรองอะไร?
      คุณบอกว่าปล่อยให้ Claude Code แนะนำซอฟต์แวร์จากอินเทอร์เน็ตที่จะติดตั้ง แล้วคุณก็ติดตั้งตามนั้น
      ผมไม่เคยได้ยินว่า Claude Code หรือ LLM ตัวไหนถูกเสนอให้เป็นตัวกรองสำหรับตัดสินว่า “แพ็กเกจนี้ตอนนี้ปลอดภัยไหม” และด้วยเหตุผลที่คุณเองก็พูดมา มันเป็น heuristic ที่แย่มาก
    • ข้อมูลฝึกที่เก่าเป็นส่วนหนึ่งของปัญหาก็จริง แต่ถึงเป็นโมเดลล่าสุด มันก็ไม่มีทางรู้ได้ว่า setup.py จะรันอะไรบนเครื่องของผม
      เพราะไม่มีอะไรตรวจแพ็กเกจก่อนรันจริง
      สิ่งที่ต้องการคือเครื่องมือที่ดึง metadata มาก่อนแล้วเช็กว่ามี hook อะไรบ้างก่อน execution
    • ถ้าไม่กด Enter ก็หลีกเลี่ยงได้ง่าย
    • “ตัวกรองที่แย่ที่สุด” หมายถึงการกด Enter ตามที่ Claude บอกงั้นเหรอ?

  • Claude Code อัปเดตแทบทุกวัน บางทีก็หลายครั้งต่อวัน
    ถ้าวันหนึ่ง Anthropic ถูกเจาะ พวกเราคงเจ็บหนักกันทุกคน

    • “พวกเรา” หมายถึงใครบ้าง?
    • ถ้ารันมันใน VM/คอนเทนเนอร์ ที่ไม่มีสิทธิ์และจำกัดการเข้าถึงเครือข่าย ก็ไม่ถึงขนาดนั้น
      แต่ทุกวันนี้ทุกอย่างเป็นแบบ YOLO กันหมด
    • เหมือนเรื่องนี้น่าจะถูกสะท้อนไปในราคาของ Polymarket แล้ว

  • ผมเห็นข้อความนี้บน GitHub ที่โพสต์เมื่อ 20 เมษายน แล้วค่อนข้างสับสน
    "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
    ถ้าพวกเขารู้ปัญหาตั้งแต่ตอนนั้นแต่ยังไม่เตือนจนถึงตอนนี้ ผมคงไม่พอใจมาก
    อยากให้คนที่รู้มากกว่ามาอธิบายให้ชัดเจนหน่อย
    https://github.com/Lightning-AI/pytorch-lightning/issues/216...

    • ผมคือ Andy จาก Lightning แพ็กเกจอันตรายถูกเผยแพร่ขึ้น PyPI วันนี้เวลา 12:45 PM UTC
      ก่อนหน้านั้นยังไม่มีดิสทริบิวชันที่ได้รับผลกระทบ และเราก็ยังไม่รู้ว่ามีการรั่วไหลเกิดขึ้น
      รีลีสดั้งเดิมบน GitHub ไม่มีปัญหา แต่เราถอดมันลงไว้ชั่วคราวเพื่อเลี่ยงความสับสน
    • สำหรับคนที่ใช้ uv: https://docs.astral.sh/uv/reference/settings/#exclude-newer