วิเคราะห์ช่องโหว่การรันโค้ดจากระยะไกลใน GitHub: CVE-2026-3854

 (wiz.io)
1 คะแนน โดย GN⁺ 13 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพียงแค่มี ข้อบกพร่องของโปรโตคอลภายในบนเส้นทาง git push ก็สามารถทำให้เกิดการรันโค้ดจากระยะไกลบนฝั่งแบ็กเอนด์ได้ โดย GitHub.com ได้บรรเทาปัญหาแล้ว แต่ GHES ยังต้องติดตั้งแพตช์
  • อินพุตที่ผู้ใช้ควบคุมได้อย่าง push option ถูกใส่เข้าไปในเฮดเดอร์ X-Stat ตรง ๆ ทำให้สามารถใช้เครื่องหมายอัฒภาคเพียงตัวเดียวเพื่อฉีดฟิลด์ใหม่ได้ และพฤติกรรมแบบ last-write-wins ที่ค่าหลังของคีย์เดียวกันจะทับค่าก่อนหน้าก็ถูกนำมาใช้โจมตี
  • เมื่อนำฟิลด์ที่ฉีดได้อย่าง rails_env, custom_hooks_dir, repo_pre_receive_hooks มาประกอบกัน จะสามารถข้าม sandbox และรัน hook จากพาธที่ผู้โจมตีกำหนดได้ภายใต้สิทธิ์ของผู้ใช้ git
  • ด้วยกลไกเดียวกัน ยังสามารถฉีด enterprise mode flag ของ GitHub.com ได้ด้วย ส่งผลให้ยืนยันการรันโค้ดบน shared storage node และต่อเนื่องไปถึงสถานะที่สามารถอ่านรีโพซิทอรีของผู้ใช้และองค์กรอื่นบนโหนดนั้นได้
  • กรณีนี้แสดงให้เห็นว่าใน สถาปัตยกรรมแบบหลายบริการ ที่บริการต่าง ๆ เชื่อถือฟอร์แมตร่วมกัน การไม่มีการทำความสะอาดอินพุต เส้นทางรันงานที่ไม่ใช่ production และการตรวจสอบพาธที่ไม่ครบถ้วน สามารถรวมกันจนกลายเป็นช่องโหว่ร้ายแรงได้

การรับมือทันทีและขอบเขตผลกระทบ

  • บน GitHub.com ปัญหานี้ได้รับการบรรเทาแล้ว และไม่จำเป็นต้องมีการดำเนินการเพิ่มเติม
  • GitHub Enterprise Server ต้องดำเนินการทันที โดยควรอัปเกรดเป็น GHES 3.19.3 ขึ้นไป ซึ่งรวมการแก้ไข CVE-2026-3854 แล้ว
  • ช่วงเวอร์ชันที่ได้รับผลกระทบคือ GHES 3.19.1 และต่ำกว่า โดยเวอร์ชันที่แก้ไขแล้วได้แก่ 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, 3.19.3
  • ณ เวลาที่เขียน 88% ของ GHES instances ยังอยู่ในสถานะเปราะบาง
  • ข้อมูลทางเทคนิคเพิ่มเติมและขั้นตอนการกู้คืนจาก GitHub ดูได้ที่ GitHub Security Blog
  • ลูกค้า Wiz สามารถใช้ pre-built query ใน Wiz Threat Center เพื่อระบุ GHES instances ที่มีช่องโหว่ได้

ภูมิหลังของการสืบสวนและแนวทาง

  • โครงสร้างพื้นฐาน git ภายในของ GitHub เป็นเส้นทางที่ประมวลผล git push ทั้งหมด และประกอบด้วยบริการภายในหลายตัวที่เขียนด้วยภาษาต่างกัน
  • ใน โครงสร้างแบบหลายบริการ ลักษณะความแตกต่างของแต่ละคอมโพเนนต์ในการ parse และเชื่อถือข้อมูลร่วมกันอาจกลายเป็นช่องโหว่ได้
  • ก่อนหน้านี้ การดึงและตรวจสอบ ไบนารีแบบ black box ที่คอมไพล์แล้ว จำนวนมากซึ่งประกอบกันเป็น pipeline นี้ ต้องใช้เวลาและงานแบบแมนนวลอย่างมาก
  • ด้วย เครื่องมือเสริมด้วย AI และการทำ reverse engineering อัตโนมัติบนพื้นฐาน IDA MCP จึงสามารถวิเคราะห์ไบนารีที่คอมไพล์แล้วและสร้างโปรโตคอลภายในกลับขึ้นมาได้อย่างรวดเร็ว
  • ในกระบวนการนั้น มีการติดตามอย่างเป็นระบบว่าจุดใดบ้างที่อินพุตของผู้ใช้ส่งผลต่อพฤติกรรมของเซิร์ฟเวอร์ตลอดทั้ง pipeline และค้นพบ ข้อบกพร่องเชิงรากฐาน ของการไหลของอินพุตทั้งหมด

