tomcat85-check

아직 Tomcat 8.5 쓰고 계신가요? 이 도구는 2025년 CVE 중 어떤 것에 실제로 영향받는지 알려줍니다 — 이 문제는 공식 페이지, NVD, 스캐너 어디에서도 완전한 답을 얻을 수 없기 때문입니다.

의존성 제로 단일 jar, 오프라인 실행, 네트워크 연결 없음, 어떤 것도 업로드하지 않음.

무엇을 해결하는가

Tomcat 8.5는 2024-03-31 EOL, 마지막 버전은 8.5.100(2024-03-19 릴리스). 이후에도 Apache는 CVE 기록에 계속해서 "8.5도 영향받음"을 명시하고 있지만, 그 말이 적힌 곳을 보는 사람은 가장 적습니다.

Apache 공식 9.x 보안 페이지에 나열된 CVE-2025-* 총 17건 중 14건이 문자 그대로 다음과 같이 적혀 있습니다:

The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.x though 8.5.100

(원문 그대로 — 14건 중 8건은 through를 though로 오타; 하한은 대부분 8.5.0, 일부 8.5.6 / 8.5.44 / 8.5.60 / 8.5.90)

이 14건을 세 군데에서 각각 보면 다음과 같습니다:

이 사실을 완전히 언급한 곳은 CVE.org에서 Apache가 CNA로 제출한 원본 기록뿐입니다 — 즉, 가장 적은 사람이 뒤지는 계층입니다. 이 도구가 하는 일은 그 계층의 정보를 여러분 머신에 실제 설치된 버전과 대조해 보여주는 것입니다.

🔴 이 도구는 데이터 소스 간의 차이를 진술하는 것이지, 특정 제품의 동작을 말하는 것이 아닙니다. "여러분의 스캐너가 이 10건을 보고할지 여부"는 그것이 어떤 DB를 읽고 어떻게 병합하는지에 달려 있습니다 — 그것은 실제 테스트해본 적이 없으므로 여기서 다루지 않습니다.

나머지 절반도 equally 중요: 14건 중 2건만 기본 구성으로 영향받음

버전 번호만으로 보고하면, 12건의 "특정 구성에서만 성립"하는 항목까지 "영향받음"으로 말하게 됩니다 — 그것은 불필요한 일을 시키는 것입니다.

따라서 설치 디렉터리를 주면 이 도구는 conf/ 아래의 모든 XML(conf/Catalina/<host>/ 포함)을 읽고, 주석 블록을 제거한 뒤 트리거 조건의 마커를 찾습니다. 주석 제거는 선택 사항이 아닙니다: 공식 server.xml에서 UpgradeProtocol 텍스트 검색은 1회 적중하지만, 주석 제거 후에는 0회입니다 — 해당 부분 전체가 주석 처리되어 있기 때문입니다.

공식 8.5.100 순정 설치에 대해 실행하면 다음과 같습니다:

기본 영향 2건 · 구성 확인됨 0건 · 수동 확인 필요 11건 · 해당 없음 1건
그중 10건은 NVD의 cpe 구성에서 8.5를 찾을 수 없음

동일한 구성에서 HTTP/2, RewriteValve, CGIServlet을 켜면 "구성 확인됨"이 5건이 됩니다.

사용법

java -jar tomcat85-check.jar <설치 디렉터리 | jar | war> ...

  --all     "버전이 범위에 없음" 항목도 함께 나열
  --utf8    Windows 콘솔에서 한글이 깨질 때 추가

# 압축 해제 배포된 Tomcat — conf/가 있는 계층을 전달하면 수동 작업이 크게 줄어듦
java -jar tomcat85-check.jar /opt/tomcat

# jar / war 하나만 있어도 스캔 가능
java -jar tomcat85-check.jar /opt/app/lib/catalina.jar

압축 해제 배포의 버전 번호는 어떻게 알아내는가

lib/ 아래의 jar 파일명에는 버전 번호가 하나도 없습니다(catalina-8.5.100.jar가 아니라 catalina.jar). 파일명만으로 버전을 얻는 도구는 이런 배포에서 하나도 인식하지 못합니다 — 그리고 "스캔 결과 없음"은 "안전함"과 똑같이 보입니다.

이 도구는 다음 순서로 버전을 얻습니다:

1. catalina.jar!/org/apache/catalina/util/ServerInfo.properties의 server.number — Tomcat 자체 version.sh가 보고하는 값
2. META-INF/MANIFEST.MF의 Implementation-Version
3. 파일명(Spring Boot 내장 형태에서만 해당)

두 출처가 일치하지 않으면(ServerInfo.properties는 덮어쓸 수 있으며, 버전 숨기기에 자주 사용됨), 둘 다 보고하며, 대신 선택하지 않습니다.

넘지 않는 세 가지 선

