Chromium 보안 문제의 70%는 메모리 오류로 인해 발생합니다.

Chromium 프로젝트의 개발자 분석 912년 이후 Chrome의 안정적인 릴리스에서 2015개의 고위험 및 심각한 취약점이 확인되었으며, 그 중 70%가 메모리 불안정(C/C++ 코드에서 포인터 작업 시 오류)으로 인해 발생한 것으로 결론지었습니다. 이러한 문제 중 절반(36.1%)은 버퍼와 관련된 메모리를 해제한 후(해제 후 사용) 버퍼에 액세스함으로써 발생합니다.

Chromium을 디자인할 때 처음에는 누워, 코드에 오류가 나타날 수 있으므로 취약점으로 인한 결과를 제한하기 위해 샌드박스 격리를 사용하는 것이 크게 강조되었습니다. 현재 이 기술을 사용할 가능성은 그 능력의 한계에 도달했으며 자원 소비의 관점에서 프로세스를 더욱 세분화하는 것은 비현실적입니다.

코드베이스의 보안을 유지하기 위해 Google은 '둘의 법칙"에 따르면 추가된 코드는 검증되지 않은 입력 데이터로 작업하기, 안전하지 않은 프로그래밍 언어(C/C++) 사용하기, 높은 권한으로 실행하기 등 세 가지 조건 중 두 가지 이하를 충족해야 합니다. 이 규칙은 외부 데이터를 처리하기 위한 코드가 최소한의 권한으로 축소(격리)되거나 보안 프로그래밍 언어로 작성되어야 함을 의미합니다.

코드베이스의 보안을 더욱 강화하기 위해 코드베이스에 메모리 오류가 나타나는 것을 방지하는 프로젝트가 시작되었습니다. 세 가지 주요 접근 방식이 있습니다. 메모리의 안전한 작동을 위한 기능이 포함된 C++ 라이브러리를 생성하고 하드웨어 보호 메커니즘을 사용하여 가비지 수집기의 범위를 확장하는 것입니다. MTE (Memory Tagged Extension) 및 안전한 메모리 작업을 보장하는 언어(Java, Kotlin, JavaScript, Rust, Swift)로 구성 요소를 작성합니다.

작업은 두 가지 영역에 집중될 것으로 예상됩니다.

• 성능에 대한 부정적인 영향(추가 경계 검사 및 가비지 수집)을 배제하지 않는 C++ 개발 프로세스에 대한 중요한 변경입니다. 원시 포인터 대신에 다음 유형을 사용하는 것이 제안됩니다. 기적Ptr이를 통해 성능, 메모리 소비 및 안정성에 눈에 띄는 부정적인 영향을 주지 않으면서 악용 가능한 use-after-free 오류를 보안 위협을 제기하지 않는 충돌로 줄일 수 있습니다.
• 컴파일 타임에 메모리 안전 검사를 수행하도록 설계된 언어를 사용하면 코드 실행 중 이러한 검사에 내재된 성능에 대한 부정적인 영향을 제거할 수 있지만 새로운 언어의 코드와 코드의 상호 작용을 구성하는 데 추가 비용이 발생합니다. C++).

메모리 안전 라이브러리를 사용하는 것은 가장 간단하지만 효율성이 떨어지는 방법입니다. Rust로 코드를 다시 작성하는 것은 가장 효과적이지만 매우 비용이 많이 드는 방법으로 평가됩니다.

출처 : opennet.ru