오픈SSL, ‘고위험도’ 취약점 패치… “예상만큼 치명적이진 않아”

오픈SSL(OpenSSL) 프로젝트 측에서 지난 주 예고한대로 2가지 취약점을 보완하는 패치를 11월 1일 배포했다. 다만 위험도를 '치명적인(critical)'에서 '고위험(high severity)'으로 하향 조정했다. 
 
가장 널리 사용되는 오픈소스 프로젝트 중 하나인 오픈SSL은 수많은 웹 사이트, 서버 및 클라이언트를 보호하는 데 사용되는 암호화 라이브러리이다. 11월 1일에 오픈SSL 프로젝트 측에서 두 가지 심각한 취약점에 대한 패치를 출시했다. 

프로젝트 유지 관리자들은 지난 주부터 사용자에게 11월 1일에 중요한 패치를 준비하라고 경고했다. 이후 추가 테스트를 거쳐 위험도가 하향 조정됐다.

기업은 여전히 영향을 받는 애플리케이션과 서버를 파악하고 가능한 한 빨리 패치를 배포해야 한다. 이 취약점은 지난해부터 사용 가능한 모든 버전의 오픈SSL 3.0에 영향을 미친다.
 

X.509 인증서 확인 시 버퍼 오버플로

두 가지 취약점(CVE-2022-3786 및 CVE-2022-3602)은 2021년 9월 오픈SSL 3.0.0에서 처음 도입된 'punycode' 디코딩 기능의 버퍼 오버플로 조건이다. 'punycode'는 유니코드 문자를 ASCII로 표현하기 위한 시스템인데, DNS에서 국제화된 도메인 이름을 나타내기 위해 사용된다. 오픈SSL에서 취약한 코드는 X.509 인증서의 이메일 주소 제약 조건을 처리하는 데도 사용된다. X.509 인증서는 일반적으로 SSL/TLS 인증서라고도 한다.

오픈SSL 유지 관리자들은 권고문에서 "신뢰할 수 없는 소스로부터 받은 X.509 인증서를 확인하는 모든 오픈SSL 3.0 애플리케이션은 취약한 것으로 간주되어야 한다"라고 말했다. 권고안은 "이는 TLS 클라이언트 인증을 사용하도록 구성된 TLS 클라이언트와 TLS 서버를 포함한다”라고 덧붙였다.

OpenSS은 인증서를 검증해 연결하는 서버의 신원을 확인하기 위해 브라우저나 응용 프로그램과 같은 클라이언트에 의존한다. 이러한 시나리오에서 응용 프로그램은 이러한 취약점을 공격하기 위해 악의적으로 조작된 인증서를 제공하는 서버에 연결해야 한다. 공격자는 중간자 공격(man in the middle attack, MITM) 공격 기법을 써 애플리케이션과 서버 사이에 악성 코드를 삽입하고 애플리케이션 요청을 가로챌 수 있다.

서버가 클라이언트 인증을 사용하도록 구성된 경우에도 (서버가 제공하는 인증서를 확인해 클라이언트의 ID도 확인할 때) 공격에 노출될 수 있다. 
 

‘치명적(critical)’에서 ‘고위험(high severity)’으로 위험도 조정

오픈SSL 프로젝트는 CVSS 취약점 점수 시스템을 사용하지 않는다. 대신 보안 정책에 설명된 대로 자체 위험도 순위 시스템을 갖추고 있다. 정책에 따르면 중요한 문제는 "공통 구성"에 영향을 미치고 악용될 가능성이 있는 문제다. 예를 들어 서버 메모리의 내용(사용자 세부 정보 노출), 서버 개인 키를 손상시키기 위해 원격으로 쉽게 악용될 수 있는 취약점, 또는 일반적인 상황에서 원격 코드 실행 가능성이 높다고 간주되는 취약점 등이 있다."

버퍼 오버플로로 인해 이론적으로 원격 코드가 실행될 수 있다. 그러나 이는 특정 조건, 특정 플랫폼 혹은 특정 시스템에서 사용되는 다양한 완화 조치에 크게 좌우된다.

처음에 유지 관리자들은 CVE-2022-3602가 4바이트 스택 오버플로우이기 때문에 치명적이라 여겼다. 또한 공격자가 덮어쓰기 내용을 제어할 수 없기 때문에 처음에는 CVE-2022-3786을 높은 위험도로 간주했다. 

그러나 취약점 세부 정보(Linux 배포와 같은 오픈SSL을 번들하는 범용 OS 공급업체 포함)를 사전에 통보받은 기업과 함께 추가 논의 및 테스트를 수행한 후 위험도를 수정했다.

"첫째, 특정 리눅스 배포판에서는 스택 레이아웃이 4바이트가 아직 사용되지 않은 인접 버퍼를 덮어쓸 수 있다는 보고가 있었다. 따라서 원격 코드를 실행할 수 있는 충돌이나 기능이 없다고 생각했다"라고 프로젝트 관리자들은 설명했다. 이어 "두 번째로, 많은 최신 플랫폼은 원격 코드 실행의 위험을 완화하려 스택 오버플로 보호를 구현한다. 대신 이는 시스템 크래시를 초래하기도 한다”라고 설명했다.

