Software Security2

Side Channel Attack
Physical implementation에서 얻은 정보로 공격한다.
Brute force나 theoretical weakness가 아니라 전자장치에서 암호 알고리즘 수행 시 전력 소모, 전자기파 등 정보를 분석함으로써 공격한다.
인풋에 따라 leakage power가 달라지기도 하는데 이런걸 이용한다.
알고리즘 자체가 아니라 시스템을 공격하는 것이라서 알고리즘이 탄탄해도 상관 없다.
평범 동작을 분석하니까 흔적이 없고, 어떤 input을 넣고 에러를 분석할 수도 있다.
대응 방법으로는 무작위성기법(계산 실제값 유출을 방지하고 유출 정보 난수를 생성)이 있다.

Cache Side Channel Attack
Privilege를 무시한다. cross cpu, cross core.
L3에서 지우면 모든 캐시에서 지워진다.

TLB는 user와 kernel 사이에서 공유되고 context switching 때 flush되지 않는다

Resource-statistics: 메모리 사용을 보고 input이나 user action을 알아낸다.

Row hammer: 동일한 메모리 row에 반복적으로 접근하면 인접 메모리에 전기 방해가 일어나서 bit flip이 일어나는 취약점이다.

Covert-channel attack

------------------------------------------------------
Meltdown & Spectre
Speculative Execution과 Indirect Branch Prediction 기술과 관련된 취약점이다.
정상적인 프로세스에서는 성능을 위해서 한 명령이 처리될 때 다음 수행 될 명령을 위한 데이터가 캐시에 미리 저장된다.
만약 잘못 예측을 했다면 해당 작업을 취소하고 전 단계로 돌아가지만 CPU 캐시에 로드해 놓았던 데이터들은 남아있다.
Variant 1(CVE2017-5753), 2(CVE2017-5715)는 스펙터 취약점이고 Variant 3(CVE2017-5754) 는 멜트다운 취약점이다.


Meltdown
인텔에서 생산된 CPU에 존재한다.
Out-of-order execution을 통해 어느 address(커널 메모리)의 데이터도 읽을 수 있다.
Privilege check이 어떤 때는 너무 느려서 kernel memory leak을 허용한다.
User space에서 kernel address를 비활성화시키는 게 아니라 아예 unmap을 해서 접근할 수 없도록 하는 방법이 있다.



Spectre
인텔, ARM 및 AMD 프로세서에 존재하는 취약점이다.
프로세서가 실행해서는 안되는 코드를 실행하도록 유도하여 다른 어플리케이션 메모리 공간에 존재하는 정보를 유출시킬 수 있는 취약점이다.
프로세서에서는 일부 조건 분기에서는 먼저 해당 조건 안에 있는 코드를 먼저 실행하며, 발생 조건이 맞지 않는다면 해당 결과를 버리게 된다. 이러한 특성을 이용한 것이다.
CPU분기가 맞는지 맞지 않는지 판단을 하기 전에 분기 내부에 포함되어 있는 악의적 코드가 실행된다면 결과적으로 일부 데이터가 L1 cache에 저장되게 된다.
그후 이 데이터가 접근한 시간을 통해 어떤 데이터가 캐시에 저장되었는지 추측한 뒤 역순으로 자신의 메모리 경계선을 넘어 메모리를 읽어올 수 있다.
명령 때 마다 bound check을 하는 방법이 있지만 성능이 현저히 떨어진다.


------------------------------------------------------
Isolatioin(Sandbox and Container)

DAC: discretionary access control
access control이 owner의 재량(discretion)에 있는 것이다.

MAC: Mandatory Access Control
access control이 시스템(admin)에게 있는 것이다.

setuid

chroot

apparmor

seccomp

namespace

cgroups(control groups)

capability

docker



------------------------------------------------------
Mobile Security

Android application component
Activity: single screen
Service: keeping an app running in the background
Broadcast receiver: deliver events to apps
Content provider: manages a shared set of app data

