Cách giảm thiểu lỗ hổng SRBDS (CVE-2020-0543) mà không cần khởi động lại máy chủ

[theanh]

Gần đây, các học giả từ Nhóm bảo mật hệ thống và mạng (VUSec) của Đại học Vrije đã công bố thông tin chi tiết về CrossTalk hoặc SRBDS (CVE-2020-0543) trong bộ xử lý Intel. Lỗ hổng CrossTalk cho phép mã do kẻ tấn công kiểm soát thực thi trên một lõi CPU để rò rỉ dữ liệu nhạy cảm từ phần mềm khác chạy trên một lõi khác. Trong bài viết này, chúng tôi sẽ chỉ cho bạn cách giảm thiểu lỗ hổng CPU Intel này mà không cần khởi động lại máy chủ.

CrossTalk là gì?​

Lỗ hổng CrossTalk là một loại tấn công MDS (lấy mẫu dữ liệu vi kiến trúc), tương tự như Spectre, Meltdown hoặc Zombieload. Nó cho phép tiết lộ và đánh cắp dữ liệu nhạy cảm trong khi máy truy cập vào chúng. Các cuộc tấn công MDS nhắm vào dữ liệu người dùng khi dữ liệu này đang ở trạng thái tạm thời, vì dữ liệu này vẫn nằm bên trong CPU và nhiều hệ thống được kết nối với nó.

Lỗ hổng SRBDS/CrossTalk là lỗ hổng thực thi tạm thời. Được Intel đặt tên là “Lấy mẫu dữ liệu bộ đệm thanh ghi đặc biệt” hoặc SRBDS (CVE-2020-0543) cho phép kẻ tấn công kiểm soát mã thực thi trên một lõi CPU, dẫn đến rò rỉ dữ liệu nhạy cảm từ phần mềm nạn nhân thực thi trên một lõi khác.


Hình 1: Thiết kế giai đoạn lập hồ sơ hướng dẫn của CrossTalk, do VUSec cung cấp


Bất kỳ hệ thống nào sử dụng CPU Intel đều có thể bị ảnh hưởng bởi lỗ hổng bảo mật này. Kiểm tra tại đây nếu CPU của bạn bị ảnh hưởng.

Giảm thiểu không cần khởi động lại lỗ hổng SRBDS (CVE-2020-0543)​

Intel đã triển khai giảm thiểu cho Lỗ hổng SRBDS trong bản cập nhật vi mã được phân phối cho các nhà cung cấp phần mềm vào thứ Ba, ngày 9 tháng 6 năm 2020. Biện pháp giảm thiểu này yêu cầu cài đặt các bản vá lỗi Linux Kernel & cập nhật vi mã mới nhất. Cả hai thao tác này thường được thực hiện khi khởi động lại.

Mặc dù việc khởi động lại một vài máy chủ nghe có vẻ không phải là vấn đề, nhưng nếu bạn là Quản trị viên hệ thống đang quản lý hơn 500 máy chủ - thì chắc chắn là vậy. Việc khởi động lại toàn bộ đội máy chủ thường đòi hỏi phải lập kế hoạch bảo trì kỹ lưỡng. May mắn thay, công nghệ vá lỗi trực tiếp cho phép áp dụng các bản cập nhật bảo mật cho hệ thống chống lại CrossTalk mà không cần khởi động lại, đối với cả bản cập nhật vi mã và ứng dụng bản vá lỗi hạt nhân Linux.

Canonical, Red Hate và các nhà cung cấp bản phân phối khác đã phát hành các bản vá bảo mật cho tất cả các bản phân phối Ubuntu được hỗ trợ, Debian, CentOS, Red Hat Enterprise Linux. Và, mặc dù Canonical & Red Hat có giải pháp riêng để vá lỗ hổng mà không cần khởi động lại, trong trường hợp SRBDS/CrossTalk, bạn vẫn cần phải khởi động lại máy tính để bàn hoặc máy chủ sau khi cập nhật.
Nhóm
KernelCare đã tạo ra một giải pháp giảm thiểu không cần khởi động lại cho CrossTalk/SRBDS để bạn có thể tránh phải khởi động lại máy chủ để áp dụng các bản vá. Tìm hướng dẫn bên dưới:

