|
:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
14/04/29 21:03
취약점은 어도비 플레시가 가지고 있습니다. IE는 그저 어도비 플레시에게 너무 많은 권한을 줬을 뿐..
문제의 본질은 어도비 플레시입니다.
14/04/29 21:11
보니까 플래시 없으면 익스플로잇이 작동하지 않는 건 사실인데, 플래시 문제 뿐만 아니라 벡터 마크업 언어를 지원하는 마이크로소프트 공용 라이브러리와도 연관이 있는 것 같습니다.
14/04/29 21:25
UAF를 이용한건데.. 거의 모든 소프트웨어는 UAF를 가지고 있습니다. UAF 자체는 취약점이 아닙니다.
NT 커널에는 셀수 없이 많은 UAF가 있고, Notepad에도, explorer.exe에도, 한컴오피스, 워드, 등등등 거의 모든 프로그램은 UAF를 가지고 있습니다. 그런데 UAF 자체로는 취약점이 아닙니다. 왜냐하면 UAF가 되는 메모리 영역을 컨트롤 할수 있어야 공격행위를 심을수 있는데, 거의 대부분의 경우 UAF가 발생하는 메모리 영역에 접근을 못하기 때문입니다. 만약 UAF가 되는 영역의 메모리 Write를 자유롭게 할 수 있다면, 비로소 거기서 큰 문제가 생깁니다. 이번 사건이 딱 그 케이스예요. 과거에도 MS에서 이런 적이 있었고. MS10-018이었나 그랬을거예요. 다시 말해서, 이 문제는 IE가 가지고 있는 아주 많은 UAF 중에서 하나를, 어도비 플레시를 통해 접근할수 있기 때문에 발생하는 문제입니다. 이거 참... 어느놈이 나쁜놈인지 가려내기 힘들죠. UAF 자체는 나쁜넘이 아니거든요. 그런데 어도비 플레시때문에 UAF가 나쁜넘이 되었어요. (개인적으로는 어도비 플레시가 나쁜넘으로 보입니다만... 보안에 거의 신경을 안쓰는 플랫폼이 어도비 플레시입니다.) 아무튼 IE가 어도비 플레시에게 너무 많은 권한을 줬기에 생기는 문제니 IE도 잘못이 없다고 볼수는 없는데, IE 자체가 오랜 역사를 가지고 있는거라 한방에 없애진 못해서 가지고 있는건데.. IE 개발팀도 참 답답할겁니다. 문제의 원흉은 일개 브라우저 플러그인에게 User Mode 프로세스 권한을 죄다 줘버리는 ActiveX라고 할수 있겠네요.. 이래저래 IE 안쓰는게 좋겠습니다. ActiveX를 완전히 끄고 쓰거나... ActiveX 때문에 IE는 참 좋은 먹잇감입니다.
14/04/29 21:33
UAF가 취약점이 아니라는 말씀엔 동의하기 힘드네요... 그걸로 크래킹이 가능하냐 아니냐는 물론 별개의 문제지만, 그 자체로 심각한 코딩 오류고 보안 취약점이죠. 코드소나나 커버리티 같은 정적 분석 도구에서 가장 먼저 검사하는 문제점이고요. 원칙적으로 해제한 자원에 대한 포인터는 가지고 있어서도 안 되는 거고 사용하면 더더욱 안 되죠.
아무튼 IE는 뼈대가 되는 코드 베이스 자체가 워낙 오래 돼서, 계속 갈아치우고는 있지만 어려움이 많겠죠. 사실 IE11에서 타 브라우저들의 성능을 따라잡은 것만 해도 엄청난 성과인 것 같긴 합니다만 -,.-;
14/04/29 21:41
UAF를 다 컨트롤한다면 프로그램이 쓸데없는 부분까지 Verification을 해야 해서 프로그램이 매우 느려집니다.
이상적으로는 UAF가 코딩 오류겠지만(보안 취약점은 아니고), 2009년 까지만 하더라도 UAF 자체가 보안 취약점이 될 수 있다는 것은 이론적으로만 언급되었을 뿐입니다. MS10-018 이후로 상황이 바꼈지만, 과거에는 UAF가 취약점이 전혀 아니었어요. UAF가 발생하더라도, 해당 값을 사용하기 전에 verification을 하면 변조 여부를 걸러낼 수 있죠. 이래저래 UAF 자체는 취약점이 아닙니다. 특히 커널 영역에서는 코딩하다보면 어쩔수 없이 생길수 밖에 없기도 하고요.. NT커널을 Kernel Mode로 들어가서 돌려보면 UAF가 놀라울정도로 많습니다. 어차피 커널스페이스 메모리는 상당히 정형화 되어있으니 문제되진 않습니다. 그런데 누구도 NT커널이 UAF때문에 취약하다고 하진 않습니다. 왜나하면 UAF가 발생한 부분을 컨트롤할수 없기 때문입니다. 99.99%의 소프트웨어는 UAF를 가지고 있습니다. 하지만 그 UAF가 발생하는 영역에 접근이 불가능하기에 취약점이 아닐 뿐입니다. 이번에 발생한 문제는 IE 단독으로는 UAF가 발생하는 영역의 메모리 write가 불가능합니다. 대신에... 어도비 플레시를 통해 거기에 Write를 했고, 공교롭게도 해당 영역의 value verification이 없어서 그냥 당해버린것 같네요. Software Testing에서도 잡아내기가 무척 힘든 케이스긴 하네요... 이러나 저러나 UAF를 없애는게 안전상으로는 좋긴 하네요.. 아무튼 원흉은 ActiveX입니다만... 개인적으로는 어도비 플레시가 더 위험한 존재 같습니다.
14/04/29 22:00
원래 UAF는 Secure보다는 Reliability 측면에서 주로 문제가 되었던 거니까요.
다만 커널 영역이야 C/ASM으로 만들어야 하는 부분이니 그럴 수 있겠지만, 유저스페이스 응용 프로그램은 또 다른 문제라고 봅니다. 아예 느려지지 않는다면 거짓말이지만, C++에서 포인터 대신 스마트 포인터 사용하는 게 그렇게 큰 성능 저하를 불러온다고 보기 어렵습니다. 유저 어플리케이션에서는 JAVA도 쓰는데요. 뭐. 뭐, 함수형 언어들은 아예 언어 디자인 자체적으로 UAF를 비롯한 몇몇 프로그래밍 실수가 생길 수 없어요. 정말 신뢰성이 필요한 분야에서 함수형 언어 및 선언식 언어로 작성하는 이유도 그 때문일 겁니다
14/04/29 22:39
그러네요. 유저모드는 아무래도 더 신경써야 할것 같아요.
제가 커널 프로그램 위주로 만지다 보니.. 유저 모드에선 좀더 신경써야할게 많네요 ^^
14/04/29 21:05
IE용 플래시에 문제가 있는 것이라 플래시 추가 기능을 사용하지 않으면 일단 IE에서 해당 문제를 피할 수 있기는 합니다만..
14/04/29 21:35
타사 브라우저를 사용하시거나 플래시를 삭제하시면 됩니다.
그런데 어느 쪽이든 한국 웹 환경상 쉽게 선택할 수 있는 선택지는 아니죠
14/04/29 22:37
14/04/29 22:42
exploit시키는 도구가 플래시였는데, 그넘은 막혔고.. (최신버전 업데이트 다들 하시구요)
아마 MS에서 패치하기 전까지는 다른 도구(ActiveX)를 통해 공격을 시도할것 같습니다. 아직 문제의 근본원인은 패치되지 않았고, XP는 패치를 기대하기 힘들것 같네요.
14/04/29 22:53
플래시 쪽은 해결됐다고는 하지만 이번에 발견된 취약점 외에 다른 문제점이 있을 수 있고요
사실 UAC를 통해 privilege를 획득해서 동작하는 ActiveX 플러그인들이 더 큰 문젭니다. 권한은 더 큰데 Flash보다도 믿기 어려우니까요. 아예 ActiveX 자체를 쓰지 않는 Protected mode를 쓰지 않는 한 당분간은 IE를 쓰지 않는 것이 나을 것 같습니다.
14/04/29 23:26
이번 취약점이 일반적으로 자주 올라오는 보안 취약점? 업데이트?와 달리, 개인 사용자나 익스플로러 쓰는 회사 사용자들에게도 크게 영향을 준다거나 공격 대상이 될 수 있는 정도로 위험한 것인가요?
14/04/30 17:39
오픈 소스와 클로즈드 소스 응용 프로그램 중에서 보안에 어느 쪽이 취약한가.. 이건 시각에 따라 다른 문제입니다.
저 개인적으로는 개발에 참여하는 개발자들의 실력이 가장 중요한 요소라고 보고요. 예를 들어 클로즈드 소스 프로그램의 취약점은 소스 코드가 없으므로 발견하기 어렵습니다. 그것을 만든 당사자조차도요. 그러나 일단 발견되고 공격당하기 시작하면 패치가 나오기 위해서는 그 프로그램을 만든 회사에서 패치를 작성해서 각종 테스트를 거친 후에야 나올 수 있습니다. 오픈 소스 응용 프로그램의 취약점은 소스가 공개되어 있으므로 누구나 실력과 열정만 있다면 찾을 수는 있습니다. 달리 말하면 그만큼 많은 사람들에게 소스 코드를 검수받으므로 취약점이 제품으로 릴리즈되기 전에 발견되어 수정될 가능성이 높습니다. 그리고 이미 릴리즈되어 여러 곳에서 사용되는 경우에는 취약점이 발견되면 관리자가 직접 소스 코드를 수정할 수 있도록 수정 방법만 안내하고, 이후 버전에 반영하면 됩니다. 그래서 얼마 전에 문제가 되었던 heartbleed 같은 심각한 취약점은 쉽게 찾아보기 어렵지요.
|
||||||||||