취약점 보고서, 옥석 가리는 '브로카드'를 아십니까?
오픈소스 프로젝트의 취약점 분석(Vulnerability Triage) 과정에서 무의미한 보고서를 걸러내기 위한 '브로카드' 목록 제시
위협 모델 부재(Lack of Threat Model), 공격 가능성 부족 등, 유효하지 않은 보고서의 특징을 구체적인 사례와 함께 설명
표준 규격 준수, ReDoS 공격 등, 취약점으로 간주하기 어려운 경우(Not a Vulnerability)에 대한 명확한 기준 제시
CVE 생태계의 문제점(Problems of CVE Ecosystem) 지적, 무분별한 보고서 제출로 인한 유지보수 부담 증가 비판
위협 모델 부재(Lack of Threat Model) 보고서의 문제점
게시물에서는 위협 모델(Threat Model)이 없는 취약점 보고서의 문제점을 지적하며, 공격자가 실제로 악용할 수 없는 상황을 묘사하는 경우를 예시로 제시한다. 예를 들어, 특정 API가 예외를 발생시키지만, 공격자가 이를 악용하여 피해를 입힐 수 있는 방법이 명시되지 않은 경우, 해당 보고서는 유효하지 않다고 판단한다. 이는 취약점 보고서의 신뢰성(Reliability)을 확보하기 위한 중요한 기준이 된다.
공격자의 능력 제한과 취약점의 유효성
게시물은 공격자가 취약점을 악용하기 위해 해당 취약점보다 더 강력한 능력을 필요로 하는 경우, 해당 보고서를 기각해야 한다고 주장한다. 예를 들어, MiTM(Man-in-the-Middle) 공격을 통해서만 콘텐츠를 조작할 수 있는 웹 서비스의 경우, MiTM 자체가 이미 임의의 콘텐츠를 전송할 수 있는 능력을 가지므로, 콘텐츠 조작은 취약점으로 간주될 수 없다. 이는 공격 가능성(Attack Surface)에 대한 정확한 이해를 바탕으로 취약점을 평가해야 함을 시사한다.
표준 규격 준수와 취약점의 관계
게시물은 표준 규격을 준수하는 과정에서 발생하는 동작은 취약점으로 간주하기 어렵다고 설명한다. 예를 들어, RFC 7230의 'Message Parsing Robustness' 조항에 따라 서버가 빈 줄을 무시하는 경우, 이는 표준에 따른 동작이므로 취약점으로 보기 어렵다. 하지만, 표준보다 엄격한 구현을 선택하고, 그 엄격함이 위반되는 경우에는 취약점으로 간주될 수 있다. 이는 표준 준수(Standard Compliance)와 구현의 적절성(Implementation Correctness) 사이의 균형을 강조한다.
ReDoS 공격과 유지보수 부담
게시물은 ReDoS(Regular Expression Denial of Service) 공격과 같이, 영향이 미미한 취약점 보고서로 인해 발생하는 유지보수 부담을 지적한다. ReDoS 공격은 주로 로컬 환경에서 제한적인 영향을 미치며, 해결에 많은 시간과 노력이 소요된다. 특히, CVE 생태계에서 무분별한 보고서 제출로 인해, 유지보수 담당자가 불필요한 대응을 해야 하는 상황을 비판한다. 이는 취약점 보고의 효율성(Reporting Efficiency)에 대한 중요성을 강조한다.