물론 결함이 쉽게 원격 코드 실행으로 이어질 수 있는 상황이나 구성 및 플랫폼은 얼마든지 있다. 오픈SSL은 코드로 배포되며 임베디드 시스템을 포함한 다양한 플랫폼에서 실행될 수 있다. 애플리케이션은 직접 번들링해 정적으로 링크하거나, OS가 번들링하는 경우 OS에 포함된 라이브러리를 사용할 수도 있다. 그러나 유지 관리자들은 중요한 문제에 대한 "공통 구성 및 악용 가능성이 있는" 기준이 더 이상 이 취약점에 부합하지 않는다고 전했다. 
 

오픈SSL 3.0, 아직 낮은 채택율 

서버 측면에서 오픈SSL 3.0의 채택률은 아직 높지 않다. 센시스(Censys, 이 회사는 전체 인터넷 IP 공간을 스캔하고 서비스 실행에 대한 정보를 수집한다)에 따르면, 거의 180만 개의 인터넷 고유 호스트가 오픈SSL을 사용하는 서비스를 1개 이상 운영한다. 이 중 약 7,000개(0.4%)만이 3.0.0 이상의 오픈SSL 버전을 실행한다. 또한 오픈SSL 3.0을 실행하는 사용자 중 일부만 클라이언트 측 인증을 수행해 취약점에 노출될 가능성이 높다.  

물론, 이 원격 측정은 내부 네트워크의 서버가 아니라 인터넷에서 액세스할 수 있는 서버만 포함한다. 내부 네트워크는 또한 네트워크에 진입한 공격자가 쉽게 연결할 수 있다. 

클라우드 및 보안 업체 아카마이(Akamai)는 고객 네트워크에서 자체 검색을 수행한 결과 절반 정도가 취약한 오픈SSL 버전을 사용해 적어도 하나의 프로세스를 가진 시스템을 가지고 있다는 것을 발견했다. 이러한 네트워크에서 취약한 오픈SSL 버전을 사용한 시스템의 비율은 중앙값 6.1 및 0.2%를 더불어 33%까지 다양했다.

이러한 취약점은 서버보다는 클라이언트에서 악용될 가능성이 높다. 따라서 오픈SSL을 사용해 서버에 연결하는 클라이언트 애플리케이션에 미치는 영향이 얼마나 큰지 확인하기는 어렵다. 

이는 많은 응용 프로그램에 대한 전이적 취약점(타사 소프트웨어 종속성에서 상속된 취약점)으로 간주될 수 있다. 이러한 취약점은 소프트웨어 BOM(Software Bill of Materials)과 같은 노력이 업계에서 널리 채택될 때까지 추적하기 매우 어렵다.

다행히 이 취약점에 대한 중요한 제한 요인은 인증서 발급자의 유효성을 검사한 후에만 발생할 수 있다는 것이다. 즉, 대부분의 경우(인증서 유효성 검사가 제대로 시행된 경우) 공격자는 신뢰할 수 있는 CA(Certificate Authority, 인증 기관)에서 악의적으로 조작된 인증서를 받아야 한다.

소프트웨어 공급망 보안업체 소나타입(Sonatype)의 CTO 브라이언 폭스는 "메모리 오버플로 버그가 최악의 시나리오로 이어질 수 있지만, 이 취약점의 세부 사항은 악용에 대한 난이도 또한 매우 높다는 이면을 보여주는 것 같다”라고 말했다. 그는 "이 취약점을 이용하려면 명명 기관에서 신뢰하거나 서명한 잘못된 인증서가 필요한다. 즉, 당국이 이 취약점을 대상으로 설계된 인증서가 생성되지 않도록 신속하게 방지해 범위를 더욱 제한할 수 있어야 한다"라고 설명했다. 

레드햇(Red Ha)t은 Red Hat Enterprise Linux 9용 오픈SSL 패치를 릴리스했다. 회사는 취약점의 영향을 "중요"로 지정했다. SELinux와 Kpatch 모두 취약점을 완화시키지 않는다고 회사는 설명했다. 

기업은 시스템 또는 애플리케이션에서 오픈SSL을 화요일에 배포된 버전 3.0.7로 즉시 업데이트해야 한다. 이 프로젝트는 오픈SSL 1.1.1s도 동시에 출시했지만, 이는 이러한 취약점과 관련이 없는 버그 수정 릴리스이다. 오픈SSL 1.1.x 계열의 버전은 영향을 받지 않으며 2023년 9월까지 계속 지원되지만, 프로젝트 유지 관리자들은 응용 프로그램 개발자에게 항상 최신 버전, 즉 현재 3.0.7을 사용할 것을 권장했다. ciokr@idg.co.kr