สถาปัตยกรรมภายในและขอบเขตความเชื่อถือ

  • เมื่อ git push เข้ามาทาง SSH คำขอจะไหลผ่าน babeld, gitauth, gitrpcd และ pre-receive hook ตามลำดับ
  • babeld เป็นจุดเริ่มต้นของงาน git ทั้งหมด รับการเชื่อมต่อ SSH และส่งต่อการยืนยันตัวตนไปยัง gitauth
  • gitauth ตรวจสอบข้อมูลประจำตัวของผู้ใช้และสิทธิ์ push ไปยังรีโพซิทอรี พร้อมส่งคืนนโยบายความปลอดภัย เช่น ข้อจำกัดขนาดไฟล์หรือกฎการตั้งชื่อสาขา
  • babeld ใช้คำตอบนี้เพื่อประกอบเฮดเดอร์ X-Stat ภายในที่บรรจุ metadata ด้านความปลอดภัย
  • gitrpcd รับเฮดเดอร์ X-Stat เพื่อกำหนดสภาพแวดล้อมของโปรเซสถัดไป และเชื่อถือ babeld อย่างสมบูรณ์โดยไม่มีการยืนยันตัวเองเพิ่มเติม
  • pre-receive hook จะตรวจสอบข้อจำกัดขนาดไฟล์ กฎการตั้งชื่อสาขา ความสมบูรณ์ของ LFS และ custom hook ที่ผู้ดูแลกำหนด ก่อนจะยอมรับ push
  • จุดเชื่อมสำคัญคือ เฮดเดอร์ X-Stat ซึ่งเก็บคู่ key=value ที่คั่นด้วย ;
  • บริการภายในจะนำ X-Stat มาแยกด้วย ; แล้วเติมลงใน map และถ้ามีคีย์เดียวกันซ้ำ ค่าที่มาทีหลังจะทับค่าก่อนหน้าตามกฎ last-write-wins
  • babeld ยังนำ push options ที่ส่งผ่าน git push -o ไปใส่ใน X-Stat ร่วมด้วยในฟิลด์อย่าง push_option_0, push_option_1, push_option_count

สาเหตุของช่องโหว่: การฉีดฟิลด์ X-Stat

  • babeld คัดลอก ค่า push option ซึ่งเป็นอินพุตที่ผู้ใช้ควบคุมได้เข้าไปยังเฮดเดอร์ X-Stat โดยไม่จัดการเครื่องหมายอัฒภาค
  • เนื่องจาก ; เป็นตัวคั่นฟิลด์ของ X-Stat เครื่องหมายอัฒภาคเพียงตัวเดียวใน push option จึงทำให้สามารถหลุดออกจากฟิลด์เดิมและสร้าง ฟิลด์ที่ผู้โจมตีควบคุม ใหม่ได้
  • ตัวอย่างเช่น ถ้าฉีด large_blob_rejection_enabled=bool:false เข้าไปใน push_option_0 ค่า bool:true ที่ถูกตั้งไว้ก่อนหน้าจะถูกค่าหลังทับ
  • พฤติกรรมนี้ได้รับการยืนยันทั้งจากการวิเคราะห์ไบนารีและจาก packet capture ของ GHES instance จริง
  • ด้วยการผสาน reverse engineering และการวิเคราะห์ระดับ wire จึงสามารถทำแผนที่ฟิลด์ X-Stat ที่ฉีดได้ทั้งหมด
  • โดยเฉพาะฟิลด์สำคัญด้านความปลอดภัยที่ตรวจพบ ได้แก่ rails_env, custom_hooks_dir, repo_pre_receive_hooks, large_blob_rejection_enabled, reject_sha_like_refs, user_operator_mode
  • ในบรรดานี้ rails_env, custom_hooks_dir, repo_pre_receive_hooks คือสามฟิลด์หลักที่นำไปสู่การรันโค้ดจากระยะไกล

