Google의 Kees Cook은 Linux 커널의 버그 작업 프로세스를 현대화할 것을 요구했습니다.

kernel.org의 전 최고 시스템 관리자이자 현재 Google에서 Android 및 ChromeOS 보안을 위해 일하고 있는 Ubuntu 보안 팀의 리더인 Kees Cook은 커널의 안정적인 분기에서 버그를 수정하는 현재 프로세스에 대해 우려를 표명했습니다. 매주 약 1개의 수정 사항이 stable 브랜치에 포함되며, 다음 릴리스의 변경 사항을 수락하는 창이 닫힌 후에는 XNUMX개에 가까워집니다(관리자는 창이 닫힐 때까지 수정 사항을 보관하고 " -rcXNUMX”이라고 하면 누적된 것을 한번에 공개한다), 이는 리눅스 커널 기반의 유지보수 제품에 비해 너무 많고 많은 노동력을 필요로 한다.

Keys에 따르면 커널의 오류 작업 프로세스에는 적절한 주의가 주어지지 않으며 커널에는 이 영역에서 공동 작업을 위한 최소 100명의 추가 개발자가 부족합니다. 주요 커널 개발자는 정기적으로 버그를 수정하지만 이러한 수정 사항이 타사에서 사용하는 커널 변형에 적용된다는 보장은 없습니다. Linux 커널을 기반으로 하는 다양한 제품의 사용자는 어떤 버그가 수정되고 어떤 커널이 장치에 사용되는지 제어할 방법이 없습니다. 궁극적으로 제조업체는 제품 보안에 대한 책임이 있지만 안정적인 커널 브랜치에서 수정 사항을 게시하는 강도가 매우 높기 때문에 모든 수정 사항을 포팅할지, 가장 중요한 수정 사항을 선택적으로 포팅할지, 아니면 모든 수정 사항을 무시할지 선택해야 합니다. .

최적의 솔루션은 가장 중요한 수정 사항과 취약점만 마이그레이션하는 것이지만, 이러한 오류를 일반적인 흐름에서 격리하는 것이 주요 문제입니다. 나타나는 문제 중 가장 많은 수는 C 언어를 사용한 결과로 메모리와 포인터를 다룰 때 세심한 주의가 필요합니다. 설상가상으로 많은 잠재적 취약성 패치에는 CVE 식별자가 제공되지 않거나 패치가 게시된 후 얼마 후에 CVE 식별자가 할당됩니다. 이러한 환경에서는 제조업체가 중요한 보안 문제와 사소한 수정 사항을 분리하는 것이 매우 어렵습니다. 통계에 따르면 CVE가 할당되기 전에 취약점의 40% 이상이 수정되며, 수정 사항 릴리스와 CVE 할당 사이의 평균 지연 시간은 XNUMX개월입니다(즉, 처음에는 수정 사항이 다음과 같이 인식됩니다. 일반적인 버그이지만 몇 달이 지나서야 취약점이 수정되었다는 것이 분명해졌습니다.

결과적으로, 취약점에 대한 수정 사항이 포함된 별도의 브랜치가 없고 특정 문제의 보안 연결에 대한 정보를 받지 못한 채 Linux 커널 기반 제품 제조업체는 최신 안정 브랜치에서 모든 수정 사항을 지속적으로 전송해야 합니다. 하지만 이 작업에는 많은 노동력이 필요하고, 제품의 정상적인 작동을 방해할 수 있는 퇴행적 변화가 나타날 수 있다는 우려로 인해 기업에서는 저항에 직면해 있습니다.

Linus Torvalds에 따르면 모든 오류는 중요하며 취약점은 다른 유형의 오류와 분리되어 별도의 더 높은 우선 순위 범주에 할당되어서는 안 됩니다. 이 의견은 보안 문제를 전문으로 하지 않는 일반 개발자의 경우 수정 사항과 잠재적인 취약점 사이의 연관성이 명확하지 않다는 사실로 설명됩니다(많은 수정 사항의 경우 별도의 감사를 통해서만 보안과 관련이 있음을 이해할 수 있습니다). ). Linus에 따르면 Linux 배포판에서 커널 패키지를 유지 관리하는 팀의 보안 전문가는 일반적인 패치 흐름에서 잠재적인 취약점을 식별하는 데 참여해야 합니다.

Kees Cook은 합리적인 장기적 비용으로 커널 보안을 유지하는 유일한 해결책은 기업이 수정 사항을 로컬 커널 빌드로 포팅하는 데 관련된 엔지니어를 공동으로 조정하여 메인 커널(업스트림)의 수정 사항과 취약성을 유지하는 것이라고 믿습니다. ). 현재 형태에서는 많은 제조업체가 제품에 최신 커널 버전을 사용하지 않고 내부 수정 사항을 백포트합니다. 서로 다른 회사의 엔지니어들이 서로의 작업을 복제하여 동일한 문제를 해결하는 것으로 나타났습니다.

예를 들어, 각각 한 명의 엔지니어가 동일한 수정 사항을 백포트하는 10개의 회사가 해당 엔지니어를 업스트림의 버그 수정에 재배정한 경우 하나의 수정 사항을 백포트하는 대신 공통 이익을 위해 10개의 다른 버그를 수정하거나 제안된 버그 수정에 참여할 수 있습니다. 변경하고 버그가 있는 코드가 커널에 포함되는 것을 방지합니다. 또한 반복해서 발생하는 일반적인 오류 클래스를 조기에 감지할 수 있는 코드 테스트 및 분석을 위한 새로운 도구를 만드는 데 리소스를 투자할 수도 있습니다.

Kees Cook은 또한 지속적인 통합 시스템을 사용하고 이메일을 통한 구식 개발 관리를 포기하고 커널 개발 프로세스에서 직접 자동화 및 퍼징 테스트를 보다 적극적으로 사용할 것을 제안합니다. 현재 효과적인 테스트는 주요 테스트 프로세스가 개발과 분리되어 릴리스가 형성된 후에 수행된다는 사실로 인해 방해를 받습니다. 키스는 또한 오류 수를 줄이기 위해 개발할 때 Rust와 같이 더 높은 수준의 보안을 제공하는 언어를 사용할 것을 권장했습니다.

출처 : opennet.ru