Microsoft MVP성태의 닷넷 이야기
Windows: 12. 비스타는 안전한 윈도우인가? [링크 복사], [링크+제목 복사],
조회: 21659
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 



우선, 다음의 기사를 읽어보십시오.

비스타는 안전한 윈도우인가? 연재1
; http://vista.golbin.net/index.php?pl=756

재미있는 기사입니다. 만약 이 기사가 정말 맞다면, 개인적으로도 비스타의 안전성에 문제가 있다고 판단됩니다. 이것은 마치, 예전에 웹 브라우저상에서 악의적인 코드를 DHTML Edit 컨트롤을 사용하여 우회해서 실행시킨 것과 같습니다. 원천적으로 보안을 해결한 것이 아니라, 특정 부분에 대한 땜질식의 보안 강화를 시킨 것과 다를 바가 없다는 것인데요.

하지만, 위의 기사의 댓글을 보시면, "지나가던.." 님과 "Z.File" 님의 의견에서 UAC가 뜬다고 언급하고 있습니다. 문제의 단계는 "사진 4"번과 "사진 5"번 사이에 UAC 관리자 획득 권한 창이 뜨는 지에 대한 유무입니다.

댓글 등에서 이미 판결이 났지만, 그것은 분명한 UAC 확인창이었으니, 그 기사는 완전히 잘못된 정보를 유포하고 있는 것입니다. 혹시나, 몇몇 사람들이 기사만 보고, "댓글"을 읽지 않는다면 (실제로 RSS Feed에는 댓글이 실리지 않습니다.) 오해하기 딱 좋은 기사입니다. 그리곤, 그러한 사람들에 의해서, 무슨 대단한 공신력이 있는 사이트에서 분석이 나온 것처럼 퍼져나갈 수도 있을 테고요.




여기서 중요한 것은, "쿠도군" 님이 UAC 기능에 대한 이해가 그다지 정확하지 않다는 것입니다. 화면이 어두워지면서 별도의 데스크톱 보안 단위에서 실행되는 것이 분명한 UAC 확인창임에도 불구하고 그것의 대화창에 씌여져 있는 문구를 보고 UAC가 아니라고 한 것입니다.

솔직히, 이 기사를 보면서 느끼게 되는 것이 많군요. 저는 개인적으로 그 토픽에서 사용된 악성 코드를 직접 테스트해 볼 생각은 없었습니다. 즉, 저 역시 그 기사를 그대로 믿으려 했고 분명 심각한 보안 결함이라고 여겼습니다. 그런데, 다행히도, "지나가던.." 님과 "Z.File" 님이 직접 그 (주소가 알려지지 않았던) 사이트를 알아내는 수고로움을 더해서 테스트해 보신 후, 명백히 잘못된 정보라고 밝혀 주셨습니다.

그 두 분의 빠른 대응이 아니었다면, 정말 수많은 사이트들에서 비스타가 비하될 수 있었을 지도 모를 일입니다.




전체적으로 완전히 잘못된 기사이긴 하지만, "쿠도군"이 "의도"한 바를 생각해 봐야 할 것 같습니다. 즉, "UAC 확인창"은 실제로 대부분의 사용자에 의해서 간단히 "확인"으로 눌려질 수 있고 그로 인해 그다지 실질적인 보안 역할을 해주지는 못할 거라는 것입니다.

그럼, 쿠도군이 의도한 대로 보안 설정을 하는 방법이 과연 없을까요? 물론 있습니다. 방법은, "일반 사용자 계정"으로 로그인 하고, "로컬 보안 정책"의 "로컬 정책/보안옵션"에서 "사용자 계정 컨트롤: 표준 사용자 계정일 때 권한 상승 확인 방법 속성" 값을 "권한 상승 요청 자동으로 거부" 값으로 설정하는 것입니다. 그렇게 한다면, 관리 권한이 필요한 모든 동작들은 거부되게 됩니다.

하지만, 그것을 사용자가 원할까요?

여기서, 다시 이야기는 돌아가서 Windows XP 시절로 거슬러 올라가 볼 필요가 있습니다. 그렇습니다. Windows XP에서도 이미 그와 같은 보안 기능이 구현되어져 있었습니다. 관리자 계정이 아닌 일반 사용자 계정으로 로그인을 하게 되면, 아예 설치조차 안 되는 프로그램이 대부분이었습니다. 그런 경우, 사용자는 로그 오프를 한 다음 관리자 계정으로 로그인 하고 원하는 프로그램을 설치한 후 다시 일반 사용자 계정으로 돌아와야 했습니다.

문제는, 대다수의 Windows XP 사용자들이 그러한 불편을 원하지 않았으며 그로 인해 "관리자" 계정으로 컴퓨터를 사용했다는 것에 있습니다. 이쯤 되면, 질문은 오히려 바뀌어야 한다고 생각되어질 수 있겠습니다.

