Hai lỗ hổng mới đã được xác định trong hệ thống con eBPF, cho phép bạn chạy các trình xử lý bên trong nhân Linux trong một máy ảo đặc biệt có JIT. Cả hai lỗ hổng đều có thể thực thi mã của bạn bằng quyền kernel, bên ngoài máy ảo eBPF bị cô lập. Thông tin về các vấn đề đã được công bố bởi nhóm Sáng kiến Zero Day, nhóm điều hành cuộc thi Pwn2Own, trong năm nay, ba cuộc tấn công vào Ubuntu Linux đã được chứng minh là sử dụng các lỗ hổng chưa được biết trước đó (liệu các lỗ hổng trong eBPF có liên quan đến các cuộc tấn công này không được báo cáo) .
- CVE-2021-3490 - Lỗ hổng này xảy ra do thiếu kiểm tra ngoài giới hạn 32 bit khi thực hiện các thao tác AND, OR và XOR theo bit trong eBPF ALU32. Kẻ tấn công có thể lợi dụng lỗi này để đọc và ghi dữ liệu ngoài giới hạn của bộ đệm được phân bổ. Sự cố với hoạt động XOR xuất hiện bắt đầu từ phiên bản kernel 5.7-rc1 và AND và OR - bắt đầu từ 5.10-rc1.
- CVE-2021-3489 - Lỗ hổng này xảy ra do lỗi trong quá trình triển khai bộ đệm vòng và do hàm bpf_ringbuf_reserve không kiểm tra khả năng kích thước của vùng bộ nhớ được phân bổ có thể nhỏ hơn kích thước thực tế của ringbuf. Sự cố xuất hiện kể từ phiên bản 5.8-rc1.
Tình trạng vá lỗ hổng trong các bản phân phối có thể được theo dõi trên các trang này: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Các bản sửa lỗi cũng có sẵn dưới dạng bản vá (CVE-2021-3489, CVE-2021-3490). Liệu vấn đề có thể bị khai thác hay không tùy thuộc vào việc người dùng có thể truy cập được lệnh gọi hệ thống eBPF hay không. Ví dụ: trong cấu hình mặc định trong RHEL, việc khai thác lỗ hổng yêu cầu người dùng phải có quyền CAP_SYS_ADMIN.
Riêng biệt, chúng ta có thể lưu ý một lỗ hổng khác trong nhân Linux - CVE-2021-32606, cho phép người dùng cục bộ nâng cao đặc quyền của họ lên cấp gốc. Sự cố này đã xuất hiện kể từ phiên bản nhân Linux 5.11 và xảy ra do tình trạng chạy đua trong quá trình triển khai giao thức CAN ISOTP, khiến có thể thay đổi các tham số liên kết ổ cắm do thiếu cài đặt khóa thích hợp trong hàm isotp_setsockopt() khi xử lý cờ CAN_ISOTP_SF_BROADCAST.
Sau khi ổ cắm ISOTP được đóng, liên kết với ổ cắm người nhận vẫn có hiệu lực, có thể tiếp tục sử dụng các cấu trúc được liên kết với ổ cắm sau khi bộ nhớ được liên kết với chúng được giải phóng (use-after-free do lệnh gọi đến cấu trúc isotp_sock đã được giải phóng khi gọi isotp_rcv()). Thông qua thao tác dữ liệu, bạn có thể ghi đè con trỏ tới hàm sk_error_report() và thực thi mã của mình ở cấp kernel.
Nguồn: opennet.ru