Personal Ops Runbook

Bối cảnh

Ceph phát hành hotfix Tentacle 20.2.4 và Squid 19.2.6 ngày 19/08/2026 để vá 4 CVE trên nhiều thành phần, và khuyến cáo mọi operator nâng cấp càng sớm càng tốt. Đây là đợt vá đánh dấu [URGENT] — không phải bản backport thông thường.

Lưu ý quan trọng về mức độ: Ceph không công bố điểm CVSS dạng số trên các trang này, chỉ công bố breakdown định tính (Confidentiality / Integrity / Availability / Access Complexity / Authentication / Gained Access). Các con số ước lượng bên dưới là đánh giá của tôi dựa trên breakdown đó, không phải điểm chính thức.

Bảng tổng hợp 4 CVE

Chi tiết từng CVE

CVE-2025-30156 — CephX auth bypass (quan trọng nhất với bạn)

Cơ chế mã hóa AES-128-CBC của CephX không có xác thực: không HMAC, và dùng IV hard-code. Đây chính là điểm yếu MIT đã ghi nhận với Kerberos 4 trong paper PERILS năm 2004. IV cố định khiến plaintext giống nhau tạo ra ciphertext giống nhau, làm lộ việc hai giá trị mã hóa có bằng nhau hay không. Việc thiếu xác thực còn tệ hơn — kẻ tấn công có thể lật bit trong ciphertext, thay đổi dữ liệu bên dưới mà không có gì phát hiện được.Kẻ tấn công chỉ cần một key quyền thấp đã bị lộ, ví dụ credential của client, hoặc một vị trí quan sát được ciphertext CephX trên mạng, rồi thao túng service ticket mã hóa từ Monitor. Một PoC của David Mohren (CLYSO) đã chứng minh có thể chiếm quyền admin toàn cluster.

Đáng lo nhất là phần Access Complexity: có một hướng tấn công chỉ cần lật bit CBC trên trường allow_all của cấu trúc AuthTicket mã hóa là giành được quyền admin cho OSD, MDS và MGR. Nghĩa là biến thể dễ nhất không đòi hỏi kỹ thuật mật mã phức tạp.

Phiên bản bị ảnh hưởng: tất cả phiên bản Ceph trước đó và mọi credential dùng key type aes.

Bản vá giới thiệu AES256-CTS-HMAC-SHA384-192, key type an toàn dựa trên RFC 8009 (chuẩn Kerberos 5). Mỗi thao tác mã hóa sinh một confounder ngẫu nhiên 128-bit; HMAC-SHA384 cung cấp xác thực thông điệp, phát hiện giả mạo và ngăn tấn công lật bit; ciphertext stealing loại bỏ padding nên chặn được padding oracle.

Một chi tiết đáng chú ý về nguồn gốc phát hiện: lỗ hổng được Erin Shepherd (e43.eu) báo cáo, sau đó độc lập bởi David Mohren và Mark Nelson (CLYSO), và cũng được David Korczynski của Ada Logics báo cáo và xác nhận — do Anthropic dùng agent nghiên cứu bảo mật các dự án mã nguồn mở tìm ra.

CVE-2026-39944 — RGW STS token

STS session token của RGW dùng chung handler AES-128-CBC không xác thực với CVE-2025-30156. Vì ciphertext không được xác thực, kẻ tấn công nắm bất kỳ STS token hợp lệ nào cũng có thể lật bit các trường acct_type và is_admin mà không bị phát hiện. Giá trị is_admin giả mạo kích hoạt override is_admin() toàn cục trong rgw_process_authenticated(), bỏ qua toàn bộ ràng buộc check_caps() và trao quyền RGW admin đầy đủ.Điều kiện: chỉ cần một STS token không có đặc quyền mà kẻ tấn công đã có sẵn, và STS phải được bật (rgw_s3_auth_use_sts = true).

→ Nếu bạn không bật STS thì CVE này không áp dụng. Đây là điểm bạn nên kiểm tra ngay.

CVE-2026-50152 — Monitor config-key store

