체크 포인트 (IT 보안 솔루션의 글로벌 제공 업체) 며칠 전에 출시 된 소개 안전 메커니즘의 "안전 연결", 해적 익스플로잇 생성을 어렵게 만듭니다. malloc 호출을 할 때 할당 된 버퍼에 대한 포인터의 정의 또는 변경을 조작합니다.
새로운«Safe-Linking»메커니즘 취약점 악용 가능성을 완전히 차단하지는 않지만 최소한의 오버 헤드로 특정 범주의 익스플로잇 생성을 복잡하게합니다.악용 된 버퍼 오버플로 외에도 메모리의 힙 위치에 대한 정보를 유발하는 또 다른 취약점을 찾아야합니다.
안전 연결 구현 패치는 Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) 및 Google TCMalloc에 대해 준비되었으며 Chromium의 보호 현대화 제안 (2012 Chromium은 이미 솔루션과 통합되었습니다. 동일한 문제) MaskPtr 보호 기술이지만 Checkpoint의 솔루션은 더 나은 성능을 보여줍니다.)
제안 된 패치는 이미 Glibc 3.32의 1.0.33 월 릴리스에서 제공되도록 승인되었으며 Safe-Linking은 기본적으로 활성화됩니다. uClibc-NG에서 보안 링크 지원은 버전 XNUMX에 포함되었으며 기본적으로 활성화되어 있습니다. gperftools (이전 tcmalloc)에서는 변경 사항이 허용되지만 향후 릴리스에서 옵션으로 제공 될 것입니다.
TCMalloc 개발자는 변경 수락을 거부했습니다. c강력한 성능 성공과 모든 것이 제대로 작동하는지 정기적으로 확인하기 위해 고급 테스트를 추가해야합니다.
수행 한 테스트 체크 포인트 엔지니어는 Safe-Linking 방법이 추가 메모리 소비로 이어지지 않는다는 것을 보여주었습니다. 평균적으로 힙 작업을 수행 할 때의 성능은 0.02 % 감소하고 최악의 경우 1.5 % 감소합니다.
Safe-Linking을 활성화하면 free ()를 호출 할 때마다 2-3 개의 추가 어셈블러 명령이 실행되고 malloc ()을 호출 할 때 3-4 개의 명령이 실행됩니다. 초기화 시작 및 임의 값 생성이 필요하지 않습니다.
Safe-Linking은 안전성을 높이기 위해서만 사용할 수 있습니다. 다양한 힙 구현의ino는 또한 모든 데이터 구조에 무결성 검사를 추가합니다. 버퍼 옆에 위치한 개별적으로 연결된 포인터 목록을 사용합니다.
방법 구현이 매우 간단하며 매크로 만 추가하면됩니다. 코드의 다음 블록에 대한 포인터에 적용합니다 (예 : Glibc의 경우 코드에서 몇 줄만 변경됨).
이 방법의 핵심은 ASLR 주소 무작위 화 메커니즘 (mmap_base)에서 무작위 데이터를 적용하여 Fast-Bins 및 TCache와 같은 개별적으로 연결된 목록을 보호하는 것입니다. 목록의 다음 항목에 포인터 값을 적용하기 전에 메모리 페이지 가장자리를 따라 마스크 변환 및 정렬 검사가 수행됩니다. 포인터는 "(L >> PAGE_SHIFT) XOR (P)"연산의 결과로 대체됩니다. 여기서 P는 포인터의 값이고 L은이 포인터가 저장된 메모리의 위치입니다.
ASLR (Address Space Layout Randomization) 시스템에서 사용되는 경우 힙의 기본 주소가있는 L 비트 중 일부는 P를 인코딩하는 키로 사용되는 임의 값을 포함합니다 (12 비트의 시프트 연산에 의해 추출 됨). 4096 바이트 페이지의 경우).
그러한 조작 익스플로잇에서 포인터를 캡처 할 위험을 줄입니다. 포인터는 원래 형식으로 저장되지 않았기 때문에이를 대체하려면 힙 위치에 대한 정보를 알아야합니다.
이 방법은 부분 포인터 재정의를 사용하는 공격으로부터 보호하는 데 효과적입니다. (낮은 바이트 시프트), 포인터의 완전한 재 작성 (공격자의 코드로 리디렉션) 정렬되지 않은 방향으로 목록 위치 변경
예를 들어 malloc에서 Safe-Linking을 사용하면 Philips Hue Bridge 스마트 백라이트에서 동일한 연구원이 최근에 발견 한 취약점 CVE-2020-6007의 악용을 차단하여 버퍼 오버 플로우로 인한 제어를 허용하는 것으로 나타났습니다. 장치.
출처 : https://research.checkpoint.com