fine-grained security feature: 앱이 실행할 수 있는 특정 작업에 제한을 둔다. 앱을 설치할 때 사용자에게 확인을 받는다. 각각 앱이 할 수 있는 일들을 정해놓는다.

runtime permission: runtime에 필요에 의해 권한 확인을 받는다.
쿠키: 브라우저가 쿠키를 갖고 있으면 서버에서 아 너 예전에 왔던 애구나 해서 로그인을 다시 안해도 된다.

intent: sender는 receiver가 permission을 갖고 있는 지 체크한다.
receiver는 어디서 왔는 지 알지 못한다.


------------------------------------------------------
Attacks and Defenses

CIA principles
Confidentiality: 허가되지 않은 접근에 정보를 숨기는 것이다.
Integrity: 데이터의 consistency, accuracy, trustworthiness를 지키는 것이다.
Availability: 허가된 접근에는 정보 요청이 가능한 것이다.

Cold Boot Attack
OS가 trusted라고 하면 cpu register, cpu cache, RAM은 trusted이고, Flash/Hard drive는 untrusted이다.
하드는 encryption돼있고 key가 reg, $, RAM에 있다.
DRAM이 공격당하면 데이터는 방전돼서 refresh돼야 한다.
이걸 냉각시키면 방전을 느리게 해서 RAM에 있는 key를 탈취할 수 있다.
대응책: 키를 reg와 $에만 넣자. 중요한 정보는 cpu를 떠날 때 항상 encrypted하게 만들자.

bus snooping: 주소 버스를 항상 감시해서 캐시상의 메모리에 대한 접근이 있었는지 감시한다. 쓰기가 발생하면 캐시 컨드롤러에 의해 자신의 캐시에 있는 복사본을 무효화시킨다.



------------------------------------------------------
Trusted Execution Environment(TEE)
클라우드로 모든 걸 처리하는 건 security issue가 있다.

ARM trustzone:
normal world와 secure world 두개로 나눠서 하두웨어 베이스로 access할 수 있도록 한다.
한계: 모바일을 위한 거라서 클라우드 환경에 부적절할 수 있다. 또한 memory encryption이 없어서 cold boot attack에 약하고 하드웨어에 키가 없어 emote attestation이 없다.

Intel SGX:
Confidentiality와 integrity를 보장한다.
enclave: 하드웨어로 보호된 execution region이다.
user level program을 실행하는 곳이다. 다른 시스템에게서 보호된다. os/hypervisor도 enclave를 볼 수 없다.
MEE(memory encryption engine).

remote attestation: enclave가 SGX에서 실행하는 지 확인한다.




댓글

댓글 쓰기

이 블로그의 인기 게시물

논문 정리 - MapReduce: Simplified Data Processing on Large Clusters

Abstract 맵리듀스는 큰 데이터 셋을 다루는 프로그래밍 모델이다 . 사용자는 map 함수를 통해서 키 / 밸류 쌍을 이용하여 intermediate key/value pair 를 만들고 reduce 함수를 통해서 그 intermediate pair 들을 같은 key 별로 합쳐준다 . 많은 일들이 이런 모델을 통해 표현될 수 있다 . 이 모델은 분산 시스템이나 병렬 시스템에 대한 경험이 부족하더라도 분산 시스템의 자원을 쉽게 사용할 수 있게 해준다 . 1. introduction 데이터가 많아지면서 reasonable time 안에 작업을 끝내기 위해 수백 혹은 수천대의 기계에 분산되어야 했다 . 이 때 어떻게 연산을 병렬화하고 , 데이터를 분산하고 , 실패 작업을 어떻게 처리할지가 이슈가 되었다 . 이런 복잡한 문제들을 해결하기 위해 병렬화의 세세한 부분들은 숨기고 fault tolerance 하며 데이터를 분산시켜주고 로드 밸런싱을 해주는 라이브러리를 통해서 연산을 맵과 리듀스로 간단히 표현하도록 했다 . 2. Programming Model 사용자가 직접 만드는 맵 함수는 입력으로 key/value pairs 를 받아서 intermediate key/value pairs 를 만든다 . 그러면 intermediate key/value pairs 에 대해서 맵리듀스 라이브러리가 같은 key 별로 value 들을 묶어서 리듀스 함수로 보내준다 . 마찬가지로 사용자가 직접 만드는 리듀스 함수는 이 데이터를 받아서 key 별로 묶인 value 들을 합쳐서 표현한다 . 리듀스 함수에 전달되는 intermediate 데이터는 iterator 의 형태로 전달되기 때문에 메모리에 다 안 들어갈 정도로 큰 데이터도 처리할 수 있다 . 예를 들어서 , 어떤 문서에 있는 각 단어들이 몇 번 나왔는지 세는 프로그램을 생각해보자 . 그렇다면 맵 함수는 입력으로 < 문서 이름 , 문서 내용 > 의...
자세한 내용 보기

