Tóm tắt nhanh
- Alpine Linux công bố cảnh báo ngày 5/11/2026 về lỗi vượt xác thực mật khẩu khi OpenSSH dùng musl và không xác thực qua PAM.
- Tài khoản có trường mật khẩu là dấu * có thể bị truy cập nếu máy chủ bật PasswordAuthentication và tồn tại tài khoản khác có hash $5$ hoặc $6$.
- Cần cập nhật gói OpenSSH rồi khởi động lại sshd; nếu chưa cập nhật được, tắt xác thực mật khẩu sau khi kiểm tra đăng nhập bằng SSH key.
- Container Alpine không chạy sshd không thuộc diện bị khai thác qua lỗ hổng này.
OpenSSH 10.6p2 và các gói vá của Alpine Linux đã được phát hành để xử lý lỗi có thể khiến một số máy chủ chấp nhận đăng nhập mà người truy cập không cần biết mật khẩu. Điểm dễ bị bỏ sót là tài khoản vốn chỉ dùng SSH key vẫn có thể nằm trong nhóm rủi ro: không đặt mật khẩu cho tài khoản chưa đồng nghĩa với việc máy chủ đã tắt đường đăng nhập bằng mật khẩu.
Tài khoản dùng SSH key chưa chắc đã đóng đường mật khẩu
Muốn đánh giá mức độ ảnh hưởng, cần xem cấu hình dịch vụ và trạng thái tài khoản cùng nhau. Cảnh báo của Alpine xác định hệ thống có nguy cơ khi chạy gói openssh-server không có PAM, hoặc chạy openssh-server-pam nhưng đặt UsePAM no; đồng thời PasswordAuthentication vẫn bật. PAM là lớp xử lý xác thực mà OpenSSH có thể sử dụng thay cho việc tự kiểm tra mật khẩu.
Máy còn phải có tài khoản với trường mật khẩu là dấu * trong /etc/shadow và ít nhất một tài khoản cục bộ khác mang hash bắt đầu bằng $5$ hoặc $6$, tương ứng với SHA-256 và SHA-512. Với đủ các điều kiện đó, người tấn công tiếp cận được cổng SSH và biết tên tài khoản mục tiêu có thể vượt xác thực. Theo cảnh báo của Alpine, việc khai thác trong cấu hình này chỉ cần một kết nối, không phải quá trình dò mật khẩu nhiều lần.
Cần phân biệt tài khoản không đặt mật khẩu với tài khoản đã bị khóa. Alpine liệt kê tài khoản có dấu ! trong trường mật khẩu là không bị ảnh hưởng, trong khi dấu * lại nằm đúng trong cơ chế gây lỗi. Vì vậy, chỉ nhìn danh sách người dùng rồi kết luận rằng mọi tài khoản không có mật khẩu đều an toàn sẽ bỏ qua khác biệt quan trọng này.
Dấu báo lỗi của thư viện bị so khớp thành kết quả đúng
Vấn đề nằm ở chỗ một kết quả báo lỗi lại trùng với dữ liệu được dùng để so sánh khi đăng nhập. Trong luồng không qua PAM, sshd gọi hàm crypt() để băm mật khẩu nhận được rồi đối chiếu với trường mật khẩu đã lưu. Nếu trường này quá ngắn để chứa salt, thành phần dùng trong quá trình băm, sshd mượn salt từ tài khoản khác có hash hợp lệ.
Với các kiểu hash nói trên, crypt() của musl trả về chuỗi * khi mật khẩu vượt quá 256 byte. Chuỗi báo lỗi ấy lại giống hệt trường mật khẩu của tài khoản mục tiêu, khiến phép so sánh được coi là khớp. Alpine xác định khoảng độ dài có thể kích hoạt đường khai thác là 257–1.024 byte; đây là đơn vị byte, không nên hiểu thành số ký tự trong mọi bảng mã.
Cơ chế này giải thích vì sao việc có thêm một người dùng đặt mật khẩu lại có thể làm thay đổi rủi ro của tài khoản khác. Tài khoản chứa hash cung cấp salt cho phép kiểm tra; tài khoản có dấu * mới là đích đăng nhập. Mật khẩu mạnh hơn ở tài khoản thứ nhất không giải quyết được lỗi so sánh của tài khoản thứ hai.
VPS cần kiểm tra sshd, không chỉ tên image Alpine
Với người quản trị VPS hoặc môi trường phát triển tại Việt Nam, ưu tiên hợp lý là rà soát máy thực sự chạy sshd và cho phép kết nối tới dịch vụ đó. Một container dùng Alpine làm nền nhưng chỉ chạy ứng dụng, không chạy sshd, không tự nhiên trở thành mục tiêu của đường khai thác này. Tên base image không đủ để kết luận máy đang bị ảnh hưởng.
Ngược lại, máy ảo nhỏ dùng Alpine và mở SSH cần được kiểm tra cấu hình xác thực ngay. Alpine cho biết các nhánh đã kiểm tra từ 3.21 đến 3.24, edge và các nhánh cũ từ 3.16 đến 3.20 đều có gói bị ảnh hưởng. Các hệ thống dùng glibc hoặc xác thực mật khẩu qua PAM không thuộc cơ chế lỗi đang được mô tả.
Quyền root cũng cần được xem riêng. Cấu hình mặc định PermitRootLogin prohibit-password bảo vệ root khỏi đăng nhập trực tiếp bằng mật khẩu, nhưng không loại bỏ nguy cơ khi tài khoản khác bị truy cập có quyền nâng lên root qua doas. Chặn root đăng nhập trực tiếp vì thế không thay thế được việc vá dịch vụ.
Cập nhật xong phải khởi động lại tiến trình sshd
Trên Alpine, hướng xử lý được công bố là cập nhật gói rồi khởi động lại sshd. Lệnh nâng cấp ghi phiên bản mới lên đĩa, còn tiến trình đang chạy không được thay thế chỉ nhờ thao tác đó. Với hệ thống dùng dịch vụ OpenRC của Alpine, thông cáo đưa ra các lệnh sau, thực hiện bằng quyền quản trị:
apk upgrade -U -a
rc-service sshd restartCác bản Alpine 3.21.10, 3.22.8, 3.23.8 và 3.24.4 đã chứa gói sửa lỗi. Không nhất thiết mọi nhánh ổn định đều hiển thị số phiên bản OpenSSH 10.6p2: Alpine cũng đưa bản vá vào các gói của từng nhánh. Vì vậy, cần đối chiếu phiên bản gói với thông cáo dành cho nhánh đang sử dụng thay vì chỉ tìm một số phiên bản upstream.
Nếu chưa thể cập nhật, đặt PasswordAuthentication no trong cấu hình sshd cũng đóng đường khai thác này. Trước khi đổi, phải xác nhận SSH key hoạt động và giữ phiên hiện tại cho đến khi thử thành công một kết nối mới, tránh tự mất quyền quản trị. Cần rà cả các khối Match, kiểm tra cấu hình bằng sshd -t rồi mới khởi động lại dịch vụ; không nên chỉ thêm một dòng mà bỏ qua các thiết lập theo từng nhóm người dùng.
Với máy từng phơi lộ, vá lỗi chưa đủ để xác định trước đó có bị truy cập hay không. Alpine khuyến nghị tìm dòng Accepted password trong /var/log/messages đối với tài khoản vốn không có mật khẩu, đồng thời rà việc dùng doas, người dùng mới và các khóa authorized_keys được thêm vào. Nếu không loại trừ được đăng nhập trái phép, cần xử lý máy như một hệ thống đã bị xâm nhập. Tại thời điểm thông cáo được công bố, lỗi chưa có mã CVE; quản trị viên không nên chờ mã định danh mới bắt đầu khắc phục.
Nguồn tham khảo: Alpine Linux; The Hacker News; Ars Technica.
