cynepmyx/nginx-rift-checknginx 구성에서 CVE-2026-42945 rewrite 패턴을 탐지합니다: 대체 문자열에 ?가 포함된 rewrite와 동일한 location 내에서 사용되는 이름 없는 캡처 그룹
nginx의 ngx_http_rewrite_module에서 힙 버퍼 오버플로우인 CVE-2026-42945에 취약한 구성을 찾아냅니다.
영향을 받는 nginx 버전(0.6.27부터 1.30.0까지)을 실행하는 것만으로는 익스플로잇이 가능하지 않습니다. 구성에는 특정 지시문 쌍이 포함되어 있어야 하며, 그 쌍은 드뭅니다. 실제 구성에 대한 두 번의 독립적인 스캔에서 1465개 중 0개, 35633개 중 1개만이 익스플로잇 가능한 것으로 나타났습니다. 이 스크립트는 자신이 그 기준선의 어느 쪽에 있는지 알려줍니다.
replacement에 ? 뒤에 인자가 따라오는 rewrite와, 같은 location에서 읽히는 이름 없는 캡처($1~$9)가 이어지는 패턴:
location / {
rewrite ^(.*) /new?c=1; # the ? here raises the internal is_args flag
set $myvar $1; # ...which was never cleared, and leaks into this
return 200 $myvar;
}
한 번의 패스는 원시 문자열에 대한 버퍼 크기를 정하고, 다음 패스는 이스케이프된 버전을 그 버퍼에 복사합니다. 두 반쪽 모두 각각은 올바르게 보입니다.
아래의 모든 규칙은 추론이 아니라 nginx 1.30.0에서 측정된 것입니다. 공개된 설명 중 두 가지가 틀렸기 때문입니다.
| 단일 location 내부의 구성 | 충돌 |
|---|---|
rewrite ^(.*) /new?c=1; + set $x $1; | yes |
rewrite ^/old/(.*)$ /new?x=1; + set $x $1; | yes |
rewrite ^/old/(.*)$ /new/$1?; + set $x $1; | no |
rewrite ... /mid?c=1; 그 다음 rewrite ... /new; 그 다음 set $x $1; | no |
rewrite ^(.*) /new?c=1 break; + set $x $1; | no |
rewrite ^(?<tail>.*) /new?c=1; + set $x $1; | yes |
rewrite ^(?<tail>.*) /new?c=1; + set $x $tail; | no |
설명할 가치가 있는 두 가지 결과:
끝에 붙는 ?는 위험하지 않습니다. /new/$1?는 상속된 쿼리 문자열을 제거하는 방법이며, 많은 마이그레이션 구성에서 나타납니다. 모든 ?를 플래그하면 인터넷의 절반에게 경고를 보내는 셈입니다.
"이름 있는 캡처는 안전하다"는 말은 잘못된 설명입니다. 중요한 것은 캡처가 어떻게 선언되었는지가 아니라 어떻게 읽히는지입니다. 이름 있는 그룹을 $1로 읽으면 이름 없는 그룹과 똑같이 충돌합니다.
같은 측정된 이유로 무시되는 것들: 정규식 자체 내부의 ?(수량자), 그리고 소비자가 실행되기 전에 처리를 종료하는 redirect / permanent / break.
nginx -T | python3 check_rewrite.py
python3 check_rewrite.py /path/to/dump.txt
python3 check_rewrite.py --json /path/to/dump.txt
Python 3, 표준 라이브러리만 사용합니다.
종료 코드: 0 깨끗함, 1 쌍을 찾음, 2 구성을 읽거나 파싱할 수 없음. 세 번째가 핵심입니다. 닫히지 않은 따옴표나 균형이 맞지 않는 중괄호는 분석을 중단시키며, 읽지 못한 파일에 대해 "아무것도 찾지 못함"이라고 답하는 검사기는 크래시하는 검사기보다 더 나쁩니다. 그런 경우에는 그 사실을 알리고 2를 반환합니다.
개별 파일이 아니라 nginx -T를 입력으로 주십시오. include는 어디에나 있을 수 있고, 생성된 구성은 실행 중인 서버에서만 참이기 때문입니다. 발견 사항은 덤프의 오프셋이 아니라 지시문이 실제로 존재하는 파일과 줄에 대해 보고됩니다.
$ python3 check_rewrite.py samples/vuln-nginx-T.txt
[HIGH] находка #1
location: location / (/etc/nginx/nginx.conf:14)
rewrite: rewrite ^(.*) /new?c=1 (/etc/nginx/nginx.conf:15)
захват $N: set -> set $myvar $1 (/etc/nginx/nginx.conf:16)
почему: обработка продолжается в этом же location без редиректа
Итого находок: 1
모든 보고서의 끝에도 출력되므로 누구도 이 도구를 보증으로 오해하지 않습니다:
location당 첫 번째 쌍만 보고됩니다.rewrite와 set이 location 안이 아니라 server에 직접 있는 경우는 추적되지 않습니다.set $tmp $1; 후 $tmp를 사용하는 경우)은 추적되지 않습니다.try_files, error_page 및 이름 있는 location을 통한 점프는 추적되지 않습니다.if 안의 쌍도 여전히 보고됩니다.구성 검사보다 업데이트가 더 확실합니다. nginx.org에서 현재 안정 버전 또는 메인라인 릴리스를 사용하십시오.
python3 -m unittest test_check_rewrite -v
29개의 테스트. 대부분은 부정 사례입니다. 이와 같은 도구의 위험은 정상적인 구성에 대해 경고를 보내는 것이기 때문입니다. 또한 11개의 포함된 파일에 걸쳐 250줄로 구성된 프로덕션 구성에 대해 실행되었으며, map 정규식과 따옴표 안에 세미콜론으로 가득 찬 CSP 헤더가 있는 상태에서 실행되었습니다. 발견 사항 0개, 파싱 불만 0개였고, 실제 쌍을 주입한 후에는 정확히 1개의 발견 사항이 있었습니다.
MIT