OpenBSD의 W^X 보안 메커니즘을 강화할 계획

테오 데 라트 공유 된 W^X(Write XOR Execute) 메모리 보호 메커니즘을 강화할 계획입니다. 메커니즘의 핵심은 쓰기와 실행을 위해 프로세스 메모리 페이지에 동시에 액세스할 수 없다는 것입니다. 따라서 쓰기가 비활성화된 후에만 코드를 실행할 수 있고, 실행이 비활성화된 후에만 메모리 페이지에 쓰기가 가능합니다. W^X 메커니즘은 스택 오버플로를 포함한 일반적인 버퍼 오버플로 공격으로부터 사용자 공간 애플리케이션을 보호하는 데 도움이 되며 OpenBSD에서 활성화됩니다. 기본적으로.

W^X 작업 시작부터 JIT를 사용하는 애플리케이션이 상당히 많았기 때문에 길이 멀다는 것이 분명했습니다. JIT 구현은 세 가지 범주로 나눌 수 있습니다.

• W 상태와 X 상태 간 메모리 전환, 시스템 호출의 "비용" 수용 엠프로텍트.
• 동일한 메모리의 W 및 X 매핑 쌍 사이에 별칭을 만듭니다.
• 가장 "더러운" 옵션에는 기록과 실행을 동시에 허용하는 W|X 메모리 모델이 필요합니다.

현재 세 번째 옵션을 사용하는 프로그램은 훨씬 적고 첫 번째와 두 번째 옵션을 사용하는 프로그램은 더 많습니다. 그러나 W|X JIT(주로 Chromium 및 Iridum)로 프로그램을 실행해야 했기 때문에 "wxallowed" 파일 시스템 마운트 옵션이 추가되었습니다. 파일에는 "wxneeded" 표시가 표시되어 있으며 애플리케이션 자체는 메커니즘을 사용하여 추가로 보호되었습니다. 서약 и 밝히다 사용되는 시스템 호출 목록과 응용 프로그램에서 사용할 수 있는 파일 시스템의 일부를 각각 제한합니다.

이러한 애플리케이션의 취약점 악용을 더욱 복잡하게 만들기 위해 메커니즘을 추가하는 것이 제안되었습니다. MAP_STACK, 쓰기 가능한 메모리 페이지에서 시스템 호출이 실행되고 있는지 확인합니다. 페이지에 쓰기 가능한 경우 프로세스가 강제로 종료됩니다. 이렇게 하면 공격자는 시스템 호출을 이용할 수 없으며 JIT 구현에서 필요한 가젯을 찾으려고 시도하거나 내부에서 직접 시스템 호출 스텁을 탐지하는 더 어려운 작업을 수행해야 합니다. 실수로 연결된 libc.

Chrome/Iridium 프로세스는 이미 서약 및 공개를 사용하여 매우 안정적으로 보호되지만, 예를 들어 write(2) 시스템 호출을 사용하는 기능을 제거하면 공격자에게 추가 어려움을 야기하므로 분명히 몇 가지 이점이 있습니다. 그러나 JIT 구현이 W|X 메모리의 기본 시스템 호출을 사용하는 경우에도 어려움이 발생할 수 있습니다. 하지만 ABI가 여러 차례 변경됐지만 아직까지 아무도 문제를 보고한 적이 없기 때문에 이런 일이 발생하지 않기를 바랄 이유가 있습니다.

변경 사항은 이미 OpenBSD-Current 브랜치의 정기 스냅샷에서 확인할 수 있으며, 관심 있는 모든 사람을 테스트에 초대합니다.

Chrome/Iridium의 모드 등장에 대한 관련 뉴스는 Theo의 별도 논평이 필요합니다. JIT리스. 그의 관점에서 볼 때 이는 일부 사용 모델에서는 허용되지만 아마도 모든 모델에서는 그렇지 않을 것입니다. 왜냐하면 이 모드는 분명히 프로세서의 로드를 증가시키기 때문입니다. 현재 Chrome은 /usr/local에 대해 "wxallowed"를 비활성화하면 대부분 작동하지만 일부 확장 프로그램에는 문제가 있을 수 있습니다(예: ghostery). 어떤 식으로든 Theo는 가까운 미래에 JITless 모드의 본격적인 작업이 완전한 작동 상태에 도달할 수 있기를 바라고 있습니다.

출처 : opennet.ru