SmallerC - scanf %s 스택 버퍼 오버플로우

프로젝트: https://github.com/alexfru/SmallerC

SmallerC의 scanf 구현은 형식 문자열에 명시적 필드 폭 없이 %s 또는 %[가 사용될 때 문자열 읽기에 상한을 적용하지 않습니다. 런타임은 버퍼의 실제 할당된 크기와 관계없이 공백이나 EOF를 만날 때까지 대상 버퍼에 계속 씁니다. 경계를 넘어선 모든 바이트는 스택에 직접 기록되어 컴파일러가 버퍼 위에 배치한 모든 것(로컬 변수, 저장된 레지스터, 반환 주소)을 덮어씁니다.

이것은 새로운 취약점 클래스가 아닙니다. 무제한 scanf 문자열 읽기는 C 초창기부터 문서화되어 왔으며, 유능한 정적 분석 도구라면 모두 이를 지적할 것입니다. 구체적으로 SmallerC의 맥락에서 이를 보고할 가치가 있는 이유는 대상 환경 때문입니다. SmallerC는 DOS 및 베어메탈 임베디드 타깃을 위해 설계되었습니다. 이러한 플랫폼은 정의상 스택 카나리, ASLR, NX 비트 또는 현대 시스템에서 익스플로잇을 어렵게 만드는 완화 장치를 제공하지 않습니다. 강화된 Linux 바이너리에서 실제 익스플로잇으로 만들려면 상당한 연구 노력이 필요한 동일한 프리미티브가 평평하고 예측 가능한 스택에서 실행되는 DOS 프로그램에서는 훨씬 다루기 쉬워집니다.

버퍼는 16바이트입니다. 입력은 20바이트의 공백이 아닌 문자입니다. %s 변환에는 폭 지정자가 없으므로 sscanf는 16바이트 할당에 20바이트 전체와 널 종결자(총 21바이트)를 읽습니다. 경계를 넘어선 5바이트는 인접한 스택 메모리를 손상시킵니다. 정확히 무엇이 손상되는지는 해당 함수에 대한 컴파일러의 스택 레이아웃 결정에 따라 달라지지만, 이 입력으로 이 코드 경로가 실행될 때마다 덮어쓰기 자체는 결정론적이고 무조건적입니다.

개념 증명

#include <stdioh>
#include <stringh>

/*
 * Build with SmallerC targeting DOS or bare-metal
 * Demonstrates unbounded %s write past a fixed stack buffer
 *
 * buffer is 16 bytes payload is 20 non-whitespace bytes
 * sscanf writes 21 bytes (20 + null terminator) into buffer
 * corrupting 5 bytes of adjacent stack memory
 *
 * To observe the corruption inspect stack memory after the call:
 * the 5 bytes immediately above buffer will contain 'A' (0x41)
 */

int main() {
    char buffer[16];
    char canary[8];

    memset(buffer 0x00 sizeof(buffer));
    memset(canary 0xCC sizeof(canary));  /* marker to detect overwrite */

    printf("[*] canary before: ");
    for (int i = 0; i < 8; i++) printf("%02x " (unsigned char)canary[i]);
    printf("\n");

    sscanf("AAAAAAAAAAAAAAAAAAAA" "%s" buffer);  /* 20 bytes into 16-byte buffer */

    printf("[*] canary after:  ");
    for (int i = 0; i < 8; i++) printf("%02x " (unsigned char)canary[i]);
    printf("\n");

    if (memcmp(canary "\xCC\xCC\xCC\xCC\xCC\xCC\xCC\xCC" 8) != 0)
        printf("[!] stack corruption confirmed  canary overwritten\n");
    else
        printf("[-] canary intact (stack layout placed it elsewhere)\n");

    return 0;
}

영향을 받는 빌드에서의 예상 출력:

[*] canary before: cc cc cc cc cc cc cc cc
[*] canary after:  41 41 41 41 41 cc cc cc
[!] stack corruption confirmed  canary overwritten

카나리의 버퍼 상대 위치는 컴파일러의 스택 레이아웃에 따라 달라집니다. 출력에서 카나리가 온전한 것으로 나타나면 덮어쓰기는 여전히 발생하는 것이며, 버퍼 위의 다른 무언가에 영향을 미친 것입니다. 디버거로 실제 스택 프레임을 검사하여 손상된 5바이트가 어디에 위치하는지 확인한 후 리프로듀서를 조정하십시오.

명시적으로 짚고 넘어가야 할 정정 사항이 있습니다. 이 취약점 클래스의 일부 보고서는 페이로드에서 널 바이트 뒤에 대상 주소를 추가하는 방식(예: "AAAAAAAAAAAAAAAAAAA\x00\x90\x04\x08")으로 반환 주소 제어를 시연하려고 합니다. 이것은 작동하지 않습니다. sscanf의 %s 변환은 \x00을 문자열 종결자로 취급하므로 이를 만나는 즉시 읽기를 중단합니다. 널 바이트 이후의 바이트는 결코 처리되지 않습니다. 실제 반환 주소 제어를 입증하려면 페이로드의 중요한 부분에 널 바이트 없이 덮어쓰기를 전달해야 하며, 그러려면 대상 바이너리의 정확한 스택 레이아웃(버퍼에서 저장된 반환 주소까지의 거리, 컴파일러가 패딩을 삽입했는지 여부, 적용되는 정렬 제약 조건)을 알아야 합니다. 그중 어느 것도 이 리프로듀서에서 자동으로 얻어지지 않습니다.

이 리프로듀서가 명확하게 입증하는 것은 손상 프리미티브 자체입니다. 경계를 벗어난 쓰기는 실제이며 재현 가능하고 어떤 경쟁 조건이나 타이밍에도 의존하지 않습니다. 스택 레이아웃이 빌드 간에 정적이고 예측 가능한 DOS 또는 임베디드 타깃에서는 이 프리미티브에서 실제 익스플로잇으로 연결하는 것이 이론적 연습이 아니라 현실적인 연구 작업입니다.

영향을 받는 시나리오는 좁지만 인위적이지는 않습니다. 프로그램이 SmallerC로 빌드되고, 무제한 %s 또는 %[ 지정자를 사용하는 scanf 계열 파싱으로 고정 크기 스택 버퍼에 쓰고, 공격자가 영향을 미칠 수 있는 소스의 입력을 받아들여야 합니다. 네 가지 조건이 모두 동시에 성립해야 합니다. 올바른 필드 폭(예: char[16]에 대해 %15s)을 사용하는 프로그램은 영향을 받지 않습니다. 공격자가 제어하는 입력을 파싱하지 않는 프로그램은 영향을 받지 않습니다. 이 문제는 SmallerC 런타임이 누락된 폭 제약 조건을 처리하는 방식의 결함이지만, 애플리케이션 코드가 그 결함을 신뢰할 수 없는 입력에 노출할 때만 보안 문제가 됩니다.

애플리케이션 측면에서 수정은 간단합니다. 널 종결자를 위한 공간을 남겨 두는 필드 폭을 지정하면 됩니다. 16바이트 버퍼에는 %15s, 64바이트 버퍼에는 %63s입니다. 이것은 표준 C 관행이며 형식 문자열 구문에서 완전히 지원됩니다. SmallerC 프로젝트 측면에서 더 지속적인 작업은 scanf, sscanf, fscanf 전반에 걸쳐 제한된(bounded) 및 무제한(unbounded) %s와 %[ 동작을 모두 다루는 회귀 테스트를 추가하고, 명시적 필드 폭이 구현에서 실제로 존중되는지 검증하며, 안전하지 않은 패턴을 눈에 띄게 문서화하는 것입니다. 형식 문자열 리터럴에서 %s 또는 %[가 필드 폭 없이 나타날 때 경고하는 컴파일러 수준 진단은 이러한 유형의 실수를 사전에 방지할 수 있으며 툴체인에 의미 있는 추가 요소가 될 것입니다.

심각도는 외부 입력이 취약한 코드 경로에 도달하면 Medium입니다. 입력이 로컬이거나 권한이 없는 경우 Low로 떨어집니다. 대상 환경, 특히 SmallerC가 의도한 플랫폼에서 현대적 익스플로잇 완화 장치가 없다는 점이 이 문제를 일반적인 "무제한 scanf를 사용하지 말라"는 권고와 구분 짓고, 순전히 애플리케이션 계층의 오용으로 취급하지 않고 프로젝트 수준에서 보고할 가치가 있게 만듭니다.

크레딧: Yousif Wazni

CVE-2026-39259

인기