Red Hat 389 Directory Server bị nhầm danh tính SASL, cho phép leo thang lên quyền Directory Manager

Một lỗi được phát hiện trong 389 Directory Server. Trong quá trình xác thực SASL PLAIN, một danh tính cũ còn lưu trong thuộc tính phụ của Cyrus SASL từ một lần bind thất bại trước đó có thể được cài đặt lên một connection sau một lần bind thành công khác, không liên quan, bất kể mechanism SASL nào hoàn tất lần bind thứ hai. Attacker có thể gửi một SASL PLAIN bind với danh tính cn=Directory Manager và mật khẩu không đúng, sau đó hoàn tất một SASL ANONYMOUS bind trên cùng connection, khiến server cấp quyền Directory Manager mà không cần bất kỳ credential hợp lệ nào. Cũng có thể thực hiện một biến thể bằng cách dùng lần bind thành công của chính một tài khoản hợp lệ có quyền thấp thay cho lần bind anonymous.

Tất cả mục affected trong bản ghi chuẩn hóa đều có default_status: affected; bản ghi không cung cấp các khoảng version chi tiết. Các nhánh bị ảnh hưởng gồm:

• Red Hat Directory Server 11.7 E4S for RHEL 8 và Red Hat Directory Server 11.9 for RHEL 8, package redhat-ds:11.
• Red Hat Directory Server 12.2 E4S for RHEL 9 và Red Hat Directory Server 12.4 E4S for RHEL 9, package redhat-ds:12.
• Red Hat Directory Server 12, package 389-ds-base.
• Red Hat Enterprise Linux 6 Extended Lifecycle Support - EXTENSION và Red Hat Enterprise Linux 7 Extended Lifecycle Support, package 389-ds-base.
• Red Hat Enterprise Linux 8, cùng các nhánh Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, 8.4 Extended Update Support Long-Life Add-On, 8.6 Advanced Mission Critical Update Support, 8.6 Extended Update Support Long-Life Add-On, 8.8 Telecommunications Update Service và 8.8 Update Services for SAP Solutions, sử dụng package 389-ds:1.4.
• Red Hat Enterprise Linux 9, cùng các nhánh 9.2 Update Services for SAP Solutions, 9.4 Update Services for SAP Solutions và 9.6 Extended Update Support, sử dụng package 389-ds-base.
• Red Hat Enterprise Linux 10 và Red Hat Enterprise Linux 10.0 Extended Update Support, package 389-ds-base.

Các comment errata trong hồ sơ Red Hat cho biết vấn đề đã được address trong từng nhánh sản phẩm được liên kết với các advisory tương ứng. Trạng thái fixed cụ thể của mục Red Hat Directory Server 12 chung không được thể hiện bằng một version duy nhất trong bằng chứng đã trả về.

Lỗi nằm trong luồng xử lý SASL bind của 389-ds-base, thuộc nhóm CWE-287, Improper Authentication. Hàm ids_sasl_canon_user() ghi DN đã phân giải vào thuộc tính phụ của Cyrus SASL trong mỗi lần canonicalization, kể cả khi lần xác thực thất bại. Một lần trao đổi PLAIN một bước bị lỗi không làm tạo lại SASL context; lần bind SASL thành công tiếp theo trên cùng connection đọc thuộc tính bằng prop_getnames() rồi tin tưởng vô điều kiện giá trị đầu tiên dnval[0].values[0], không kiểm tra mechanism, độ mới của giá trị hoặc sự khớp với danh tính vừa xác thực.

Luồng ảnh hưởng đã được xác nhận ở mức triển khai như sau:

• Một SASL PLAIN bind thất bại có thể để lại DN cn=Directory Manager trong thuộc tính phụ.
• Một bind SASL thành công, không liên quan, trên cùng connection có thể khiến server lấy lại DN cũ, kể cả khi mechanism thứ hai là SASL ANONYMOUS.
• Server sau đó cài đặt danh tính cũ thay cho danh tính thực sự vừa được xác thực và cấp quyền Directory Manager.

Root cause được xác định trong ldap/servers/slapd/saslbind.c, tại ids_sasl_canon_user() và ids_sasl_check_bind(). Chi tiết về bản vá nội bộ, chẳng hạn cách server làm mới hoặc xóa thuộc tính phụ, không được nêu trong các bằng chứng đã trả về.

Lỗ hổng có thể bị khai thác qua mạng trên connection LDAP được Red Hat mô tả là LDAPS, không cần user interaction và không cần attacker có tài khoản trong biến thể không cần credential. Điều kiện chính là server cho phép SASL PLAIN trong cơ chế xác thực được cấu hình; Red Hat nêu rằng không cần cấu hình ngoài mặc định để xảy ra chuỗi lỗi này. Biến thể khác yêu cầu attacker có một tài khoản hợp lệ với quyền thấp và dùng chính bind thành công của tài khoản đó ở bước thứ hai.

Bằng chứng được cung cấp ghi nhận Red Hat đã xác nhận hành vi trong sandbox cô lập, nhưng không xác nhận một public exploit hoặc chiến dịch khai thác thực tế. Trường public_exploit trong bản ghi được đánh dấu là false; điều này không chứng minh rằng chưa từng có khai thác ngoài thực tế.

