Tóm tắt nhanh
- Lỗ hổng *sshole (CVE-2026-123158) có thể cho phép đăng nhập SSH vào một số tài khoản bị khóa mật khẩu bằng chuỗi dài từ 257 đến 1024 ký tự.
- Điều kiện khai thác gồm OpenSSH chạy trên musl libc, không dùng PAM, bật xác thực bằng mật khẩu và có tài khoản phù hợp trong /etc/shadow.
- OpenSSH 10.6p2 đã khắc phục lỗi; nếu chưa thể cập nhật, quản trị viên có thể tắt PasswordAuthentication.
Một tài khoản SSH được khóa bằng dấu * trong /etc/shadow về lý thuyết không thể nhận đăng nhập bằng mật khẩu. Lỗ hổng *sshole (CVE-2026-123158) phá vỡ giả định đó trên một số cấu hình OpenSSH dùng musl libc: chuỗi nhập dài hơn giới hạn băm có thể khiến phép kiểm tra mật khẩu nhận kết quả trùng với dấu * lưu trong tài khoản.
Hai cách xử lý lỗi riêng lẻ đã ghép thành một đường đăng nhập
Để hiểu lỗi, cần nhìn vào hai hành vi vốn được tạo ra vì những lý do khác nhau. Trường mật khẩu có giá trị * trong /etc/shadow biểu thị tài khoản không có mật khẩu hợp lệ; không chuỗi nào được phép khớp với nó.
Trong khi đó, musl libc giới hạn đầu vào của hàm crypt() khi xử lý SHA-512 ở 256 byte. Nếu đầu vào vượt giới hạn, hàm trả về dấu * như một giá trị báo lỗi. OpenSSH lại có cơ chế xử lý tài khoản không có hash hợp lệ: nhằm làm cho thời gian xác thực khó bị dùng để dò tên tài khoản, máy chủ vẫn thực hiện phép băm bằng salt của một tài khoản khác.
Khi các hành vi này gặp nhau, mật khẩu dài hơn 256 byte khiến musl trả về *, rồi OpenSSH so sánh kết quả đó với trường * của tài khoản đang bị khóa. Hai giá trị giống nhau nên quá trình xác thực có thể bị chấp nhận. Đây là lỗi ở ranh giới giữa cách thư viện báo lỗi và cách máy chủ SSH so sánh kết quả, chứ không phải mật khẩu của tài khoản hợp lệ bị đoán ra.
Chỉ một nhóm cấu hình Linux cụ thể bị ảnh hưởng
Không phải mọi máy Linux hay mọi tài khoản đều có thể bị khai thác. Điều kiện được nêu trong thông tin kỹ thuật gồm máy chủ OpenSSH chạy trên hệ thống dùng musl như Alpine Linux, OpenWrt, Buildroot hoặc Yocto; xác thực PAM không được sử dụng; đăng nhập SSH bằng mật khẩu vẫn bật; tài khoản đích có trường mật khẩu là *; và hệ thống có ít nhất một tài khoản khác với hash hợp lệ để OpenSSH dùng salt.
Vì vậy Debian, Ubuntu và Fedora dùng glibc không thuộc trường hợp này; hệ thống đi qua PAM cũng không bị ảnh hưởng theo cách khai thác đã công bố. OpenWrt mặc định dùng Dropbear, nên chỉ đáng lưu ý nếu quản trị viên cài OpenSSH. Tài khoản đã có hash mật khẩu hợp lệ cũng không thể bị mở khóa theo cách này.
Điểm cần kiểm tra là các máy Alpine làm nền cho container, máy chủ đám mây và thiết bị nhúng. Bản Alpine chính thức dành cho AWS và Azure được nêu là có tài khoản mặc định phù hợp với điều kiện rủi ro; môi trường triển khai nào bật SSH password authentication sẽ cần được rà soát thay vì suy rộng rằng mọi container đều có thể truy cập từ Internet.
Vá OpenSSH hoặc tắt đăng nhập SSH bằng mật khẩu
Bản OpenSSH 10.6p2 đã sửa lỗi. Trên Alpine, hướng dẫn cập nhật là chạy apk upgrade openssh. Nếu chưa thể nâng cấp ngay, biện pháp giảm thiểu được công bố là đặt PasswordAuthentication no trong cấu hình máy chủ SSH rồi khởi động lại dịch vụ sshd. Cách này chỉ phù hợp nếu quy trình quản trị của máy không cần đăng nhập bằng mật khẩu; cần xác nhận quyền truy cập bằng khóa trước khi áp dụng để tránh tự khóa khỏi máy chủ.
Quản trị viên cũng nên kiểm tra log xác thực để tìm lượt đăng nhập mật khẩu thành công vào tài khoản vốn bị khóa. Trên Alpine, lệnh được hướng dẫn là grep "Accepted password" /var/log/messages; nếu thấy đăng nhập thành công cho tài khoản như alpine, có thể kiểm tra trường tương ứng trong /etc/shadow. Một dòng log bất thường cần được điều tra cùng thời điểm, địa chỉ nguồn và hoạt động sau đăng nhập; chỉ riêng sự tồn tại của tài khoản bị khóa không chứng minh máy đã bị xâm nhập.
Rủi ro thực tế phụ thuộc việc dịch vụ SSH có thể tiếp cận từ đâu và cấu hình xác thực cụ thể ra sao. Với hạ tầng chạy Alpine, ưu tiên hợp lý là xác định máy nào dùng musl và OpenSSH, vá bản dựng bị ảnh hưởng, rồi xác nhận đăng nhập mật khẩu đã tắt ở những máy không cần đến nó.
Nguồn tham khảo: Ozgun Kultekin – *sshole; BleepingComputer; Tom’s Hardware.
