[방어] 분석 — CVE-2026-35188

• 심각도 medium · CVSS 5.0 · EPSS 0.00302 · 악용난이도 hard

공격자는 악의적인 서버를 운영하며 TLS 핸드셰이크 과정에서 status_request 확장 필드를 통해 정교하게 조작된(crafted) OCSP stapled response를 클라이언트에 전송합니다. 클라이언트가 이 응답을 검증하는 경로에서 메모리가 중복 해제되는 double-free 현상이 발생하며, 이는 힙(Heap) 영역의 메모리 오염으로 이어집니다.

악용 가능성: 본 취약점의 공격 난이도는 Hard로 평가되며, 이는 공격자가 제어하는 악성 서버가 TLS Client와 핸드셰이크를 수행해야 하는 AV:N 환경임에도 불구하고 매우 까다로운 전제조건을 요구하기 때문입니다. 특히 OCSP stapling 기능이 기본적으로 비활성화되어 있어 대상의 설정 상태에 따라 공격 표면이 제한되며, AC:H 및 PR:L 벡터가 시사하듯 정교하게 조작된 OCSP 응답을 통해 Client의 인증서 검증 경로에서 Double-free를 유발해야 하므로 기술적 진입장벽이 높습니다. 실제 힙 메모리 오염을 통한 RCE(원격 코드 실행)는 환경 의존성이 매우 커 실현 가능성이 낮으며, 현실적으로는 DoS(서비스 거부) 유발 가능성이 더 큽니다. EPSS 수치가 0.00302로 매우 낮고 KEV에 등재되지 않은 점은 현재 야생에서 이 취약점을 이용한 실제 공격 사례가 드물며 이론적 심각도 대비 실질적 위협 수준이 낮음을 뒷받침합니다. 주요 공격 표면은 TLS 핸드셰이크 과정의 status_request 확장 필드이며, 공격자는 해당 엔드포인트를 통해 조작된 OCSP stapled response를 전달함으로써 트리거를 작동시킵니다.

• Denial of Service (DoS): 가장 직접적이고 달성하기 쉬운 결과로, 프로세스 크래시를 유발합니다.
• Arbitrary Code Execution (RCE): 추정: 힙 레이아웃 조작(Heap Grooming)을 통해 실행 흐름을 제어할 수 있으나, 이는 환경 의존성이 매우 높고 기술적으로 복잡합니다.

• Memory-Corruption: double-free 특성상 다른 힙 기반 취약점과 체이닝되어 권한 상승이나 RCE로 이어질 가능성이 존재합니다. 다만, 본 취약점은 네트워크 경계에서 발생하므로 초기 진입점으로 활용될 수 있습니다.

본 취약점은 TLS 핸드셰이크 단계의 바이너리 데이터 수준에서 발생하므로, 일반적인 애플리케이션 로그만으로는 탐지가 어렵습니다. 네트워크 트래픽 분석(NTA/IDS)과 시스템 메모리 모니터링에 집중해야 합니다.

• 네트워크 레벨 탐지 (IDS/IPS):
  • 지표: TLS Client Hello의 status_request 확장에 이어 서버가 보내는 Certificate Status 메시지의 비정상적인 길이 또는 구조 확인.
  • 탐지 패턴(의사코드):
    IF (TLS_ServerHello contains status_request_response) AND (OCSP_Response_Length > EXPECTED_MAX_SIZE OR OCSP_Response_Structure == MALFORMED) THEN ALERT
• 시스템 레벨 탐지 (SIEM/EDR):
  • 지표: OpenSSL을 사용하는 프로세스(예: curl, nginx, custom clients)의 비정상적인 종료 및 Segmentation Fault 로그.
  • SIEM 쿼리 예시:
    index=os_logs process="*openssl*" (message="segmentation fault" OR message="double free or corruption") | stats count by host, process_id
• 오탐 튜닝 및 한계:
  • 단순한 네트워크 순단으로 인한 세션 종료와 구분하기 위해, 크래시 직전의 TLS Handshake 패킷 유입 여부를 상관분석해야 합니다.

본 리포트는 다중 소스에서 일관성이 확인된 데이터를 근거로 하며, EPSS 0.00302(백분위 0.2259)라는 낮은 실측 악용 예측치와 AV:N/AC:H (높은 공격 복잡도)를 고려하여 우선순위를 monitor로 결정하였습니다. 하지만 RCE 가능성을 완전히 배제할 수 없으므로 다음과 같이 대응합니다.

• 즉시 (긴급 차단): OCSP Stapling 비활성화

  • 방법: TLS 클라이언트 설정에서 OCSP stapling 기능을 <0xEB><0x81><0x95>니다. (기본값은 비활성이나, 명시적으로 활성화한 경우 해제)
  • 난이도/영향: 낮음 / 인증서 상태 확인 지연으로 인한 보안 가시성 소폭 감소.
  • 검증: openssl s_client -status 명령어로 status response가 오지 않는지 확인.

• 단기 (완화): 메모리 보호 기법 강화

  • 방법: OS 레벨의 ASLR(Address Space Layout Randomization) 및 Heap Canary 활성화 상태를 점검하여 double-free를 통한 RCE 난이도를 극대화합니다.
  • 난이도/영향: 보통 / 시스템 전역 설정으로 운영 영향 적음.
  • 검증: /proc/sys/kernel/randomize_va_space 값 확인 (2 권장).

• 근본 (해결): OpenSSL 패치 적용

  • 방법: 영향 제품군(OpenSSL 3.6.0 - 3.6.3)을 취약점이 해결된 최신 버전으로 업데이트합니다.
  • 난이도/영향: 보통 / 라이브러리 교체 후 서비스 재시작 필요 (가용성 일시 중단).
  • 검증: openssl version 명령어로 패치 버전 적용 여부 확인.

• 조치: monitor (모니터링)
• 근거: CVSS=5.0 · non-KEV · EPSS=0.00302 · exploit=hard · in_scope=None