kernel.org의 전 최고 시스템 관리자 인 Kees Cook Ubuntu 보안 팀의 리더이자 현재 Google에서 Android 및 ChromeOS를 보호하기 위해 일하고 있습니다. 커널 스택 오프셋을 무작위 화하는 패치 세트를 출시했습니다. 시스템 호출을 처리 할 때. 패치는 스택 위치를 변경하여 커널 보안을 향상시킵니다.또는 스택 공격을 훨씬 더 어렵고 덜 성공적으로 만듭니다.
패치의 원래 아이디어는 PaX RANDKSTACK 프로젝트에 속합니다. 2019 년 Intel의 엔지니어 인 Elena Reshetova는 Linux 커널의 주요 구성에 포함하기에 적합한이 아이디어를 구현하려고했습니다.
그 후 Kees Cook이 이니셔티브를 취했습니다. 커널의 주 버전에 적합한 구현을 제시했으며 Linux 버전 5.13에 대한 패치를 계획했습니다.
모드는 기본적으로 비활성화되며 활성화하기 위해 커널 명령 줄 매개 변수가 제공됩니다. "Randomize_kstack_offset = 켜기 / 끄기»및 설정 CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, 또한 모드를 활성화하는 오버 헤드는 약 1 %의 성능 손실로 추정됩니다.
제안 된 보호의 핵심은 각 시스템 호출에서 임의의 스택 오프셋을 선택하는 것입니다.이는 스택의 기본 주소가 다음 호출에서 변경되기 때문에 주소 정보를 수신하더라도 메모리의 스택 레이아웃 결정을 복잡하게합니다.
구현과 달리 PaX RANDK 스택, 커널에 포함되도록 제안 된 패치에서 무작위 화는 초기 단계에서 수행되지 않습니다., 하지만 pt_regs 구조를 설정 한 후이는 장기 실행 시스템 호출 중에 임의 오프셋을 결정하기 위해 ptrace 기반 메서드를 사용하는 것을 불가능하게합니다.
Linux 커널 스택 보호 기능이 지속적으로 향상됨에 따라 (보호 페이지가있는 vmap 기반 스택 매핑, thread_info 제거, STACKLEAK) 공격자는 악용을위한 새로운 방법을 찾아야했습니다.
그들은 다음과 같은 상황에서 커널 스택 결정 성을 가지고 있으며 계속해서 의존합니다. VMAP_STACK 및 THREAD_INFO_IN_TASK_STRUCT 관련성이 없었습니다. 예를 들어, 스택 오프셋이 시스템 호출간에 결정적이지 않으면 다음과 같은 최근 공격이 방해를 받았을 것입니다.
randomize_kstack_offset 함수의 목적은 임의 오프셋을 추가하는 것입니다. pt_regs가 스택으로 푸시 된 후 시스템 호출 처리 중에 나머지 스레드 스택이 사용되기 전에 프로세스가 시스템 호출을 발행 할 때마다 변경합니다. 임의의 소스는 현재 아키텍처에 의해 정의되지만 x86은 rdtsc ()의 하위 바이트를 사용합니다.
다양한 엔트로피 소스에 대해 향후 향상이 가능하지만이 패치의 범위를 벗어납니다. 또한 예측 불가능 성을 더하기 위해 시스템 호출이 끝날 때 (시스템 호출 입력 시보 다 사용자 공간에서 측정하기가 더 쉬워야하는 시간) 새 오프셋을 선택하고 CPU 당 하나의 변수에 저장합니다. 따라서 값의 수명이 단일 작업에 명시 적으로 연결되지 않도록합니다.
스택 세이버가 컴파일 단위에 대해 이미 무조건 비활성화되어 있기 때문에 x86에서는 눈에 띄는 변경 사항이 없지만 arm64에서는 변경이 필요합니다. 불행히도 특정 기능에 대해 스택 세이버를 비활성화하는 데 사용할 수있는 속성은 없습니다. PaX RANDKSTACK 함수와 비교 : RANDKSTACK 함수는 스택 (cpu_current_top_of_stack)의 시작 위치를 무작위로 지정합니다. 즉, 스택에있는 pt_regs 구조의 위치를 포함합니다.
처음에는 이 패치는 동일한 접근 방식을 따랐습니다. 그러나 최근 논의 중에 공격자가 ptrace 기능을 사용할 수있는 것처럼 거의 가치가없는 것으로 확인되었습니다. PTRACE_PEEKUSR을 사용하여 pt_regs 구조에 대한 다른 오프셋을 읽고 / 쓰고, pt_regs 액세스의 캐시 동작을 관찰하고 임의 스택 오프셋.
마지막으로 언급됩니다 초기 구현은 ARM64 및 x86 / x86_64 프로세서를 지원합니다..