첫째, 켜져 있음을 확인할 수는 있어도, 꺼져 있음을 확인할 수는 없습니다. 보고서에 "찾지 못함"이라고 쓰면, 그것은 내가 본 파일에서 찾지 못했다는 뜻이지 "켜져 있지 않다"는 뜻이 아닙니다. 구성은 이 도구가 볼 수 없는 곳에 존재할 수 있습니다: war 내부의 WEB-INF/web.xml, 외부 CATALINA_BASE, 시작 파라미터. 따라서 "영향받지 않음"이라는 등급은 없습니다 — 찾지 못하면 전부 수동 확인 필요로 떨어집니다.

둘째, 찾았다고 해서 항상 그것과 같지는 않습니다. 예를 들어 공식 기본 server.xml에서 AprLifecycleListener는 원래 활성화되어 있고, 그것은 단지 native 라이브러리 로드를 시도할 뿐입니다 — 라이브러리가 없으면 APR 커넥터는 활성화되지 않습니다. 그래서 이것은 "약한 마커"입니다: 적중 시 "가능성 있음"만 보고하고 "확인됨"은 보고하지 않습니다.

셋째, 업그레이드할 수 있는 8.5 버전이 없습니다. 14건의 first_patched_version은 8.5 쪽에서 전부 null입니다. "아직 수정 안 됨"이 아니라 "8.5를 위해 수정하지 않을 것"입니다. 유일한出路는 라인 변경(9.0 / 10.1 / 11.0)입니다. 이 도구는 "무엇에 영향받았는지"를 답하며, "어느 8.5로 업그레이드할지"를 답하는 척하지 않습니다.

"도구가 오류를 보고했다"고 착각하게 만드는 또 한 가지: 같은 CVE에 여러 등급이 있음

CVE-2025-55754를 예로 들면, 네 숫자 모두 진짜입니다:

NVD만 보면 가장 심각한 항목이라고 생각할 것이고, Apache만 보면 무시해도 된다고 생각할 것입니다. 둘 다 틀린 것이 아닙니다 — Apache는 기본 구성에서의 실제 악용 가능성을 평가하고, CVSS는 벡터에 따라 기계적으로 계산하며, 해당 기능을 켰는지 보지 않습니다.

그래서 이 도구는 네 숫자를 모두 출력하고, 양쪽 판정이 다를 때 명확히 말합니다.

두 용어 체계는 같은 것이 아니며, 정렬은 공식 지원 단계까지만 수행

Apache는 low / moderate / important / critical을, GitHub는 low / medium / high / critical을 사용합니다. 정렬 근거는 Tomcat 공식 security-impact.html 원문에서 옵니다:

Important / High — A vulnerability rated as Important (or High) impact is one which could result in the compromise of data or availability of the server.

→ Important와 High는 같은 등급의 두 이름이며, 이것은 공식 문서에서 함께 적혀 있습니다. 🔴 그리고 moderate와 medium은 공식적으로 정렬된다고 말하지 않으며, 이 도구도 대신 정렬하지 않습니다 — ASF의 Moderate는 "현저한 완화 요소 / 일반 구성에 영향 없음 / 인증 필요" 같은 악용 가능성 조건을 정의하고, GitHub의 medium은 CVSS 점수 구간으로, 둘은 같은 것이 아닙니다. 이런 경우 "공식적으로 두 등급이 같다고 말하지 않음"으로 보고하고 둘 다 제시합니다.

이 기준에 따르면 14건 중 5건은 양쪽 판정이 실질적으로 다르며(가장 큰 차이 CVE-2025-52520: Apache low / GitHub high), 2건은 정렬 불가, 7건은 동일합니다.

데이터 출처와 재현 방법

판정 테이블 CveTable.java는 생성되며, 한 줄도 수기로 작성하지 않습니다:

python -u tools/fetch_sources.py    # 1차 소스 3개 가져오기 → tools/sources.json
python -u tools/gen_table.py        # CveTable.java 생성(단언 5개, 하나라도 실패하면 파일을 쓰지 않음)

문서/릴리스 전에 독립 기준의 재검증을 한 번 더 실행합니다 — 위의 sources.json을 읽지 않고, 생성된 CveTable.java를 파싱한 다음 cpe로 NVD를 다시 조회합니다:

python -u tools/recheck_before_publish.py

이 단계는 형식적인 것이 아닙니다: 첫 실행에서 실제 오류를 하나 잡아냈습니다. 생성 스크립트가 "NVD에 8.5가 있는지"를 판정할 때 "범위 하한이 8.5로 시작"만 인식했는데, CVE-2025-24813은 versionStartIncluding=None .. versionEndExcluding=9.0.99로 적혀 있었습니다 — 하한이 열려 있어 8.5를 포함합니다. 차집합이 그래서 한 건 더 계산되었습니다. cveId를 하나씩 조회해서는 절대 발견할 수 없습니다; "8.5.100을 cpe로 한 번 조회"라는 사용자 관점의 기준으로 바꿔야 비로소 걸러졌습니다.

빌드

mvn package        # → target/tomcat85-check.jar
mvn test           # 테스트 59개

JDK 17+ 필요. 런타임 의존성 제로, JUnit은 테스트 전용.

License

MIT — LICENSE 참조