세그멘테이션 폴트로 하드웨어 보안을 우회하는 SFOP 공격

현대 CPU는 메모리 손상 취약점을 막기 위해 다양한 하드웨어 보안 기능을 도입하고 있다. 대표적인 예가 Intel의 **Control‑Flow Enforcement Technology(CET)**다. 그러나 최근 연구에 따르면 운영체제의 동작 방식과 결합될 경우 이러한 하드웨어 방어도 우회될 수 있다.

독일 CISPA 헬름홀츠 정보보안 센터(CISPA Helmholtz Center for Information Security) 연구진은 **Segmentation Fault Oriented Programming(SFOP)**이라는 새로운 공격 기법을 공개했다. 이 연구는 IEEE 보안·프라이버시 심포지엄 관련 논의에서 소개되었으며, Linux 시스템에서 Intel CET 보호를 우회할 수 있음을 보여준다.

SFOP(Segmentation Fault Oriented Programming)란

SFOP는 연속적인 코드 재사용(serial code‑reuse) 공격 기법이다. 공격자는 프로그램을 반복적으로 세그멘테이션 폴트(segmentation fault) 상태로 만들고, 그때 실행되는 신호 처리 로직을 제어 흐름의 구성 요소처럼 사용한다.

일반적인 공격 흐름은 다음과 같다.

• 공격자가 프로그램에서 불법 메모리 접근을 유도한다.
• 프로그램은 **SIGSEGV(세그멘테이션 폴트 신호)**를 발생시킨다.
• Linux는 해당 신호를 처리하기 위해 등록된 signal handler로 실행을 전환한다.
• 공격자는 이 핸들러에서 다음 단계의 충돌이나 동작을 준비한다.

이 과정을 반복하면 각각의 충돌이 하나의 단계가 되어, 공격자는 프로그램이나 라이브러리에 이미 존재하는 코드 조각을 조합해 원하는 동작을 수행할 수 있다.

이 방식은 ROP(Return‑Oriented Programming) 같은 기존 코드 재사용 공격과 다르다. ROP가 반환 주소 조작에 의존한다면, SFOP는 연속적인 크래시와 신호 처리 과정 자체를 제어 흐름 체인으로 사용한다.

Intel CET이 원래 막으려 했던 것

Intel의 **CET(Control‑Flow Enforcement Technology)**는 코드 재사용 공격을 방지하기 위해 설계된 하드웨어 보안 기능이다.

주요 목표는 다음과 같다.

• 반환 주소 검증
• 간접 분기(indirect branch) 제한
• 프로그램 내 의도되지 않은 명령어로의 점프 차단

즉 공격자가 기존 코드의 흐름을 가로채 임의의 실행 경로를 만들지 못하도록 하는 것이다.

하지만 CET는 기본적으로 프로그램 내부의 비정상적인 제어 흐름 이동을 차단하는 데 초점을 둔다.

SFOP는 바로 이 점을 우회한다.

SFOP가 Linux에서 CET을 우회하는 방식

SFOP의 핵심 아이디어는 운영체제가 처리하는 신호 전달(signal delivery) 자체가 합법적인 제어 흐름 전환이라는 점이다.

공격 과정은 대략 다음과 같다.

1. 공격자가 프로그램이 보호된 메모리에 접근하도록 만들어 세그멘테이션 폴트를 유도한다.
2. Linux는 SIGSEGV 신호를 발생시키고 실행을 신호 핸들러로 이동시킨다.
3. 핸들러는 다음 공격 단계(예: 또 다른 충돌 조건)를 준비한다.
4. 프로그램이 다시 크래시하면서 다음 신호 전달이 발생한다.

이렇게 SIGSEGV 핸들러가 연쇄적으로 연결된 실행 단계가 된다. 각 단계는 운영체제가 허용하는 정상적인 제어 흐름이기 때문에 CET이 일반적으로 검사하는 간접 분기나 반환 보호를 우회할 수 있다.

결과적으로 공격자는 프로그램에 이미 존재하는 코드 조각을 조합해 **임의 코드 실행(arbitrary code execution)**에 도달할 수 있다.

Linux의 SIGSEGV 신호 처리 메커니즘

Linux에서 프로그램은 SIGSEGV 같은 신호에 대해 signal handler를 등록할 수 있다. 일반적으로는 다음과 같은 용도로 사용된다.

• 오류 로그 기록
• 프로그램 복구 시도
• 디버깅 정보 출력

SFOP는 이 기능을 다음 방식으로 악용한다.

• 반복적으로 segmentation fault 발생
• 매번 signal handler 실행
• 핸들러에서 다음 실행 단계 준비

즉 신호 처리 메커니즘 자체가 재사용 가능한 제어 흐름 구성 요소가 되는 셈이다.

제안된 대응 방법

연구진과 보안 엔지니어들은 SFOP와 같은 공격을 줄이기 위한 여러 대응책을 제안했다.

1. Linux 커널 보강

하나의 방향은 Linux 커널의 신호 처리 동작을 강화하는 것이다. 반복적인 segmentation fault와 signal handler 체인을 이용한 공격 가능성을 줄이기 위한 커널 수준 수정이 논의되고 있다.

현재 공개된 요약 자료에서는 구체적인 구현 세부 사항이 제한적으로 공개되어 있다.

2. PLaTypus 하드닝 계층

또 다른 방어책은 PLaTypus라는 연구용 보안 계층이다.

연구진은 CET이 활성화된 상태에서도 공격자가 서로 다른 공유 라이브러리 사이를 자유롭게 이동하며 실행 흐름을 재구성할 수 있다는 점을 발견했다.

PLaTypus는 다음 방식으로 이를 완화한다.

• 간접 점프가 가능한 범위를 제한
• 가능하면 같은 라이브러리 내부에서만 제어 흐름 이동 허용
• 라이브러리 간 이동은 명시적으로 허용된 경우에만 가능

이 방식은 공격자가 활용할 수 있는 코드 재사용 대상(가젯)을 크게 줄여 공격 표면을 대폭 감소시킨다.

왜 SFOP 연구가 중요한가

SFOP는 중요한 보안 교훈을 보여준다.

하드웨어 보안 기능만으로는 충분하지 않으며, 운영체제 동작과의 상호작용까지 고려해야 한다는 점이다.

CET처럼 강력한 CPU 보호 기능도 공격자가 **합법적인 시스템 메커니즘(예: 신호 처리)**을 활용하면 우회될 수 있다.

따라서 향후 보안 설계에서는 다음과 같은 접근이 중요해진다.

• CPU 하드웨어 보호
• 운영체제 커널 설계
• 라이브러리 및 런타임 구조

이 모든 계층을 함께 고려하는 전체 스택 보안 모델이다.