보안 담당자로서, 공개된 익스플로잇이 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 비활성화를 가정함
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이 없다면 괜찮을 것 같음
Hacker News 의견들
보안 담당자로서, 공개된 익스플로잇이 ASLR 우회를 하지 않는다는 이유로 이 문제가 훨씬 덜 무섭다고 단정하거나 암시하는 반응이 너무 많아 피곤함
원문은 이 공격으로 ASLR을 안정적으로 우회할 방법이 있다고 주장하고, 증거가 없어도 기본 가정으로 믿을 만하다고 봄
ASLR은 익스플로잇을 어렵게 만드는 심층 방어 기법일 뿐이고, 대부분의 경우 시간과 실력이 있으면 ASLR 우회가 붙게 됨
LLM 에이전트 때문에 그 시간과 실력의 장벽도 몇 주마다 낮아지고 있어, 완전히 무기화된 익스플로잇이 나오는 건 시간문제이며 공개될 수도, 비공개로 남을 수도 있음
“ASLR을 켰으면 위험하지 않다”는 말은 명백히 틀렸고, 그런 말을 믿는 사람에게 매우 해롭다
완화 기법이 익스플로잇을 어렵게 만들 수 있으니 보안 취약점을 신경 쓰지 않아도 된다는 잘못된 믿음은 이미 과거에 많은 피해를 냈음
현대적 완화 기법이 있다는 건 다행이지만 최대한 빨리 패치해야 하며, 벤더라면 연구자가 ASLR 우회를 제시하지 않았다고 취약점 보고를 무효로 취급하지 말고 근본 원인을 고쳐야 함
다만 현재로서는 전제 조건이 좀 특이해 보임
10년 동안 여러 구성으로 nginx를 써 왔지만
rewrite와set을 함께 쓴 적은 한 번도 없음그리고 꼭 “cyber”라고 말함
ASLR은 맞춰야 하는 추가 비밀번호와 비슷하고, 일정한 엔트로피를 가지며 보통 안정적임
취약점에 정보 누출 부분이 없다면 ASLR은 그 취약점을 완전히 완화하거나, 아니면 두 번째 취약점이 필요함
그건 다른 논의임
ASLR은 개별 취약점은 완전히 완화할 수 있지만, 익스플로잇 체인까지 막을 수는 없음
그래도 빠른 패치를 설득하려면 정보 누출을 만드는 두 번째 취약점 가능성을 근거로 드는 편이 낫다고 봄
익스플로잇 체인은 모든 종류의 취약점에서 위험함
정말 해로운 건 확신에 찬 무작위 인터넷 댓글을 그대로 믿는 것임
그런 걸 꿰뚫어 보는 능력을 키우면 보안뿐 아니라 다른 곳에서도 도움이 됨
그래서 이런 보고서를 읽는 것이고, 진지하게 받아들여야 함
그러지 않으면 조만간 기계가 뚫림
최근에는 공개되는 원격 코드 실행 익스플로잇 중 사전 공지가 없는 경우가 많아 보이고, 적어도 소프트웨어를 업그레이드할 몇 분은 줬으면 함
원격 익스플로잇 가능한 sendmail 버그들이 쏟아지던 1980년대 말~1990년대 초처럼 공개에 안전장치가 없던 시절 같음
이런 보고서를 읽지 않거나 너무 늦게 읽으면 수백만 대가 침해될 수 있음
현재 nginx는 공개 웹 서버 시장의 약 39~43%를 차지하므로 꽤 심각함
이번 건은 꽤 나쁘지만 전제 조건이 있음
대체 문자열에 물음표가 들어간
rewrite지시문이 필요하고, 그 뒤에 정규식 캡처 그룹을 참조하는set지시문이 와야 함예:
set $var $1또한 개념 증명은 ASLR 비활성화를 가정함
수동으로 끈다고 해도 nginx가 그럴 만한 후보로 떠오르지는 않음
rewrite는 거의 안 쓰지 않나?PHP와 Apache의 예전 시절에 쓰던 것 같음
공식 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
참고로 두 저장소 모두 직접 만든 것임
둘 다 그렇게 오래 시장 점유율을 유지했다는 사실은 오히려 좋은 신호임
다만 제대로 된 플러그인 시스템 대신 원하는 플러그인 조합에 따라 수천 개의 바이너리가 생기는 모델은 좀 별로임
그래도 소스에서 빌드한다면 꽤 깔끔하고 단순함
대체 HTTP 서버들은 대부분 범위를 많이 줄이므로, 어떤 기능이 필요한지 먼저 정해야 함
메모리 안전 언어로 된 HTTP 서버 논의는 많이 보지 못했음
C 기반의 큰 세 서버인 Apache, Nginx, lighttpd는 모두 꽤 탄탄하고, 단지 언어 때문에 새 프로젝트로 갈아타려는 사람이 많지는 않은 듯함
또 대부분의 메모리 안전 언어를 선택하면 그 언어의 때로는 방대한 런타임이나 가상 머신, 부속 요소까지 같이 받아들이게 됨
Java 웹 서버라면 무작위 Java 프로젝트가 흔히 그렇듯 log4j를 쓸 가능성이 있음
“익스플로잇은 요청 간 힙 풍수(cross-request heap feng shui)를 사용한다”라니, 이런 식으로 feng shui가 쓰인 건 처음 봄
Debian 12에는 이게 패치됐나?
그래도 어디에서도
rewrite나set을 쓰지 않으면 영향받지 않는다고 보면 되나?Debian은 아직 trixie를 패치한 것 같지 않음
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)