Kết quả kỹ thuật là server có thể cài đặt một DN cũ, có đặc quyền cao, thay cho danh tính vừa hoàn tất xác thực. Trong biến thể không cần credential, attacker có thể đạt quyền Directory Manager từ xa; trong biến thể còn lại, một tài khoản quyền thấp có thể được nâng quyền trên cùng connection. Quyền này có khả năng cho phép đọc dữ liệu, thay đổi nội dung hoặc cấu hình thư mục và ảnh hưởng đến tính sẵn sàng của các dịch vụ phụ thuộc.

Phạm vi tác động được giới hạn bởi các server và nhánh package thực sự chứa code dễ lỗi, cũng như việc SASL PLAIN phải được cho phép để bắt đầu chuỗi lỗi. Bản ghi không xác nhận rằng mọi thao tác Directory Manager đều sẽ thành công trong mọi deployment, vì ACL, plugin và cấu hình dịch vụ có thể thay đổi kết quả.

Nếu khai thác thành công, attacker có thể được server xem như Directory Manager, tức là có quyền cao nhất trong dịch vụ thư mục bị ảnh hưởng. Hậu quả có thể gồm:

• Đọc dữ liệu thư mục và các thuộc tính chỉ dành cho Directory Manager.
• Thay đổi danh tính, nhóm, quyền truy cập hoặc cấu hình LDAP nếu các thao tác đó được Directory Manager cho phép.
• Làm gián đoạn dịch vụ thư mục hoặc làm sai lệch dữ liệu mà các hệ thống phụ thuộc sử dụng.

Bản ghi không xác nhận một vụ rò rỉ, thay đổi dữ liệu hoặc gián đoạn cụ thể nào đã xảy ra. Mức độ thiệt hại thực tế phụ thuộc vào dữ liệu, ACL và các hệ thống sử dụng Directory Server.

1. Ưu tiên áp dụng Red Hat security errata phù hợp với từng sản phẩm, kiến trúc và nhánh hỗ trợ. Các advisory được liên kết trong hồ sơ gồm RHSA-2026:64771, RHSA-2026:64776, RHSA-2026:64778, RHSA-2026:64779, RHSA-2026:64780, RHSA-2026:64781, RHSA-2026:64783, RHSA-2026:64784, RHSA-2026:64785, RHSA-2026:64789, RHSA-2026:64790, RHSA-2026:64791, RHSA-2026:64792, RHSA-2026:64793, RHSA-2026:64804 và RHSA-2026:64811.
2. Xác minh sau khi cập nhật rằng package đang chạy trên server thực sự là package đã được Red Hat cung cấp qua advisory tương ứng. Không dùng một version package upstream duy nhất để kết luận an toàn, vì Red Hat có thể backport bản vá.
3. Nếu chưa thể cập nhật ngay, giới hạn nsslapd-allowed-sasl-mechanisms chỉ còn các mechanism thực sự cần thiết và loại bỏ PLAIN. Red Hat nêu các ví dụ như GSSAPI, EXTERNAL và GSS-SPNEGO. Biện pháp này ngăn bước bind PLAIN thất bại dùng để tạo danh tính còn sót, qua đó chặn cả biến thể dùng SASL ANONYMOUS và biến thể dùng tài khoản quyền thấp.
4. Đánh giá tác động tương thích trước khi loại bỏ PLAIN, sau đó kiểm tra lại các ứng dụng và integration phụ thuộc vào cơ chế này. Đây là mitigation, không thay thế việc triển khai security update.
5. Nếu hệ thống đã có khả năng bị khai thác, rà soát các thay đổi LDAP, quyền Directory Manager, cấu hình dịch vụ và dữ liệu nhạy cảm kể từ thời điểm nghi vấn. Bản ghi không cung cấp một quy trình khôi phục hoặc IOC cụ thể.

Thực hiện các bước kiểm tra sau:

1. Lập inventory các máy chạy Red Hat Directory Server hoặc package 389-ds-base, bao gồm các triển khai trên Red Hat Enterprise Linux 6, 7, 8, 9 và 10 cùng các nhánh EUS, E4S, AUS, TUS hoặc SAP được liệt kê trong bản ghi.
2. Đối chiếu package và trạng thái errata với advisory Red Hat tương ứng của từng nhánh. Không suy luận an toàn chỉ từ upstream package version, vì Red Hat có thể backport bản vá vào package cũ.
3. Nếu hệ thống lưu bind outcome và connection identifier, rà soát các connection có một SASL PLAIN bind thất bại rồi tiếp tục bằng một bind SASL thành công khác mechanism, đặc biệt khi quyền sau bind cao hơn danh tính vừa xác thực.
4. Trong môi trường kiểm thử được cô lập và có phê duyệt, kiểm tra tính nhất quán giữa danh tính mà server báo sau bind và danh tính thực sự của bind vừa hoàn tất. Không thực hiện chuỗi xác thực này trên production.
5. Nếu phát hiện connection đã được gán quyền Directory Manager sau một bind không hợp lệ, cô lập máy chủ, bảo toàn log và điều tra các thao tác LDAP đã thực hiện. Việc không thấy log phù hợp không chứng minh hệ thống an toàn.