UNTRUSTEDCODE/etccredsnetSANDBOXno access outside

샌드박싱

10 분 읽음보안

샌드박싱은 브라우저가 모든 사이트에서 JavaScript를 실행하고, 휴대폰에서 모든 개발자의 앱을 실행하고, 노트북에서 전자 메일 첨부 파일을 열 수 있도록 하는 보안 패턴입니다. 이 모든 작업을 해당 프로그램이 은행 계좌 파일을 읽을 수 없도록 합니다. 신뢰할 수 없는 코드를 취약점에서 기능으로 바꾸는 것은 기술 계층입니다.

전체 기사 본문은 아래에 영어로 제공됩니다.

Sandboxing는 경계 외부의 리소스에 액세스하지 못하도록 제한된 환경 내에서 코드를 실행하는 방식입니다. 샌드박스는 읽을 수 있는 파일, 만들 수 있는 네트워크 연결, 통신할 수 있는 다른 프로세스, 호출할 수 있는 시스템 호출을 제한합니다. 코드가 악성이거나 버그가 있는 것으로 밝혀지면 피해는 제한됩니다.

샌드박싱이 중요한 이유

최신 컴퓨팅은 우리가 완전히 신뢰하지 않는 코드 실행에 따라 달라집니다.

  • 브라우저가 방문하는 모든 웹사이트의 JavaScript
  • 앱 스토어의 모바일 앱(검증되었지만 공식적으로 확인되지 않음)
  • Browser 확장 프로그램, IDE 플러그인, 코드의 종속성
  • 문서의 매크로, 이메일에 첨부된 스크립트
  • 클라우드 인프라의 컨테이너 작업 부하

샌드박스가 없으면 이러한 모든 것이 자격 증명 도용 공격이 일어나기를 기다리고 있습니다. 샌드박싱은 모델이 작동하도록 하는 것입니다.

샌드박스 구축 방법

계층화된 구현 기술:

  • 프로세스 격리. 최신 브라우저의 각 탭은 별도의 OS 프로세스입니다. 브라우저 커널은 프로세스가 수행할 수 있는 작업을 중재합니다. Linux의
  • seccomp-bpf — 프로세스가 수행할 수 있는 시스템 호출에 대한 커널 강제 필터입니다. 샌드박스는 필요한 syscall(읽기, 쓰기, mmap 등)을 선언하고 커널은 다른 모든 것을 거부합니다.
  • 네임스페이스 및 기능 on Linux — 파일 시스템, 프로세스, 네트워크 등에 대한 격리된 보기입니다. 컨테이너는 이러한 기본 요소로 구축됩니다. macOS/iOS의
  • App Sandbox — 앱에 필요한 기능(카메라 액세스, 네트워크, 특정 경로)을 설명하는 선언적 권한입니다. 자격이 없는 앱은 이러한 기능에 액세스할 수 없습니다.
  • AppContainer / Windows Sandbox — Microsoft의 동등한 격리 모델.
  • Chrome 및 Firefox의 사이트 격리 — 커널 수준 악용이 발생하더라도 한 사이트의 JavaScript가 다른 사이트의 메모리를 읽지 못하도록 오리진별로 프로세스를 분리합니다. found.

브라우저 샌드박스 자세히

브라우저는 컴퓨팅 분야에서 가장 공개적이고 가장 많이 공격받는 샌드박스입니다. 브라우저 커널은 신뢰할 수 있는 프로세스로 실행됩니다. 각 렌더러 프로세스(탭당 하나 이상)는 최소한의 기능을 갖춘 신뢰할 수 없는 프로세스로 실행됩니다. 렌더러는 다음을 수행할 수 있습니다.

  • 메모리 할당
  • 매우 특정한 작업을 위해 IPC를 통해 브라우저 커널과 통신
  • 그래픽 버퍼로 렌더링
  • JavaScript 및 WebAssembly 실행

It 할 수 없음:

  • 샌드박스 디렉터리 외부의 파일 열기
  • 임의의 네트워크 대상과 대화(브라우저 커널이 이러한 연결을 만듭니다)
  • 다른 프로세스 생성
  • 다른 프로세스의 메모리 읽기

브라우저 공급업체는 다음을 위해 수천만 달러의 버그 현상금을 지불합니다. 샌드박스 이스케이프 취약점. Chrome에서 가장 수익성이 높은 단일 현상금($200,000 이상)은 샌드박스를 탈출하는 전체 체인에 대한 것입니다.

모바일 앱 샌드박싱

iOS 및 Android는 샌드박스를 논리적 극단으로 활용합니다. 모든 앱은 자체 UID에서 실행되고 자체 파일 시스템 보기를 확인하며 좁은 OS 중재 IPC 채널(Android의 인텐트, URL)을 통해서만 다른 앱과 통신할 수 있습니다. iOS의 구성표 및 AppExtensions). OS는 런타임 시 사용자에게 기능 스타일 권한(카메라, 마이크, 연락처)을 묻는 메시지를 표시합니다. 결과적으로 휴대폰의 맬웨어는 데스크톱보다 훨씬 더 엄격하게 포함됩니다.

WebAssembly와 새로운 sandbox

