Những điểm chính của ZDNET

• Một lỗi cổ đang ảnh hưởng đến Alpine Linux và một số bản phân phối Linux khác.
• Nó tệ đến mức có thể xảy ra.
• Bạn phải vá càng sớm càng tốt, sau đó khởi động lại phần mềm đã vá.

Kịch bản ác mộng hoàn hảo đối với máy chủ Linux là khi tất cả những gì kẻ tấn công cần làm là tiếp cận cổng Secure Shell (SSH) của máy chủ, đột nhập ngay và chiếm lấy nó. Đó là những gì đã xảy ra với Alpine Linux, máy chủ Linux nhẹ và phổ biến. Thêm sự xúc phạm đến thương tích, điều này xảy ra chỉ vài ngày sau khi Alpine Linux né được một viên đạn có kích thước lỗ hổng bảo mật trong quá trình triển khai GitLab của mình.

Cách thức hoạt động của cuộc tấn công

Như kỹ sư bảo mật Gregory Bryant đã giải thích trong bài đăng trên LinkedIn của mình:

Hầu hết các bước bỏ qua xác thực đều đến từ các chuỗi logic phức tạp, nhưng lỗ hổng Alpine Linux OpenSSH ngày hôm qua (CVE-2026-123158) lại bắt nguồn từ một ký tự duy nhất: *.”

Nếu bạn chạy Alpine Linux (hoặc một bản phân phối dựa trên musl khác) với gói openssh-server mặc định (không có Mô-đun xác thực có thể cắm (PAM)) và bật Xác thực mật khẩu, kẻ tấn công có thể đăng nhập vào các tài khoản bị vô hiệu hóa mật khẩu hoặc chỉ có khóa chỉ bằng cách gửi mật khẩu dài từ 257 đến 1024 byte.

Thế thôi. Thế thôi.

Alpine Linux không phải là hệ điều hành duy nhất sử dụng musl, một phiên bản nhẹ của thư viện C tiêu chuẩn (libc). Các hệ điều hành khác sử dụng musl và có khả năng bị tấn công bao gồm Adélie Linux; Linux trống; Phá hoại Linux; OpenWrt, một biến thể của Android và Dự án Yocto, được sử dụng để xây dựng các bản phân phối Linux nhúng.

Wind River, hãng sản xuất bản phân phối Linux nhúng thương mại, Wind River Linux, cũng đang xem xét vấn đề này. Một đại diện của công ty nói với tôi: "Wind River rất coi trọng vấn đề bảo mật. Chúng tôi đang tích cực xem xét lỗ hổng được báo cáo và đánh giá tác động tiềm ẩn của nó. Chúng tôi sẽ thực hiện hành động thích hợp nếu cần."

Đằng sau hậu trường, khi OpenSSH được xây dựng mà không có PAM, nó sẽ xác minh mật khẩu bằng cách băm mật khẩu bằng hàm crypt() của thư viện C. Sau đó, nó so sánh kết quả với trường mật khẩu được lưu trữ của tài khoản. Cho đến nay, rất tốt.

Nhưng khi một khóa dài hơn 256 byte, hàm crypt() của musl sẽ trả về chuỗi * làm chỉ báo lỗi. Đó cũng là những gì trường mật khẩu áp dụng cho bất kỳ tài khoản nào không có mật khẩu, chẳng hạn như tài khoản chỉ có khóa. Do đó, “băm” khớp và đăng nhập thành công và kẻ tấn công bước vào.

Để khai thác nó, kẻ tấn công chỉ cần tên của tài khoản đó. Kẻ tấn công cũng cần ít nhất một tài khoản khác trên máy có mật khẩu băm 5 hoặc 6, sau đó gửi mật khẩu từ 257 đến 1.024 byte. Theo Alpine, một người dùng có mật khẩu là đủ để mọi tài khoản không cần mật khẩu đều có thể truy cập được.

Trong các hệ thống Linux sử dụng crypt() của glibc, gần như tất cả chúng, nỗ lực tương tự sẽ trả về lỗi NULL, điều mà sshd đã từ chối, vì vậy Debian, Ubuntu, Fedora, v.v., không bị ảnh hưởng.

