▲

NGINX Rift - 새로운 NGINX 익스플로잇

 (github.com/DepthFirstDisclosures)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • NGINX Rift는 NGINX ngx_http_rewrite_module의 치명적 힙 버퍼 오버플로인 CVE-2026-42945에 대한 원격 코드 실행 PoC임
  • 이 취약점은 rewrite와 set 지시어를 사용하는 서버에서 인증 없는 원격 코드 실행을 가능하게 함
  • 문제는 2008년에 도입된 버그로, NGINX 스크립트 엔진의 길이 계산 패스와 복사 패스가 is_args 플래그를 다르게 처리하면서 발생함
  • rewrite 치환 문자열에 ?가 있으면 메인 엔진에는 is_args가 설정되지만, 길이 계산은 새로 0으로 초기화된 서브 엔진에서 실행되어 원본 캡처 길이만 반환함
  • 복사 단계에서는 is_args = 1 상태로 ngx_escape_uri와 NGX_ESCAPE_ARGS가 호출되어 이스케이프 가능한 각 바이트가 3바이트로 확장되고, 과소 할당된 힙 버퍼를 공격자 제어 URI 데이터로 넘치게 만듦
  • 익스플로잇은 요청 간 힙 풍수(heap feng shui) 를 사용해 인접한 ngx_pool_t의 cleanup 포인터를 오염시키며, URI 바이트에 null 바이트를 넣을 수 없어 POST 본문을 통해 스프레이함
  • 오염된 포인터는 가짜 ngx_pool_cleanup_s로 리다이렉트되고, 풀 파괴 시 system()을 호출하도록 구성됨
  • CVE-2026-42945와 함께 CVE-2026-42946, CVE-2026-40701, CVE-2026-42934 등 3개의 메모리 손상 이슈도 depthfirst의 보안 분석 시스템이 NGINX 소스 온보딩 한 번으로 자율 발견함
  • 영향을 받는 버전은 NGINX Open Source 0.6.27–1.30.0 및 NGINX Plus R32–R36이며, 수정 버전은 Open Source 1.31.0/1.30.1, Plus R36 P4/R35 P2/R32 P6로 제시됨
  • 전체 벤더 권고는 https://my.f5.com/manage/s/article/K000160932에 있으며, 기술 상세는 technical write-up에서 다룸
  • PoC는 Ubuntu 24.04.3 LTS에서 테스트되었고, ./setup.sh, docker compose -f env/docker-compose.yml up, python3 poc.py --shell 순서로 취약 NGINX 컨테이너를 띄우고 셸을 실행하는 흐름을 제공함

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 보안 담당자로서, 공개된 익스플로잇이 ASLR 우회를 하지 않는다는 이유로 이 문제가 훨씬 덜 무섭다고 단정하거나 암시하는 반응이 너무 많아 피곤함
    원문은 이 공격으로 ASLR을 안정적으로 우회할 방법이 있다고 주장하고, 증거가 없어도 기본 가정으로 믿을 만하다고 봄
    ASLR은 익스플로잇을 어렵게 만드는 심층 방어 기법일 뿐이고, 대부분의 경우 시간과 실력이 있으면 ASLR 우회가 붙게 됨
    LLM 에이전트 때문에 그 시간과 실력의 장벽도 몇 주마다 낮아지고 있어, 완전히 무기화된 익스플로잇이 나오는 건 시간문제이며 공개될 수도, 비공개로 남을 수도 있음
    “ASLR을 켰으면 위험하지 않다”는 말은 명백히 틀렸고, 그런 말을 믿는 사람에게 매우 해롭다
    완화 기법이 익스플로잇을 어렵게 만들 수 있으니 보안 취약점을 신경 쓰지 않아도 된다는 잘못된 믿음은 이미 과거에 많은 피해를 냈음
    현대적 완화 기법이 있다는 건 다행이지만 최대한 빨리 패치해야 하며, 벤더라면 연구자가 ASLR 우회를 제시하지 않았다고 취약점 보고를 무효로 취급하지 말고 근본 원인을 고쳐야 함

    • 원격에서 접근 가능한 취약점은 가볍게 보면 안 됨
      다만 현재로서는 전제 조건이 좀 특이해 보임
      10년 동안 여러 구성으로 nginx를 써 왔지만 rewrite와 set을 함께 쓴 적은 한 번도 없음
    • “AI가 사이버를 해결할 것”이라고 말하는 사람들과, “ASLR 켰으면 괜찮다”고 말하는 사람들은 1:1로 겹친다고 봐도 안전함
      그리고 꼭 “cyber”라고 말함
    • 이 관점에는 동의하지 않거나, 적어도 다르게 표현하고 싶음
      ASLR은 맞춰야 하는 추가 비밀번호와 비슷하고, 일정한 엔트로피를 가지며 보통 안정적임
      취약점에 정보 누출 부분이 없다면 ASLR은 그 취약점을 완전히 완화하거나, 아니면 두 번째 취약점이 필요함
      그건 다른 논의임
      ASLR은 개별 취약점은 완전히 완화할 수 있지만, 익스플로잇 체인까지 막을 수는 없음
      그래도 빠른 패치를 설득하려면 정보 누출을 만드는 두 번째 취약점 가능성을 근거로 드는 편이 낫다고 봄
      익스플로잇 체인은 모든 종류의 취약점에서 위험함
    • 인터넷에서 잘못된 정보가 퍼지는 걸 막기는 어렵고, 대부분은 자신이 틀렸다는 것도 모름
      정말 해로운 건 확신에 찬 무작위 인터넷 댓글을 그대로 믿는 것임
      그런 걸 꿰뚫어 보는 능력을 키우면 보안뿐 아니라 다른 곳에서도 도움이 됨
    • 공개 인터넷에 노출된 소프트웨어의 원격 코드 실행 보고서를 읽으면 보통 몇 분 안에 업그레이드함
      그래서 이런 보고서를 읽는 것이고, 진지하게 받아들여야 함
      그러지 않으면 조만간 기계가 뚫림
      최근에는 공개되는 원격 코드 실행 익스플로잇 중 사전 공지가 없는 경우가 많아 보이고, 적어도 소프트웨어를 업그레이드할 몇 분은 줬으면 함
      원격 익스플로잇 가능한 sendmail 버그들이 쏟아지던 1980년대 말~1990년대 초처럼 공개에 안전장치가 없던 시절 같음
      이런 보고서를 읽지 않거나 너무 늦게 읽으면 수백만 대가 침해될 수 있음
      현재 nginx는 공개 웹 서버 시장의 약 39~43%를 차지하므로 꽤 심각함

  • 이번 건은 꽤 나쁘지만 전제 조건이 있음
    대체 문자열에 물음표가 들어간 rewrite 지시문이 필요하고, 그 뒤에 정규식 캡처 그룹을 참조하는 set 지시문이 와야 함
    예: set $var $1
    또한 개념 증명은 ASLR 비활성화를 가정함

  • 공식 F5 페이지는 여기 있음: https://my.f5.com/manage/s/article/K000161019
    다른 곳에서도 적혔듯 ASLR이 보호해 줌
    영향받는 플랫폼의 수정판을 기다리는 동안 완화책으로 “rewrite 정의에서 이름 없는 캡처 대신 이름 있는 캡처를 쓰라”고 안내함
    “이 예시에서 취약점을 완화하려면 $1과 $2를 적절한 이름 있는 캡처인 $user_id, $section으로 바꾸라”는 내용임
    F5는 1.31.0과 1.30.1을 패치했음
    OpenResty는 1.27과 1.29용 패치가 있음: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
    Nginx 기반 Lua 애플리케이션 서버인 OpenResty의 진행 상황은 여기서 볼 수 있음: https://github.com/openresty/openresty/issues/1119

  • 개념 증명은 ASLR을 비활성화함: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

    • 워커 프로세스는 마스터에서 fork되므로 같은 메모리 배치를 받음
      워커를 상대로는 무제한으로 크래시를 낼 수 있음
      이를 이용해 읽기 오라클을 만들 방법이 있을 가능성이 큼
      적어도 안정적인 서비스 거부는 가능함
      Depth First의 전체 분석: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

  • Apache와 Nginx의 좋은 대안 중 메모리 안전 언어로 작성됐고 보안 구멍이 많지 않은 것이 있을까?
    Java로 작성된 Jetty와 Go로 작성된 Caddy를 잠깐 봤지만, Jetty의 셸 주입 같은 다른 유형의 취약점 이력이 있어서 더 나을지 확신이 안 듦

    • 메모리 안전성은 좋지만 모든 위협을 막지는 못함
      요즘 인프라 운영자는 능동적 방어인 MAC, 즉 SELinux와 AppArmor에 익숙해져야 함
      예전에는 마찰이 컸지만 지금은 사용을 쉽게 해 주는 도구가 더 많음
      https://presentations.nordisch.org/apparmor/
      https://github.com/nobody43/apparmor-profiles/blob/master/ng...
      https://github.com/nobody43/apparmor-suggest
      참고로 두 저장소 모두 직접 만든 것임
    • Apache와 nginx 규모로 쓰이는 소프트웨어라면 어떤 것이든 취약점 이력이 있을 수밖에 없음
      둘 다 그렇게 오래 시장 점유율을 유지했다는 사실은 오히려 좋은 신호임
    • Caddy는 사용하기 정말 편했음
      다만 제대로 된 플러그인 시스템 대신 원하는 플러그인 조합에 따라 수천 개의 바이너리가 생기는 모델은 좀 별로임
      그래도 소스에서 빌드한다면 꽤 깔끔하고 단순함
    • Apache와 아마 Nginx도 기능과 구성 요소가 엄청 많음
      대체 HTTP 서버들은 대부분 범위를 많이 줄이므로, 어떤 기능이 필요한지 먼저 정해야 함
      메모리 안전 언어로 된 HTTP 서버 논의는 많이 보지 못했음
      C 기반의 큰 세 서버인 Apache, Nginx, lighttpd는 모두 꽤 탄탄하고, 단지 언어 때문에 새 프로젝트로 갈아타려는 사람이 많지는 않은 듯함
      또 대부분의 메모리 안전 언어를 선택하면 그 언어의 때로는 방대한 런타임이나 가상 머신, 부속 요소까지 같이 받아들이게 됨
      Java 웹 서버라면 무작위 Java 프로젝트가 흔히 그렇듯 log4j를 쓸 가능성이 있음
    • 로드 밸런서 용도라면 HAProxy가 아주 잘하고 있음

  • “익스플로잇은 요청 간 힙 풍수(cross-request heap feng shui)를 사용한다”라니, 이런 식으로 feng shui가 쓰인 건 처음 봄

  • Debian 12에는 이게 패치됐나?
    그래도 어디에서도 rewrite나 set을 쓰지 않으면 영향받지 않는다고 보면 되나?

    • https://security-tracker.debian.org/tracker/CVE-2026-42945
    • Ubuntu는 오늘 아침 기준으로 패치됐음
      Debian은 아직 trixie를 패치한 것 같지 않음
    • nginx를 쓰면서 최소한 set조차 안 쓰는 경우는 매우 드물 것 같음
      대부분의 nginx 사용 사례는 TLS를 종료하고 요청을 node/php/go 등으로 넘기는 것임
      그래서 proxy_set_header X-Host $host; 같은 줄에서 공격자가 제어하는 데이터가 들어간 set이 하나쯤은 있을 거라고 봤음
      정정: 이름 있는 캡처는 영향을 받지 않는 듯함
      어디엔가 $1이 없다면 괜찮을 것 같음

  • 더 나은 링크:
    https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
    https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)

답변달기