สมมติว่าทีมของคุณมีเซิร์ฟเวอร์เล็ก ๆ บนคลาวด์ไว้รันงานเบื้องหลัง เช่น ตัวรับไฟล์จากคู่ค้า ตัวสำรองข้อมูล หรือเครื่อง jump host สำหรับเข้าไปดูแลระบบอื่น เครื่องพวกนี้มักใช้ Alpine Linux เพราะเบาและติดตั้งเร็ว และเปิด SSH ไว้ให้ผู้ดูแลเข้าไปแก้ปัญหา
ถ้าเครื่องแบบนั้นยังไม่ได้อัปเดตแพ็กเกจ openssh ในสัปดาห์นี้ คนที่เข้าถึงพอร์ต SSH ได้อาจล็อกอินเข้าไปได้โดยไม่ต้องทราบรหัสผ่านเลย
เกิดอะไรขึ้น
วันที่ 5 พฤศจิกายน 2569 ทีม OpenSSH ออกรุ่น Portable OpenSSH 10.6p2 พร้อมระบุในบันทึกการเปลี่ยนแปลงว่าแก้ปัญหาความปลอดภัยระดับวิกฤต เป็นการข้ามการล็อกอินด้วยรหัสผ่านผ่าน sshd บน Linux บางระบบที่ build และรันโดยไม่เปิด PAM ทีม OpenSSH มองว่าต้นเหตุอยู่นอก sshd แต่ผู้โจมตีใช้ sshd เป็นทางเข้าได้ จึงแก้ที่ sshd ผู้รายงานคือ Özgün Kültekin จาก Wakefield
วันเดียวกัน Alpine Linux ออกประกาศความปลอดภัยอธิบายว่าผู้โจมตีที่เข้าถึงพอร์ต SSH ได้สามารถล็อกอินโดยไม่ทราบรหัสผ่าน ใช้การเชื่อมต่อครั้งเดียว ได้ผลทุกครั้ง ไม่ต้องลองซ้ำ
ฐานข้อมูล NVD ของ NIST บันทึกเป็น CVE-2026-123158 ระบุว่ากระทบ sshd ใน OpenSSH ก่อนรุ่น 10.6p2 บน Linux ที่ใช้ musl libc โดยไม่มี PAM และในบางการตั้งค่าบัญชี รหัสผ่านอะไรก็ได้ที่ยาว 256 ถึง 1024 ตัวอักษรจะล็อกอินผ่าน คะแนน CVSS 3.1 ที่บันทึกไว้คือ 8.1
วันที่ 9 พฤศจิกายน 2569 CISA หน่วยงานความมั่นคงไซเบอร์ของสหรัฐฯ เพิ่มช่องโหว่นี้เข้ารายการ Known Exploited Vulnerabilities ซึ่งเป็นรายการช่องโหว่ที่มีหลักฐานว่าถูกโจมตีจริง และให้หน่วยงานรัฐบาลกลางสหรัฐฯ แก้ภายในวันที่ 12 พฤศจิกายน 2569 กำหนดนี้ไม่ได้บังคับบริษัทไทย แต่ระยะเวลาเพียงสามวันบอกได้ว่าเรื่องนี้เร่งแค่ไหน
ช่องโหว่ทำงานอย่างไร
Alpine อธิบายกลไกไว้ค่อนข้างตรงไปตรงมา เมื่อ sshd ถูก build โดยไม่มี PAM มันจะตรวจรหัสผ่านด้วยการนำรหัสที่ผู้ใช้พิมพ์ไปเข้าฟังก์ชัน crypt() แล้วเทียบกับค่าที่เก็บไว้ในไฟล์ shadow
ฟังก์ชัน crypt() ของ musl คืนค่าเป็นเครื่องหมาย * เพื่อบอกว่าเกิดข้อผิดพลาด เมื่อรหัสผ่านยาวเกิน 256 ไบต์ บังเอิญว่าบัญชีที่ไม่ได้ตั้งรหัสผ่าน เช่น บัญชีที่ล็อกอินด้วยคีย์อย่างเดียว ก็เก็บค่าเป็น * เหมือนกัน ผลคือค่าที่ได้ตรงกันและ sshd ยอมให้เข้า
เงื่อนไขที่ Alpine ระบุว่าทำให้เครื่องเข้าข่ายมีครบทั้งหมดดังนี้
- ใช้แพ็กเกจ openssh-server ของ Alpine ที่ build โดยไม่มี PAM หรือใช้ openssh-server-pam แต่ตั้ง UsePAM no
- PasswordAuthentication เป็น yes ซึ่งเป็นค่าเริ่มต้นของ OpenSSH ถ้าไม่ได้เปลี่ยน
- มีบัญชีที่ช่องรหัสผ่านเป็น * เช่น root ใน base image ตั้งแต่ราว Alpine 3.16 บัญชีที่สร้างไว้ล็อกอินด้วยคีย์อย่างเดียว หรือผู้ใช้ที่ดึงมาจากระบบไดเรกทอรีผ่าน musl-nscd
- มีบัญชีในเครื่องอย่างน้อยหนึ่งบัญชีที่ตั้งรหัสผ่านแบบ hash ขึ้นต้นด้วย $5$ หรือ $6$
ค่าเริ่มต้น PermitRootLogin prohibit-password ช่วยกันบัญชี root ไว้ได้ แต่ Alpine เตือนว่าถ้ามีบัญชีอื่นที่ล็อกอินได้และยกสิทธิ์เป็น root ได้ เช่น ผ่าน doas ก็ไม่ช่วยอะไร
Alpine ยังระบุว่า cloud image แบบ tiny-cloud ตั้งแต่ 3.18.11 ถึง 3.24.3 มีบัญชี alpine ที่ไม่มีรหัสผ่านและใช้ doas ได้โดยไม่ถามรหัส เครื่องปลอดภัยตอนบูตครั้งแรก แต่จะเข้าข่ายทันทีที่มีใครตั้งรหัสผ่านให้บัญชีใดบัญชีหนึ่งในเครื่อง
เครื่องแบบไหนไม่เข้าข่าย
ประกาศของ Alpine ระบุว่ากลุ่มต่อไปนี้ไม่ได้รับผลกระทบ container ที่ไม่ได้รัน sshd อยู่ข้างใน เครื่องที่ตั้ง PasswordAuthentication no เครื่องที่ใช้ openssh-server-pam กับ UsePAM yes บัญชีที่ถูกล็อกด้วยเครื่องหมาย ! และเครื่องที่ไม่มีบัญชีใดตั้งรหัสผ่านแบบ hash เลย cloud image ที่ตั้งค่าผ่าน cloud-init ก็ไม่เข้าข่าย เพราะ cloud-init เขียน PasswordAuthentication no ไว้ให้
บันทึกของ OpenSSH ระบุว่าปัญหานี้กระทบ Linux ที่ใช้ musl libc และปิด PAM ส่วน NVD ยก Alpine เป็นตัวอย่างของระบบแบบนี้ เครื่องที่ไม่ตรงเงื่อนไขทั้งสองข้อจึงไม่เข้าข่าย แต่ทีมไอทีควรยืนยันจากเครื่องจริงว่า sshd ที่รันอยู่ build แบบไหน ไม่ใช่เดาจากชื่อระบบปฏิบัติการ
