Glibc에는 Aurora OS 개발자가 준비한 memcpy 취약점에 대한 수정 사항이 포함되어 있습니다.

Aurora 모바일 운영 체제(Open Mobile Platform 회사에서 개발한 Sailfish OS의 포크)의 개발자는 Aurora 모바일 운영 체제 제거에 대한 공개적인 이야기를 공유했습니다. 심각한 취약점 (CVE-2020-6096)는 ARMv7 플랫폼에만 나타나는 Glibc에 있습니다. 취약점에 대한 정보는 지난 XNUMX월에 공개되었지만, 취약점이 있음에도 불구하고 최근까지 수정 사항이 제공되지 않았습니다. 할당된 위험도가 높으며 memcpy() 및 memmove() 함수에서 특정 방식으로 형식화된 데이터를 처리할 때 코드 실행을 구성할 수 있는 작동 중인 익스플로잇 프로토타입이 있습니다. 패키지 수정 사항 데비안 и Ubuntu 아직 공개되지 않았으며 취약점은 공개된 시점부터 거의 XNUMX개월, Glibc 개발자에게 통보된 시점부터 XNUMX개월 동안 수정되지 않은 상태로 남아 있습니다.

해당 취약점은 ARMv7용 어셈블리 언어의 memcpy() 및 memmove() 구현에서 나타났으며 복사된 영역의 크기를 결정하는 매개변수의 음수 값을 잘못 처리하여 발생했습니다. 패치 개발 문제는 회사에서 시작되었습니다. SUSE и 레드햇 자사 플랫폼은 32비트 ARMv7 시스템용으로 빌드되지 않았고 수정 사항 작성에 참여하지 않았기 때문에 문제의 영향을 받지 않는다고 발표했습니다. 많은 임베디드 배포판의 개발자들은 Glibc 팀에 의존해 왔으며 수정 사항 준비에 적극적으로 참여하지 않은 것 같습니다.

옵션 반점 문제를 차단하기 위해 Huawei는 서명된 피연산자(bge 및 blt)로 작동하는 조립 지침을 서명되지 않은 아날로그(blo 및 bhs)로 대체하려고 시도한다고 거의 즉시 제안했습니다. Glibc 관리자는 다양한 오류 조건을 확인하기 위해 일련의 테스트를 개발한 후 Huawei 패치가 적합하지 않으며 가능한 모든 입력 데이터 조합을 처리하지 못하는 것으로 나타났습니다.

Aurora OS에는 ARM용 32비트 빌드가 있으므로 개발자는 자체적으로 취약점을 해결하고 커뮤니티에 솔루션을 제공하기로 결정했습니다. 어려운 점은 함수의 효율적인 어셈블리 언어 구현을 작성하고 입력 인수에 대한 다양한 옵션을 고려해야 한다는 것이었습니다. 서명되지 않은 지침을 사용하여 구현이 다시 작성되었습니다. 패치 작은 것으로 밝혀졌지만 가장 큰 문제는 실행 속도를 유지하고 memcpy 및 memmove 함수의 성능 저하를 피하면서 모든 입력 값 조합과의 호환성을 유지하는 것이 었습니다.

3월 초에 Glibc 관리자의 테스트 프레임워크와 Aurora의 내부 테스트 제품군을 통과한 두 가지 버전의 수정 사항이 준비되었습니다. XNUMX월 XNUMX일에 옵션 중 하나가 선택되었고 선적 된 Glibc 메일링 리스트에. 일주일 후
있었다 제안 접근 방식이 유사한 또 다른 패치는 Huawei가 이전에 수정하려고 시도한 다중 아키텍처 구현의 문제를 수정했습니다. 테스트는 한 달이 걸렸고 법적 등록 패치의 중요성 때문입니다.
8월 XNUMX일 정정 받아들여졌다 곧 출시될 glibc 2.32 릴리스의 메인 브랜치로 이동합니다. 구현에는 두 가지 패치가 포함됩니다. первый ARMv7용 memcpy의 다중 아키텍처 구현 초 ARM용 memcpy() 및 memmove()의 일반 어셈블리 언어 구현을 위한 것입니다.

이 문제는 Linux를 실행하는 수백만 대의 ARMv7 장치에 영향을 미치며 적절한 업데이트가 없으면 소유자가 네트워크에 연결할 때 위험에 처하게 됩니다(크기 제한 없이 입력 데이터를 허용하는 네트워크 액세스 가능 서비스 및 애플리케이션이 공격받을 수 있음). 예를 들어, 취약점을 식별한 연구원들이 준비한 익스플로잇은 매우 큰 GET 요청을 보내고 시스템에 대한 루트 액세스 권한을 획득하여 자동차 정보 시스템에 내장된 HTTP 서버를 공격하는 방법을 보여줍니다.

출처 : opennet.ru