เส้นทางสู่ RCE บน GHES

  • GHES รองรับ custom pre-receive hooks ที่ทำงานก่อนยอมรับ push
  • ไบนารี pre-receive มี สองเส้นทางการทำงาน ที่แยกกันตามค่า rails_env ใน X-Stat
  • ถ้าเป็นค่า production จะรัน hook ภายใน sandbox แต่ถ้าเป็นค่าอื่น จะรันโดยตรงภายใต้สิทธิ์ของผู้ใช้บริการ git โดยไม่มีทั้ง sandbox และการแยกกัก
  • ดังนั้นการฉีด rails_env เป็นค่าที่ไม่ใช่ production จึงทำให้ ข้าม sandbox ได้
  • จากนั้นเมื่อฉีด custom_hooks_dir ผู้โจมตีก็จะควบคุมไดเรกทอรีพื้นฐานที่ใช้ค้นหา hook script ได้
  • สุดท้าย หากฉีดนิยาม hook ที่มี path traversal เข้าไปใน repo_pre_receive_hooks การ resolve path ของไบนารีจะนำไดเรกทอรีที่ผู้โจมตีควบคุมมารวมกับ payload การไต่พาธจนชี้ไปยัง พาธใดก็ได้ในระบบไฟล์
  • เส้นทางการทำงานแบบ non-production จะรันพาธที่ resolve ได้ดังกล่าวโดยตรงโดยไม่มีอาร์กิวเมนต์ ไม่มี sandbox และภายใต้ผู้ใช้บริการ git
  • ในการทดสอบจริง เพียง git push ครั้งเดียวก็ได้ผลลัพธ์ uid=500(git) กลับมา ยืนยัน RCE ภายใต้สิทธิ์ผู้ใช้ git
  • ด้วยสิทธิ์นี้ ผู้โจมตีสามารถเข้าควบคุมทั้งหมดได้ ทั้งการอ่านและเขียนระบบไฟล์ของ GHES instance และการมองเห็นการตั้งค่าของบริการภายใน

การขยายไปยัง GitHub.com และการเปิดเผยข้ามเทนเนนต์

  • เมื่อนำ exploit chain เดียวกันไปใช้กับรีโพซิทอรีบน GitHub.com ในตอนแรก push สำเร็จแต่ custom hooks ไม่ถูกรัน
  • เมื่อฉีด user_operator_mode=bool:true เพื่อเปรียบเทียบเอาต์พุตดีบักของทั้งสองแพลตฟอร์ม ก็พบว่าบน GitHub.com ไม่ได้เข้าสู่ code path ของ custom hooks
  • จากการทำ reverse engineering เพิ่มเติม พบว่ามี boolean flag ในเฮดเดอร์ X-Stat ที่ควบคุมการทำงานของ enterprise mode บนเซิร์ฟเวอร์
  • บน GHES ค่านี้เป็น true โดยปริยาย จึงเปิดใช้งานเส้นทาง custom hooks ตลอดเวลา ขณะที่บน GitHub.com ค่าเริ่มต้นเป็น false ทำให้ในสถานะปกติจะไม่เข้าสู่เส้นทางดังกล่าว
  • เนื่องจาก flag นี้ก็สามารถฉีดได้ด้วยกลไกเดียวกัน เพียงฉีดฟิลด์เพิ่มอีกตัว ก็ทำให้ exploit chain ทั้งชุด ทำงานบน GitHub.com ได้เช่นกัน
  • หลังจากนั้น มีผลลัพธ์ของคำสั่ง hostname ถูกส่งกลับมาจากภายในโครงสร้างพื้นฐานของ GitHub.com เป็นการยืนยัน GitHub.com RCE
  • GitHub.com เป็น แพลตฟอร์มแบบหลายเทนเนนต์ ที่รีโพซิทอรีของผู้ใช้และองค์กรหลายรายถูกเก็บอยู่บนโครงสร้างพื้นฐานแบ็กเอนด์ร่วมกัน
  • จุดที่เกิดการรันโค้ดคือ shared storage node ซึ่งผู้ใช้ git มีสิทธิ์ระดับระบบไฟล์กว้างขวางเพื่อจัดการงานรีโพซิทอรีทั้งหมดบนโหนดนั้น
  • หากผู้ใช้นี้ถูกยึดได้ ก็จะสามารถอ่านรีโพซิทอรีขององค์กรและผู้ใช้อื่นบนโหนดเดียวกันได้ โดยไม่เกี่ยวกับเจ้าของเดิม
  • เมื่อทำการ enumerate รายการดัชนีรีโพซิทอรีที่เข้าถึงได้บนสองโหนดที่ถูกยึด พบว่าแต่ละโหนดมี หลายล้านเอนทรี และรวมรีโพซิทอรีของผู้ใช้และองค์กรอื่นอยู่ด้วย
  • ผู้วิจัยไม่ได้เข้าถึงเนื้อหาจริงของรีโพซิทอรีของเทนเนนต์อื่น และใช้เพียงบัญชีทดสอบของตนเองเพื่อยืนยันว่า สิทธิ์ระดับระบบไฟล์ของผู้ใช้ git อนุญาตให้อ่านรีโพซิทอรีทั้งหมดบนโหนด

