개발자에게 보이지 않는 코드 변경을 유도하는 트로이 목마 소스 공격

캠브리지 대학의 연구원들은 동료 검토를 거친 소스 코드에 악성 코드를 자동으로 삽입하는 기술을 발표했습니다. 준비된 공격 방법(CVE-2021-42574)은 Trojan Source라는 이름으로 제시되며, 컴파일러/해석자 및 코드를 보는 사람에게 다르게 보이는 텍스트 구성을 기반으로 합니다. C, C++(gcc 및 clang), C#, JavaScript(Node.js), Java(OpenJDK 16), Rust, Go 및 Python용으로 제공되는 다양한 컴파일러 및 인터프리터에 대한 메서드의 예가 설명되어 있습니다.

이 방법은 양방향 텍스트의 표시 순서를 변경하는 코드 주석에 특수 유니코드 문자를 사용하는 것을 기반으로 합니다. 이러한 제어 문자를 사용하면 텍스트의 일부 부분을 왼쪽에서 오른쪽으로 표시하고 다른 부분은 오른쪽에서 왼쪽으로 표시할 수 있습니다. 일상적으로 이러한 제어 문자는 예를 들어 히브리어 또는 아랍어로 된 코드 줄을 파일에 삽입하는 데 사용할 수 있습니다. 그러나 지정된 문자를 사용하여 텍스트 방향이 다른 줄을 한 줄에 결합하면 오른쪽에서 왼쪽으로 표시되는 텍스트 구절이 왼쪽에서 오른쪽으로 표시되는 기존 일반 텍스트와 겹칠 수 있습니다.

이 방법을 사용하면 코드에 악의적인 구문을 추가할 수 있지만 다음 주석을 추가하거나 오른쪽에서 왼쪽으로 표시된 리터럴 문자 내부에 추가하여 코드를 볼 때 이 구문이 포함된 텍스트가 보이지 않게 만들 수 있습니다. 악의적인 삽입에 다른 문자가 겹쳐집니다. 이러한 코드는 의미상으로는 올바른 상태로 유지되지만 다르게 해석되고 표시됩니다.

코드를 검토하는 동안 개발자는 문자의 시각적 순서에 직면하게 되며 최신 텍스트 편집기, 웹 인터페이스 또는 IDE에서 의심스럽지 않은 주석을 보게 되지만 컴파일러와 통역사는 문자의 논리적 순서를 사용하여 댓글의 양방향 텍스트에 주의를 기울이지 않고 악의적인 삽입을 있는 그대로 처리합니다. 이 문제는 널리 사용되는 다양한 코드 편집기(VS Code, Emacs, Atom)와 리포지토리(GitHub, Gitlab, BitBucket 및 모든 Atlassian 제품)에서 코드를 보기 위한 인터페이스에 영향을 미칩니다.

이 메서드를 사용하여 악의적인 작업을 구현하는 방법에는 여러 가지가 있습니다. 숨겨진 "반환" 표현식을 추가하여 미리 기능을 완료하는 것입니다. 일반적으로 유효한 구문으로 표시되는 표현식을 주석 처리합니다(예: 중요한 검사를 비활성화하기 위해). 문자열 검증 실패로 이어지는 다른 문자열 값 할당.

예를 들어 공격자는 다음 줄을 포함하는 변경을 제안할 수 있습니다. if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {

이는 마치 access_level != “user” { // 관리자인지 확인하는 것처럼 검토 인터페이스에 표시됩니다.

또한, 모양은 비슷하지만 의미가 다르고 유니코드 코드가 다른 문자인 동형 문자(예: 문자 "ɑ"는 " a", "ɡ" - "g", "ɩ" - "l"). 일부 언어에서는 함수 및 변수 이름에 유사한 문자를 사용하여 개발자를 오도할 수 있습니다. 예를 들어, 서로 다른 작업을 수행하는 구별할 수 없는 이름을 가진 두 개의 함수를 정의할 수 있습니다. 자세한 분석 없이는 이 두 기능 중 어떤 기능이 특정 위치에서 호출되는지 즉시 명확하지 않습니다.

보안 조치로서 유니코드 문자를 지원하는 컴파일러, 인터프리터 및 어셈블리 도구는 주석, 문자열 리터럴 또는 출력 방향을 변경하는 식별자(U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E 및 U+200F). 이러한 문자는 프로그래밍 언어 사양에서도 명시적으로 금지되어야 하며 코드 편집기 및 저장소 인터페이스에서 존중되어야 합니다.

부록 1: GCC, LLVM/Clang, Rust, Go, Python 및 binutils에 대한 취약점 패치가 준비되었습니다. GitHub, Bitbucket 및 Jira도 문제를 해결했습니다. GitLab에 대한 수정이 진행 중입니다. 문제가 있는 코드를 식별하려면 grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ 명령을 사용하는 것이 좋습니다. 원천

부록 2: Plan 9 OS 및 Go 프로그래밍 언어 개발자 중 한 명인 Russ Cox는 설명된 공격 방법(Go, Rust, C++, Ruby)에 대해 지나친 관심이 집중되고 심각하게 받아들여지지 않는다고 비판했습니다. . Cox에 따르면 이 문제는 주로 코드 편집기와 웹 인터페이스에 정보가 올바르게 표시되는 것과 관련이 있으며 이는 검토 중에 올바른 도구와 코드 분석기를 사용하면 해결할 수 있습니다. 따라서 추측성 공격에 주목하기보다는 코드 및 종속성 검토 프로세스를 개선하는 데 집중하는 것이 더 적절할 것입니다.

Ras Cox는 또한 컴파일러가 문제를 해결하는 데 적합한 장소가 아니라고 믿습니다. 왜냐하면 컴파일러 수준에서 위험한 기호를 금지함으로써 이러한 기호의 사용이 허용되는 빌드 시스템, 어셈블러, 패키지 관리자 및 다양한 구성 파서 및 데이터. 예를 들어, 컴파일러에서 LTR/RTL 코드 처리를 금지했지만 Cargo.toml 파일을 통해 유사한 공격을 허용하는 Cargo 패키지 관리자에 수정 사항을 추가하지 않은 Rust 프로젝트가 제공됩니다. 마찬가지로 BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml 및 요구 사항.txt와 같은 파일은 공격 소스가 될 수 있습니다.

출처 : opennet.ru