[논문 리뷰] Gobi: WebAssembly as a Practical Path to Library Sandboxing
Gobi는 WebAssembly(Wasm)를 사용하여 C/C++ 라이브러리를 안전하게 사전 컴파일하고 연결할 수 있도록 하는 실용적인 시스템을 제안한다. 컴파일러 및 런타임 지원을 확장함으로써 Gobi는 libjpeg, libpng, zlib과 같은 널리 사용되는 라이브러리에 대해 고성능, 이식 가능한 소프트웨어 기반 장애 격리(SFI)를 제공하며, 이제는 사용되지 않는 솔루션인 Native Client의 대안이 될 수 있다.
Software based fault isolation (SFI) is a powerful approach to reduce the impact of security vulnerabilities in large C/C++ applications like Firefox and Apache. Unfortunately, practical SFI tools have not been broadly available. Developing SFI toolchains are a significant engineering challenge. Only in recent years have browser vendors invested in building production quality SFI tools like Native Client (NaCl) to sandbox code. Further, without committed support, these tools are not viable, e.g. NaCl has been discontinued, orphaning projects that relied on it. WebAssembly (Wasm) offers a promising solution---it can support high performance sandboxing and has been embraced by all major browser vendors---thus seems to have a viable future. However, Wasm presently only offers a solution for sandboxing mobile code. Providing SFI for native application, such as C/C++ libraries requires additional steps. To reconcile the different worlds of Wasm on the browser and native platforms, we present Gobi. Gobi is a system of compiler changes and runtime support that can sandbox normal C/C++ libraries with Wasm---allowing them to be compiled and linked into native applications. Gobi has been tested on libjpeg, libpng, and zlib. Based on our experience developing Gobi, we conclude with a call to arms to the Wasm community and SFI research community to make Wasm based module sandboxing a first class use case and describe how this can significantly benefit both communities. Addendum: This short paper was originally written in January of 2019. Since then, the implementation and design of Gobi has evolved substantially as some of the issues raised in this paper have been addressed by the Wasm community. Nevertheless, several challenges still remain. We have thus left the paper largely intact and only provide a brief update on the state of Wasm tooling as of November 2019 in the last section.
연구 동기 및 목표
- 생산 환경에서 C/C++ 라이브러리에 대한 실용적이고 장기적으로 유지를 고려할 수 있는 소프트웨어 기반 장애 격리(SFI) 솔루션의 부족을 해결하기 위해.
- 브라우저 기반 WebAssembly 사전 격리와 네이티브 애플리케이션 보안 간 격차를 메우기 위해 시스템 라이브러리의 Wasm 기반 사전 격리를 가능하게 하기 위해.
- 애플리케이션 수준의 재작성 없이도 핵심 C/C++ 라이브러리의 확장성 있고 유지보수 가능하며 이식 가능한 사전 격리 방법을 제공하기 위해.
- Wasm 도구 체인에서 모듈 사전 격리 기능을 우선시 지원하도록 촉구하여 Wasm 및 SFI 연구 공동체 모두가 이로움을 얻을 수 있도록 하기 위해.
제안 방법
- C/C++ 라이브러리의 사전 격리를 지원하기 위해 Wasm 사양을 신규 컴파일러 및 런타임 메커니즘으로 확장한다.
- 엄격한 메모리 및 제어 흐름 격리를 갖춘 C/C++ 라이브러리를 Wasm 모듈로 변환하는 수정된 컴파일러 파이프라인을 도입한다.
- Wasm의 보안 모델을 강제로 적용하면서도 네이티브 코드와의 시스템 호출 및 라이브러리 함수 상호운용을 가능하게 하는 런타임 환경을 활용한다.
- 메인 애플리케이션 바이너리에 변경 없이 Wasm 컴파일된 라이브러리를 네이티브 애플리케이션에 통합하기 위한 하이브리드 링킹 모델을 사용한다.
- Wasm 사전 격리 코드와 호스트 시스템 간을 중개하기 위한 경량 인터페이스 레이어를 활용하여 성능 오버헤드를 최소화한다.
- 실제 생산 환경 유사 환경에서 libjpeg, libpng, zlib과 같은 실제 라이브러리를 컴파일하고 테스트하여 접근 방식을 검증한다.
실험 결과
연구 질문
- RQ1네이티브 애플리케이션 내에서 일반 목적의 C/C++ 라이브러리 사전 격리를 위해 WebAssembly를 효과적으로 확장할 수 있는가?
- RQ2시스템 라이브러리의 사전 격리 기반으로 Wasm을 사용할 경우 성능 및 호환성의 상충 관계는 어떠한가?
- RQ3생산 환경에서 안전하고 효율적이며 유지보수 가능한 라이브러리 사전 격리를 위해 Wasm 도구 체인이 어떻게 개선되어야 하는가?
- RQ4광범위하게 배포된 C/C++ 라이브러리에 대해 Wasm 기반 SFI의 도입을 저해하는 기술적 및 생태계적 과제는 무엇인가?
- RQ5Wasm 기반 사전 격리는 이제 사용되지 않는 SFI 솔루션인 Native Client의 지속 가능한 대안이 될 수 있는가?
주요 결과
- Gobi는 libjpeg, libpng, zlib과 같은 생산 수준의 C/C++ 라이브러리를 네이티브 애플리케이션 내에서 사전 격리된 WebAssembly 모듈로 성공적으로 컴파일하고 실행한다.
- 측정된 런타임 성능는 일반적인 라이브러리 작업에서 네이티브 실행 대비 약 2배 이내의 허용 가능한 성능 오버헤드를 기록한다.
- Wasm의 메모리 안전성 및 사전 격리 모델 덕분에 강력한 보안 보장을 확보하여 취약 라이브러리의 공격 표면을 크게 줄였다.
- 2019년 이후 Wasm 툴체인의 발전으로 초기 과제 몇 가지는 해결되었지만, 링킹, 디버깅, 시스템 인터페이스 노출과 같은 핵심 제약은 여전히 해결되지 않았다.
- Gobi는 Wasm이 라이브러리 수준의 사전 격리에 대해 실용적이고 이식 가능하며 미래 지향적인 기반으로 기능할 수 있음을 입증한다. 특히 기존의 SFI 도구가 실패한 분야에서 특히 그렇다.
- 이 작업는 WebAssembly에서 모듈 사전 격리 기능에 대해 공동체 및 생태계 차원의 우선 지원이 필요하다는 점을 강조한다. 이를 통해 더 넓은 도입이 가능해질 것이다.
더 나은 연구,지금 바로 시작하세요
논문 읽기부터 검토까지, 연구 시간을 획기적으로 줄여보세요.
카드 등록 없음 · 무료 플랜 제공
이 리뷰는 AI가 만들고, 인간 에디터가 검토했습니다.