Comments [0]
윈도우즈 시스템이 갑자기 멈춘다든지 문제가 생겼음에도 불구하고 크래쉬가 되지 않아서 크래쉬 덤프를 얻지 못하는 경우가 있다. 이렇게 멈춘 시스템에서 메모리 덤프를 얻을 수 있다면 프로세스의 쓰레드등의 상태를 분석하여 원인을 알아 낼 수 있을 것이다. 이에 대한 방법으로 키보드의 핫키를 통한 크래쉬 온 디맨드 서비스를 사용할 수 있다.
간단히 요약하자면 다음의 해당하는 레지스트리 키에 CrashOnCtrlScroll이라는 Value를 만들고 데이타를 1으로 세팅하면 된다. 한가지 아쉬운 점은 Windows 2008시스템에서 USB Keyboard를 사용할 경우 이 핫키 세팅이 작동하지 않는다라는 사실이다.
Registry Key
PS/2 Keyboard: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters
USB Keyboard: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\kbdhid\Parameters
Value: CrashOnCtrlScroll
Data Type: DWORD
Data: 1
Forcing a System Crash from the Keyboard
Windows feature lets you generate a memory dump file by using the keyboard
단 이 키는 미리 세팅이 된 후에 리부팅을 한 상태여야 하므로 평소에 레지스트리 키를 셋업해 놓는 것이 좋을 것이다.
Comments [0]
Application Verifier is a runtime verification tool for unmanaged code that assists in quickly finding subtle programming errors that can be extremely difficult to identify with normal application testing. Application Verifier is designed specifically to detect and help debug memory corruptions and critical security vulnerabilities. It makes it easier to create reliable applications by monitoring an application's interaction with the Windows operating system, profiling its use of objects, the registry, the file system, and Win32 APIs (including heaps, handles, locks, and more). It also includes checks to predict how well the application will perform under Least-privileged User Account operation, compatibility tests to be used in logoing, and print tests to verify your usage of the print subsystem.
Comments [0]
Comments [0]
오픈웹이라는 운동이 있다. 근본적인 취지에 동의한다. 나 자신도 이미 15년전부터 리눅스, BSD(사실 부끄럽지만 프로그래밍 세계라는 잡지에 FreeBSD에 대한 글을 쓰기도 했고, 마이크로소프트웨어라는 잡지에 OpenBSD를 소개하기도 했다), 맥(2008년 이후 사용중이다), 윈도우즈(1998년 이후에 본격적으로 사용하게 되었다)를 골고루 사용하고 있는 유저로서 한국의 웹환경이 IE 일변도로 흐르고 있다라는 현실은 개탄스럽다. 사실 IE에서 조차도 수많은 이미지와 광고들로 인해서 더럽혀진 포탈 사이트들을 볼때면 사실 웹서핑의 짜증도가 확 올라가기 일쑤다. 인터넷 뱅킹도 가끔 잔고 확인등을 위해서 확인하고는 하는데 소리 소문 없이 설치된 액티브 엑스 모듈들 때문 기분이 상했던 적이 있다. 키보드 보안 모듈이나 백신이 소리 소문 없이 설치 되어 있는 것을 달가워 할 사람은 아무도 없다. 이러한 상황에 변화가 와야 한다라는 것을 인지 못하는 사람은 아마 드물것이다.
하지만 이러한 모든 책임을 단지 은행권에 대한 납품 업체에 불과한 보안 업체들에게 모두 떠넘기고, 마치 보안 업체들이 보안 모듈의 배포 정책(강제 설치)이나 배포 형식(액티브 엑스)에 전적으로 책임이 있다라고 주장하는 것에는 사실 함정이 있다.
배포 정책: 강제 설치
일단 배포 정책에 대해서는 사실 어떻게 실제로 결정이 되었는지는 당사자들 말고는 아무도 확신을 가지고 알 수 없다. 그런데 무조건 보안 업체들이 정부와 은행권을 꼬드겨서 강제 배포를 실시하고 있다라는 사실의 근거는 어디에 있는지 도저히 알 수가 없다. 근거가 없다면 함부로 누구에게 책임을 함부로 묻는 것은 자제하는 것이 낫지 않을까? 그러한 주장이 모욕적인 인신 공격의 형태로 나온다면 그것은 어떠한 논의도 혼란에 빠뜨릴 뿐이다.
배포 형식: 액티브 엑스
먼저 필자의 직업은 액티브 엑스와 많은 관련이 있다. 필자는 미국 캘리포니아에 위치한 보안 회사(http://www.eeye.com)에 근무하는데 업무상 액티브 엑스 모듈들의 활동을 분석하는 모듈을 개발한 적이 있다.
취약한 액티브 엑스 모듈을 공격하는 스크립트들을 차단하는 모듈을 개발했고, 해당 기술은 2008년에 미국에 특허 출원 상태이고,
미국의 유수 업체에 납품하고 있는 우리 회사의 제품에도 탑재되어 고객들의 보안을 지켜 주고
있다(http://www.reuters.com/article/pressRelease/idUS106893+26-Jan-2009+MW20090126 참조).
결론부터 이야기하자면 액티브 엑스라는 형식이 악성 코드에 의해서 악용되는 경우가 많다고 해서 액티브 엑스로 만든 모듈들은 모두다 악성 코드라고 주장하는 것은 어불 성설이다. 마이크로소프트의 정품 인증 모듈을 비롯해서 마이크로소프트 웹페이지에서도 아직도 액티브 엑스로 배포되는 모듈들을 심심치 않게 찾아 볼 수 있고, JRE나 어도비사의 플래쉬 플레이어 조차도 액티브 엑스와 관련된 부분이 있다. 액티브엑스 기술의 가장 큰 수혜자는 사실 어도비 사가 아닌가 한다. 그런데 액티브 엑스 중에서 가장 많이 실행되는 모듈은 말할 것도 없이 플래쉬 플레이어 모듈이다. 하지만 누구도 플래쉬 플레이어를 악성 코드라고 말하지 않는다. 액티브 엑스로 실행되는 코드의 내용이 악성 양성을 가르는 것이지, 액티브 엑스 기술을 사용하면 악성이 되는 것은 아니다. 이는 마치 많은 바이러스들이 Windows API를 사용한다고해서 Windows API를 사용하면 바이러스라고 단정하는 것과 똑같다. 즉, 전혀 설득력이 없는 주장이라는 것이다.
그렇다면 일단 내 주위에서 접할 수 있는 유용한 양성 액티브 엑스 모듈들을 찾아 보자. 업무상으로 많이들 사용하는 블래베리와 관련된 액티브 엑스 모듈이 있다. 또한 미국에서 엄청난 가입자를 유치하고 있는 웹을 통한 텔레 컨퍼런스 시스템인 GoToMeeting이 있다. 또한 집이나 출장지에서 회사 시스템에 접속하여 사내망에서 일하는 것처럼 해주는 쥬니퍼사에서 판매하는 VPN시스템의 클라이언트도 액티브 엑스 형태의 배포형식을 제공하고 있다. 물론 맥이나 리눅스 시스템을 동시에 서포트하는 경우도 있지만, 시스템에서 실행 되어야 하는 코드가 존재할 경우에는 해당 스크립트를 따로 관리자 권한으로 돌려야 다음 단계로 진행하는 식으로 처리하고 있다. 그 외에 맥아피나 트렌드 마이크로사와 같은 유수의 안티 바이러스 업체들은 모두 라이브 스캔 서비스를 제공하고 있다. 물론 해당 서비스는 액티브 엑스 기술이 아니라면 거의 구현이 불가능 한 것들이다.
액티브 엑스 배포형태라서 악성이라고 하거나 악성 코드를 가지고 있다라고 몰아 부치는 것은 납득하기 어려운 주장이다.
이렇게 미국에서도 일상 업무에 많이 사용되는 액티브 엑스를 마이크로소프트가 쉽게 포기하리라고 보지 않는다. 사실 액티브 엑스 기술의 99.9%는 COM기술에 기반하고 있으며 액티브 엑스의 실행 과정은 단지 해당 COM 모듈을 vbscript나 jscript에 노출 시켜주는 중간 모듈을 통해서 스크립트를 COM 시스템 내에서 해석해 내는 과정에 불과하다. 이론적으로 vbscript나 jscript가 아닌 다른 형태의 언어가 COM모듈을 이용하도록 만드는 것은 기술적으로 어려운 일이 아니다. 실제로 사용되는지는 모르겠지만 기억으로는 파이어팍스 소스 코드 베이스에도 이 COM 시스템을 이용하기 위한 코드들이 존재하였던것으로 기억한다.
결국 마이크로소프트의 입장에서 액티브엑스라는 기술은 COM의 단순한 확장에 불과하고 COM은 사실 윈도우즈의 가장 핵심적인 기술의 하나이다. 필자의 생각은 현재로서는 마이크로소프트에서 그 확장을 제거할 뚜렷한 이유가 없다라는 것이다. 그러기에는 이미 너무 많은 모듈들이 액티브엑스 기술에 의지하고 있다. 한국의 이야기가 아니라 미국의 이야기이다. 한국의 인터넷 뱅킹때문에 마이크로소프트에서 액티브 엑스를 유지하고 있다라는 과대 망상은 금물이다.
결론
이 글은 현재의 한국의 인터넷 뱅킹 시스템이 좋다라고 말하기 위한 목적이 아니다. 어떻게 고쳐야 된다라고 제시하기 위한 글도 아니다. 앞에서 이미 말했듯이 개인적으로도 한국의 인터넷 뱅킹을 좋아하지 않는다. 단지 엔지니어 입장에서 액티브 엑스에 대해서 알고 있는 내용을 간단하게 정리한 글이다. 다만 한국의 인터넷 뱅킹 시스템에 대해 논의하기 전에 미리 알아야 할 내용을 간단하게 적어 본 글이다. 올바른 배경 지식을 가지고 있지 않으면 올바른 결론이 나올 수 없다. 단지 추측이라든지 남이 그렇게 얘기하니까 그렇다라고 해서는 안된다. 어느 주장에나 그 주장을 뒷받침하는 근거가 있어야 한다. 사실 관계를 제대로 모르고 있는데 과연 올바른 해결책이 나올 수 있을까?
Comments [2]
Comments [0]
Comments [0]