Các nhà nghiên cứu từ Đại học Cambridge đã công bố một kỹ thuật âm thầm chèn mã độc vào mã nguồn được bình duyệt. Phương thức tấn công đã chuẩn bị sẵn (CVE-2021-42574) được trình bày dưới tên Nguồn Trojan và dựa trên việc hình thành văn bản trông khác nhau đối với trình biên dịch/trình thông dịch và người xem mã. Ví dụ về phương pháp được minh họa cho nhiều trình biên dịch và trình thông dịch khác nhau được cung cấp cho C, C++ (gcc và clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go và Python.
Phương pháp này dựa trên việc sử dụng các ký tự Unicode đặc biệt trong các nhận xét mã để thay đổi thứ tự hiển thị của văn bản hai chiều. Với sự trợ giúp của các ký tự điều khiển như vậy, một số phần của văn bản có thể được hiển thị từ trái sang phải, trong khi những phần khác - từ phải sang trái. Trong thực tế hàng ngày, các ký tự điều khiển như vậy có thể được sử dụng, ví dụ, để chèn các dòng mã bằng tiếng Do Thái hoặc tiếng Ả Rập vào một tệp. Nhưng nếu bạn kết hợp các dòng với các hướng văn bản khác nhau trong một dòng, bằng cách sử dụng các ký tự được chỉ định, các đoạn văn bản được hiển thị từ phải sang trái có thể chồng lên văn bản thông thường hiện có được hiển thị từ trái sang phải.
Khi sử dụng phương pháp này, bạn có thể thêm một cấu trúc độc hại vào mã, nhưng sau đó làm cho văn bản có cấu trúc này ẩn đi khi xem mã, bằng cách thêm vào nhận xét sau hoặc bên trong các ký tự chữ được hiển thị từ phải sang trái, điều này sẽ dẫn đến hoàn toàn các ký tự khác nhau được xếp chồng lên phần chèn độc hại. Mã như vậy sẽ vẫn đúng về mặt ngữ nghĩa nhưng sẽ được diễn giải và hiển thị khác nhau.
Trong khi xem xét mã, nhà phát triển sẽ phải đối mặt với thứ tự trực quan của các ký tự và sẽ thấy nhận xét không đáng ngờ trong trình soạn thảo văn bản, giao diện web hoặc IDE hiện đại, nhưng trình biên dịch và trình thông dịch sẽ sử dụng thứ tự logic của các ký tự và sẽ xử lý nguyên phần chèn độc hại mà không chú ý đến văn bản hai chiều trong nhận xét. Sự cố này ảnh hưởng đến nhiều trình soạn thảo mã phổ biến khác nhau (VS Code, Emacs, Atom), cũng như các giao diện xem mã trong kho (GitHub, Gitlab, BitBucket và tất cả các sản phẩm của Atlassian).
Có một số cách sử dụng phương pháp này để thực hiện các hành động độc hại: thêm biểu thức “return” ẩn, dẫn đến việc hoàn thành chức năng trước thời hạn; nhận xét các biểu thức thường được hiển thị dưới dạng cấu trúc hợp lệ (ví dụ: để vô hiệu hóa các kiểm tra quan trọng); gán các giá trị chuỗi khác dẫn đến lỗi xác thực chuỗi.
Ví dụ: kẻ tấn công có thể đề xuất một thay đổi bao gồm dòng: if access_level != "user{U+202E} {U+2066}// Kiểm tra xem quản trị viên{U+2069} {U+2066}" {
sẽ được hiển thị trong giao diện đánh giá như thể access_level != “user” { // Kiểm tra xem quản trị viên có
Ngoài ra, một biến thể tấn công khác đã được đề xuất (CVE-2021-42694), liên quan đến việc sử dụng các từ đồng âm, các ký tự có hình dáng giống nhau nhưng khác nhau về ý nghĩa và có mã unicode khác nhau (ví dụ: ký tự “ɑ” giống “ a”, “ɡ” - “g”, “ɩ” - “l”). Các ký tự tương tự có thể được sử dụng trong một số ngôn ngữ trong tên hàm và biến để đánh lừa các nhà phát triển. Ví dụ: hai hàm có tên không thể phân biệt được có thể được xác định để thực hiện các hành động khác nhau. Nếu không phân tích chi tiết thì không thể xác định ngay chức năng nào trong hai chức năng này được gọi ở một địa điểm cụ thể.
Để đảm bảo an toàn, chúng tôi khuyến nghị các trình biên dịch, trình thông dịch và công cụ tập hợp hỗ trợ các ký tự Unicode hiển thị lỗi hoặc cảnh báo nếu có các ký tự điều khiển không được ghép nối trong nhận xét, chuỗi ký tự hoặc mã định danh thay đổi hướng đầu ra (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E và U+200F). Những ký tự như vậy cũng phải bị cấm rõ ràng trong các đặc tả ngôn ngữ lập trình và phải được tôn trọng trong các trình soạn thảo mã và giao diện kho lưu trữ.
Phụ lục 1: Các bản vá lỗ hổng đã được chuẩn bị cho GCC, LLVM/Clang, Rust, Go, Python và binutils. GitHub, Bitbucket và Jira cũng đã khắc phục sự cố. Đang sửa lỗi cho GitLab. Để xác định mã có vấn đề, bạn nên sử dụng lệnh: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ nguồn
Phụ lục 2: Russ Cox, một trong những nhà phát triển Plan 9 OS và ngôn ngữ lập trình Go, đã chỉ trích sự chú ý quá mức đến phương thức tấn công được mô tả, vốn đã được biết đến từ lâu (Go, Rust, C++, Ruby) và không được coi trọng . Theo Cox, vấn đề chủ yếu liên quan đến việc hiển thị chính xác thông tin trong trình soạn thảo mã và giao diện web, vấn đề này có thể được giải quyết bằng cách sử dụng các công cụ và trình phân tích mã chính xác trong quá trình xem xét. Do đó, thay vì thu hút sự chú ý đến các cuộc tấn công mang tính suy đoán, sẽ phù hợp hơn nếu tập trung vào việc cải thiện quy trình xem xét mã và phần phụ thuộc.
Ras Cox cũng tin rằng trình biên dịch không phải là nơi thích hợp để khắc phục vấn đề, vì bằng cách cấm các ký hiệu nguy hiểm ở cấp độ trình biên dịch, vẫn còn một lớp công cụ khổng lồ trong đó việc sử dụng các ký hiệu này vẫn được chấp nhận, chẳng hạn như hệ thống xây dựng, trình biên dịch, trình quản lý gói và các trình phân tích cú pháp cấu hình và dữ liệu khác nhau. Ví dụ: dự án Rust được đưa ra, cấm xử lý mã LTR/RTL trong trình biên dịch, nhưng không thêm bản sửa lỗi vào trình quản lý gói Cargo, điều này cho phép một cuộc tấn công tương tự thông qua tệp Cargo.toml. Tương tự, các tệp như BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, pack.json, pom.xml và require.txt có thể trở thành nguồn tấn công.
Nguồn: opennet.ru