Theo *sshole, nhóm phát hiện ra vấn đề, đây là một tác dụng phụ đã được che giấu từ năm 2016.

Ai bị lộ

Alpine cho biết mọi bản phát hành mà nó kiểm tra đều bị ảnh hưởng: 3,21 đến 3,24, cạnh và các nhánh cũ hơn là 3,16 đến 3,20. Việc tiếp xúc đòi hỏi những điều sau:

• Gói openssh-server được xây dựng không có PAM hoặc openssh-server-pam có UsePAM no.
• Xác thực mật khẩu được đặt thành có, đây là OpenSSH mặc định.
• Một tài khoản có * làm trường mật khẩu và một tài khoản khác có hàm băm 5 hoặc 6.

Root không được tiếp xúc trực tiếp trong hầu hết các trường hợp. Nó đã được vận chuyển dưới dạng root:* trong hình ảnh cơ sở kể từ khoảng Alpine 3.16, nhưng mật khẩu cấm PermitRootLogin mặc định của OpenSSH đã chặn nó. Một tài khoản khác có thể trở thành root, chẳng hạn như thông qua doas, vẫn cung cấp cho kẻ tấn công một lộ trình để root.

Alpine đã chỉ ra các hình ảnh đám mây nhỏ chính thức của mình, các phiên bản 3.18.11 đến 3.24.3, là đặc biệt dễ bị tấn công. Những thứ này được cung cấp cho người dùng Alpine với trường mật khẩu * và doas không cần mật khẩu. Chúng an toàn trong lần khởi động đầu tiên nhưng có thể bị khai thác khi có 6 hàm băm bất kỳ tồn tại trên máy. Điều đó có thể xảy ra khi quản trị viên đặt mật khẩu bảng điều khiển hoặc khi dữ liệu người dùng thêm người dùng bằng mật khẩu băm, về cơ bản có nghĩa là tất cả chúng.

Alpine cho biết những điều này không bị ảnh hưởng:

• Container không chạy sshd.
• Hệ thống bị vô hiệu hóa xác thực mật khẩu.
• Hệ thống sử dụng openssh-server-pam với UsePAM có.
• Tài khoản bị khóa với! trong trường mật khẩu.
• Hình ảnh đám mây được định cấu hình thông qua cloud-init, ghi Số xác thực mật khẩu.

Cách khắc phục

Alpine đã phát hành 3.21.10, 3.22.8, 3.23.8 và 3.24.4 vào thứ Năm, với bản sửa lỗi OpenSSH cùng với các thay đổi về bảo mật. Nó cũng xuất bản các gói cố định cho mỗi bản phát hành trở lại phiên bản 3.16. Alpine 3.21 đã hết hỗ trợ vào ngày 1 tháng 11.

OpenSSH 10.6p2 vừa được phát hành sẽ tránh được sự cố trong sshd. Các nhánh ổn định của Alpine mang theo một bản vá cho vấn đề tương tự. Bạn nên chạy apk nâng cấp -U -a và sau đó khởi động lại daemon bằng rc-service sshd restart. Alpine nhấn mạnh rằng việc nâng cấp gói không thay thế daemon đang chạy. Bất kỳ ai không thể cập nhật nên đặt Số xác thực mật khẩu và khởi động lại sshd, sau khi xác nhận rằng khóa đăng nhập hoạt động.

Để kiểm tra xem có bị tấn công hay không, Alpine đã yêu cầu quản trị viên tìm kiếm /var/log/messages để tìm dòng “Accepted pass for” có tên tài khoản không có mật khẩu. Nó cũng khuyên nên xem xét việc sử dụng trình thực thi con (doas) ứng dụng OpenBSD chuyên dụng cũng như những người dùng, tệp và khóa được ủy quyền được tạo gần đây. “Nếu bạn không thể loại trừ việc đăng nhập, hãy coi máy như bị xâm phạm.” Tôi biết đó chỉ là điều bạn muốn cho ngày cuối tuần của mình, nhưng chúng ta đang ở đây.