Bất kỳ user CephX nào có cap mon allow r đều có thể đọc toàn bộ config-key store của Monitor bằng cách gửi một message MMonSubscribe được chế tác. Config-key store lưu nhiều secret của Ceph, bao gồm passphrase LUKS của OSD và — trên cluster quản lý bởi cephadm — SSH private key mà cephadm dùng để xác thực trên mọi host Ceph.Access Complexity là Low: một message MMonSubscribe duy nhất dump deterministic toàn bộ store, không cần điều kiện gì thêm.

Kẻ tấn công lấy được SSH key của cephadm có thể gián tiếp có root trên mọi host cephadm quản lý.

Đây là CVE dễ khai thác nhất trong 4 cái — và cũng là cái để lại "hậu quả tồn dư" sau khi vá, vì secret đã có thể bị lộ từ trước.

CVE-2026-54330 — RGW SigV4

AWS S3 yêu cầu mọi header x-amz-* trên request SigV4 phải được ký và từ chối request mang header chưa ký. RGW thì không — nó chỉ kiểm tra các header liệt kê trong X-Amz-SignedHeaders và bỏ qua phần còn lại, nên header x-amz-* chưa ký lọt qua kiểm tra chữ ký.Kẻ tấn công chỉ cần một presigned PUT URL là có thể dùng x-amz-copy-source cùng ACL public-read để đọc mọi object mà identity của người ký truy cập được, và ghi/sửa ACL của object đích.

Availability: None.Khuyến cáo của Ceph khá gắt: nếu chưa vá được, không nên dùng tính năng presigned URL trong bất kỳ hoàn cảnh nào.

Yêu cầu về kernel

Đây là phần bạn hỏi và cũng là điểm dễ vấp nhất:

Nên nâng cấp client và kernel để hỗ trợ aes256k. Hỗ trợ trong kernel client Linux thượng nguồn bắt đầu từ kernel 7.0 và đã được backport về CentOS Stream 9 và 10. Cần kiểm tra với nhà cung cấp distro xem có backport chưa trước khi rotate client key dùng bởi kernel.

Điểm mấu chốt: nâng cấp client/kernel là khuyến nghị để hỗ trợ key type mới, nhưng không bắt buộc để xử lý phần nghiêm trọng nhất của lỗ hổng. Toàn bộ package/container daemon Ceph thì bắt buộc phải nâng.

Cảnh báo thực tế: nếu bạn dùng kernel client (kernel RBD krbd, hoặc CephFS kernel mount) trên kernel cũ chưa backport aes256k, mà bạn rotate key của client đó sang aes256k, client sẽ mất khả năng xác thực. Đây là kịch bản tự khóa cửa. Ở VN đa số cluster chạy Ubuntu LTS hoặc Rocky/Alma — kernel 7.0 gần như chắc chắn chưa có, nên bạn phải xác minh backport trước.

Sáu health warning/error mới sẽ xuất hiện

Trong quá trình nâng cấp, sáu health warning và error mới sẽ được sinh ra. Đây là bình thường — bạn xử lý chúng dần theo tiến trình rotate key.

Thêm một cái thứ bảy chỉ xuất hiện khi bạn tự cứu cluster: AUTH_EMERGENCY_CIPHERS_SET.

Thứ tự xử lý bắt buộc (làm sai thứ tự sẽ mất quyền admin):

1. AUTH_INSECURE_SERVICE_TICKETS → ceph mon set auth_service_cipher aes256k, chỉ làm khi mọi service daemon đã nâng lên phiên bản hỗ trợ cipher mới
2. AUTH_INSECURE_SERVICE_KEY_TYPE → rotate từng daemon: ceph auth rotate --key-type=aes256k mds.a > MDS_A_KEYRING, phải lưu key mới vào keyring của daemon nếu không nó sẽ không xác thực được
3. AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE → chỉ xử lý được sau khi resolve AUTH_INSECURE_SERVICE_TICKETS; sẽ tự hết khi key hết hạn theo auth_service_ticket_ttl (mặc định 3600s), hoặc ép bằng ceph auth wipe-rotating-service-keys — nhưng wipe sẽ vô hiệu hóa ticket của mọi client hiện có, chỉ daemon và client đã nâng cấp mới biết cách lấy key mới. Bạn gần như chắc chắn không muốn làm thủ công.
4. AUTH_INSECURE_CLIENT_KEY_TYPE → rotate từng client. Nếu còn client legacy chưa hỗ trợ, khuyến nghị mute warning này thay vì cố xử lý.
5. AUTH_INSECURE_KEYS_ALLOWED → cuối cùng: ceph mon set auth_allowed_ciphers aes256k

