Lỗ hổng OpenSSH "sshole": mật khẩu dài hơn 256 ký tự mở được tài khoản đã khóa trên Alpine Linux

Một mật khẩu dài hơn 256 ký tự vừa đủ để đăng nhập vào tài khoản Linux vốn được khóa chặn mật khẩu — không cần biết mật khẩu thật. Lỗ hổng có tên "sshole", tồn tại âm thầm từ năm 2016 trên các hệ thống dùng thư viện musl, vừa được công bố ngày 05/11/2026 cùng bản vá OpenSSH 10.6p2.

Một mật khẩu dài hơn 256 ký tự vừa đủ để đăng nhập vào tài khoản Linux vốn được khóa chặn mật khẩu — không cần biết mật khẩu thật, không cần khai thác phức tạp. Lỗ hổng có tên "sshole", tồn tại âm thầm từ năm 2016 trên các hệ thống dùng thư viện musl, vừa được công bố ngày 05/11/2026 cùng bản vá OpenSSH 10.6p2.

Lỗ hổng OpenSSH Alpine Linux: chuyện gì xảy ra

Nhà nghiên cứu bảo mật Özgün Kültekin (Wakefield) công bố lỗ hổng ngày 05/11/2026 trên trang sshole.com, sau khi phát hiện ra nó nhờ cho các AI agent chạy khoảng 17.600 phép thử xác thực với nhiều cấu hình OpenSSH khác nhau. OpenSSH phát hành bản sửa 10.6p2 ngay trong cùng ngày.

Cơ chế của lỗ hổng gọn đến mức khó tin. Trên Linux, tài khoản muốn chặn hẳn đăng nhập bằng mật khẩu thường được đặt dấu sao (*) thay cho hash mật khẩu trong tệp /etc/shadow. Dấu * không phải là một hash hợp lệ, nên theo lý thuyết không mật khẩu nào có thể khớp với nó.

Năm 2016, OpenSSH vá lỗ hổng liệt kê tên người dùng CVE-2016-6210 bằng cách thay đổi cách xử lý: để kẻ tấn công không đoán được tên tài khoản hợp lệ qua thời gian phản hồi khác nhau, OpenSSH vẫn thực hiện phép băm mật khẩu ngay cả khi tài khoản không có hash dùng được. Vấn đề nằm ở phía thư viện C musl: hàm crypt() của musl cũng trả về * khi phép băm thất bại — trong đó có trường hợp mật khẩu gửi lên dài hơn giới hạn 256 byte của musl. Kết quả: OpenSSH so sánh * mà musl trả về với * đang lưu trong /etc/shadow, thấy hai chuỗi giống nhau, và cho đăng nhập thành công.

Theo phân tích kỹ thuật độc lập, mật khẩu dài từ 257 đến 1.024 byte là đủ — chỉ một lần thử, không cần dò dẫm nhiều lần. Cần nói rõ giới hạn: lỗ hổng không mở được tài khoản có hash mật khẩu hợp lệ. Tài khoản đặt mật khẩu mạnh vẫn đứng vững; thứ bị mở là đúng những tài khoản mà quản trị viên tưởng đã khóa chặt bằng mật khẩu.

Lỗ hổng sshole trong OpenSSH: mật khẩu quá dài vượt qua tài khoản khóa bằng dấu sao trên Alpine Linux

Lỗ hổng OpenSSH Alpine Linux: ai bị ảnh hưởng — và điều kiện cần đủ

Lỗ hổng chỉ xảy ra khi năm điều kiện cùng đúng: máy chủ OpenSSH chạy trên hệ dùng thư viện musl (Alpine Linux, OpenWrt, Buildroot, Yocto); xác thực PAM đang tắt — đây lại là mặc định của gói openssh-server trên Alpine; SSH vẫn bật xác thực bằng mật khẩu; trên máy có ít nhất một tài khoản mang dấu *; và có một tài khoản khác mang hash mật khẩu hợp lệ, để OpenSSH mượn "muối" (salt) khi băm.

Với riêng danh sách đó, phạm vi ảnh hưởng đã rộng hơn vẻ ngoài của nó. Alpine Linux là image nền phổ biến nhất cho container Docker; OpenWrt chạy trên rất nhiều router; Buildroot và Yocto là nền của thiết bị nhúng và IoT.

Nghiêm trọng nhất là trường hợp image cloud chính thức của Alpine trên AWS và Azure: các image này có sẵn tài khoản mặc định alpine mang dấu * và quyền doas không cần mật khẩu. Kẻ tấn công đăng nhập được bằng mật khẩu dài rồi dùng doas là leo thẳng lên quyền root — toàn bộ máy chỉ còn cách một bước.

Ngược lại, các hệ dùng glibc — Debian, Ubuntu, Fedora — và mọi hệ dùng PAM để xác thực đều không bị ảnh hưởng, vì crypt() của glibc không trả về * khi băm thất bại, và đường xác thực qua PAM không đi qua nhánh mã lỗi này.

Lỗ hổng OpenSSH Alpine Linux: mức độ

