etc.

WebAssembly 간단하게 알아보기

Aile_I'll 2020. 11. 22. 16:11

WebAssembly

웹에서 바이너리 포맷을 처리할 수 있게 해주는 low-level 어셈블리 언어

Emscripten (C/C++/… -> Wasm bytecode)로 컴파일

JavaScript와 함께 동작할 수 있어 고성능 처리와 빠른 구현 ->

고성능 처리 작업은 C 단에서 돌리고 JS로 웹에서 핸들링 해 사용하는 구조

 

Stack 기반 머신이고 모듈로 구성되어있다.

WASMVM은 다른 프로그램 & 시스템과 분리 =>

import & export를 이용해서 호스트 프로그램과 communication

웹에서 바이너리를 실행하고 자바스크립트와 연결해서 사용하기 때문에 전통적인 바이너리 공격 + 웹 해킹 기법이 모두 적용되는 케이스가 발생 가능하다.

 

Ewasm (Ethereum-flavored WebAssembly)

Ethereum 네트워크를 위해 특별히 수정된 "Wasmsubset"

기존 EVM보다 빠른 실행 속도를 기대

C/C++를 사용함에도 호스트 브라우저의 권한 정책을 적용하여 보안이 유지

Solidity를 배우지 않아도 많은 개발자들이 편한 언어로 contract를 만들 수 있음

Ewasm 예시

EVM과 Ewasm 비교

EVM

Ethereum 1.0 에서 제시된 모델

Solidity, Viper등 특정 언어사용

네트워크의 모든 노드가 EVM을 완전히 정확하게 실행해야 하기 때문에 효율성보다는 정확성이 강조됨

이론적으로 설계되어서 실제 세계 어플리케이션에 맞지 않음

 

Ewasm

Ethereum 2.0 에서 제시된 모델

C/C++, Rust, Go 등 다양한 언어 사용 가능

웹을 위해 발명

정확성보다는 효율성과 빠른 load

실제 하드웨어 instruction에 가깝게 쓰여 실제 코딩에 더욱 효율적

 

Deploy관점에서 보면

아래 스마트 컨트랙트를 배포한다고 했을때

 

 

EVM에서의 dApp 배포

Ewasm 에서의 dApp 배포

EVM에서는 truffle을 이용해서 블록체인에 네트워크에 배포한 후 Frontend에서는 스마트 컨트랙트를 가져와 따로 구현함

Ewasm에서 배포할때는 한번에 컨트랙트를 import해서 바로 배포하고 바로 사용이 가능

 

WebAssembly 취약성

Linear Memory Model

웹어셈블리는 Linear Memory모델을 이용해서 가상머신을 구현하였습니다.

실제 메모리 주소가 VM과 분리되어 있어서 WebAssembly가 접근할 수 있는 유일한 메모리는 선형 메모리 버퍼 

instruction 주소나 메모리에 접근할 때 별도의 index를 이용해서 접근

그래서 원래는 메모리 주소가 WebAssembly 메모리의 밖에 있어서 c/c++스타일의 함수 포인터 사용 불가하지만

위 그림처럼 따로 테이블을 둬서 사용 가능

 

Wasm에서 자주 쓰이는 Linear memory구조 인데 제일 왼쪽 모델은 현재 쓰지 않음

컴파일러와 backend에 따라서 layout이 다름

Heap은 항상 마지막에 위치

read-only 데이터가 없음

출처 : Everything Old is New Again: Binary Security of WebAssembly, Daniel Lehmann, Johannes Kinder, Michael Pradel, Proceedings of the 29th USENIX Security Symposium ,2018

 

다음 3가지가 없음

메모리가 분리되어 있고 그에 따라 메모리에서 각 영역이 고정되어 있어서 필요 없다고 설명함

취약성

출처 : Everything Old is New Again: Binary Security of WebAssembly, Daniel Lehmann, Johannes Kinder, Michael Pradel, Proceedings of the 29th USENIX Security Symposium,2018

 

예상과 달리 위와 같은 취약점이 있음

쓰기 권한을 탈취하고 데이터를 overwriting해서 가능한 공격을 나타내는데 한가지 루트만 가능한게 하니라 각각 영역이 복합적으로 연계해서 일어날수 있기 때문에 3*3*3으로 27가지가 가능함

 

Stack-Based Buffer Overflow 예시

위의 코드에서 9번줄에서 Stack-Based Buffer Overflow가 일어날수있음

왼쪽 처럼 일반적인 x86 stack에서는 stack canary랑 stack reordering 덕분에 overflow가 방지될수있지만 Wasm에서는 막아주는 기능을 하는 요소가 없기 때문에 그대로 overflow가 일어날 수 있음

 

굵은 글씨로 표시되어있는 공격의 실제 예시를 설명하면 다음과 같음

PNM 파일 업로드하면 Client환경에서 C라이브러리를 이용해 PNG로 변환해서 홈페이지에 업로드 되는 예시

원래 동작은 

원래 동작은 이미지를 pngconver하고 base64로 인코딩한다음 img tag에 인코딩한 내용을 추가해서 document에 추가하는 동작을 함

이대로만 동작하면 XSS는 일어나지 않음

그런데 위 코드에서 3번줄에서 사용하는 라이브러리 함수에서 CVE로 등록된 취약점으로 인해 overflow가 발생함

그래서 Attacker가 악성코드가 들어있는 특정이미지를 업로드하면 PNG로 변환하는 중에 overflow가 발생

그 내용이 document.write의 매개변수로 들어가 img 태그 대신 Alert을 띄우는 코드가 됨

그래서 위와 같이 Alert 

 

대응방안

“Compositional Information Flow Analysis for WebAssembly Program”, Quentin Stiévenart, Coen De Roover , SCAM2020

youtube에 논문제목 치면 나오는 발표영상

Compositional한 정적분석 방법을 제안 => 분석속도가 빠름

WASM 을 함수 단위로 나누고 각 함수 마다 information flow가 어떻게 되는지 summary 도출

Abstract Semantic로 표현

함수들 간 call graph를 파악하고 함수들 사이에 summary를 확인

함수의 return value global variable가 어디서 영향을 받는지 알아냄

 

 

제안한 정적분석 기법을 활용해서 취약점 분석방법이 나올수 있을것