*sshole là tên mà nhà nghiên cứu Özgün Kültekin đặt cho một lỗi bỏ qua xác thực mật khẩu trong OpenSSH trên một số hệ thống Linux dùng musl libc. Trong điều kiện cụ thể, kẻ tấn công chỉ cần biết tên tài khoản và gửi một mật khẩu dài từ 257 đến 1.024 byte để đăng nhập vào tài khoản vốn không được phép dùng mật khẩu. OpenSSH 10.6p2 và các gói Alpine Linux đã vá lỗi ngày 5/11/2026.
Vấn đề đáng chú ý không nằm ở một thuật toán mã hóa yếu, mà ở cách ba lựa chọn hợp lý ở ba thời điểm khác nhau tương tác với nhau: ký tự * dùng để khóa mật khẩu, giá trị lỗi của hàm crypt() trong musl và cơ chế chống dò tên người dùng của OpenSSH. Đây là bài học điển hình về rủi ro tại ranh giới giữa các thành phần phần mềm.
*sshole hoạt động như thế nào?
Trên Linux, trường mật khẩu trong /etc/shadow thường chứa một chuỗi băm có tiền tố như $6$ cho SHA-512. Với tài khoản chỉ đăng nhập bằng khóa SSH, quản trị viên có thể đặt trường này thành *; vì đây không phải chuỗi băm hợp lệ, về nguyên tắc không mật khẩu nào khớp được.
Trên musl libc, crypt() cũng trả về đúng ký tự * khi việc băm thất bại. Thuật toán SHA-512 crypt của musl giới hạn đầu vào ở 256 byte để tránh tác vụ băm quá tốn tài nguyên. Khi nhận mật khẩu dài hơn giới hạn, hàm trả về *. Nếu OpenSSH so sánh kết quả đó với trường mật khẩu * của tài khoản, hai chuỗi trùng nhau và xác thực có thể thành công.
Vì sao OpenSSH lại băm mật khẩu cho tài khoản bị khóa?
Năm 2016, OpenSSH sửa CVE-2016-6210, một kênh bên cho phép đo thời gian phản hồi để suy đoán tên người dùng có tồn tại hay không. Để các đường xử lý mất thời gian gần tương đương, sshd vẫn thực hiện phép băm cho người dùng không hợp lệ hoặc tài khoản không có chuỗi băm dùng được, bằng cách mượn salt từ tài khoản khác.
Cơ chế chống dò tên người dùng này không tự nó tạo ra lỗ hổng. Lỗi xuất hiện khi nó gặp đúng hành vi trả về * của musl và tài khoản có trường mật khẩu cũng là *. OpenSSH đánh giá nguyên nhân gốc nằm ngoài sshd, nhưng đã bổ sung biện pháp tránh khai thác trong bản 10.6p2.
Những hệ thống nào có nguy cơ?
Theo cảnh báo chính thức của Alpine Linux, hệ thống chỉ bị ảnh hưởng khi đồng thời thỏa các điều kiện sau:
- OpenSSH chạy trên Linux dùng musl, điển hình là Alpine Linux; các môi trường OpenWrt, Buildroot hoặc Yocto cũng cần kiểm tra cấu hình thực tế.
- PAM bị tắt. Gói
openssh-servermặc định của Alpine không dùng PAM;openssh-server-pamvớiUsePAM yeskhông bị ảnh hưởng. PasswordAuthentication yesvẫn được bật.- Có ít nhất một tài khoản với trường mật khẩu là
*và ít nhất một tài khoản khác dùng chuỗi băm$5$hoặc$6$.
Debian, Ubuntu và Fedora dùng glibc, các máy đi qua PAM, hệ thống đã tắt đăng nhập mật khẩu và container không chạy sshd không nằm trong phạm vi này. Tài khoản có trường ! cũng không chịu cách khai thác trên. Vì vậy, việc chỉ thấy Alpine trong chuỗi cung ứng container chưa đủ để kết luận máy chủ có thể bị tấn công.
Rủi ro đặc biệt với ảnh máy ảo đám mây Alpine
Các ảnh tiny-cloud chính thức từ Alpine 3.18.11 đến 3.24.3 có tài khoản alpine với trường mật khẩu * và quyền doas không cần mật khẩu. Ảnh mới khởi động vẫn an toàn khi cloud-init tắt xác thực mật khẩu. Tuy nhiên, nếu cấu hình sau đó bật đăng nhập mật khẩu và xuất hiện một chuỗi băm $6$, kẻ tấn công có thể lấy shell của tài khoản alpine rồi nâng quyền lên root.
Alpine cho biết các nhánh 3.16 đến 3.24 và edge đã được kiểm tra đều có lỗi ở các phiên bản cũ. Dự án còn phát hành gói sửa cho một số nhánh đã hết hỗ trợ, nhưng quản trị viên không nên coi đó là lý do trì hoãn kế hoạch nâng cấp hệ điều hành.
Cách vá và giảm thiểu an toàn
Biện pháp ưu tiên là cập nhật toàn bộ gói và khởi động lại dịch vụ SSH. Với Alpine, cảnh báo chính thức đề xuất:
apk upgrade -U -a
rc-service sshd restartChỉ nâng cấp gói là chưa đủ vì tiến trình sshd đang chạy không tự được thay thế. Các bản Alpine 3.21.10, 3.22.8, 3.23.8 và 3.24.4 đã chứa gói sửa; nhánh edge dùng OpenSSH 10.6_p2-r0.
Nếu chưa thể cập nhật ngay, hãy xác nhận đăng nhập bằng khóa hoạt động, giữ phiên quản trị hiện tại mở, sau đó đặt PasswordAuthentication no, kiểm tra cấu hình bằng sshd -t và khởi động lại dịch vụ. Không nên đóng phiên hiện tại trước khi thử thành công một kết nối SSH mới để tránh tự khóa mình khỏi máy chủ.
Cách kiểm tra dấu hiệu bị khai thác
Trên Alpine, quản trị viên nên tìm các dòng Accepted password trong /var/log/messages, đặc biệt với alpine, root hoặc tài khoản vốn chỉ dùng khóa. Một lần đăng nhập mật khẩu thành công cho tài khoản có trường * là dấu hiệu nghiêm trọng.
Nếu không thể loại trừ xâm nhập, cần xử lý máy như đã bị chiếm quyền: cô lập, bảo toàn log, rà soát lệnh doas, tài khoản và tệp mới, khóa trong authorized_keys, tiến trình duy trì truy cập và thông tin xác thực có mặt trên máy. Việc vá chỉ chặn lần khai thác tiếp theo, không loại bỏ cửa hậu đã được cài.
Một lỗi tồn tại suốt mười năm
Chuỗi nguyên nhân kéo dài từ quyết định của musl năm 2012, bản vá chống dò người dùng của OpenSSH năm 2016 đến cách Alpine dùng * cho tài khoản chỉ dùng khóa từ năm 2022. Nhà nghiên cứu phát hiện sai khác khi thử khoảng 17.600 trường hợp xác thực trên nhiều tổ hợp glibc, musl, PAM và shadow.
Tại thời điểm Alpine công bố cảnh báo, dự án cho biết chưa có mã CVE được cấp. Một số bài viết sau đó gọi lỗi là CVE-2026-123158, nhưng quản trị viên nên ưu tiên định danh bằng cảnh báo Alpine và ghi chú OpenSSH 10.6p2 cho đến khi cơ sở dữ liệu CVE chính thức đồng bộ đầy đủ.
Bài học cho đội vận hành
*sshole cho thấy kiểm thử từng thư viện riêng lẻ không đủ để bảo đảm an toàn của cả hệ thống. Một giá trị lỗi có thể vô hại trong musl nhưng trở thành kết quả xác thực hợp lệ khi đi qua logic của OpenSSH và dữ liệu tài khoản. Các đội vận hành nên kiểm thử ma trận cấu hình thực tế, theo dõi các khác biệt giữa libc và PAM, đồng thời loại bỏ xác thực mật khẩu trên máy chủ chỉ cần khóa SSH.
Ưu tiên tức thời là kiểm kê máy Alpine có mở cổng SSH, cập nhật và khởi động lại sshd, xác minh cấu hình hiệu lực bằng sshd -T, rồi rà soát log. Đây là một lỗi có điều kiện khai thác hẹp, nhưng khi các điều kiện hội đủ, tác động có thể là đăng nhập từ xa và chiếm quyền root chỉ trong một kết nối.
VNCyberS tổng hợp từ Alpine Linux, OpenSSH, sshhole.com và BleepingComputer
Tiếng Việt
English