Lỗi nghiêm trọng trên OpenSSH tại Alpine Linux cho phép đăng nhập bằng mật khẩu dài

Một lỗ hổng nghiêm trọng trong OpenSSH cho phép kẻ tấn công bỏ qua bước xác thực trên các cấu hình Alpine Linux cụ thể bằng cách gửi các mật khẩu quá dài. Dự án OpenSSH đã phát hành phiên bản 10.6p2 vào ngày 5 tháng 11 năm 2026 để giải quyết vấn đề này, trong khi Alpine Linux cũng đã áp dụng ngược (backport) các bản vá cho tất cả các phiên bản được hỗ trợ.

Chuyện gì đã xảy ra

Kẻ tấn công có quyền truy cập mạng có thể đăng nhập vào các tài khoản người dùng chưa đặt mật khẩu, chẳng hạn như những người dùng chỉ sử dụng khóa SSH hoặc tài khoản alpine mặc định trong các image cloud. Để thành công, kẻ tấn công cần biết tên tài khoản và phải cung cấp một mật khẩu có độ dài từ 257 đến 1.024 byte. Lỗi này ảnh hưởng cụ thể đến các hệ thống chạy gói openssh-server tiêu chuẩn trên Alpine Linux, vốn được xây dựng mà không có giao diện Module Xác thực Cắm ghép (PAM).

Lỗ hổng xuất phát từ sự tương tác giữa logic kiểm tra mật khẩu của OpenSSH và musl, thư viện C được Alpine sử dụng. Khi xác thực bằng mật khẩu được bật và ít nhất một tài khoản cục bộ khác có chứa hash mật khẩu, máy chủ sẽ chấp nhận sai mật khẩu dài đó cho bất kỳ tài khoản nào có trường mật khẩu trống. Mặc dù chưa có báo cáo về các cuộc khai thác đang hoạt động, đội ngũ OpenSSH đã đánh giá mức độ nghiêm trọng của lỗi là critical (nghiêm trọng) và kêu gọi biện pháp giảm thiểu ngay lập tức.

Damien Miller từ dự án OpenSSH nhấn mạnh tính cấp bách, tuyên bố rằng quản trị viên nên "đặt PasswordAuthentication=no hoặc tắt SSH cho các hệ thống này NGAY LẬP TỨC." Bản vá được phát hành nhanh chóng, với việc Miller lưu ý rằng các thời gian chờ công bố (embargo) kéo dài ngày càng nguy hiểm vì các tác nhân AI có thể tái khám phá những lỗi như vậy chỉ trong vài giờ.

Cơ chế hoạt động

Nguyên nhân gốc rễ nằm ở cách sshd xử lý việc xác minh mật khẩu khi PAM không được sử dụng. Thông thường, sshd băm mật khẩu được cung cấp bằng hàm crypt() và so sánh nó với hash được lưu trữ trong /etc/shadow. Các tài khoản không có mật khẩu sẽ có ký tự * trong trường này. Vì * quá ngắn để chứa salt, sshd mượn salt từ một tài khoản khác có chứa hash mật khẩu.

Khi kẻ tấn công gửi một mật khẩu dài hơn 256 byte, hàm crypt() của musl từ chối xử lý và trả về * để báo hiệu lỗi. Vì trường lưu trữ của tài khoản mục tiêu cũng là *, phép so sánh thành công và máy chủ cấp quyền truy cập. Hành vi này bắt nguồn từ một thay đổi năm 2012 trong musl nhằm ngăn chặn sự cố sập chương trình ở các ứng dụng không kiểm tra lỗi của crypt(), kết hợp với một thay đổi năm 2016 của OpenSSH nhằm ngăn chặn việc liệt kê tên người dùng.

Phiên bản mới, 10.6p2, giới thiệu một giải pháp tạm thời từ chối mọi khớp nếu trường mật khẩu được lưu trữ ngắn hơn bốn ký tự. Mặc dù điều này ngăn chặn được cuộc tấn công, đội ngũ OpenSSH lưu ý rằng vấn đề cơ bản nằm ở cách thư viện C xử lý đầu vào dài chứ không phải ở chính SSH.

