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

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

원격에서 접근 가능한 취약점은 가볍게 보면 안 됨
다만 현재로서는 전제 조건이 좀 특이해 보임
10년 동안 여러 구성으로 nginx를 써 왔지만 rewrite와 set을 함께 쓴 적은 한 번도 없음

“AI가 사이버를 해결할 것”이라고 말하는 사람들과, “ASLR 켰으면 괜찮다”고 말하는 사람들은 1:1로 겹친다고 봐도 안전함
그리고 꼭 “cyber”라고 말함

이 관점에는 동의하지 않거나, 적어도 다르게 표현하고 싶음
ASLR은 맞춰야 하는 추가 비밀번호와 비슷하고, 일정한 엔트로피를 가지며 보통 안정적임
취약점에 정보 누출 부분이 없다면 ASLR은 그 취약점을 완전히 완화하거나, 아니면 두 번째 취약점이 필요함
그건 다른 논의임
ASLR은 개별 취약점은 완전히 완화할 수 있지만, 익스플로잇 체인까지 막을 수는 없음
그래도 빠른 패치를 설득하려면 정보 누출을 만드는 두 번째 취약점 가능성을 근거로 드는 편이 낫다고 봄
익스플로잇 체인은 모든 종류의 취약점에서 위험함

인터넷에서 잘못된 정보가 퍼지는 걸 막기는 어렵고, 대부분은 자신이 틀렸다는 것도 모름
정말 해로운 건 확신에 찬 무작위 인터넷 댓글을 그대로 믿는 것임
그런 걸 꿰뚫어 보는 능력을 키우면 보안뿐 아니라 다른 곳에서도 도움이 됨

공개 인터넷에 노출된 소프트웨어의 원격 코드 실행 보고서를 읽으면 보통 몇 분 안에 업그레이드함
그래서 이런 보고서를 읽는 것이고, 진지하게 받아들여야 함
그러지 않으면 조만간 기계가 뚫림
최근에는 공개되는 원격 코드 실행 익스플로잇 중 사전 공지가 없는 경우가 많아 보이고, 적어도 소프트웨어를 업그레이드할 몇 분은 줬으면 함
원격 익스플로잇 가능한 sendmail 버그들이 쏟아지던 1980년대 말1990년대 초처럼 공개에 안전장치가 없던 시절 같음
이런 보고서를 읽지 않거나 너무 늦게 읽으면 수백만 대가 침해될 수 있음
현재 nginx는 공개 웹 서버 시장의 약 3943%를 차지하므로 꽤 심각함

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

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을 쓰지 않으면 영향받지 않는다고 보면 되나?

Ubuntu는 오늘 아침 기준으로 패치됐음
Debian은 아직 trixie를 패치한 것 같지 않음

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