한 가지 취약점에 대해...

21년 전인 2019년 XNUMX월 XNUMX일, 버그 현상금 프로그램 Mail.Ru HackerOne에 아주 좋은 사람이 왔습니다 버그 보고서 부터 맥사르. HTTP 리디렉션을 반환한 웹 메일 API 요청 중 하나의 POST 매개 변수에 0바이트(ASCII XNUMX)를 도입하면 초기화되지 않은 메모리 조각이 리디렉션 데이터에 표시되었습니다. 동일한 서버.

이는 심각한 취약점이기 때문에... 요청에는 세션 쿠키도 포함되어 있습니다. 몇 시간 후, 13바이트를 필터링하는 임시 수정이 이루어졌습니다(나중에 밝혀졌지만 헤더를 조작할 수 있는 CRLF/ASCII 10, XNUMX을 주입할 가능성이 여전히 있었기 때문에 이것만으로는 충분하지 않았습니다. HTTP 응답 데이터의 경우 덜 중요하지만 여전히 불쾌합니다). 동시에 버그의 원인을 찾아 제거하기 위해 문제를 보안 분석가와 개발자에게 전달했습니다.

Mail.ru 메일은 매우 복잡한 애플리케이션으로, 오픈 소스(모든 무료 소프트웨어 개발자에게 감사드립니다)와 자체 개발된 다양한 프런트엔드/백엔드 구성 요소가 응답 생성에 포함될 수 있습니다. 우리는 nginx와 openresty를 제외한 모든 구성 요소를 제외하고 호출하기 전에 문제를 현지화했습니다. ngx.req.set_uri() 예상대로 작동하지 않는 OpenResty 스크립트에서(문서에 따르면 사용되며 정확히 동일한 방식으로 작동해야 하는 ngx_http_rewrite_module에서 다시 작성하여 GET 매개변수를 통해 널 바이트 또는 라인 피드 삽입) 작동하지). 가능한 결과를 제거하고 필터링을 최대한 엄격하게 추가했으며 필터링을 검증하여 가능한 모든 벡터를 제거했습니다. 그러나 메모리 내용 유출을 초래한 메커니즘은 미스터리로 남아 있었습니다. 한 달 후, 버그 리포트는 해결된 대로 종료되었고, 버그 원인 분석은 더 나은 때까지 연기되었습니다.

OpenResty는 nginx 내부에서 Lua 스크립트를 작성할 수 있는 매우 인기 있는 플러그인이며 여러 Mail.ru 프로젝트에서 사용되므로 문제가 해결되지 않은 것으로 간주되었습니다. 그리고 얼마 후 그들은 진정한 이유와 가능한 결과를 이해하고 개발자에게 권장 사항을 제시하기 위해 마침내 다시 돌아왔습니다. 소스코드 발굴에 참여했습니다. 데니스 데니 소프 и 니콜라이 에르미쉬킨. 그것은 밝혀졌다:

• nginx에서 사용자 데이터로 다시 쓰기를 사용할 때 일부 구성에서는 디렉터리 탐색(아마도 SSRF)이 발생할 가능성이 있지만 이는 알려진 사실이며 다음의 정적 구성 분석기에 의해 감지되어야 합니다. Nginx 증폭 и 기시 Yandex에서 제공합니다(예, 저희도 그걸 사용하고 있습니다. 감사합니다). OpenResty를 사용할 때 이 기능을 놓치기 쉽지만 이는 구성에 영향을 미치지 않습니다.

  구성 예:

  location ~ /rewrite {
      rewrite ^.*$ $arg_x;
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  결과

  curl localhost:8337/rewrite?x=/../../../../../../../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

• Nginx에는 다시 쓰기 라인에 널 바이트가 포함된 경우 메모리 누수를 일으키는 버그가 있습니다. 리다이렉트가 발생하면 nginx는 라인의 전체 길이에 해당하는 새로운 메모리 버퍼를 할당하지만 XNUMX바이트가 라인 종결자인 line 함수를 통해 거기에 라인을 복사하므로 라인은 XNUMX까지만 복사됩니다. 바이트; 버퍼의 나머지 부분에는 초기화되지 않은 데이터가 포함됩니다. 상세한 분석을 보실 수 있습니다 여기에.

  구성 예(^@ XNUMX바이트)

  
  location ~ /memleak {
      rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  결과
  curl localhost:8337/secret -vv
...
curl localhost:8337/memleak -vv
...
Location: http://localhost:8337/secret
...


• Nginx는 서비스 문자 주입으로부터 GET 매개변수를 보호하고 재작성 시 GET 매개변수만 사용할 수 있도록 합니다. 따라서 nginx에서는 사용자가 제어하는 ​​매개변수를 통한 주입을 이용하는 것이 불가능합니다. POST 매개변수는 보호되지 않습니다. OpenResty를 사용하면 GET 및 POST 매개변수 모두로 작업할 수 있으므로 OpenResty를 통해 POST 매개변수를 사용할 때 특수 문자를 삽입하는 것이 가능해집니다.

  구성 예:

  location ~ /memleak {
      rewrite_by_lua_block {
          ngx.req.read_body();
          local args, err = ngx.req.get_post_args();
          ngx.req.set_uri( args["url"], true );
      }
  }
  
  location / {
      root html;
      index index.html index.htm;
  }
  

  결과 :

  curl localhost:8337 -d "url=secret" -vv
...
curl localhost:8337 -d "url=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv
...
Location: http://localhost:8337/{...может содержать secret...}
...


추가 반응

이 문제는 nginx 및 OpenResty 개발자에게 보고되었으며 개발자는 이 문제를 nginx의 보안 버그로 간주하지 않습니다. nginx 자체에는 특수 문자를 삽입하여 오류를 악용할 수 있는 방법이 없습니다. 메모리 공개 16월 4일에 출판되었습니다. 보고서 이후 18개월 동안 OpenResty에는 변경 사항이 없었지만 ngx.req.set_uri() 함수의 안전한 버전이 필요하다는 이해가 있었습니다. 2020년 21월 XNUMX일에 정보를 게시했으며, XNUMX월 XNUMX일에 OpenResty가 출시되었습니다. 버전 1.15.8.3, URI 유효성 검사를 추가합니다.

포트위거 написал 좋은 기사이며 OpenResty 및 Nginx에서 의견을 가져왔습니다(비록 작은 메모리 조각만 노출된다는 의견은 부정확하고 오해의 소지가 있지만 이는 null 바이트 다음 줄의 길이에 의해 결정되며, 길이는 공격자가 제어할 수 있습니다).

그렇다면 실수는 무엇이며 이를 방지하기 위해 무엇을 할 수 있습니까?

nginx에 버그가 있었나요? 네, 그렇습니다. 메모리 내용 유출은 어떤 경우에도 오류이기 때문입니다.

OpenResty에 버그가 있었나요? 예, 최소한 OpenResty가 제공하는 기능의 보안 문제는 조사 및 문서화되지 않았습니다.

OpenResty에 구성/사용 오류가 있었나요? 예, 명시적인 설명이 없으면 사용 중인 기능의 보안에 대해 확인되지 않은 가정이 이루어졌기 때문입니다.

다음 중 현상금이 10000달러인 보안 취약점은 무엇입니까? 우리에게 이것은 일반적으로 중요하지 않습니다. 모든 소프트웨어, 특히 여러 구성 요소의 교차점, 특히 다양한 프로젝트와 개발자가 제공하는 소프트웨어에서는 누구도 작업의 모든 기능이 알려져 있고 문서화되어 있으며 오류가 없다고 보장할 수 없습니다. 따라서 모든 보안 취약점은 보안에 영향을 미치는 곳에서 정확하게 발생합니다.

어떤 경우든 명시적인 지침이 없고 이것이 필요하지 않다는 명확한 이해가 없는 한 외부 모듈/API에 들어가는 입력 데이터를 가능한 한 많이 정규화하거나 제한/필터링하는 것이 좋습니다.

에라타

경험에서 이전 기사, 언어의 순수성을 보존하기 위해:

버그 현상금 - 버그 사냥 대회
버그 보고서 - 오류 알림
리디렉션 - 리디렉션
오픈 소스 - 오픈 소스
정오표 - 실수에 대해 노력하라

출처 : habr.com