WebAssembly는 처음부터 샌드박싱을 일류 속성으로 설계되었습니다. WASM 모듈에는 자체 시스템 호출이 없습니다. 모든 것은 호스트 환경(시스템 호출 스타일 API의 경우 WASI, 브라우저의 웹 API)에서 제공되어야 합니다. 이로 인해 WASM은 신뢰할 수 있는 애플리케이션 내에서 신뢰할 수 없는 플러그인을 실행하기 위한 강력한 후보가 되었습니다. 이는 이전에 과도한 프로세스 격리가 필요했던 사용 사례입니다. wasmtime 및 wasmer와 같은 도구는 이 모델을 사용합니다.

샌드박스가 실패할 때

샌드박스 이스케이프 취약점은 현실적이고 소중합니다. 반복되는 실패 모드:

  • 커널 표면의 버그. seccomp로 제한된 프로세스라도 때때로 허용된 syscall을 통해 도달할 수 있는 커널 버그를 악용할 수 있습니다.
  • IPC 버그. 샌드박스가 브로커 프로세스와 통신하는 데 사용하는 인터페이스 자체가 공격 표면입니다.
  • 사이드 채널. 스펙터 및 Meltdown은 CPU 최적화로 인해 프로세스 경계를 넘어 데이터가 유출될 수 있음을 보여주었습니다. 최신 샌드박스는 이를 완화하지만 근본적인 문제는 여전히 하드웨어 수준의 문제입니다.
  • 샌드박스 프로필 실수. 운영자는 때때로 소프트웨어가 작동하도록 샌드박스 프로필을 느슨하게 하여 실수로 구멍을 엽니다.

샌드박싱은 확률론적 방어입니다. 악용 기준을 높이는 것이지 제거하는 것은 아닙니다. 심층 방어는 샌드박싱을 다른 조치(메모리 안전 언어, 새니타이저, 공격 표면 감소)와 결합합니다.

샌드박싱이 사용자에게 의미하는 것

최종 사용자에게 샌드박싱은 대부분 눈에 띄지 않습니다. 실질적인 의미는 샌드박스 이스케이프가 최우선 보안 수정 사항이므로 브라우저와 OS를 최신 상태로 유지하는 것입니다. 결과를 이해하지 못하는 한 샌드박스 기능을 비활성화하지 마십시오(일부 Linux 사용자는 seccomp 프로필을 끄고 일부 고급 사용자는 Chrome의 샌드박스 플래그를 비활성화합니다). 브라우저는 기본적으로 강화되어 제공됩니다. 기본값은 거의 모든 사용자에게 적합합니다.

자주 묻는 질문

샌드박싱은 가상화와 동일합니까?
겹치지만 동일하지는 않습니다. 가상화는 에뮬레이터 내에서 전체 운영 체제를 실행합니다. 격리는 하드웨어 가상화 수준에서 이루어집니다. 샌드박싱은 일반적으로 커널 적용 제한을 통해 동일한 OS 내에서 프로세스를 실행합니다. 가상화는 더 무겁지만 더 강력한 격리를 제공합니다. 최신 디자인은 종종 두 가지를 결합합니다(서버리스용 Firecracker VM, 컨테이너용 gVisor).
샌드박스를 사용하면 속도가 느려지나요?
보통의 오버헤드 - 일반적으로 syscall 필터링의 경우 한 자릿수 비율이며, 프로세스 격리의 경우 약간 더 높습니다. 하드웨어 지원(Intel CET, ARM PAC)을 통해 성능 비용이 적극적으로 감소되었으므로 최신 샌드박스는 기본적으로 대부분의 워크로드에 대해 무료입니다.
VPN이 샌드박스를 벗어날 수 있나요?
VPN 클라이언트 소프트웨어는 일반적으로 샌드박스 앱보다 더 많은 권한이 필요합니다. 즉, 라우팅 및 네트워크 인터페이스를 구성합니다. macOS 및 iOS에서는 이를 안전하게 수행하기 위해 특정 API(NetworkExtension 프레임워크)를 사용합니다. VPN 클라이언트 자체에는 권한이 있습니다. 이를 통해 흐르는 데이터는 다른 앱에 불투명합니다.
Docker 컨테이너에서 코드를 실행하는 것이 샌드박싱과 동일합니까?
Docker 컨테이너는 격리를 위해 Linux 네임스페이스와 seccomp를 사용하며 이는 샌드박싱의 한 형태입니다. 격리는 가상화 기반 샌드박스(컨테이너가 호스트 커널을 공유함)보다 약하고 대부분의 syscall을 금지하는 사용자 공간 샌드박스(컨테이너는 다수를 허용함)보다 약합니다. 신뢰할 수 없는 워크로드의 경우 gVisor 또는 Kata 컨테이너와 같은 프로젝트는 Docker UX를 더욱 강력하게 격리합니다.
Chrome은 왜 그렇게 많은 메모리를 사용하나요?
사이트 격리. 모든 오리진은 자체 프로세스에서 실행됩니다. 서로 다른 사이트의 탭 50개는 프로세스 50개를 의미하며 각 프로세스에는 자체 메모리 오버헤드가 있습니다. 비용은 RAM입니다. 이점은 한 탭의 공격이 다른 탭의 데이터(비밀번호, 세션)를 읽을 수 없다는 것입니다. 최신 Chrome은 영향을 줄이기 위해 메모리 공유 최적화에 더 많은 노력을 기울이지만 아키텍처는 본질적으로 보안을 위해 메모리를 교환합니다.
샌드박싱 설명: 브라우저와 운영 체제에 신뢰할 수 없는 코드가 포함되는 방식