C에서 이름을 쓰지 않고 함수 호출하기
(news.hada.io)
C 언어 자동 채점 환경의 함수 호출 제한을 우회하여 셸을 실행하는 보안 취약점 증명 사례를 통해, ASLR과 ASan 같은 보안 메커니즘이 특정 조건에서 어떻게 공격의 단서가 될 수 있는지 분석합니다.
이 글의 핵심 포인트
- 1학교 C 코드 자동 채점 시스템의 `execve` 함수 호출 제한을 우회하여 셸 실행 성공
- 2ASLR(주소 무작위화)을 우회하기 위해 허용된 함수와 목표 함수의 메모리 주소 오프셋을 활용
- 3ASan(Address Sanitizer)이 `printf`를 대체하면서 발생한 함수 주소 오프셋의 불일치를 이용해 `mmap`을 공격 대상으로 선택
- 4`mmap`을 통해 읽기, 쓰기, 실행(RWX) 권한이 모두 있는 메모리 영역을 확보
- 5직접 작성한 x86-64 어셈블리 루틴을 통해 `execve` 시스템 호출(번호 59)을 직접 실행
이 글에 대한 공공지능 분석
왜 중요한가?
단순한 코드 검사를 넘어 실행 환경의 보안 설계가 얼마나 정교해야 하는지를 보여줍니다. 보안 메커니즘(ASLR, ASan)이 역설적으로 공격자에게 메모리 구조를 파악할 수 있는 이정표를 제공할 수 있음을 증명했습니다.
어떤 배경과 맥락이 있나?
자동 채점 시스템은 사용자 코드를 실행하되 특정 함수 사용을 제한하는 샌드박스 환경을 전제로 합니다. 하지만 함수 심볼을 검사하는 방식은 공격자가 시스템 호출을 직접 호출하거나 메모리 오프셋을 계산하는 방식에 매우 취약할 수 있습니다.
업계에 어떤 영향을 주나?
클라우드 컴퓨팅이나 서버리스 환경에서 사용자 정의 코드를 실행하는 플랫폼 개발자들에게 큰 경종을 울립니다. 함수 수준의 제한보다는 `seccomp`나 `WebAssembly(Wasm)`와 같은 강력한 커널 수준의 격리 기술 도입의 필요성을 시사합니다.
한국 시장에 어떤 시사점이 있나?
보안 솔루션 및 에듀테크 기업들은 정적 분석을 넘어 동적 실행 환경에서의 권한 분리와 시스템 호출 제어를 설계의 핵심 요소로 고려해야 합니다. 단순한 화이트리스트 방식의 방어는 고도화된 공격에 무력화될 수 있음을 인지해야 합니다.
이 글에 대한 큐레이터 의견
이번 사례는 보안의 '창과 방패' 싸움에서 방어자가 사용하는 도구(ASLR, ASan)가 역설적으로 공격의 단서가 될 수 있음을 보여주는 매우 흥미로운 사례입니다. 개발자는 보안 메커니즘이 완벽하지 않음을 인지하고, 단일 레이어의 방어보다는 다층적인 방어 전략(Defense in Depth)을 구축해야 합니다.
특히, 함수 이름이나 심볼을 검사하는 방식은 공격자가 시스템 호출을 직접 호출하거나 오프셋을 계산하는 방식에 매우 취약합니다. 따라서 스타트업이 사용자 코드를 실행하는 서비스를 운영한다면, 단순한 화이트리스트 방식의 함수 제한보다는 `seccomp`를 통한 시스템 호출 차단이나 `WebAssembly(Wasm)`와 같은 격리된 런타임 도입을 진지하게 검토해야 합니다.
다만, 이러한 강력한 샌드박싱은 성능 저하나 개발 복잡도 증가라는 트레이드오프를 동반합니다. 따라서 무조건적인 강력한 보안보다는 서비스의 보안 요구 수준과 운영 비용 효율성을 면밀히 계산하여 적절한 수준의 격리 기술을 선택하는 실행력이 필요합니다.
관련 뉴스
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.