Google은 브라우저에서 JavaScript를 실행하여 Spectre 취약점 악용을 시연합니다.

Google은 이전에 추가된 보호 방법을 우회하여 브라우저에서 JavaScript 코드를 실행할 때 Spectre 클래스 취약점을 악용할 가능성을 보여주는 여러 익스플로잇 프로토타입을 게시했습니다. 익스플로잇은 현재 탭에서 웹 콘텐츠를 처리하는 프로세스의 메모리에 액세스하는 데 사용될 수 있습니다. 익스플로잇의 작동을 테스트하기 위해 Leaky.page 사이트가 시작되었고 작업 논리를 설명하는 코드가 GitHub에 게시되었습니다.

제안된 프로토타입은 Linux 및 Chrome 7 환경에서 Intel Core i6500-88U 프로세서를 탑재한 시스템을 공격하기 위해 설계되었으며, 다른 환경에도 익스플로잇을 적용하려면 변경이 필요합니다. 악용 방법은 Intel 프로세서에만 국한되지 않습니다. 적절하게 적용한 후에는 ARM 아키텍처 기반 Apple M1을 포함하여 다른 제조업체의 CPU를 사용하는 시스템에서 악용이 작동하는 것으로 확인되었습니다. 사소한 조정 후에는 Chromium 엔진을 기반으로 하는 다른 운영 체제 및 기타 브라우저에서도 익스플로잇이 작동합니다.

표준 Chrome 88 및 Intel Skylake 프로세서 기반 환경에서 현재 Chrome 탭(렌더러 프로세스)의 웹 콘텐츠 처리를 담당하는 프로세스에서 초당 1KB의 속도로 데이터가 유출되었습니다. 또한 8마이크로초(5밀리초)의 정확도로performance.now() 타이머를 사용할 때 안정성을 낮추는 대신 누출 속도를 0.005kB/s로 증가시킬 수 있는 익스플로잇과 같은 대체 프로토타입이 개발되었습니다. . 초당 약 60바이트의 속도로 다른 프로세스의 메모리에 대한 액세스를 구성하는 데 사용할 수 있는 XNUMX밀리초의 타이머 정확도로 작동하는 변형도 준비되었습니다.

공개된 데모 코드는 세 부분으로 구성됩니다. 첫 번째 부분은 CPU 명령의 추측 실행 결과로 프로세서 캐시에 남아 있는 데이터를 복원하는 데 필요한 작업의 실행 시간을 추정하기 위해 타이머를 보정합니다. 두 번째 부분은 JavaScript 배열을 할당할 때 사용되는 메모리 레이아웃을 결정합니다.

세 번째 부분은 Spectre 취약점을 직접 이용하여 특정 작업의 추측 실행을 위한 조건을 생성한 결과 현재 프로세스의 메모리 내용을 결정하며, 그 결과는 실패한 예측을 결정한 후 프로세서에 의해 삭제되지만 실행은 추적은 일반 캐시에 저장되며 캐시된 데이터와 캐시되지 않은 데이터에 대한 액세스 시간의 변화를 분석하는 타사 채널을 통해 캐시 내용을 결정하는 방법을 사용하여 복원될 수 있습니다.

제안된 활용 기술은 Performance.now() API를 통해 사용 가능한 고정밀 타이머를 제거하고 공유 메모리에 배열을 생성할 수 있는 SharedArrayBuffer 유형을 지원하지 않습니다. 익스플로잇에는 추측성 코드 실행을 제어하는 ​​Spectre 가젯과 추측성 실행 중에 캐시에 들어간 데이터를 확인하는 부채널 누출 분석기가 포함됩니다.

가젯은 JavaScript 배열을 사용하여 구현됩니다. 이 배열에서는 버퍼 경계 외부 영역에 액세스하려는 시도가 이루어지며 컴파일러(프로세서, 앞을 내다보는 프로세서)가 추가한 버퍼 크기 확인으로 인해 분기 예측 블록의 상태에 영향을 줍니다. , 추론적으로 액세스를 수행하지만 확인 후 상태를 롤백합니다. 타이머 정확도가 충분하지 않은 조건에서 캐시의 내용을 분석하기 위해 프로세서에서 사용하는 Tree-PLRU 캐시 제거 전략을 속이고 사이클 수를 늘려서 반환 시 시간 차이를 크게 늘릴 수 있는 방법을 제안합니다. 캐시의 값과 캐시에 값이 없을 때.

Google은 Spectre 클래스의 취약점을 이용한 공격의 현실성을 보여주고 웹 개발자가 그러한 공격으로 인한 위험을 최소화하는 기술을 사용하도록 장려하기 위해 프로토타입 익스플로잇을 발표했습니다. 동시에 Google은 제안된 프로토타입을 대폭 수정하지 않으면 시연뿐만 아니라 널리 사용할 수 있는 범용 익스플로잇을 만드는 것이 불가능하다고 믿습니다.

위험을 줄이기 위해 사이트 소유자는 최근 구현된 COOP(Cross-Origin Opener Policy), COEP(Cross-Origin Embedder Policy), CORP(Cross-Origin Resource Policy), 메타데이터 가져오기 요청, X-Frame-Options, X -Content-Type-Options 및 SameSite 쿠키. 이러한 메커니즘은 공격으로부터 직접적으로 보호하지는 않지만 공격자의 JavaScript 코드가 실행될 수 있는 프로세스로 사이트 데이터가 누출되는 것을 방지할 수 있습니다(누출은 공격자의 코드 외에 데이터가 현재 프로세스의 메모리에서 발생합니다). 같은 탭에서 열린 다른 사이트에서). 주요 아이디어는 신뢰할 수 없는 소스(예: iframe을 통해 포함됨)에서 얻은 제XNUMX자 코드와 사이트 코드 실행을 여러 프로세스에서 분리하는 것입니다.

출처 : opennet.ru