키스 쿡 나는 블로그 게시물을 작성합니다. 버그 수정 프로세스에 대한 우려를 제기했습니다. Linux 커널의 안정적인 분기에서 진행 중이며 매주 약 XNUMX개의 수정 사항이 포함되어 있다고 언급 Linux 커널 기반 제품을 유지 관리하는 데 너무 많은 노력과 노력이 필요한 안정적인 브랜치에 있습니다.
키에 따르면, 커널 오류 처리 프로세스가 무시되고 커널에 최소 100명의 추가 개발자가 부족합니다. 이 영역에서 조정된 방식으로 작동합니다. 주요 커널 개발자가 정기적으로 버그를 수정한다고 언급하는 것 외에도 이러한 수정 사항이 타사 커널 변형에도 적용된다는 보장은 없습니다.
그렇게 하면서 그는 다양한 Linux 커널 기반 제품의 사용자가 어떤 버그가 수정되고 어떤 커널이 장치에서 사용되는지 제어할 방법이 없다고 언급했습니다. 궁극적으로 공급업체는 제품의 보안을 책임지지만 안정적인 커널 브랜치에서 매우 높은 비율의 패치에 직면하여 모든 패치를 마이그레이션하거나 가장 중요한 패치를 선택적으로 마이그레이션하거나 모든 패치를 무시하는 선택에 직면했습니다. .
업스트림 커널 개발자는 버그를 수정할 수 있지만 다운스트림 공급업체가 제품에 통합하기로 선택한 항목을 제어할 수 없습니다. 최종 사용자는 제품을 선택할 수 있지만 일반적으로 어떤 버그가 수정되었는지 또는 어떤 커널이 사용되는지(자체 문제)에 대한 제어 권한이 없습니다. 궁극적으로 공급업체는 제품 코어를 안전하게 유지할 책임이 있습니다.
키스 쿡 가장 중요한 수정 사항과 취약점만 이전하는 것이 최적의 솔루션임을 시사합니다., 그러나 주요 문제는 이러한 오류를 일반적인 흐름과 분리하는 것입니다. 새로 나타나는 문제의 대부분은 메모리 및 포인터로 작업할 때 많은 주의가 필요한 C 언어 사용의 결과이기 때문입니다.
설상가상으로 많은 잠재적 취약성 수정 사항에 CVE 식별자가 태그로 지정되지 않았거나 패치가 릴리스된 후 일정 시간이 지나면 CVE 식별자가 수신되지 않습니다.
이러한 환경에서 제조업체는 주요 보안 문제와 사소한 수정 사항을 구분하기가 매우 어렵습니다. 통계에 따르면 취약점의 40% 이상이 CVE 할당 전에 제거되며, 수정 릴리스와 CVE 할당 사이의 평균 지연은 XNUMX개월입니다(즉, 초기에는 솔루션을 일반적인 실수로 인식하고,
그 결과, 취약점에 대한 수정 사항이 있는 별도의 분기가 없음 이 문제 또는 그 문제의 보안과의 연결에 대한 정보를 받지 못한 경우 Linux 커널 기반 제품 제조업체는 모든 수정 사항을 지속적으로 전송해야 합니다. 새로운 안정적인 지점의. 그러나 이 작업은 노동 집약적이며 제품의 정상적인 작동을 방해할 수 있는 퇴행적 변화에 대한 두려움으로 기업의 저항에 직면해 있습니다.
키 쿡 장기적으로 합리적인 비용으로 커널을 안전하게 유지하는 유일한 솔루션은 패치 엔지니어를 재배치하는 것이라고 믿습니다. 미친 커널 빌드에l 조정된 방식으로 함께 일하기 업스트림 커널의 패치와 취약점을 유지합니다. 현재로서는 많은 공급업체가 제품에 최신 커널 버전을 사용하지 않고 자체적으로 수정 사항을 백포트합니다. 즉, 다른 회사의 엔지니어가 서로의 작업을 복제하여 동일한 문제를 해결하는 것으로 나타났습니다.
예를 들어, 각각 동일한 수정 사항을 지원하는 엔지니어가 있는 10개 회사가 하나의 수정 사항을 마이그레이션하는 대신 이러한 엔지니어를 업스트림에서 버그를 수정하도록 리디렉션하면 전반적인 이점을 위해 10개의 서로 다른 버그를 수정하거나 버그를 검토하기 위해 함께 할 수 있습니다. . 그리고 커널에 버그가 있는 코드를 포함하지 마십시오. 리소스는 또한 반복적으로 발생하는 일반적인 오류 클래스를 초기 단계에서 자동으로 감지하는 새로운 코드 분석 및 테스트 도구를 만드는 데 사용할 수 있습니다.
키 쿡 또한 자동화된 테스팅 및 퍼징을 보다 적극적으로 사용할 것을 제안합니다. 커널 개발 프로세스에서 직접 지속적 통합 시스템을 사용하고 이메일을 통한 구식 개발 관리를 포기하십시오.
출처 : https://security.googleblog.com