PostgreSQL đã phát hành các bản cập nhật để khắc phục một lỗ hổng bảo mật cho phép tài khoản có thuộc tính REPLICATION thực thi mã tùy ý dưới quyền của người dùng hệ điều hành đang chạy máy chủ cơ sở dữ liệu.
Lỗ hổng này, được theo dõi với mã CVE-2026-6471 (điểm CVSS: 7.2), đã tồn tại kể từ khi tính năng logical decoding được giới thiệu trong PostgreSQL 9.4 vào năm 2014. Các phiên bản trước PostgreSQL 18.6, 17.11, 16.15, 15.19 và 14.24 đều bị ảnh hưởng.
Việc khai thác yêu cầu một tài khoản có thuộc tính REPLICATION và máy chủ đang chạy với wal_level = logical. Các công cụ sao lưu, máy chủ dự phòng (standby servers), đường ống truyền dữ liệu thay đổi (CDC) và các hệ thống giám sát thường xuyên nắm giữ thuộc tính này.
Bản vá được tung ra vào ngày 13 tháng 8, bổ sung một tham số máy chủ có tên là output_plugin_libraries, liệt kê các thư viện có thể được tải dưới dạng plugin đầu ra của logical decoding, mặc định là 'pgoutput, test_decoding'.
Các cài đặt sử dụng bất kỳ plugin đầu ra nào khác, bao gồm cả wal2json và decoderbufs, sẽ bị từ chối logical decoding sau khi cập nhật cho đến khi quản trị viên thêm thư viện vào danh sách đó và tải lại cấu hình máy chủ.
"Trước đây, người dùng replication có thể chọn bất kỳ thư viện nào có thể tải được cho logical decoding, cho phép thực hiện nhiều loại hình khai thác khác nhau. Để thắt chặt vấn đề này mà không làm hỏng các thiết lập đã hoạt động trước đó, chúng tôi giới thiệu một whitelist các plugin đầu ra được phép," Nhóm Phát triển Toàn cầu PostgreSQL cho biết trong ghi chú phát hành 18.6.
Phát hiện lỗ hổng PostGREShell
Dự án PostgreSQL đã ghi nhận Vladimir Tokarev và Yu Kunpeng vì đã báo cáo vấn đề này. Tokarev đã trình bày chi tiết trong một bài viết vào ngày 1 tháng 9 cho công ty bảo mật dữ liệu Cyera Research, đặt tên cho lỗ hổng là PostGREShell.
Cyera cho biết tên plugin được cung cấp trong lệnh CREATE_REPLICATION_SLOT sẽ được chuyển trực tiếp đến hàm tải thư viện. Các hạn chế hiện tại của PostgreSQL đối với đường dẫn plugin vốn chỉ giới hạn những người dùng không phải superuser vào một thư mục duy nhất do quản trị viên kiểm soát, nhưng lại không bao giờ được gọi trên đường dẫn replication.
Trình phân tích cú pháp của giao thức replication chấp nhận hầu như bất kỳ ký tự nào bên trong tên plugin được đặt trong dấu ngoặc kép, bao gồm cả các dấu phân cách đường dẫn và kỹ thuật ../ traversal, do đó một đường dẫn hệ thống tệp đầy đủ sẽ đến trình tải đúng như những gì đã nhập.
Trên Windows, máy chủ sẽ giải quyết một đường dẫn mạng thông qua Server Message Block (SMB) và lấy thư viện từ một máy do kẻ tấn công kiểm soát mà không ghi bất cứ thứ gì vào mục tiêu. Trên Linux và macOS, kết quả tương tự yêu cầu phải kích hoạt tính năng tự động gắn kết Network File System (NFS). Ở những nơi khác, kẻ tấn công cần một cách hiện có để ghi tệp vào đĩa của máy chủ. Mã được tải theo cách này sẽ chạy bên trong tiến trình backend của cơ sở dữ liệu với tư cách là người dùng hệ điều hành postgres.
Plugin thử nghiệm của Cyera sau đó đã ghi trực tiếp vào danh mục vai trò (role catalog) để biến tài khoản replication thành một PostgreSQL superuser. Nó cũng thiết lập ba cơ chế duy trì (persistence) để sống sót sau khi khởi động lại máy chủ.
Các bước khuyến nghị cho quản trị viên
Quản trị viên được khuyên thực hiện các bước sau:
- Chạy lệnh SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; trước khi cập nhật để xác định các plugin đầu ra đang được sử dụng.
- Cập nhật lên các phiên bản PostgreSQL 18.6, 17.11, 16.15, 15.19, hoặc 14.24, hoặc các gói phân phối tương đương.
- Thêm bất kỳ plugin không mặc định nào vào output_plugin_libraries và tải lại cấu hình bằng pg_ctl reload hoặc SELECT pg_reload_conf(). Không yêu cầu khởi động lại.
- Thiết lập output_plugin_libraries của cụm mới trước khi chạy pg_upgrade --check khi di chuyển từ phiên bản 17 trở lên.
Các gói đã vá hiện có sẵn trên Amazon RDS cho cả năm nhánh, cũng như từ Debian, SUSE và Ubuntu. Tuy nhiên, một lỗ hổng trong bản vá vẫn còn mở: pg_createsubscriber tạo các replication slots bằng pgoutput mà không kiểm tra tham số mới, dẫn đến việc --dry-run thành công nhưng quá trình chuyển đổi thực tế sau đó thất bại.
Cho đến khi có thể áp dụng bản cập nhật, Cyera cho biết mức độ rủi ro có thể được giảm bớt bằng cách loại bỏ thuộc tính REPLICATION khỏi các tài khoản không cần nó, giới hạn các mục replication trong pg_hba.conf ở các địa chỉ đã biết, chặn lưu lượng SMB (cổng 445) và NFS (cổng 2049) hướng ra ngoài từ các máy chủ cơ sở dữ liệu.