Cảnh báo từ docs: thay đổi allowed cipher có thể làm mất quyền admin vào cluster (nếu không có biện pháp khẩn cấp). Nếu admin key của bạn đang dùng cipher cũ, hãy rotate nó sang key type an toàn và lưu vào keyring trước. Đừng cố resolve AUTH_INSECURE_KEYS_ALLOWED trước AUTH_INSECURE_SERVICE_KEY_TYPE.

Đường cứu hộ nếu tự khóa: dùng mon_auth_emergency_allowed_ciphers qua tham số dòng lệnh ceph-mon hoặc ceph.conf cục bộ — MON sẽ ưu tiên config này hơn setting mon. Ghi lại cái này trước khi bắt đầu.

Checklist triển khai

Vì bạn sắp triển khai, tin tốt là bạn ở vị thế thuận lợi hơn người phải upgrade cluster đang chạy: cài đặt mới sẽ tự động dùng key type an toàn.

Nếu deploy mới: cài thẳng 20.2.4 hoặc 19.2.6 trở lên. Đừng deploy version cũ rồi upgrade sau — bạn sẽ tự chuốc lấy toàn bộ quy trình rotate key ở trên. Vẫn cần kiểm tra kernel client trước khi ép auth_allowed_ciphers aes256k.

Nếu upgrade cluster có sẵn — làm trước khi bắt đầu:

1. Đọc kỹ quy trình rotate key — operator cần làm quen với quy trình upgrade CephX key trước khi nâng cấp. Đây là lần đầu Ceph đổi key type CephX, chưa ai có kinh nghiệm sẵn.
2. Nếu chạy multisite RGW: bắt buộc đặt rgw_sigv4_insecure = true TRƯỚC khi bắt đầu upgrade, và đặt lại false sau khi tất cả cluster đã upgrade xong. Lý do: REST client dùng trong multisite lại đang sinh ra chính loại request ký sai mà bản vá sẽ từ chối. Bỏ sót bước này = đứt replication.
3. Kiểm kê kernel client — liệt kê mọi node dùng krbd/CephFS kernel mount, xác minh backport aes256k với vendor distro. Chưa có backport thì đừng rotate key của client đó.
4. Rotate SSH key của cephadm — được khuyến nghị mạnh cho cluster cephadm, theo quy trình đã có trong tài liệu SSH Configuration. Hướng dẫn chính thức về rotate toàn bộ secret trong config-key store sẽ có sau; hiện tại operator tự đánh giá mức phơi nhiễm của cluster mình để quyết định có cần rotate ngay không.
5. Nếu dùng cephadm: quy trình được tự động hóa trừ client key. Cephadm sẽ mất nhiều thời gian hơn bình thường sau khi update image của các daemon — do tiến trình rotate key OSD và MDS. Cần kiên nhẫn. Đừng tưởng bị treo mà kill giữa chừng.
6. Nếu dùng Rook: cũng tự động rotate một số client key, với vài ngoại lệ — xem thông báo từ dự án Rook.
7. Kiểm tra STS — ceph config get client.rgw rgw_s3_auth_use_sts. Nếu đang bật, CVE-2026-39944 áp dụng trực tiếp.
8. Kiểm tra presigned URL — nếu ứng dụng của bạn dùng, đó là vector CVE-2026-54330.

Một tài liệu tham khảo thêm nếu bạn muốn hiểu sâu: có một talk tại Cephalocon 2025 của Patrick Donnelly (IBM) và Yehuda Sadeh-Weinraub (Ubiquiti) trình bày chi tiết quy trình upgrade CephX key mới.

Nếu bạn cho tôi biết bạn định deploy bằng cephadm hay package, phiên bản OS/kernel, và có dùng RGW multisite không, tôi có thể thu hẹp checklist này thành một quy trình cụ thể cho môi trường của bạn.