Chi tiết quan trọng

• Hệ thống bị ảnh hưởng: Alpine Linux chạy openssh-server không có PAM, hoặc openssh-server-pam với cấu hình UsePAM no.
• Điều kiện tiên quyết: PasswordAuthentication phải được đặt là yes, ít nhất một tài khoản phải có hash $5$ hoặc $6$, và tài khoản mục tiêu phải có * trong trường mật khẩu.
• Vector tấn công: Một lần thử kết nối duy nhất với mật khẩu dài từ 257 đến 1.024 byte sẽ thành công mỗi lần.
• Mục tiêu rủi ro cao: Người dùng alpine trong các image tiny-cloud (phiên bản 3.18.11 đến 3.24.3) dễ bị tổn thương khi có bất kỳ hash mật khẩu nào tồn tại trên hệ thống, có khả năng cho phép truy cập root thông qua doas.
• Hệ thống không bị ảnh hưởng: Các bản phân phối Linux sử dụng glibc, các hệ thống sử dụng PAM cho xác thực và thiết bị OpenWrt sử dụng Dropbear.
• Khả năng sửa chữa: OpenSSH 10.6p2 hiện đã có sẵn; Alpine đã cập nhật các gói cho các phiên bản từ 3.16 đến 3.24.

Tại sao điều này quan trọng

Đối với các kỹ sư xây dựng hạ tầng trên Alpine Linux, lỗ hổng này làm suy yếu bảo mật của các thiết lập xác thực chỉ dùng khóa. Nhiều nhà phát triển dựa vào Alpine nhờ kích thước nhỏ gọn trong container và instance cloud, thường giả định rằng việc tắt đăng nhập bằng mật khẩu hoặc sử dụng khóa SSH cung cấp đủ sự bảo vệ. Tuy nhiên, vì PasswordAuthentication được bật theo mặc định trong nhiều cấu hình, các hệ thống này vẫn bị lộ trừ khi chúng được gia cố rõ ràng.

Sự cố này cũng nêu bật áp lực ngày càng tăng đối với những người bảo trì mã nguồn mở trong việc phát hành bản vá nhanh chóng. Quyết định bỏ qua thời gian chờ công bố truyền thống phản ánh bối cảnh mối đe dọa đang thay đổi, nơi các công cụ tự động có thể đảo ngược quy trình để tìm ra lỗ hổng rất nhanh. Các nhóm hiện nay phải ưu tiên chu kỳ vá lỗi nhanh và giả định rằng chi tiết kỹ thuật của các lỗi nghiêm trọng có thể trở thành kiến thức công khai gần như ngay lập tức sau khi được khám phá.

Bạn có thể làm gì

• Cập nhật các gói Alpine của bạn ngay lập tức bằng cách sử dụng apk upgrade -U -a và khởi động lại dịch vụ SSH với rc-service sshd restart.
• Nếu bạn không thể cập nhật ngay, hãy tắt xác thực bằng mật khẩu bằng cách đặt PasswordAuthentication no trong cấu hình SSH của bạn.
• Xác minh các thay đổi cấu hình bằng cách chạy sshd -T | grep -i passwordauthentication để đảm bảo nó trả về no.
• Kiểm tra /var/log/messages để tìm các mục hiển thị Accepted password for cho những người dùng như root hoặc alpine, những người lẽ ra không nên có quyền truy cập bằng mật khẩu.
• Xem xét việc sử dụng doas và các người dùng mới tạo gần đây trên bất kỳ máy nào có khả năng bị lộ, coi chúng là đã bị xâm phạm nếu tìm thấy hoạt động đáng ngờ.
• Kiểm toán các hệ thống dựa trên musl khác như Buildroot hoặc Yocto nếu chúng chạy OpenSSH, mặc dù OpenWrt thường an toàn nếu sử dụng Dropbear.