기술 지원
문서
로그인
문의하기
TuxCare 블로그
"우리는 cve.org가 하라는 대로 하고 있을 뿐입니다."라는 말을 Greg K-H가 최근 프레젠테이션에서 여러 번 반복했습니다. 최근 프레젠테이션에서. 올해 초, 커널 팀의 새로운 CNA(CVE 번호 지정 기관) 지위는 보안 분야의 많은 사람들을 놀라게 했습니다. "소각하라!"는 해결책이 제안되었을 정도로 CVE 시스템에 완전히 반대했던 이전 입장과 달리, 이들은 취약점(커밋 ID)을 추적하는 데 다른 접근 방식을 사용하고 있었고 애초에 보안 결함으로 공개하지 않았기 때문입니다.
CNA 변경은 업계 전반에 걸쳐 파급 효과를 가져왔는데, 그 이유는 점점 더 분명해지고 있습니다. 더 많은 CVE가 발생할 뿐만 아니라 방대한 숫자로 인해 중요한 CVE를 추적, 분석, 식별하기가 훨씬 더 어려워졌기 때문입니다.
하지만 이 모든 것은 이전에 우리에 의해 (그리고 많은 업계의 다른 사람들). 심지어 몇 달 전에 발표한 보고서를 읽어보세요.
흥미로운 점은 이 문제에 대한 커널 팀 자체의 관점이며, 이 글에서는 최근 발표를 분석하고 그 발표에서 회피된 문제를 파악하려고 합니다.
아래 인용된 모든 텍스트는 프레젠테이션에서 발췌한 것입니다. "CVE는 살아있지만 당황하지 마세요!" 가능한 한 문맥을 유지하면서 Greg K-H의 프레젠테이션에서 발췌한 것입니다.
방 안의 코끼리
몇 가지 숫자부터 시작하겠습니다. 이 수치는 프레젠테이션에 명시적으로 나와 있습니다. 현재(2024년 10월 기준) 커널 CNA는 매주 평균 55개의 새로운 CVE를 발표하고 있습니다. 주당. 이는 CNA 활동 초기 몇 달 동안의 주당 60개보다는 약간 적은 수치입니다. 그러나 발표에 따르면 지난 몇 년 동안에는 분기당 약 20개의 CVE가 있었습니다. 분기당.
커널 CNA가 처음 제시한 정책은 모든 버그에 대한 접근 방식으로 해석되었습니다. 하지만 지금은 버그의 약 20%만이 실제로 버그를 발견하는 것으로 확대되어 매주 55개의 버그가 발견되고 있습니다. "엄청나게 많습니다." Linux 커널 메일링 리스트를 추적해보니 이 정도면 적당하다고 느껴집니다.
프로세스는 다음과 같이 진행됩니다. 모든 안정화 커밋에 대해 (최소) 세 사람이 검토하고 CVE를 적용할 가치가 있는지 여부를 결정합니다. 합의가 이루어지지 않으면 공개적으로 논의됩니다. 합의에 도달하면 CVE가 할당됩니다.
특정 버그에 대해 CVE가 할당된 후에도 설득력 있는 논거가 제시되면 사후에 취소할 수 있습니다. 이는 할당된 CVE의 1~2%를 차지합니다.
커널 CNA가 "#1이 아님"
...그렇다는 것만 빼면요. (매우 많은) 숫자가 관련되어 있고 비판을 해소하기 위해 프레젠테이션에는 다른 프로젝트 목록과 해당 프로젝트에서 발생하는 주간 CVE의 수가 포함되어 있습니다. 워드프레스가 주당 112건으로 가장 높은 수치를 기록했지만, 여기에는 모든 플러그인과 테마가 포함되어 있어 실제 워드프레스가 아니므로 주당 112건은 아니라는 점을 주의해야 합니다. MITRE는 주당 95개로 표시되지만 이 역시 단일 프로젝트가 아닙니다. Windows(11~12개), Chrome(6개), macOS(6개), iOS(2~3개)도 목록에 있습니다. 오픈 소스와 비공개 소스의 차이로 인해 이 수치의 정확성을 독립적으로 검증할 수는 없지만, 커널이 다른 어떤 개별 프로젝트보다 더 많은 CVE를 발생시키고 모든 경쟁 OS를 합친 것보다 더 많이 발생한다는 것은 커널 자체보다는 프로세스에 문제가 있을 수 있다는 것을 의미할 수 있습니다.
그렇다면 왜 이런 일이 발생했을까요?
CVE를 발행하기 시작한 이유는 두 가지입니다. 첫째, cve.org에서 오픈소스 프로젝트에 자체 CNA를 허용했고, 둘째, 여러 관할권에서 취약점 공개를 요구하는 법과 규정이 시행되고 있기 때문입니다. 더 따라야 할).
"우리는 이 일을 해야 한다"[CVE 발급을 언급]는 속담처럼 지니를 병 속에 다시 넣을 수 있는 것은 아닙니다.
무엇이 취약성을 구성하나요?
커널 CNA와 다른 프로젝트의 CNA의 주요 차이점 중 하나는 앞서 언급했듯이 발행된 CVE의 수가 많다는 점입니다. 이는 cve.org의 CVE 정의에 대한 해석으로 귀결됩니다. 커널 팀의 설명에 따르면 다음 버그는 새로운 CVE를 생성해야 합니다(프레젠테이션에서 인용):
- "사용자가 트리거할 수 있는 모든 충돌 또는 재부팅
- 메모리 사용량-프리/누수/오버플로우 이후
- 잘못된 경계 확인
- 서비스 거부
- 논리 오류
- 다른 많은 것들"
다음은 특별히 취약점으로 간주되지 않으며 CVE를 받지 않습니다:
- "데이터 손상/손실
- 성능 문제
- 외부에서 트리거되지 않는 버그 수정
- 하드웨어 CVE 없음"
특히 두 번째 목록의 첫 번째 요점인 데이터 손상은 프레젠테이션에서 더 자세히 설명할 필요가 있으며, 솔직히 말해서 데이터 손실 가능성을 보안 문제로 고려하지 않는 것은 이와 관련된 서비스 거부 공격의 가능성을 무시하는 것입니다(Q&A 중 한 청중이 정확하게 지적한 바와 같이). 그 이유는 무엇일까요? "우리는 cve.org 가이드라인을 따르고 있습니다. 그것은 그들의 문제이지 우리의 문제가 아닙니다." 별로 도움이 되지 않는 입장입니다.
"행운을 빕니다".
엔터프라이즈 배포의 큰 문제
프레젠테이션에 참석한 여러 유통업체의 대표들은 질의응답을 통해 이 문제에 대해 매우 분명한 견해를 밝혔는데, 심하게 말하면 불만이 많았습니다.
그 이유는 커널을 사용하고 환경에 통합하는 경우 사용 중인 커널을 잘 이해하고 있어야 하며, 따라서 특정 환경에 실제로 의미 있는 CVE를 식별하는 것이 덜 고통스럽기 때문에 - 사용되거나 로드되지 않는 코드에 대해 걱정할 필요가 없으므로 - 주당 55개의 CVE 중 상당 부분은 각 특정 사례에서 실제로 중요하지 않기 때문입니다.
그러나 배포판 공급업체는 최종 사용자보다는 커널 팀에 더 가까운 위치에 있습니다. 배포판은 무한히 다양한 방법과 상황에서 사용될 수 있으며, 커널 팀과 마찬가지로 공급업체도 커널의 어떤 부분이 관련성이 있는지 없는지 알 수 없습니다. 결과적으로 공급업체는 발생하는 모든 취약점을 해결해야 합니다. 이는 배포 공급업체의 릴리스를 기반으로 작업하는 회사들에게도 영향을 미칩니다.
따라서 매주 55개의 CVE를 각각 분석하고, 점수를 매기고, 수정하고, 테스트하고, 기업 고객에게 공개해야 합니다. 공급업체 보안 게시판에 수백 개의 CVE가 포함되는 이유를 찾는다면, 바로 몇 주마다 한꺼번에 발표되기 때문입니다.
그래도 단순히 업스트림에서 다운스트림으로 수정 사항을 옮기고 하루를 마무리하면 되겠죠? 글쎄요, 그보다 더 많은 것이 있습니다.
커널 CNA에서 할당된 CVE는 실제 수정 커밋만 참조합니다. 수정 사항이 적용되거나 올바르게 작동하는 데 필요한 다른 패치 체인이 있는 경우, 이는 독자의 몫으로 남겨집니다.
또한 "독립적으로 테스트되지 않고 블록 단위로만 테스트"됩니다. 배포에서 사용자 지정을 적용하는 즉시 모든 테스트를 반복해야 하므로 이 방법은 쓸모가 없어집니다.
"엔터프라이즈 배포판에는 자초한 문제가 있으며, 저는 동정심이 없습니다."[배포 공급업체가 제공하고 지원하는 이전 커널 버전에 대한 백포트된 수정 사항에 대해 이야기하는 것]. 사실입니다.
"내 문제가 아닙니다."
최종 사용자/조직
"[최신 커널로 업데이트]하고 재부팅하거나 모든 수정 사항을 분류하고 관련 수정 사항을 적용한 후 재부팅해야 합니다. 라이브 패치를 사용할 수도 있습니다." 동시에 그는 인프라가 재부팅 횟수를 감당할 수 없기 때문에 많은 기업이 그렇게 할 수 없다는 점을 인정합니다. 따라서 매주 55개의 CVE를 분류하거나 최신 버전을 적용합니다. 이는 엔터프라이즈 환경에서는 비용이 매우 많이 드는 현실적인 선택입니다.
세 번째이자 유일하게 실행 가능한 대안은 다음과 같습니다. 시스템 실시간 패치.
사물 상태
"우리는 cve.org가 요청한 대로 정확하게 하고 있다"는 것이 현재 프로세스를 옹호하는 기본 입장인 것 같습니다. 이를 액면 그대로 받아들이고 "우리는 서비스 거부를 일으키지 않고 있다"는 것도 [CVE 프로세스의] 의도가 아닙니다. 그러나 많은 기업, 유통 공급업체, 사이버 보안 회사가 직면한 실제 상황과 매주 55개의 새로운 취약점으로 시스템이 신고되는 데 따른 규정 준수 및 보안 문제는 현재의 상황을 (의도적이든 우발적이든) 악의적인 규정 준수 이외의 다른 것으로 받아들이는 데 도움이 되지 않습니다.
커널 팀, 특히 소규모의 커널 CNA 팀이 수행한 엄청난 작업은 더 나은 평가를 받아야 마땅했지만, 안타깝게도 전체 에코시스템에 새로운, 종종 점수화되지 않은 이슈가 넘쳐나는 수천 명의 보안 전문가에게 너무 많은 슬픔과 고통을 안겨주어 이미 스트레스가 많은 환경에 부담을 더했을 뿐입니다.
"이로 인해 생태계에서 약간의 이탈과 충돌이 발생하고 있습니다. 제가 이 문제에 대해 인용될 거라는 걸 알고 있습니다." 농담이 아닙니다.
참고: 프로세스를 투명하게 공개하고 커튼 뒤의 모습을 보여준 Greg K-H에게 감사의 인사를 전합니다.