"
Windows가 정말로 안전하지 않은 운영체제인가? 
오히려 사용자들 스스로가 Windows XP를 안전하지 않은 상태로 사용하고 있었던 것은 아닌가?
"




[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 11/29/2022]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2007-01-08 12시19분
[WaterStone] 원문 글은 이미 지워졌군요... 함 보고 싶었는데...
사실 비스타의 UAC는 파워 유저에겐 불편한 기능임에 틀림없습니다만
일반 사용자들을 바이러스나 스파이웨어로 부터 보호하는데 기여를 할 것임은 분명해 보입니다.
다만 다수의 ActiveX를 사용하는 국내 여러 사이트와 편의적으로 어플리케이션을 개발하는 개발자들이
많은 코드를 수정해야 한다는 아픔이 물밀듯이 밀려온다는 것이지요.
[guest]
2007-01-08 01시21분
제가, 지울 것을 권했는데... 정말 삭제를 했네요. (블로그 저자 스스로도 다소 충격이 있었나 봅니다.)

어쨌든, UAC는 ... 개인적으로도 참 그렇습니다. 파워 유저들은 분명 불편함을 벗어나기 위해 "Disable UAC"나 "로컬 보안 정책" 등의 설정을 고려해 볼 수 있겠지만... 보안 관계상 어쩔 수 없다는 것을 또한 파워 유저들은 잘 알기 때문에 불편함을 감수하면서 켜야만 할지도 모르겠습니다. (저도 얼마 전부터 다시 켜고 있거든요. ^^;)

그래도, 이렇게 명시적인 제한을 두었다는 것을 계기로, 이후 개발되는 많은 프로그램들이 최소 권한(Least Privilege) 상태에 잘 적응했으면 합니다. ^^
kevin25

... 61  62  63  64  65  66  67  68  69  70  71  72  [73]  74  75  ...
NoWriterDateCnt.TitleFile(s)
12111정성태1/12/202020608디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification) [16]파일 다운로드1
12110정성태1/11/202019972디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례 [5]파일 다운로드1
12109정성태1/10/202016644오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/202017468오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
12107정성태1/10/202018666.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
12106정성태1/8/202019679VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작 [1]
12105정성태1/8/202018191디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
12104정성태1/7/202019425DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [4]
12103정성태1/7/202022544DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
12102정성태1/6/202018837디버깅 기술: 152. User 권한(Ring 3)의 프로그램에서 _ETHREAD 주소(및 커널 메모리를 읽을 수 있다면 _EPROCESS 주소) 구하는 방법
12101정성태1/5/202019200.NET Framework: 876. C# - PEB(Process Environment Block)를 통해 로드된 모듈 목록 열람
12100정성태1/3/202016618.NET Framework: 875. .NET 3.5 이하에서 IntPtr.Add 사용
12099정성태1/3/202019471디버깅 기술: 151. Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회 [1]
12098정성태1/2/202019274.NET Framework: 874. C# - 커널 구조체의 Offset 값을 하드 코딩하지 않고 사용하는 방법 [3]
12097정성태1/2/202017387디버깅 기술: 150. windbg - Wow64, x86, x64에서의 커널 구조체(예: TEB) 구조체 확인
12096정성태12/30/201919977디버깅 기술: 149. C# - DbgEng.dll을 이용한 간단한 디버거 제작 [1]
12095정성태12/27/201921713VC++: 135. C++ - string_view의 동작 방식
12094정성태12/26/201919395.NET Framework: 873. C# - 코드를 통해 PDB 심벌 파일 다운로드 방법
12093정성태12/26/201918983.NET Framework: 872. C# - 로딩된 Native DLL의 export 함수 목록 출력파일 다운로드1
12092정성태12/25/201917694디버깅 기술: 148. cdb.exe를 이용해 (ntdll.dll 등에 정의된) 커널 구조체 출력하는 방법
12091정성태12/25/201920045디버깅 기술: 147. pdb 파일을 다운로드하기 위한 symchk.exe 실행에 필요한 최소 파일 [1]
12090정성태12/24/201920134.NET Framework: 871. .NET AnyCPU로 빌드된 PE 헤더의 로딩 전/후 차이점 [1]파일 다운로드1
12089정성태12/23/201919084디버깅 기술: 146. gflags와 _CrtIsMemoryBlock을 이용한 Heap 메모리 손상 여부 체크
12088정성태12/23/201918043Linux: 28. Linux - 윈도우의 "Run as different user" 기능을 shell에서 실행하는 방법
12087정성태12/21/201918554디버깅 기술: 145. windbg/sos - Dictionary의 entries 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12086정성태12/20/201921091디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
... 61  62  63  64  65  66  67  68  69  70  71  72  [73]  74  75  ...