CVE-2020-11100 haproxy: 잘못된 형식의 HTTP/2 요청으로 범위를 벗어난 쓰기 문제 발생 가능

요약

HAProxy가 특정 HTTP/2 요청 패킷을 처리하는 방식과 관련하여 보안 취약점이 있음이 발견되었습니다.  공격자는 메모리 손상을 일으키는 조작된 HTTP/2 요청 패킷을 전송하여 시스템 충돌을 일으키거나 HAProxy를 실행하는 사용자의 권한으로 임의의 원격 코드를 실행할 수 있습니다. 

이 문제는 CVE-2020-11100 으로 지정되어 있으며 심각한 영향을 미치는 것으로 평가되고 있습니다.

영향을 받는 제품

CVE-2020-11100의 영향을 받는 Red Hat 제품 목록은 다음과 같습니다.

영향을 받는 제품의 업데이트

기술적 세부 사항 및 배경 정보

HAProxy는 고가용성 환경에서 사용되도록 설계된 TCP/HTTP 리버스 프록시입니다.  HAProxy는 일반적으로 애플리케이션 서버 클러스터 앞에 배치되며 들어오는 요청을 서버에 분배하여 성능과 고가용성을 향상시킵니다.  웹 사이트와 함께 배포할 경우 HAProxy는 HTTP/2 프로토콜을 사용하여 네트워크 리소스를 보다 효율적으로 사용할 수 있습니다.

HAProxy가 HTTP/2 요청 패킷을 처리하는 방식에 결함이 존재합니다. 

Red Hat Enterprise Linux 6 및 7에서 제공되는 HAProxy 패키지에는 HTTP/2 지원이 포함되어 있지 않으므로 이 보안 취약점의 영향을 받지 않습니다.

OpenShift Container Platform 4 부터 4.3 버전에는 이러한 보안 취약점이 있는 코드가 포함되어 있습니다. OpenShift Ingress Operator에서 ROUTER_USE_HTTP2를 설정해야 이러한 보안 취약점을 악용할 수 있습니다. 하지만 이는 현재 불가능합니다. 따라서 이 취약점은 4.4 이전 버전의 OCP 4.x 시스템에 미치는 영향이 낮습니다.

OpenShift Container Platform 3.11에서는 ose-haproxy-router 설정 옵션을 추가하여 HTTP/2 지원을 가능하게 하고 있습니다. 그러나 해당 버전에서는 이러한 설정이 기본값으로 활성화되어 있지 않습니다.

완화 방법

영향을 받는 제품에 대한 보안 패치가 곧 릴리즈될 예정됩니다. 자세한 내용은 위의 표를 참조하십시오. 보안 패치가 제공되기 전에 솔루션이 필요하거나 대체 솔루션을 찾고 있는 고객은 아래 설명된 완화 솔루션을 확인하십시오.

Red Hat Enterprise Linux 8에서 HAProxy는 SELinux에 의해 제한되므로 원격 임의 코드 실행 문제를 완화할 수 있습니다.  

HTTP/2 프로토콜을 지원하지 않으면 이 문제를 완화할 수 있습니다. Red Hat 제품과 함께 제공되는 기본 HAProxy 설정에는 HTTP/2가 비활성화되어 있지만 고객의 환경에 맞게 이러한 기본값을 변경할 수 있습니다.

HAProxy 설정 파일에서 'h2'가 포함된 행을 검색하여 HTTP/2가 활성화되어 있는지 확인할 수 있습니다.  일반적으로 이 행은 다음과 같습니다.
    bind :443 ssl crt pub.pem alpn h2,http/1.1

OpenShift Container Platform 3.11에서 이 취약점을 완화하려면 기본적으로 HTTP/2를 비활성화 상태로 유지하고 이미 활성화된 경우 비활성화하십시오.

curl 명령행 도구를 사용하여 다음과 같이 지정된 서버에서 HTTP/2 지원이 활성화되어 있는지 확인할 수도 있습니다.  두 경우 모두 클라이언트는 HTTP/2를 사용하지만 서버는 첫 번째 경우에만 HTTP/2를 허용합니다.  호스트 이름을 적절한 이름으로 변경합니다.

$ curl -v --http2 https://h2-enabled.example.com/ 2>&1 >/dev/null | grep ALPN 
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server accepted to use h2

$ curl -v --http2 https://h2-not-enabled.example.com/ 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

** 백엔드 서버가 HTTP/2 응답을 제공하고 HAProxy가 passthrough 모드를 사용하는 경우 이 테스트는 HTTP/2가 사용되고 있음으로 표시됩니다.  테스트 결과에 HTTP/2가 사용되지 않는 것으로 표시(server did not agree to a protocol)되는 경우 HTTP/2가 지원되지 않습니다.  테스트 결과에 HTTP/2가 사용되고 있는 것으로 표시(server accepted to use h2)되는 경우 HTTP/2 응답이 승인된 위치 정보를 확인하기 위해 추가 설정 검사가 필요합니다.  테스트 결과에서 HTTP/2가 사용되고 있는 것으로 표시되지만 HTTP/2가 사용되고 있지 않다고 생각되면 라우팅 설정에서 passthrough 모드를 사용하는지 확인하십시오.

openshift-console 프로젝트의 “Cluster Console”은 passthrough 라우팅을 사용하지 않기 때문에 OpenShift Container Platform 3.11을 테스트하기에 가장 적합한 URL입니다. 이 경로는 라우터 pod 프록시를 통과하지 않는“OpenApplication-web-console 프로젝트”의 “Application Console”과 다릅니다.

$ curl -v --http2 https://console.apps.example.com 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

OpenShift Container Platform 3.11의 API 서버는 passthrough 라우팅을 사용하는 예입니다.  이는 haproxy 뒤에 있지만 passthrough하기 때문에 HTTP/2가 활성화된 golang 바이너리의 pod 내부에서 연결이 종료됩니다.  이 경우 apiserver pod 내부에 있으며 라우터 pod의 취약한 haproxy가 아닌 HTTP/2가 활성화된 것으로 감지됩니다.

$ curl -v --http2 https://apiserver-kube-service-catalog.apps.example.com 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

감사 인사

Red Hat은 이 보안 취약점을 보고해 주신 HAProxy 프로젝트팀에 감사의 말씀을 전합니다. 업스트림에서 보안 취약점의 첫 번째 보고자인 Google Project Zero의 Felix Wilhelm 님에게도 감사의 말씀을 전합니다.

참고 자료

Google Project Zero 

HAProxy팀 블로그