인기 있는 오픈소스 프로젝트인 ‘ip’의 GitHub 저장소는 최근 보관되거나 개발자에 의해 “읽기 전용”으로 설정되었습니다.
표도르 인두트니는 자신의 프로젝트에 대한 CVE 보고서가 접수된 후, 인터넷에서 많은 사람들이 그의 취약점에 대해 알려주며 괴롭힘을 당하기 시작했습니다.
안타깝게도 Indutny의 사례는 고립된 것이 아닙니다. 최근 들어 오픈소스 개발자들은 프로젝트에 대한 확인 없이 제출된 논란의 여지가 있거나, 어떤 경우에는 완전히 허위인 CVE 보고서를 받는 경우가 늘고 있습니다.
이로 인해 이러한 프로젝트의 사용자 사이에 불필요한 공황 상태가 발생할 수 있으며 보안 스캐너에서 경고가 발생할 수 있습니다. 이는 모두 개발자에게 골치 아픈 문제로 이어질 수 있습니다.
‘node-ip’ GitHub 저장소가 보관되었습니다.
이번 달 초, ‘node-ip’ 프로젝트의 저자인 Fedor Indutny는 해당 프로젝트의 GitHub 저장소를 사실상 읽기 전용으로 보관하고, 사람들이 새로운 이슈(토론)를 열거나, 풀 리퀘스트를 제출하거나, 프로젝트에 대한 의견을 제출하는 기능을 제한했습니다.
‘node-ip’ 프로젝트는 npmjs.com 레지스트리에 ‘ip’ 패키지로 존재하며, 매주 1,700만 건의 다운로드를 기록하며 JavaScript 개발자가 사용하는 가장 인기 있는 IP 주소 파싱 유틸리티 중 하나입니다.
6월 25일 화요일, Indutny는 소셜 미디어를 통해 ‘node-ip’ 보관에 대한 자신의 생각을 밝혔습니다.
“지난 몇 달간 저를 괴롭혔던 일이 있어서 GitHub에 node-ip 저장소를 보관하게 되었습니다.” 개발자가 Mastodon 계정을 통해 게시했습니다.
이는 올해 초 프로젝트에서 공개된 취약점인 CVE-2023-42282와 관련이 있습니다.
“누군가가 내 npm 패키지에 대해 의심스러운 CVE를 제출했고, 그후로 ‘npm audit’에서 경고를 받은 모든 사람들에게서 메시지를 받기 시작했습니다.” 개발자는 같은 게시물에서 이렇게 말했습니다.
npm 패키지 및 종속성과 같은 다른 오픈 프로젝트를 애플리케이션에서 사용하는 Node.js 개발자는 “npm audit” 명령을 실행하여 애플리케이션에서 사용하는 프로젝트에 취약점이 보고되었는지 확인할 수 있습니다.
CVE는 유틸리티가 16진수와 같은 비표준 형식으로 제공된 개인 IP 주소를 올바르게 식별하지 못하는 것과 관련이 있습니다. 이로 인해 ‘node-ip’ 유틸리티는 “0x7F.1…”(127.1…을 나타냄)과 같은 개인 IP 주소(16진수 형식)를 공개 주소로 취급하게 됩니다.
애플리케이션이 제공된 IP 주소가 공개되어 있는지 확인하기 위해 node-ip에만 의존하는 경우, 비표준 입력으로 인해 영향을 받는 유틸리티 버전에서 일관되지 않은 결과가 반환될 수 있습니다.
‘의심스러운’ 보안 영향
공개 소스에 따르면 CVE-2023-42282는 원래 9.8점 또는 “중요”로 평가되었습니다.
Indutny는 실제로 그의 프로젝트의 후속 버전에서 문제를 해결했지만 버그가 다음과 같은 문제를 구성한다는 데는 이의를 제기했습니다. 실제 취약성이 매우 심각하며 심각도도 매우 높습니다.
개발자는 이전에 “버그의 보안 영향은 다소 의심스럽다”고 글을 남기며 GitHub에 CVE를 철회해 달라고 요청했습니다.
“나는 실제로 모듈을 보안 관련 검사에 사용하도록 의도하지 않았지만 신뢰할 수 없는 입력이 어떻게 전달될 수 있는지 매우 궁금합니다. ip.isPrivate 또는 ip.isPublic(함수)를 사용하여 네트워크 연결이 어디에서 왔는지 확인하는 데 사용됩니다.”
GitHub 보안팀 멤버가 설명했듯이 CVE에 이의를 제기하는 것도 간단한 일이 아닙니다. 프로젝트 관리자가 원래 CVE를 발급한 CVE 번호 지정 기관(CNA)을 추적해야 합니다.
CNA는 전통적으로 NIST의 NVD와 MITRE로 구성되었습니다. 지난 몇 년 동안 기술 회사와 보안 공급업체가 목록에 가입했으며 원하는 대로 CVE를 발급할 수도 있습니다.
이러한 CVE는 취약점 설명과 보고된 심각도 등급과 함께 GitHub 권고 사항과 같은 다른 보안 데이터베이스에 의해 공동으로 배포되고 다시 게시됩니다.
Indutny가 소셜 미디어에 게시한 내용에 따라 GitHub은 데이터베이스에서 CVE의 심각도를 낮추고 개발자에게 비공개 취약성 보고 기능을 켜서 들어오는 보고를 보다 효과적으로 관리하고 불필요한 정보를 줄일 것을 제안했습니다.
이 글을 쓰는 시점에서 NVD의 취약점 심각도는 여전히 “중요”로 유지됩니다.
점점 더 커지는 귀찮음
CVE 시스템은 원래 보안 연구원이 프로젝트의 취약점을 윤리적으로 보고하고 책임감 있게 공개한 후 이를 카탈로그화하는 데 도움을 주기 위해 고안되었으나, 최근에는 검증되지 않은 보고서를 제출하는 커뮤니티 구성원들의 관심을 끌고 있습니다.
많은 CVE가 책임감 있는 연구자에 의해 선의로 제출되고 신뢰할 만한 보안 취약점을 나타내지만, 최근 들어 늘어나고 있는 패턴은 초보 보안 전문가와 버그 현상금 사냥꾼이 실제적이고 실질적인 영향을 미치는 보안 버그를 보고하기보다는 이력서를 보강하기 위해 CVE를 “수집”하는 것입니다.
결과적으로 개발자와 프로젝트 관리자는 반발했습니다.
2023년 9월, 잘 알려진 소프트웨어 프로젝트 ‘컬(curl)’의 제작자 다니엘 스텐버그는 해당 프로젝트에 보고된 서비스 거부 버그인 “가짜 컬(curl) 문제 CVE-2020-19909″를 비난했습니다.
원래 NVD의 기록에 따르면 심각도 9.8 또는 중대한 것으로 평가되었던 CVE는 결함의 실질적인 보안 영향에 대한 논의가 이어진 후 등급이 “낮음” 3.3으로 낮아졌습니다.
“이것은 독특한 사례가 아니었고 처음 일어난 일도 아니었습니다. 이런 일은 수년 동안 계속되어 왔습니다.” Stenberg는 CVE 항목을 비판하며 글을 썼습니다.
“저는 취약점을 중심으로 한 철학적 사고 연습을 좋아하지 않습니다.”
“그것들은 실제 문제에서 주의를 돌리는 것이고, 저는 그것들이 무의미하다고 생각합니다. 이 결함이 수많은 컴파일러를 사용하여 수많은 플랫폼에서 어떻게 작용하는지 테스트하는 것은 쉽습니다.”
“어느 쪽에도 보안 문제가 없습니다.”
스텐버그에 따르면, “어리석은 버그”의 기술적 세부 사항은 예상치 못한 동작이 발생할 수 있다는 것을 의미하며, 남용될 수 있는 보안 결함은 아닙니다.
매주 6,400만 건의 다운로드를 기록하는 또 다른 npm 프로젝트인 micromatch에서는 ‘높음’ 심각도의 ReDoS 취약점이 보고되었으며, 이 문제에 대해 문의하는 커뮤니티 회원들이 이를 제작자에게 쫓기고 있습니다.
“취약성에 취약한 micromatch나 braces를 구현한 라이브러리 중 하나라도 알려줄 수 있나요? 그러면 그것이 이론적인 것이 아니라 실제로 어떻게 취약한지 알 수 있을 텐데요.” Jon Schlinkert가 자신의 프로젝트 micromatch에 제출한 CVE-2024-4067에 반응하며 물었습니다.
같은 스레드에서 개발자는 취약성 보고자로부터 만족스러운 개념 증명 익스플로잇을 받지 못한 후 다음과 같이 응답했습니다.
“저는 이런 문제를 항상 겪습니다. 스스로 하지 않는 한 취약점이 될 수 없는 것들 말입니다. 브라우저에서 절대 접근할 수 없는 저수준 라이브러리의 정규 표현식처럼요. 사용자가 웹 양식에서 정규 표현식을 제출하도록 허용하지 않는 한, 애플리케이션에서만 사용되는 정규 표현식이죠.”
“저는 실제 도서관이 이러한 ‘취약성’에 어떻게 직면하게 될지에 대한 예를 들어 달라고 요청했지만, 당신은 결코 예를 들어 답변하지 않았습니다.”
저도 최근에 제3자가 저희에게 이 프로젝트가 초래할 수 있는 잠재적인 “위험”에 대해 알려준 후에 마이크로매치 개발자에게 메시지를 보냈습니다. 당시에는 그것이 책임감 있는 일이라고 생각했기 때문입니다.
안타깝게도 이는 악용 가능한 취약점을 나타내는 것이 아니라, 이미 개발자들이 쫓겨난 귀찮은 보고(CVE-2024-4067과 매우 유사)로 끝났습니다.
검증되지 않은 취약성 보고서로 인해 CVE가 발행된다는 것은 프로젝트 관리자에게 귀찮은 일일 뿐만 아니라, 프로젝트, 프로젝트 제작자, 더 넓은 소비자 기반에 대한 서비스 거부(DoS)를 조장하는 것과 마찬가지이므로, 그럴 만한 이유가 있습니다.
취약한 구성 요소가 애플리케이션에 도달하는 것을 차단하도록 설계된 개발자 보안 솔루션(예: npm audit)은 알려진 취약성이 감지되면 경고를 발생시킬 수 있으며, 설정에 따라 빌드를 중단시킬 수도 있습니다.
“잭슨은 몇 달 전에 이런 문제를 겪었는데, 누군가가 프로젝트에 대한 중요한 CVE를 보고해서 전 세계적으로 빌드가 망가졌습니다.” 한 해설자는 2023년에 허무한 컬 CVE에 반응하며 이렇게 썼습니다.
다른 개발자들이 언급했듯이 이 문제는 프로젝트의 보안 문제가 아니라 재귀적 Java 데이터 구조의 본질적인 특성을 나타내는 것이었습니다.
균형은 어디에 있나요?
이런 일이 계속 반복되면 어떻게 균형을 맞출 수 있을지에 대한 의문이 제기됩니다.
이론적 취약점을 끊임없이 보고하면, 많은 경우 자원봉사자인 오픈소스 개발자들은 노이즈를 분류하는 데 지쳐 버릴 수 있습니다.
반면, 초보자를 포함한 보안 실무자가 보안 결함이라고 생각하는 부분에 대해 프로젝트 관리자에게 불편을 끼치지 않기 위해 가만히 앉아 있는 게 윤리적일까요?
세 번째 문제는 활동적인 유지 관리자가 없는 프로젝트의 경우 발생합니다. 수년간 건드리지 않은 버려진 소프트웨어 프로젝트에는 취약성이 포함되어 있으며, 공개되더라도 결코 수정되지 않으며 원래 유지 관리자에게 연락할 방법이 없습니다.
이런 경우 CNA와 버그 바운티 플랫폼을 포함한 중개자는 난처한 처지에 놓이게 됩니다.
연구자로부터 취약성 보고서를 받으면 이러한 조직은 항상 모든 보고서를 독립적으로 충분히 검토할 수 없을 수 있습니다. (이제는 없는) 프로젝트 유지 관리자로부터 연락을 받지 못하면 “책임 있는 공개” 기간이 지난 후 CVE를 할당하고 게시해야 할 수도 있습니다.
아직까지 이러한 문제에 대한 간단한 답은 존재하지 않습니다.
보안 연구, 개발자 및 공급업체 커뮤니티가 효과적인 솔루션을 찾기 위해 함께 모일 때까지 개발자들은 허위 보고서에 좌절하여 지치고 CVE 시스템에는 서류상으로는 믿을 만해 보이지만 실제로는 전혀 의미가 없는 과장된 “취약점”이 넘쳐나게 될 것입니다.