บทเรียนสำคัญและไทม์ไลน์การเปิดเผย

  • เพียง git push ครั้งเดียว ก็สามารถใช้ประโยชน์จากข้อบกพร่องของโปรโตคอลภายในเพื่อทำให้เกิด การรันโค้ดจากระยะไกล บนโครงสร้างพื้นฐานแบ็กเอนด์ได้
  • เมื่อหลายบริการที่เขียนด้วยภาษาต่างกันแลกเปลี่ยนข้อมูลผ่านโปรโตคอลภายในร่วมกัน สมมติฐานเรื่องความเชื่อถือ ของแต่ละบริการเองก็กลายเป็นพื้นผิวการโจมตี
  • ใน chain นี้ บริการหนึ่งแทรกค่า push option เข้าไปตรง ๆ อีกบริการหนึ่งเชื่อถือทุกฟิลด์ของ X-Stat และ pre-receive hook ก็สมมติว่า rails_env จะเป็น production ในสภาพแวดล้อมใช้งานจริง
  • เส้นทางโค้ดสำหรับ non-production ในไบนารี production การไม่มีการตรวจสอบ path traversal ของ hook script และการไม่มีการทำความสะอาดอินพุตในโปรโตคอลที่อาศัยตัวคั่น ล้วนเป็นรูปแบบที่อาจพบได้ใน codebase อื่นเช่นกัน
  • ทีมที่ดูแลสถาปัตยกรรมแบบหลายบริการควรตรวจสอบโดยเฉพาะว่า เมื่อการตั้งค่าที่ไวต่อความปลอดภัยถูกอนุมานจากฟอร์แมตข้อมูลร่วมกัน อินพุตที่ผู้ใช้ควบคุมได้ไหลผ่าน โปรโตคอลภายใน อย่างไรบ้าง
  • งานวิจัยครั้งนี้แสดงให้เห็นว่าเครื่องมือ reverse engineering ที่เสริมด้วย AI รวมถึง IDA MCP ช่วยให้การวิเคราะห์ไบนารีที่คอมไพล์แล้วและการสร้างโปรโตคอลภายในกลับขึ้นมาเป็นไปได้อย่างรวดเร็ว
  • เมื่อเครื่องมือเหล่านี้พัฒนามากขึ้น ก็น่าจะมีบทบาทสำคัญยิ่งขึ้นในการค้นหาช่องโหว่ที่ต้องอาศัย การวิเคราะห์ข้ามคอมโพเนนต์อย่างลึก
  • ตามไทม์ไลน์การเปิดเผย มีการค้นพบช่องโหว่การฉีด push option ลงใน X-Stat เมื่อ 2026-03-04 และในวันเดียวกันก็ยืนยัน RCE บน GHES 3.19.1 พร้อมรายงานไปยัง GitHub โดย GitHub.com ได้ปล่อยการแก้ไขในวันนั้นเช่นกัน
  • เมื่อ 2026-03-10 มีการกำหนด CVE-2026-3854 และ CVSS 8.7 พร้อมเผยแพร่แพตช์ของ GHES
  • เปิดเผยต่อสาธารณะ เมื่อ 2026-04-28

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

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

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

  • เหมือนกับว่าพวกเขาปล่อยให้ สตริงตามอำเภอใจ ที่ผู้ใช้ปลายทางใส่ผ่าน git push -o หลุดเข้าไปอยู่ใน security-critical header ที่ บริการยืนยันตัวตน ภายในเป็นคนตั้งค่าเองด้วย
    จะมาพูดตอนหลังว่าควรเห็นตั้งแต่แรกก็ง่ายอยู่หรอก แต่ถึงอย่างนั้นอันนี้ก็ชวนอึ้งเกินไป

  • วิธี reverse engineering แบบเสริมพลังด้วย AI แสดงให้เห็นจุดแข็งของเอเจนต์ LLM ในตอนนี้ได้ดีมาก
    โมเดลที่ฝึกมาจากโค้ดจำนวนมากสามารถเร่งความเร็วในการทำความเข้าใจระบบภายในที่ซับซ้อนได้มหาศาล
    งานวิจัยด้านความปลอดภัยมักซ้อนกันระหว่าง 1) การทำความเข้าใจพฤติกรรมภายในที่ซับซ้อน และ 2) การหาช่องโหว่ในนั้น
    ซึ่งหลายครั้งพอเห็นกลไกภายในจริง ๆ แล้ว ตัวช่องโหว่กลับมองออกได้ง่ายกว่าที่คิด
    CVE-2026-3854 ไม่ใช่เคสที่ obvious ทันทีแม้จะรู้ภายในแล้วก็ตาม
    แต่ถ้ามันไปโผล่บน attack surface ที่ดั้งเดิมกว่านี้หรือเข้าถึงง่ายกว่านี้ ก็คงเจอ command injection นี้ได้เร็วมาก

    • เดิมทีก็มีสัญญาณอยู่แล้วว่า AI เก่งเรื่อง C++ reverse engineering หรือการพอร์ต C++ ปริมาณมากให้กลายเป็น C แบบง่าย ๆ
      แต่ช่วงนี้รู้สึกว่าทิศทางนั้นเริ่มสับสนลง หรือไม่ก็โดนขัดขวางโดยฝั่งที่อยากรักษา dev/vendor lock-in ที่เกิดจากความซับซ้อนของไวยากรณ์ C++ ไว้โดยตั้งใจ

  • ผลงานดูดีมากจนเกือบเหมือนมีคนจาก Wiz มาอยู่แถวนี้
    ตัวผลิตภัณฑ์เองก็ยังรับมือได้ค่อนข้างดีทั้งที่โตแบบสุดขีดและฟีเจอร์พองตัวหนัก
    ส่วนทีมความปลอดภัยก็เจอของน่าสนใจจริง ๆ อยู่บ่อยมาก

    • มีคนมาจาก Unit 8200 เยอะ
    • มันมี noise เยอะเกินไป เราเลยใช้แค่ custom pipeline ที่รัน osv-scanner กับ trivy เพื่อดูเฉพาะ critical
    • ฉันไม่ได้ทำงานที่นั่น แต่พอลองใช้ในบริษัทเรา มันชอบเตือนแม้แต่พฤติกรรมที่ไม่อันตรายอะไรเลย
      แต่พองานที่ดูน่าสงสัยจริง ๆ อย่าง query DC ผ่าน CLI แล้วรีเซ็ตรหัสผ่าน กลับเงียบกริบ เลยชวนหมดอารมณ์

  • ตอนที่ babeld ส่งต่อคำขอ push มันเอา push options ไปใส่ไว้ใน X-Stat header ของคำขอภายใน
    ซึ่งค่านั้นก็คือ สตริงตามอำเภอใจ ที่ผู้ใช้ใส่ผ่าน git push -o
    แต่ดันคัดลอกค่าตรง ๆ โดยไม่ sanitize เครื่องหมายอัฒภาค
    แล้วเพราะ ; เป็นตัวคั่นฟิลด์ของ X-Stat ผู้โจมตีจึงหลุดออกจากฟิลด์เดิมและสร้างฟิลด์ใหม่เองได้
    มันคือความผิดพลาดพื้นฐานที่สุดแบบตรงตัว จนเหมือนผลไม้อยู่ต่ำเกินไปจนฝังลงดินแล้ว

    • อ้อ แม่ของ Bobby Tables นี่ฉลาดจริง ๆ

  • ทั้งที่เป็นช่องโหว่ที่จับได้ก่อนจะถูกนำไปใช้โจมตีจริง
    ก็ยังอดสงสัยไม่ได้ว่าจำเป็นไหมที่จะต้องใช้คำอย่าง BREAKING, unauthorized access, millions of repositories มาปลุกความกลัวเกินเหตุ
    https://x.com/wiz_io/status/2049153209982140718

    • แต่ก็ใช่ว่าคำพวกนั้นจะไม่ถูกต้อง
      GitHub แค่โชคดีที่คนเจอคือ fuzzing ของ Wiz ไม่ใช่ผู้โจมตีที่ได้รับการสนับสนุนจากรัฐ

  • การที่ 88% ของอินสแตนซ์ GHES ยังไม่ได้ติดตั้ง security patch ระดับวิกฤตที่ออกมาตั้งแต่ 7 สัปดาห์ก่อนนั้น ดูค่อนข้างน่ากังวล
    https://docs.github.com/en/enterprise-server@3.19/admin/release-notes#3.19.3

    • จริง ๆ แล้ว GHES แทบจะอยู่ในสภาพถูกปล่อยทิ้งมาหลายปี
      แค่จะลง patch-level release หนึ่งครั้งก็ต้องใช้ downtime หลายชั่วโมง
      และก็ไม่มีวิธีอัปเกรด HA ที่รองรับอย่างเป็นทางการ ทำให้แม้แต่ลูกค้าที่ขยันจริงจังก็ยังตามเวอร์ชันล่าสุดได้ยาก
      ถ้าบ่นขึ้นมาก็มักจะโดนบอกให้ย้ายไป GitHub Enterprise Cloud
      แต่ในยุคแบบนี้ก็ไม่แน่ใจว่าจะมีคนพร้อมเลือกทางนั้นมากแค่ไหน
      ถึงอย่างนั้น GHES ก็มีข้อดีตรงที่มันไม่ล่มตามปัญหารายวันของ github.com
    • ลูกค้า on-prem จำนวนมากวาง GHES ไว้ หลัง VPN
      และน่าจะรอเลือกวันที่กระทบการปฏิบัติงานน้อยที่สุดแล้วค่อยอัปเกรด
      แต่ถ้าเป็นอินสแตนซ์สาธารณะก็ควรอัปเดตทันที
      จากข้อมูลในบทความและซอร์ส GitHub Enterprise ที่เปิดเผยอยู่ ก็ดูไม่ยากนักที่จะประกอบวิธีทำซ้ำขึ้นมา
    • ในฝั่ง enterprise คุณอาจอัปเดตนอกตารางแล้วระบบพังหมดจนต้องรับผิดชอบเอง
      หรือไม่ก็ทำตามตารางเดิมแล้วหวังว่าจะไม่มีอะไรเกิดขึ้น ซึ่งส่วนใหญ่ก็มักเลือกอย่างหลัง
    • ในสภาพแวดล้อมที่ใช้ github.com ไม่ได้เพราะให้ความสำคัญกับ ความปลอดภัยอย่างจริงจังมาก
      การที่ผลิตภัณฑ์ on-prem จะอัปเดตปีละครั้งก็ไม่ใช่เรื่องแปลก
    • สำหรับระบบติดตั้งขนาดใหญ่ ประเด็นสำคัญคือกระบวนการอัปเกรดนั้น เปราะบาง แค่ไหน
      ซอฟต์แวร์ enterprise ที่มีข้อมูลขนาดใหญ่มักพังจากเรื่องเล็กน้อยได้ง่าย และทีมปฏิบัติการก็ต้อง rollback กันเป็นประจำ
      การอัปเกรด SharePoint สมัยก่อนแทบเหมือนการทอยลูกเต๋า

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

    • มันเลยเป็นรอยร้าวอีกจุดต่อข้ออ้างว่า ไม่ควรเปิดซอร์สเพื่อไม่ให้ AI เจาะง่ายขึ้น
      เป็นอีก data point ว่าสุดท้ายแล้วความปลอดภัยไม่ควรพึ่ง security through obscurity

  • ทุกคนพูดกันว่าให้หาตัวแทน GitHub แต่พอถึงจุดนั้นก็ต้องถามต่อว่าจะใช้อะไรแทน
    ขนาดระดับ GitHub ยังมี RCE โผล่มาตอนนี้ ก็ยากจะรับประกันง่าย ๆ ว่าทางเลือกอื่นจะดีกว่า

    • จะเล่นมุกก็ได้ว่าไม่ต้องห่วง เดี๋ยว Thomas Dohmke แก้ทุกอย่างให้ด้วยโปรเจกต์ใหม่
      https://news.ycombinator.com/item?id=46961345
      https://news.ycombinator.com/item?id=47712656
    • คำตอบที่พอเป็นจริงได้ที่สุดน่าจะเป็นใช้ Forgejo แบบ self-hosted เป็นต้นทางหลัก
      แล้วใช้ GitHub เป็น mirror ระหว่างที่ยังอาศัย CI ฟรีอยู่
      ส่วน secret ก็ฝากไว้กับผู้ให้บริการ secret-hosting แยกต่างหาก
    • เราเพิ่งย้ายจาก GitHub ไป Forgejo แบบ self-hosted เมื่อ 6 เดือนก่อน และมันทำงานดีมาก
      ยังไม่หายแปลกใจเลยว่า Forgejo ตอบสนองไวขนาดนี้ ขณะที่ GitHub กลับช้าลงได้ขนาดนั้น
    • ตอนนี้เราแยกโปรเจกต์ภายในกับโปรเจกต์สาธารณะออกจากกันชัดเจน
      ของภายในอยู่บน Forgejo instance แบบ private ส่วนของสาธารณะอยู่บน GitHub แต่ mirror กลับเข้า Forgejo
      ที่น่าทึ่งคือ Forgejo แทบเป็น single binary และตั้งค่าง่ายมาก
      แถมบริการภายในทั้งหมดก็ชี้ไปที่ Forgejo อยู่แล้ว ต่อให้ต้องออกจาก GitHub ก็มีแรงเสียดทานน้อย
    • GitLab แบบ self-hosted หลัง VPN ก็ใช้ได้ดีเหมือนกัน
      มีแค่ Docker image แบบ all-in-one กับ GitLab runner สักไม่กี่ตัว ก็พอสำหรับทีมขนาดเล็กถึงกลางแล้ว
      ถ้าไม่ได้จำเป็นจริง ๆ ก็ไม่มีเหตุผลต้องทำให้ซับซ้อนถึงขั้นไปใช้เวอร์ชัน Kubernetes

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

    • เดิมที Transformer เป็นสถาปัตยกรรมที่ออกแบบมาเพื่อการแปล
      ดังนั้นที่มันเก่งกับ source-to-source หรือ text-to-source จึงไม่ใช่เรื่องใหม่อะไร
      และการที่มันเหมาะกับการทำความเข้าใจเวอร์ชัน asm ก็อาจไม่ใช่เรื่องเหนือความคาดหมายสุดขีด
      ถึงอย่างนั้นก็ยังน่าประทับใจอยู่ดี

  • สงสัยว่าจริง ๆ แล้วจะตรวจได้ไหมว่า ถูกนำไปใช้โจมตีแล้วหรือยัง

    • เท่าที่ฉันดู ช่องโหว่นี้น่าจะถูกใช้โจมตีได้แม้แต่โดย ผู้ใช้ไม่ระบุตัวตน
      เราอาจพอเช็กได้จาก HTTP/git protocol logs ว่ามีการใช้ประโยชน์จากมันหรือไม่
      แต่มีโอกาสสูงว่าจะไม่เหลือข้อมูลว่าเข้าถึงอะไรไปบ้างและใครเป็นคนทำ
      เพราะถ้า exploit สามารถรันได้อย่างอิสระบน git server ก็เท่ากับว่ามันสามารถหลบเลี่ยงการบันทึก log ได้โดยนิยาม