Lỗ hổng OpenSSH 10 năm trên Linux musl cho phép chiếm root
Một lỗ hổng tồn tại từ năm 2016 trong OpenSSH trên các hệ thống Linux dùng musl libc cho phép kẻ tấn công giành quyền root bằng cách nhập mật khẩu dài hơn 256 byte. OpenSSH 10.6p2 đã vá lỗi này.

Một lỗ hổng đã âm thầm tồn tại gần một thập kỷ trong OpenSSH vừa được công bố và vá. Trên một số hệ thống Linux dùng musl libc, kẻ tấn công có thể giành quyền root chỉ bằng cách nhập một mật khẩu dài hơn 256 byte.
Lỗ hổng được nhà nghiên cứu Özgün Kültekin (Wakefield) phát hiện và đặt tên là *sshole. Tuy vậy, nó chỉ khai thác được trong những điều kiện rất cụ thể.
Điều kiện khai thác
Lỗ hổng ảnh hưởng đến các hệ thống Linux dùng musl libc thay vì GNU C library (glibc) truyền thống. Ngay cả khi đó, hệ thống phải đang chạy dịch vụ shell bảo mật của OpenSSH (sshd) mà không có PAM (Pluggable Authentication Modules) và đã bật xác thực bằng mật khẩu.
Khi hội đủ các điều kiện trên, và có ít nhất một tài khoản khác chứa hash mật khẩu hợp lệ, những tài khoản lẽ ra không nhận đăng nhập mật khẩu — như root, tài khoản triển khai chỉ dùng khóa (key-only) hay người dùng LDAP — có thể bị truy cập bằng cách gửi mật khẩu dài từ 257 đến 1.024 ký tự.
Các tài khoản bị nhắm đến phải có dấu hoa thị (*) trong trường mật khẩu, và việc đăng nhập trực tiếp bằng root vẫn chịu sự ràng buộc của cấu hình OpenSSH.
Không hề "hiếm gặp" như tưởng
Nghe có vẻ là trường hợp đặc thù, nhưng không phải. Musl libc rất phổ biến trên các hệ thống Linux nhúng nhờ dung lượng nhỏ gọn. Quan trọng hơn, nó là thư viện C tiêu chuẩn của Alpine Linux — bản phân phối cung cấp ảnh cloud chính thức cho cả AWS và Azure. Vì vậy, một số hệ thống Alpine chạy trên các nền tảng này có thể bị ảnh hưởng tùy vào cấu hình.
Gốc rễ từ thời BSD Unix
Lỗ hổng trong OpenSSH trên Linux nền musl bắt nguồn từ năm 2016, nhưng Kültekin cho biết nguồn gốc của nó còn xa hơn — từ thời BSD Unix.
Năm 1980, Bill Joy — đồng sáng lập Sun Microsystems và là nhân vật quan trọng của BSD Unix — tham gia phát triển BSD Unix với file mật khẩu chứa một dấu hoa thị duy nhất trong mục /etc/passwd của người dùng daemon. Dấu hoa thị không phải hash mật khẩu, mà thực chất là vô hiệu hóa xác thực mật khẩu cho tài khoản đó.
Ngày nay, hash mật khẩu thường nằm trong /etc/shadow và chứa thông tin đã băm để hệ thống đối chiếu với mật khẩu dạng văn bản người dùng nhập. Dấu hoa thị vẫn xuất hiện ở các tài khoản không được phép đăng nhập bằng mật khẩu, nhưng theo Kültekin, đó không phải cách chặn truy cập hoàn toàn đáng tin cậy.
Hàm crypt() — dùng để sinh hash mật khẩu và so sánh với giá trị lưu trữ — có thể trả về NULL nếu không tính được hash. Các ứng dụng không kiểm tra kết quả này có thể bị sập. Thay vào đó, nhóm phát triển musl libc chọn trả về một ký tự đơn trong một số trường hợp lỗi — và họ chọn chính dấu hoa thị.
Musl cũng bổ sung cơ chế băm mật khẩu dựa trên SHA-512 cùng thời điểm đó. Kültekin lưu ý rằng cơ chế này càng chậm khi mật khẩu càng dài, có thể dẫn tới tấn công từ chối dịch vụ nếu ai đó dội vào máy chủ một mật khẩu siêu dài. Musl đã giới hạn mật khẩu ở 256 byte — và có lẽ bạn đã thấy hướng đi của câu chuyện.
Năm 2016, OpenSSH đưa vào một biện pháp khắc phục nhằm ngăn kẻ tấn công liệt kê tên tài khoản hợp lệ qua SSH. Trước thay đổi đó, sshd có thể từ chối nhanh hơn với người dùng không tồn tại so với tài khoản hợp lệ, do máy chủ phải băm mật khẩu được gửi lên trước khi từ chối. Giải pháp là buộc sshd thực hiện băm mật khẩu "giả" cho người dùng không hợp lệ, dùng thuật toán băm và salt phù hợp để giảm khác biệt về thời gian phản hồi.
Trên các hệ thống Linux nền musl bị ảnh hưởng, những tài khoản được đánh dấu bằng dấu hoa thị thay vì hash mật khẩu có thể bị mở khóa bằng cách gửi mật khẩu dài hơn 256 byte — lỗi bắt nguồn từ năm 2016. Bất kỳ hệ thống Linux nền musl nào chạy cấu hình OpenSSH dễ bị tổn thương mà không có PAM, đã bật xác thực mật khẩu, có ít nhất một tài khoản đánh dấu hoa thị và một tài khoản khác có hash mật khẩu hợp lệ đều có thể bị tấn công kiểu *sshole.
Cách khắc phục
May mắn là OpenSSH đã phản ứng nhanh. Bất kỳ bản dựng OpenSSH 10.6p2 (phát hành thứ Năm) trở lên đều được bảo vệ. Nếu không thể cập nhật OpenSSH trên hệ thống bị ảnh hưởng, chỉ cần tắt xác thực bằng mật khẩu và khởi động lại SSH daemon.
Chưa có dấu hiệu cho thấy các hệ thống dễ bị tổn thương đã bị khai thác, nhưng nếu muốn kiểm tra, Kültekin đã đưa vào bài viết của mình một lệnh CLI đơn giản để xem liệu tài khoản không mật khẩu nào trên máy quan trọng vừa nhận mật khẩu hay không.
Góc nhìn
Đối với lập trình viên và kỹ sư vận hành tại Việt Nam, đây là lời nhắc về cái giá của những cấu hình "đặc thù" trong hệ sinh thái container. Alpine Linux vốn được ưa chuộng vì image nhỏ và nhanh, nên nhiều dự án chạy trên nền musl mà không ai để ý rằng thư viện C ở đây xử lý lỗi khác glibc.
Việc cần làm rất cụ thể: kiểm tra phiên bản OpenSSH trên các máy chủ và image Docker nền Alpine, ưu tiên nâng lên 10.6p2 trở lên, và cân nhắc tắt xác thực mật khẩu, chuyển hẳn sang xác thực bằng khóa SSH. Với các hệ thống nhúng hoặc thiết bị công nghiệp khó cập nhật, việc rà soát lại cấu hình sshd và các tài khoản đánh dấu hoa thị nên được đưa vào quy trình kiểm tra định kỳ thay vì chờ đến khi có cảnh báo.
Nguồn: theregister.com · Quy trình biên tập