Điểm đáng chú ý nhất của "sshole" không phải độ phức tạp — mà là thời gian nó tồn tại và nơi nó ẩn nấp. Mười năm, từ 2016 tới nay, trong một đoạn mã mà ai cũng tưởng đã được vá xong từ bản sửa CVE-2016-6210. Tại thời điểm công bố, lỗ hổng chưa được gắn mã CVE riêng. Nhưng vì nhà nghiên cứu đã công bố toàn bộ chi tiết kỹ thuật cùng bản demo ngay trong ngày 05/11, khoảng thời gian từ "đã biết" tới "ai cũng làm được" gần như bằng không — đó mới là lý do đội IT cần xử lý trong hôm nay chứ không phải tuần sau.

Nói cho đúng sắc thái: đây là lỗi vượt xác thực qua SSH, không phải lỗi chiếm máy từ xa không cần điều kiện. Kẻ tấn công cần máy chủ phơi SSH ra ngoài và một tài khoản * đang tồn tại trên máy — nhưng trong thực tế, hai điều kiện đó lại rất thường gặp.

Checklist 24 giờ: cập nhật OpenSSH 10.6p2, khởi động lại SSH và rà log đăng nhập lạ

Làm gì trong 24 giờ

  • Cập nhật OpenSSH lên 10.6p2 ngay: trên Alpine, chạy apk upgrade openssh. Lưu ý quan trọng: cập nhật gói không tự khởi động lại daemon đang chạy — sau khi cập nhật phải khởi động lại dịch vụ SSH thì bản sửa mới có hiệu lực.
  • Nếu chưa cập nhật được, chặn đứng ngay: đặt PasswordAuthentication no trong tệp cấu hình SSH rồi khởi động lại dịch vụ. Máy chỉ còn cho đăng nhập bằng khóa SSH — đúng chuẩn vận hành mà phần lớn server sản xuất vẫn dùng.
  • Rà dấu vết trong log: trên Alpine, chạy grep "Accepted password" /var/log/messages và đối chiếu với danh sách tài khoản vốn không cho phép mật khẩu. Nếu log ghi nhận một lần đăng nhập bằng mật khẩu vào tài khoản alpine trong khi grep '^alpine:' /etc/shadow cho thấy trường mật khẩu của nó là *, đó là dấu hiệu lỗ hổng đã bị khai thác.
  • Rà toàn bộ tài khoản mang dấu *: liệt kê mọi tài khoản có trường mật khẩu là *, đặc biệt tài khoản mặc định trên image cloud; khóa hoặc xóa tài khoản không còn dùng; rà lại quyền doas/sudo không mật khẩu trên các tài khoản đó.
  • Rà diện phơi nhiễm: liệt kê máy Alpine, router OpenWrt và thiết bị nhúng đang phơi SSH ra internet; ưu tiên trước các máy dùng image cloud chính thức của Alpine trên AWS và Azure.
  • Kiểm tra container Alpine chạy SSH: phần lớn container không chạy sshd nên không bị ảnh hưởng, nhưng container nào chạy sshd (bastion, máy build, môi trường kiểm thử) thì cập nhật image nền và build lại ngay.

"sshole" là lời nhắc đắt giá rằng một biện pháp khóa tài khoản tưởng như tuyệt đối vẫn có thể bị vô hiệu hóa bởi sự tương tác giữa hai đoạn mã tưởng chừng không liên quan — một bản vá chống liệt kê tên người dùng từ 2016 và một hàm băm trả về * khi thất bại. Đội IT nào giữ được thói quen rà tài khoản định kỳ, tắt xác thực mật khẩu ở nơi không cần, và cập nhật SSH ngay trong ngày có bản vá sẽ đứng ở phía an toàn của câu chuyện này.

Nguồn tham khảo

  • BleepingComputer — "OpenSSH flaw lets attackers log into password-disabled Linux accounts" (05/11/2026): https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/
  • The Register — "Alpine Linux warns of an OpenSSH-server password authentication bypass" (05/11/2026)
  • Trang công bố của nhà nghiên cứu Özgün Kültekin: sshole.com; ghi chú phát hành OpenSSH 10.6p2 (05/11/2026)

Bài viết liên quan

Tác giả:
author avatar
Tôi là Trường Phạm, hiện đảm nhiệm vai trò CEO của SunCloud. Với kiến ​​thức sâu rộng về mạng lưới hệ thống, điện toán đám mây và an ninh mạng, góp phần định hướng chiến lược phát triển bền vững cho doanh nghiệp. Tôi đã điều hành SunCloud phát triển và vận hành thành công hàng loạt dự án thực tiễn, mang lại giá trị thực tế cho các doanh nghiệp và cơ sở kinh doanh. Bản thân tôi đã đạt được các chứng chỉ quốc tế uy tín như CCNP, LPI, VCP và không ngừng học hỏi để nâng cao năng lực quản lý cũng như chuyên môn mỗi ngày. Đam mê công nghệ và khao khát cống hiến, tôi luôn nỗ lực xây dựng SunCloud trở thành một hệ sinh thái công nghệ đáng tin cậy, đồng thời lan tỏa những giá trị tri thức hữu ích đến cộng đồng.

Tin tức nổi bật
Tin tức khác