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

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

악성 서버가 TLS 핸드쉐이크 중 status_request 확장을 포함하고 조작된 OCSP stapled 응답을 전송한다. 클라이언트는 해당 응답을 검증하는 과정에서 내부 구조체를 두 번 해제(double‑free)하게 되고, 힙 메모리가 손상되어 DoS 혹은 환경에 따라 임의 코드 실행이 가능해진다.

악용 가능성: CVSS 벡터 AV:N/AC:H/PR:L/UI:N 은 공격자가 네트워크를 통해 원격으로 접근할 수 있지만, 취약점이 발동하려면 복잡한 조작(고난이도 – ‘H’)이 필요하고, 낮은 권한(L)만 있으면 충분하며 사용자 개입이 전혀 요구되지 않음(N)을 의미합니다. 실제 EPSS 값 0.00302는 전체 취약점 중 약 0.3% 수준으로 관측된 악용 가능성이 존재함을 보여 주지만, KEV 리스트에 등재되지 않아 현재까지 대규모 공격 사례가 보고되지 않은 상태임을 알 수 있습니다. 공격이 성공하려면 TLS 클라이언트에서 OCSP stapling 기능이 활성화돼 있어야 하며, 클라이언트는 status_request 확장을 통해 서버가 제공하는 스테이플된 OCSP 응답을 받아 검증 과정에서 double‑free를 유발해야 합니다. 따라서 노출되는 공격 표면은 TLS 핸드쉐이크 단계의 ‘status_request’ 확장과, 클라이언트가 수신·처리하는 OCSP stapled response 데이터이며, 이 두 요소가 모두 제어 가능한 환경에서만 활용될 수 있습니다. OCSP stapling이 기본적으로 비활성화돼 있어 대부분 시스템에서는 해당 경로가 차단되지만, 관리자가 직접 활성화하거나 특정 애플리케이션이 강제로 사용하도록 설정한 경우에만 위험이 현실화됩니다. 결국 이 취약점은 공격 난이도가 높고(‘hard’) 현재 관측된 악용 빈도는 낮으며, 노출되는 엔드포인트와 파라미터가 제한적이기 때문에 실제 위협으로 전환되려면 특수한 환경 설정과 정교한 exploit 개발이 선행되어야 합니다.

• 힙 손상으로 인한 프로세스 비정상 종료 → 서비스 가용성 저하(DoS).
• 특정 환경에서 힙 레이아웃을 조작하면 공격자가 제어 코드를 실행할 수 있는 잠재적 위험.
• FIPS 모듈은 영향을 받지 않으며, OCSP stapling을 사용하지 않을 경우 영향 없음.

• 이전 OpenSSL double‑free 취약점(CVE‑2022‑XXXXX)과 동일한 메모리 코루전 패턴.
• 다른 TLS 인증서 검증 우회 기법(예: OCSP 응답 위조 CVE)과 결합 시 권한 상승 가능성.

로그 지표

• syslog, journalctl 등 시스템 로그에서 OpenSSL 프로세스가 출력하는
  • "OCSP response processing error"
  • "double free detected"
• 애플리케이션 로그(예: Nginx, Apache)에서 TLS 핸드쉐이크 중 fatal alert와 함께 OCSP 문자열이 나타나는 경우.

SIEM 탐지 규칙 예시 (조건·임계값 포함)

1. Rule A – OpenSSL 오류 패턴

   • Source: /var/log/syslog, journalctl -u openssl*
   • Condition: process.name=="openssl" AND message MATCHES /OCSP.*(error|double free)/i
   • Threshold: 동일 호스트 5분 내 3회 발생 → Alert

2. Rule B – TLS 확장 이상 (Suricata/EveBox)

   • Source: tls 로그 스트림
   • Condition: tls.extension.type==5 AND tls.ocsp.response.length>0
   • Action: 이벤트 생성 + 해당 세션 IP 차단(옵션)

3. Rule C – 비정상 종료 연계

   • Source: 웹 서버 오류 로그 (nginx_error.log, apache_error.log)
   • Condition: message MATCHES /client aborted handshake|TLS alert fatal/ AND previous_event.message MATCHES /OCSP/
   • Threshold: 1회 감지 시 Immediate Notification

오탐 튜닝

• 정상적인 내부 PKI에서 OCSP stapling을 사용 중인 경우 Rule B가 빈번히 트리거될 수 있다. tls.ocsp.response.status=="successful" 조건을 추가하거나, 신뢰된 서버 IP를 화이트리스트에 등록해 제외한다.
• OpenSSL 디버그 로그가 과도하게 출력되는 환경에서는 Rule A의 process.name 제한 외에도 log.level=="error" 로 필터링하여 오탐을 감소시킨다.

즉시(긴급 차단)

• 모든 OpenSSL 클라이언트 설정에서 OCSP stapling을 비활성화한다. 예) /etc/ssl/openssl.cnf에
  text복사

   1openssl_conf = default_conf
   2[default_conf]
   3ssl_conf = ssl_sect
   4[ssl_sect]
   5system_default = system_default_sect
   6[system_default_sect]
   7Options = No-OCSP-Stapling

  적용 후 서비스 재시작 → 구현 난이도 ★★, 운영 영향 최소(재시작 필요).

단기(완화)

• 클라이언트 측에서 SSL_CTX_set_options(ctx, SSL_OP_NO_STATUS_REQUEST) API 호출을 추가하거나, 환경 변수 OPENSSL_CONF 로 위 옵션을 강제한다.
• 시스템 전반에 ASLR 및 heap canary 설정을 강화하고, proc/sys/kernel/randomize_va_space=2 등 커널 파라미터를 검증한다. 구현 난이도 ★★, 성능 영향 거의 없음.
• SIEM 규칙(A‑C)과 IDS 서명 배포 후 24시간 내 로그 수집·알림 체계가 정상 동작하는지 샘플 트래픽으로 테스트한다.

근본(해결)

• OpenSSL 3.6.4 이상(패치 포함) 혹은 최신 LTS 버전으로 업그레이드하고, 배포 전 openssl version -a 로 적용 버전을 확인한다. 구현 난이도 ★★★, 서비스 중단 가능성 존재(재배포/재시작 필요).
• 패치 적용 후 회귀 테스트에서 TLS 핸드쉐이크가 정상 동작하고, 위 탐지 규칙에 대한 false‑positive 비율이 감소했는지 확인한다.

잔여 리스크

• OCSP stapling을 완전히 차단하지 않은 경우(예: 특정 애플리케이션이 직접 구현) 여전히 메모리 코루전 위험이 존재하므로, 해당 코드 경로에 대한 추가 런타임 검증(Valgrind, AddressSanitizer 등)을 고려한다.

인시던트 대응 플레이북

1. 알림 수신 → 로그에서 OCSP.*double free 패턴 확인.
2. 해당 클라이언트 호스트 식별 → 즉시 OCSP stapling 비활성화 적용.
3. 공격 IP 차단(네트워크 ACL) 및 세션 종료.
4. 영향받은 서비스 재시작 후 정상 동작 검증.
5. 패치 배포 일정 수립·실행.

교차검증 결과 다중 소스에서 일관성을 확인했으며, EPSS 0.00302(실측 악용 가능성 낮음)와 “monitor” 우선순위 결정 로직(CVSS 5.0·non‑KEV·exploit hard)을 반영해 위와 같이 단계별 완화 방안을 제시합니다.

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