티스토리 뷰


Protected Mode 의 목적


2006년에 Protected Mode 가 IE 7에서 소개되었다. 이 PM의 목적은 데이터 수정 그리고 시스템 상에서의 악성코드 인스톨을 예방하는 것이었다.  비스타에서 소개된 무결성 메커니즘 사용해서 PM은 SANDBOXED IE 를 동작시킨다. 그리고 이것은 쓰는 작업에 대한 강력한 리미트를 제공한다.


2012년 EPM 이 소개되었다. EPM은 목적 중 하나는 기존 pm의 한계이다. 기존의 PM은 민감한 정보에 대한 read 는 제한하고 있지 않았다. EPM 에서 IE는 AppContainer 안에서 작동한다. 프로세스 고립 메커니즘은 Window8에서 소개 되었다. 이 것은 sandboxed process 로의 read write 를 둘다 제한한다. 그리고 sandboxed process 에 대한 특정 명령 수행을 예방한다.


AppContainer


AppContainer 에 대해 app들이 작동하며 app들의 접근과 수행에 대해 제한하는 박스들로 생각할 수 있다. EPM 에서 AppContainer는 Windows Store Apps 에서 사용하는 샌드박스 메커니즘을 사용한다.


AppContainer들은 프로세스들을 안에 작동시키며 특정 리소스들에만 접근 가능하게 하며 특정한 오퍼레이션만 사용하게 하기 위해 능력들을 갖는다.


한계와 취약점


개인적인 정보 또는 민감한 정보가 악성코드 가 EPM sandbox안에서 작동했을 때 여전히 접근 가능할 가능성은 있나??

그리고 EPM 안에서 작동하는 악성코드가 여전히 나쁜 행동들을 할 수 있냐고 묻는다면 둘다 가능하다고 말할 수 있다.


사용자 고유 영역에 대한 접근


유저 고유의 영역이 있다. %UserProfile% 안의 폴더 그리고 HKEY_CURRNET_USER subkey 아래의 정보라던가 이 부분은  sandboxed ie process 에서 여전히 접근 가능한 부분이다. 이 곳에 있는 리소스들은 여전히 민감하거나 개인적인 정보들을 가지고 있다.


여전히 접근 가능한 민감한 파일의 예는 epm cache 파일 그리고 epm cookie 이다.


(%UserProfile%\AppData\Local\Packages\%AppContainerName%\AC\InetCache, InetCookies)


적용되지


다른 샌드박스와 달리 예를 들어 크롬 같은 경우 여전히 제한, 고립 매커니즘을 적용하고 있지 않다. 이러한 적용되지 않은 부분은 토큰들, job object 제한, 윈도우, 데스크탑의 코립이다. 이러한 매커니즘이 없다면 스크립 캡처, 클립보드 데이터의 훔침이나 변조는 여전히 일어날 수 있다.



마지막으로 Appcontainer는 여전히 클라이언트 기능이 있다 이 것은 즉슨 악성코드가 외부 접속이 가능하다는 의미이다. 그리고 이 것은 해커의 통신을 가능하게 해줄 것이다.








'시스템 보안 > 취약점' 카테고리의 다른 글

off by one 에러  (0) 2016.09.26
SEH overwrite 공격  (0) 2016.09.26
버퍼 오버 플로우란?  (0) 2016.09.26
2 취약점 발견 방법  (0) 2016.09.25
1 취약점 발견 방법  (0) 2016.09.24
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
글 보관함