A) Nếu bạn đang chạy trên phần cứng, hãy thực hiện 3 bước để bảo vệ máy chủ của bạn khỏi lỗ hổng CrossTalk/SRBDS mà không cần khởi động lại:

Bước 1:Đăng ký dùng thử miễn phí giấy phép KernelCare​

KernelCare miễn phí sử dụng trong 30 ngày trên tất cả các máy chủ của bạn, không cần thẻ tín dụng để đăng ký dùng thử. Nó cũng miễn phí cho các tổ chức chăm sóc sức khỏe trong thời gian còn lại của năm 2020 và miễn phí mãi mãi cho các tổ chức phi lợi nhuận.

Bước 2: Cập nhật Microcode mà không cần khởi động lại​

Ví dụ: Cập nhật microcode trên RHEL​

Đây là ví dụ về bản cập nhật vi mã không cần khởi động lại trên RHEL.Hướng dẫn dành cho Debian, Ubuntu, CentOS và các bản phân phối khác có thể được tìm thấy trong Tài liệu KernelCare.

Đối với các bản phân phối dựa trên RHEL, bạn có thể sử dụng tiện ích microcode_ctl để cập nhật vi mã.

Trước khi bắt đầu, hãy kiểm tra tại đây nếu các bản vá cho bản phân phối của bạn đã sẵn sàng. Trang này được cập nhật mỗi giờ.

1. Nhận mã vi mô mới nhất bằng cách cập nhật gói microcode_ctl

yum update microcode_ctl

2. Tạo force-late-intel–06–4f–01 bên trong thư mục chương trình cơ sở.

chạm /lib/firmware/`uname -r`/force-late-intel-06-4f-01

3. Chạy bản cập nhật vi mã

/usr/libexec/microcode_ctl/update_ucode

4. Buộc hạt nhân tải vi mã mới

echo 1 > /sys/devices/system/cpu/microcode/reload

5. Kiểm tra vi mã mới

dmesg | grep microcode[B][ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12
[ 2.254820] microcode: Trình điều khiển cập nhật microcode: v2.01 , Peter Oruba
[ 1483.494573] nền tảng microcode: chương trình cơ sở: chương trình cơ sở tải trực tiếp intel-ucode/06-3a-09
[ 1483.495985] microcode: cập nhật lên bản sửa đổi 0x21, ngày = 2019-02-13
[ 1483.496012] nền tảng microcode: chương trình cơ sở: chương trình cơ sở tải trực tiếp intel-ucode/06-3a-09
[ 1483.496698] nền tảng microcode: chương trình cơ sở: tải trực tiếp firmware intel-ucode/06-3a-09
[ 1483.497391] nền tảng microcode: firmware: tải trực tiếp firmware intel-ucode/06-3a-09

6. (Tùy chọn) Kiểm tra lại phiên bản microcode mới (bản sửa đổi cho mỗi lõi)

cat /proc/cpuinfo | grep -e microcode
microcode : 0x21
microcode : 0x21
microcode : 0x21
microcode : 0x21

Bước 3: Áp dụng các bản vá KernelCare​

Bây giờ bạn cần cập nhật Linux Kernel để đảm bảo rằng người dùng cục bộ không thể đọc dữ liệu bạn đang chạy trên CPU. Với KernelCare, bạn có thể làm điều đó mà không cần khởi động lại. Nếu bạn đã đăng ký dùng thử ở Bước 1 - bạn đã hoàn tất và không cần phải làm gì thêm.[/b]

B) Nếu bạn đang chạy trên VM:

Bạn chỉ cần vá Linux Kernel bên trong VM. Đảm bảo rằng nút máy chủ của bạn cũng được cập nhật, việc này thường do nhà cung cấp dịch vụ của bạn thực hiện.

Nếu bạn đang sử dụng KernelCare - các bản vá của bạn sẽ được KernelCare tự động cung cấp và bạn không cần phải làm gì thêm. Nếu không -hãy đăng ký dùng thử miễn phí 30 ngày.