논문 정리 - The Google File System

The Google File System 1. Introduction 새로운 관점 component failure 은 예외가 아니라 일반적인 상황이다 . 그래서 constant monitoring, error detection, fault tolerance, automatic recovery 가 필요하다 . 파일의 크기가 커졌다 . I/O 작업이나 block 크기 등이 고려되어야 한다 . 원래 있는 데이터에 덮어쓰는 작업보다는 새로운 데이터를 추가한다 . 따라서 appending 이 성능 최적화에 중요해졌다 . 2. Design Overview 2.1 assumptions 시스템은 잘 고장나는 저렴한 장비들로 구성되어 있다 . 시스템은 큰 파일이 있다 . 작은 파일들도 있지만 optimizing 할 때는 고려하지 않는다 . 로드는 주로 큰 스트리밍 읽기와 작은 랜덤 읽기로 구성되어 있다 . 로드는 또한 파일에 데이터를 추가하는 많은 sequential write 가 있다 . 같은 파일에 여러 사용자가 동시에 데이터를 추가하는 경우도 잘 고려해야 한다 . 빠른 반응 속도 보다는 high sustained bandwidth 가 더 중요하다 . 대부분의 타겟 애플리케이션은 데이터 뭉텅이를 빠른 시간 내에 처리하는 것을 중요하게 여긴다 . 2.2 Interface 파일은 hierarchically , 디렉토리에 정렬돼있고 path name 으로 구분된다 . 또한 GFS 는 snapshot 과 record append 기능이 있다 . snapshot 은 파일이나 디렉토리 트리를 복사한다 . record append 는 다수 클라이언트가 데이터를 하나의 파일에 동시에 추가할 수 있도록 해준다 . 각 append 의 atomicity 를 보장하면서 . 2.3 Architecture 하나의 마스터와 여러개의 chunkserver 로 구성되어 있다 . 그리고 다수의...
자세한 내용 보기

kazoo: Using zookeeper api with python

``` pip3 install kazoo ``` https://kazoo.readthedocs.io/en/latest/basic_usage.html https://kazoo.readthedocs.io/en/latest/api/client.html ### 접속 ``` from kazoo.client import KazooClient zk = KazooClient(hosts='127.0.0.1:2181') zk.start() ``` 호스트에 접속할 때 default port는 2181이다. ### 상태 Listener zookeeper의 상태가 변하는 것을 알 수 있다. ``` from kazoo.client import KazooState def my_listener(state):     if state == KazooState.LOST:         # Register somewhere that the session was lost     elif state == KazooState.SUSPENDED:         # Handle being disconnected from Zookeeper     else:         # Handle being connected/reconnected to Zookeeper zk.add_listener(my_listener) ``` LOST CONNECTED SUSPENDED 의 state를 가질 수 있다. 가능한 상태 변화 - LOST -> CONNECTED - CONNECTED -> SUSPENDED - CONNECTED -> LOST - SUSPENDED -> LOST - SUSPENDED -> CONNECTED ### CRUD - `zk.create("/my/favorite/node", b"a value")` `create(path...
자세한 내용 보기