Windows Administration

Windows Vista 커널 속으로: 3부

Mark Russinovich

 

한 눈에 보기:

• 안정성
• 복구
• 보안

지금까지 프로세스, I/O, 메모리 관리, 시스템 시작, 종료 및 전원 관리에 관련된 Windows Vista 커널의 향상된 기능에 대해 알아봤습니다. 세 번째이자 마지막 기사인

이번 호에서는 안정성, 복구 및 보안에 관련된 새로운 사항과 향상된 기능에 대해 살펴보겠습니다.

이 연재물에서 다루지 않는 한 가지 기능은 UAC(사용자 계정 컨트롤)입니다. UAC는 레거시 응용 프로그램을 위한 파일 시스템 및 레지스트리 가상화, 관리 권한 액세스를 위한 권한 상승 승인, 관리 권한으로 실행되는 프로세스를 동일한 계정에서 더 낮은 권한으로 실행되는 프로세스와 격리하는 Windows® 무결성 수준 메커니즘을 비롯한 여러 가지 기술로 구성됩니다. UAC에 대해서는 TechNet Magazine의 향후 기사에서 자세히 다룰 것입니다.

Windows Vista™에서는 다양한 새로운 기능과 향상된 기능을 통해 시스템 안정성과 시스템 및 응용 프로그램 문제를 진단하는 기능이 향상되었습니다. 예를 들어 커널 ETW(Windows용 이벤트 추적) 로거는 항상 활성화되어 파일, 레지스트리, 인터럽트 및 기타 작업 유형에 대한 추적 이벤트를 순환 버퍼로 생성합니다. 문제가 발생하면 새로운 WDI(Windows 진단 인프라)가 버퍼의 스냅숏을 캡처하여 로컬에서 분석하거나 문제 해결을 위해 Microsoft 기술 지원부로 보낼 수 있습니다.

새로운 Windows 성능 및 안정성 모니터를 사용하면 충돌이나 중단과 같은 오류를 시스템 구성 변경 내용과 연관하여 분석할 수 있습니다. 또한 부팅 불가능한 시스템의 오프라인 복구를 위한 기존 복구 콘솔이 강력한 SRT(시스템 복구 도구)로 대체되었습니다.

시스템에 대한 커널 수준의 변경에 많은 영향을 받는 세 가지 영역은 KTM(커널 트랜잭션 관리자), 향상된 충돌 처리, 그리고 이전 버전입니다. 이번 기사에서는 이 세 가지 영역에 대해 자세히 살펴보겠습니다.

커널 트랜잭션 관리자

소프트웨어 개발에서 많은 어려움이 따르는 분야 중 하나가 오류 조건의 처리입니다. 특히 높은 수준의 작업을 수행하는 과정에서 응용 프로그램이 파일 시스템 또는 레지스트리를 변경하는 하위 작업을 한 가지 이상 수행한 경우에 더욱 그렇습니다. 예를 들어 응용 프로그램의 소프트웨어 업데이트 서비스가 레지스트리 업데이트를 수행하고 응용 프로그램의 실행 파일 중 하나를 바꾸었는데 두 번째 실행 파일을 업데이트하려고 하자 액세스가 거부되는 경우가 발생할 수 있습니다. 이 경우 응용 프로그램을 일관성 없는 상태로 남겨두지 않으려면 변경 내용을 모두 추적하여 실행을 취소할 수 있도록 준비해야 합니다. 오류 복구 코드를 테스트하는 것은 상당히 까다롭기 때문에 생략되는 경우가 많습니다. 이 경우 복구 코드의 오류로 인해 위와 같은 노력이 물거품이 될 수 있습니다.

Windows Vista용으로 개발된 응용 프로그램은 NTFS의 새로운 트랜잭션 지원과 커널 트랜잭션 관리자를 통한 레지스트리를 사용함으로써 별다른 어려움 없이 자동 오류 복구 기능을 갖출 수 있습니다. 많은 수의 관련된 변경을 수행하려는 응용 프로그램에서는 DTC(Distributed Transaction Coordinator) 트랜잭션과 KTM 트랜잭션 핸들을 만들거나, KTM 핸들을 직접 만들어서 파일 및 레지스트리 키의 수정 내용을 트랜잭션에 연결할 수 있습니다. 모든 변경이 성공적으로 수행되면 응용 프로그램은 트랜잭션을 커밋하고 변경 내용이 적용됩니다. 그러나 이 단계 이전에는 언제라도 응용 프로그램에서 트랜잭션을 롤백하고 변경을 취소할 수 있습니다.

또한 다른 응용 프로그램에서는 트랜잭션이 커밋될 때까지는 해당 트랜잭션의 변경 내용을 볼 수 없지만 Windows Vista와 향후 출시될 Windows Server®(코드명 "Longhorn")의 DTC를 사용하는 응용 프로그램에서는 SQL Server™, Microsoft® Message Queue Server(MSMQ) 및 기타 데이터베이스를 통해 트랜잭션을 조정할 수 있습니다. 따라서 KTM 트랜잭션을 사용하는 응용 프로그램 업데이트 서비스로 인해 응용 프로그램이 일관성 없는 상태가 되는 일은 없습니다. 이러한 이유 때문에 Windows Update와 시스템 복원 모두에 트랜잭션이 사용됩니다.

NTFS, 레지스트리 등의 트랜잭션 리소스 관리자는 트랜잭션 지원의 핵심인 KTM을 통해 응용 프로그램이 수행한 특정 변경 사항과 자체 업데이트를 조정합니다. Windows Vista의 NTFS에서는 TxF라고 하는 트랜잭션 지원 확장 기능을 사용합니다. 레지스트리에서는 TxR이라고 하는 비슷한 확장 기능을 사용합니다. 사용자 모드 리소스 관리자가 DTC를 사용하여 여러 사용자 모드 리소스 관리자를 대상으로 트랜잭션 상태를 조정하는 것처럼 이 커널 모드 리소스 관리자는 KTM을 통해 트랜잭션 상태를 조정합니다. 타사에서도 KTM을 사용하여 자체 리소스 관리자를 구현할 수 있습니다.

TxF와 TxR은 트랜잭션 매개 변수를 포함한다는 점 외에는 모두 기존의 것과 비슷한 새로운 파일 시스템 및 레지스트리 API를 정의합니다. 응용 프로그램이 트랜잭션 내에서 파일을 만들려면 먼저 KTM을 사용하여 트랜잭션을 만든 다음, 그 결과로 생성되는 트랜잭션 핸들을 새 파일 만들기 API로 전달합니다.

TxF 및 TxR은 Windows Server 2003 R2에서 소개된 CLFS(공용 로그 파일 시스템)(%SystemRoot%\System32\Clfs.sys)의 고속 파일 시스템 로깅 기능을 사용합니다. TxR 및 TxF는 CLFS를 사용하여 트랜잭션을 커밋하기 전에 트랜잭션 상태 변경을 안정적으로 저장합니다. 따라서 전원이 끊긴 경우에도 트랜잭션을 복구하여 신뢰성을 확보할 수 있습니다. TxR은 CLFS 로그 외에도 각 사용자 레지스트리 하이브에 대한 별도의 로그 파일 집합뿐만 아니라 그림 1에서 볼 수 있는 것처럼 %Systemroot%\System32\Config\Txr의 시스템 레지스트리 파일에 대한 트랜잭션 변경을 추적하기 위해 관련 로그 파일 집합을 만듭니다. TxF는 각 볼륨의 트랜잭션 데이터를 해당 볼륨에서 \$Extend\$RmMetadata라고 하는 숨겨진 디렉터리에 저장합니다.

그림 1** 시스템 레지스트리 하이브 TxR 로깅 파일  **(더 크게 보려면 이미지를 클릭하십시오.)

향상된 충돌 지원

장치 드라이버의 버그, 하드웨어 또는 운영 체제의 오류 등의 이유로 복구할 수 없는 커널 모드 오류가 발생하는 경우 Windows에서는 "블루 스크린"을 표시한 다음 시스템을 중지하여 디스크의 데이터 손상을 방지합니다. 또한 구성에 따라서는 실제 메모리의 내용 전체 또는 일부를 크래시 덤프 파일에 씁니다. 충돌이 발생한 후 다시 부팅하면 Microsoft Online Crash Analysis(OCA) 서비스에서 덤프 파일을 분석하여 근본 원인을 찾기 때문에 이 덤프 파일은 유용하게 사용됩니다. 필요한 경우 Windows용 Microsoft 디버깅 도구를 사용하여 직접 원인을 분석할 수도 있습니다.

그러나 이전 버전의 Windows에서는 세션 관리자(%Systemroot%\System32\Smss.exe) 프로세스가 페이징 파일을 초기화할 때까지 크래시 덤프 파일을 사용할 수 없습니다. 따라서 이 시점 이전에 심각한 오류가 발생하면 블루 스크린이 표시되지만 덤프 파일은 생성되지 않습니다. Smss.exe가 시작하기 전에 많은 장치 드라이버의 초기화가 수행되기 때문에 초기에 충돌이 발생하면 크래시 덤프가 생성되지 않으므로 원인을 진단하기가 매우 어렵습니다.

Windows Vista에서는 모든 부팅 시작 장치 드라이버가 초기화된 후 시스템 시작 드라이버가 로드되기 전에 덤프 파일 지원이 초기화되므로 덤프 파일이 생성되지 않는 시간이 줄었습니다. 따라서 부팅 프로세스의 초기 단계에서 충돌이 발생하더라도 시스템에서 크래시 덤프를 만들 수 있기 때문에 OCA를 통해 문제 해결에 도움을 받을 수 있습니다. 또한 이전 버전의 Windows에서는 데이터를 4KB 블록 단위로 덤프 파일에 저장하지만 Windows Vista는 64KB 블록 단위로 저장합니다. 따라서 용량이 큰 덤프 파일도 최대 10배까지 더 빠르게 기록할 수 있습니다.

Windows Vista에서는 응용 프로그램 충돌 처리도 개선되었습니다. 이전 버전의 Windows에서는 응용 프로그램이 충돌하면 처리되지 않은 예외 처리기가 실행됩니다. 이 처리기는 Microsoft AER(응용 프로그램 오류 보고) 프로세스(%Systemroot%\System32\Dwwin.exe)를 실행하여 프로그램에 오류가 발생했음을 알리고 Microsoft에 오류 보고서를 보낼 것인지 묻는 대화 상자를 표시합니다. 그러나 충돌로 인해 프로세스의 주 스레드 스택이 손상된 경우에는 처리되지 않은 예외 처리기가 실행될 때 오류가 발생하여 커널에 의해 프로세스가 종료되고 프로그램 창이 사라지며 오류 보고 대화 상자가 나타나지 않습니다.

Windows Vista에서는 충돌 프로세스의 컨텍스트가 아니라 새로운 서비스인 WER(Windows 오류 보고)에서 오류 처리를 수행합니다. 이 서비스는 서비스 호스팅 프로세스 내의 DLL(%Systemroot%\System32\Wersvc.dll)로 구현됩니다. 응용 프로그램 충돌이 발생할 때 여전히 처리되지 않은 예외 처리기가 실행되기는 하지만 이 처리기는 WER 서비스로 메시지를 보내고 WER 서비스는 WER 오류 보고 프로세스(%Systemroot%\System32\Werfault.exe)를 실행하여 오류 보고 대화 상자를 표시합니다. 스택이 손상되고 처리되지 않은 예외 처리기가 충돌하면 처리기가 다시 실행되고 다시 충돌이 발생하여 결과적으로 스레드의 모든 스택(스크래치 메모리 영역)을 소비하게 됩니다. 이 단계에서 커널이 개입하여 해당 서비스에 충돌 알림 메시지를 보냅니다.

Windows XP 및 Windows Vista에서 충돌하는 테스트 프로그램인 Accvio.exe의 프로세스 관계와 녹색으로 강조 표시된 오류 보고 프로세스를 보여 주는 그림 2와 3에서 이 두 가지 방식의 차이를 확인할 수 있습니다. 새로운 Windows Vista 오류 처리 아키텍처에서는 충돌한 프로그램이 자동으로 종료되어 Microsoft에 오류 보고서를 보내지 못하는 경우가 발생하지 않습니다. 따라서 소프트웨어 개발자는 응용 프로그램을 개선할 기회를 얻을 수 있습니다.

그림 2a** Windows XP에서의 응용 프로그램 오류 처리 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 2b(더 크게 보려면 이미지를 클릭하십시오.)

그림 3a** Windows Vista에서의 응용 프로그램 오류 처리 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 3b

볼륨 섀도 복사본

Windows XP에서는 디스크 볼륨의 지정 시간 스냅숏을 만들기 위한 볼륨 섀도 복사본이라는 기술이 도입되었습니다. 백업 응용 프로그램은 이 스냅숏을 사용하여 일관된 백업 이미지를 만들 수 있습니다. 스냅숏은 사용자에게 표시되지 않으며 백업 프로세스 실행 중에만 유지됩니다.

스냅숏이 실제로 볼륨의 전체 복사본은 아닙니다. 스냅숏은 실시간 볼륨 데이터 위에 스냅숏이 생성된 이후 변경된 볼륨 섹터 복사본을 덧씌운 형태로 이루어진, 이전 시점의 볼륨 보기입니다. 볼륨 스냅숏 공급자 드라이버(%Systemroot\%System32\Drivers\Volsnap.sys)는 볼륨을 대상으로 수행되는 작업을 모니터링하면서 해당 작업이 변경하는 내용을 허용하기 전에 섹터의 백업 복사본을 만들고 원래 데이터는 해당 볼륨의 System Volume Information 디렉터리에 있는 스냅숏과 연결된 파일에 저장합니다.

Windows Server 2003에서 서버의 관리자와 클라이언트 시스템의 사용자는 공유 폴더의 섀도 복사본을 통해 스냅숏 관리를 확인할 수 있습니다. 이 기능을 사용하면 사용자가 서버의 파일 공유에 있는 자신의 폴더 및 파일에 대한 탐색기 속성 대화 상자의 이전 버전 탭을 통해 영구 스냅숏에 액세스할 수 있습니다.

Windows Vista의 이전 버전 기능은 이러한 기능을 모든 클라이언트 시스템에서 사용할 수 있도록 지원하며 일반적으로 매일 한 번씩 자동으로 볼륨 스냅숏을 만듭니다. 사용자는 공유 폴더의 섀도 복사본에 사용되는 것과1 동일한 인터페이스를 사용하여 탐색기 속성 대화 상자를 통해 볼륨 스냅숏에 액세스할 수 있습니다. 따라서 실수로 수정했거나 삭제한 파일과 디렉터리의 이전 버전을 보거나 복원하거나 복사할 수 있습니다. 기술적인 면에서 볼 때 새로운 것은 아니지만 Windows Vista에서 구현되는 볼륨 섀도 복사본의 이전 버전 기능은 Windows Server 2003의 볼륨 새도 복사본을 클라이언트 데스크톱 환경에서 사용할 수 있도록 최적화한 것입니다.

또한 Windows Vista에서는 볼륨 스냅숏을 활용하여 사용자 및 시스템 데이터 보호 메커니즘을 단일화하고 백업 데이터가 중복 저장되지 않도록 합니다. 응용 프로그램 설치 또는 구성 변경으로 인해 올바르지 않거나 바람직하지 않은 동작이 발생하면 Windows XP에서 Windows NT® 운영 체제 제품군에 도입된 기능인 시스템 복원을 사용하여 시스템 파일과 데이터를 복원 지점이 생성된 시점의 상태로 복원할 수 있습니다.

Windows XP에서 시스템 복원 기능은 파일 수준에서 변경 내용을 확인할 수 있는 드라이버 유형인 파일 시스템 필터 드라이버를 사용하여 변경 시점에서 시스템 파일의 백업 복사본을 만듭니다. Windows Vista의 시스템 복원 기능은 볼륨 스냅숏을 사용합니다. Windows Vista에서 시스템 복원 사용자 인터페이스를 사용하여 복원 지점으로 돌아가는 경우 실제로는 수정된 시스템 파일의 이전 버전이 복원 지점과 연결된 스냅숏에서 현재 볼륨으로 복사됩니다.

BitLocker

Windows Vista는 지금까지의 Windows 운영 체제 중 가장 안전한 버전입니다. Windows Vista에서는 Windows Defender 스파이웨어 방지 엔진 외에도 BitLocker™ 전체 볼륨 암호화, 커널 모드 코드를 위한 코드 서명, 보호된 프로세스, 주소 공간 로드 불규칙화, 향상된 Windows 서비스 보안 및 사용자 계정 컨트롤을 비롯하여 다양한 보안 및 심층 방어 기능을 제공합니다.

운영 체제는 활성화 상태에서만 보안 정책을 적용할 수 있기 때문에 시스템의 물리적 보안이 손상되었을 경우와 운영 체제 외부에서 데이터에 액세스할 경우를 대비하여 데이터를 보호하기 위한 추가적인 대책도 마련해야 합니다. BIOS 암호 및 암호화와 같은 하드웨어 기반 메커니즘은 분실이나 도난의 위험이 큰 랩톱에서 무단 액세스를 방지하는 용도로 많이 사용되는 두 가지 기술입니다.

Windows 2000에서 도입된 EFS(파일 시스템 암호화)는 Windows Vista에서 성능이 더욱 향상되어 페이징 파일 암호화 지원 및 스마트 카드에 사용자 EFS 키 저장과 같은 다양한 향상된 기능을 제공합니다. 그러나 레지스트리 하이브 파일과 같이 시스템의 중요한 영역에 대한 액세스를 보호하는 용도로 EFS를 사용할 수는 없습니다. 예를 들어 도메인에 연결되어 있지 않더라도 랩톱에 로그온할 수 있도록 그룹 정책이 설정된 경우 도메인 자격 증명 확인 프로그램이 레지스트리에 캐시되기 때문에 공격자가 도구를 사용하여 도메인 계정 암호 해시를 취득하고 이를 사용하여 암호 크래커를 통해 암호를 알아내려는 시도를 할 가능성이 있습니다. 공격자가 암호를 알아내면 사용자의 계정과 EFS 파일(EFS 키를 스마트 카드에 저장하지 않은 경우)에 액세스할 수 있게 됩니다.

Windows Vista에서는 모든 시스템 파일과 데이터를 포함한 전체 부팅 볼륨(Windows 디렉터리가 있는 볼륨)을 쉽게 암호화할 수 있도록 Windows BitLocker 드라이브 암호화라고 하는 전체 볼륨 암호화 기능을 제공합니다. NTFS 파일 시스템 드라이버로 구현되며 파일 수준에서 작동하는 EFS와는 달리 BitLocker는 그림 4에 설명된 것처럼 FVE(전체 볼륨 암호화) 드라이버(%Systemroot%\System32\Drivers\Fvevol.sys)를 사용하여 볼륨 수준에서 암호화합니다.

그림 4** BitLocker FVE 필터 드라이버 **(더 크게 보려면 이미지를 클릭하십시오.)

FVE는 필터 드라이버이므로 NTFS가 볼륨으로 전송하는 모든 I/O 요청을 자동으로 확인하고, 처음에 BitLocker를 사용하도록 볼륨을 구성한 경우 해당 볼륨에 할당된 FVEK(전체 볼륨 암호화 키)를 사용하여 블록을 기록할 때 암호화하고 블록을 읽을 때 암호를 해독합니다. 기본적으로 볼륨은 128비트 AES 키와 128비트 Diffuser 키를 통해 암호화됩니다. 암호화 및 암호 해독은 I/O 시스템의 NTFS 아래에서 수행되기 때문에 볼륨은 암호화되지 않은 것처럼 NTFS에 표시되고 NTFS는 BitLocker가 설정되어 있는 것을 알 필요도 없습니다. 그러나 Windows 외부에서 볼륨에 있는 데이터를 읽으려고 시도하면 해당 데이터는 무작위 데이터로 보입니다.

FVEK는 VMK(볼륨 마스터 키)로 암호화되어 볼륨의 특별한 메타데이터 영역에 저장됩니다. BitLocker를 구성할 때는 시스템의 하드웨어 성능에 따라 VMK의 보호 수준을 다양하게 설정할 수 있습니다. 시스템에 TPM 사양 v1.2를 준수하는 TPM(신뢰할 수 있는 플랫폼 모듈)이 설치되어 있고 BIOS에서 이를 지원하는 경우 TPM을 통해 VMK를 암호화하거나, TPM에 저장되어 있는 키와 USB 플래시 장치에 저장되어 있는 키를 사용하여 시스템에서 VMK를 암호화하도록 하거나, TPM 저장 키와 시스템 부팅 시 사용자가 입력하는 PIN을 사용하여 키를 암호화할 수 있습니다. TPM이 없는 시스템의 경우 BitLocker는 외부 USB 플래시 장치에 저장된 키를 사용하여 VMK를 암호화하는 옵션을 제공합니다. 어떠한 경우든 암호화되지 않은 1.5GB의 NTFS 시스템 볼륨이 필요합니다. 이 볼륨에는 부팅 관리자와 BCD(부팅 구성 데이터베이스)가 저장됩니다.

TPM을 사용할 때 얻게 되는 이점은 BitLocker를 사용하도록 설정한 이후에 BIOS나 시스템 부팅 파일이 변경된 경우 BitLocker가 TPM을 사용하여 VMK의 암호를 해독하거나 부팅 볼륨의 잠금을 해제하지 못하도록 할 수 있다는 것입니다. 시스템 볼륨을 처음 암호화하는 경우, 그리고 앞에서 언급한 구성 요소를 업데이트할 때마다 BitLocker는 해당 구성 요소의 SHA-1 해시를 계산하고 TPM 장치 드라이버(%Systemroot%\System32\Drivers\Tpm.sys)를 사용하여 측정값이라고 하는 각 해시를 TPM의 개별 PCR(플랫폼 구성 레지스터)에 저장합니다. 그런 다음 TPM을 사용하여 VMK를 봉인합니다. 이 작업에는 VMK를 암호화하기 위해 TPM에 저장된 개인 키와 BitLocker가 TPM으로 전달하는 다른 데이터와 함께 PCR에 저장된 값이 사용됩니다. 그런 다음 BitLocker는 봉인된 VMK와 암호화된 FVEK를 볼륨의 메타데이터 영역에 저장합니다.

시스템은 부팅될 때 자체 해시 값과 PCR 로딩 코드를 측정하여 해시를 TPM의 첫 번째 PCR에 씁니다. 그런 다음 BIOS를 해시하여 해당 측정값을 적절한 PCR에 저장합니다. BIOS는 부팅 시퀀스의 그 다음 구성 요소인 부팅 볼륨의 MBR(마스터 부트 레코드)을 해시하고 이 프로세스는 운영 체제 로더가 측정될 때까지 계속됩니다. 이후 실행되는 각 코드는 로드되는 코드를 측정하고 측정값을 TPM의 적절한 레지스터로 저장하는 역할을 합니다. 마지막으로 사용자가 부팅할 운영 체제를 선택하면 부팅 관리자(Bootmgr)가 볼륨에서 암호화된 VMK를 읽고 TPM에 봉인 해제를 요청합니다. 선택적으로 사용할 수 있는 PIN을 포함하여 측정값이 VMK가 봉인될 때와 동일한 경우에만 TPM이 VMK의 암호를 성공적으로 해독합니다.

이러한 체계는 부팅 시퀀스의 각 구성 요소가 그 다음 구성 요소를 TPM에 설명하는 확인 체인(Verification Chain)에 비유할 수 있습니다. 모든 설명이 원래 할당된 설명과 일치하는 경우에만 TPM이 암호 해독을 수행합니다. 따라서 BitLocker는 디스크를 분리하여 다른 시스템에 설치하거나, 다른 운영 체제를 사용하여 시스템을 부팅하거나, 부팅 볼륨의 암호화되지 않은 파일이 손상된 경우에도 암호화된 데이터를 보호할 수 있습니다.

코드 무결성 확인

루트킷을 포함하여 커널 모드 장치 드라이버로 구현되는 맬웨어는 커널과 동일한 권한 수준에서 실행되기 때문에 이를 식별하여 제거하는 것이 매우 어렵습니다. 이러한 맬웨어는 사실상 눈에 띄지 않게 커널 및 기타 드라이버의 동작을 수정할 수 있습니다. KMCS(커널 모드 코드 서명)라고도 하는 커널 모드 코드에 대한 Windows Vista 코드 무결성 기능은 CA(인증 기관) 중 하나에서 인증을 받은 개발자가 게시하고 디지털 서명한 장치 드라이버만 로드할 수 있도록 허용합니다. KMCS는 64비트 시스템용 Windows Vista에서 기본적으로 적용됩니다.

인증 기관은 제공하는 서비스에 대해 요금을 부과하고 비즈니스 ID 확인과 같은 기본적인 배경 검사를 수행합니다. 따라서 64비트 Windows Vista에서 실행되는 익명 커널 모드 맬웨어를 만드는 것이 더욱 어렵습니다. 또한 확인 프로세스를 빠져 나가는 맬웨어라도 공격을 받은 시스템에서 맬웨어가 발견되었을 때 만든 이를 추적할 수 있는 단서가 남을 가능성이 많습니다. 또한 KMCS는 사용자 시스템에서 충돌을 일으키는 버그가 있는 것으로 의심되는 드라이버에 대해 Windows Online Crash Analysis 팀에게 연락처 정보를 제공하고 고화질 멀티미디어 콘텐츠의 잠금을 해제하는 등의 용도로도 사용됩니다. 이에 대해서는 뒷부분에서 간단히 살펴보겠습니다.

KMCS는 Windows에서 10년 이상 사용되고 있는 공개 키 암호화 기술을 사용하며 신뢰할 수 있는 인증 기관 중 하나가 생성한 디지털 서명을 커널 모드 코드에 포함하도록 요구합니다. 게시자가 드라이버를 Microsoft Windows Hardware Quality Laboratory(WHQL)에 제출하고 해당 드라이버가 안정성 테스트를 통과하면 Microsoft는 해당 코드에 서명한 인증 기관 역할을 하게 됩니다. 대부분의 게시자는 WHQL을 통해 서명을 얻습니다. 그러나 드라이버에 WHQL 테스트 프로그램이 없거나, 게시자가 WHQL 테스트에 드라이버를 제출하지 않으려 하거나, 드라이버가 시스템 시작 초기에 로드되는 부팅 시작 드라이버인 경우에는 게시자가 직접 코드에 서명해야 합니다. 이렇게 하려면 해당 게시자는 먼저 Microsoft에서 커널 모드 코드 서명을 신뢰할 수 있는 것으로 구분한 인증 기관 중 한 곳을 통해 코드 서명 인증서를 얻어야 합니다. 그런 다음 게시자는 코드를 디지털 방식으로 해시하고 개인 키로 이를 암호화하여 해시에 서명하고 코드에 인증서와 암호화된 해시를 추가합니다.

드라이버 로드가 시도되면 Windows에서는 인증서에 저장된 공개 키를 사용하여 코드에 포함된 해시의 암호를 해독한 다음 이 해시가 코드에 포함된 것과 일치하는지 확인합니다. 인증서의 신뢰성도 이와 동일한 방법으로 확인하지만 이 경우에는 Windows에 포함된 인증 기관의 공개 키를 사용합니다.

또한 Windows에서는 Windows 부팅 로더와 운영 체제 커널에 포함된 루트 인증 기관 중 하나까지 연관된 인증서 체인을 확인합니다. 프로덕션 시스템에서는 서명되지 않은 64비트 드라이버의 로드가 시도되지 않아야 합니다. 따라서 WQHL 테스트를 통과했음을 확인하는 서명이 없는 드라이버를 로드하려고 하면 경고 대화 상자를 표시하는 플러그 앤 플레이 관리자와는 달리 64비트 Windows Vista에서는 서명되지 않은 드라이버의 로드를 차단할 때마다 그림 5에 표시된 것처럼 CodeIntegrity 응용 프로그램 이벤트 로그에 이벤트를 자동으로 기록합니다. 32비트 Windows Vista에서도 드라이버 서명을 확인하지만 서명되지 않은 드라이버의 로드가 허용됩니다. 이를 차단하면 Windows XP에서 로드된 드라이버를 필요로 하는 업그레이드된 Windows XP 시스템의 작동에 문제가 생길 수 있습니다. 또한 서명되지 않은 드라이버 로드를 허용하면 Windows XP 드라이버만 있는 하드웨어를 지원할 수도 있습니다. 32비트 Windows Vista도 서명되지 않은 드라이버를 로드할 때 CodeIntegrity 이벤트 로그에 이벤트를 기록합니다.

그림 5** 서명되지 않은 드라이버 로드 시도 이벤트 **(더 크게 보려면 이미지를 클릭하십시오.)

코드 서명은 일반적으로 엄격한 테스트를 통과한 공식 릴리스 코드에 사용되기 때문에 테스트 코드에는 서명을 하지 않으려고 하는 게시자가 많습니다. 따라서 Windows Vista에는 자체 인증 기관에서 생성한 테스트 인증서로 디지털 서명된 커널 모드 드라이버를 로드하는 Bcdedit 도구(필자의 2007년 3월 TechNet Magazine 기사에서 설명)를 통해 사용하거나 사용하지 않도록 설정할 수 있는 테스트 서명 모드가 포함되어 있습니다. 이 모드는 프로그래머가 코드 개발 과정에서 사용하도록 설계되었습니다. Windows가 이 모드에 있을 때는 바탕 화면에 그림 6과 같은 표시가 나타납니다.

그림 6** Windows Vista 테스트 서명 모드 **

보호된 프로세스

향후 몇 년 이내에 HD-DVD, 블루 레이 및 AACS(Advanced Access Content System)에 따라 사용이 허가된 기타 형식과 같은 차세대 멀티미디어 콘텐츠가 널리 사용될 것입니다. Windows Vista에는 AACS 표준에 따라 이러한 콘텐츠를 재생하는 데 필요한 여러 기술이 포함되어 있으며 이를 통칭하여 PMP(Protected Media Path)라고 합니다. PMP에는 승인되지 않은 소프트웨어 또는 하드웨어에서 콘텐츠를 고화질로 캡처하는 것을 방지하기 위해 미디어 플레이어 응용 프로그램과 오디오 및 비디오 드라이버를 위한 메커니즘을 제공하는 PUMA(Protected User-Mode Audio) 및 PVP(Protected Video Path)가 포함됩니다.

PUMA와 PVP는 오디오 및 비디오 플레이어, 장치 드라이버 및 하드웨어에 관련된 인터페이스와 지원을 정의하지만 PMP는 Windows Vista에 포함된 보호된 프로세스라고 하는 일반 커널 메커니즘도 활용합니다. 보호된 프로세스는 실행 가능 이미지, DLL, 프로세스가 실행되는 계정과 보안 권한을 의미하는 보안 컨텍스트 및 프로세스 내에서 코드를 실행하는 스레드를 캡슐화하는 표준 Windows 프로세스 구성을 기반으로 하지만 특정한 유형의 액세스는 차단합니다.

표준 프로세스는 프로세스의 소유자 및 프로그램 디버깅 권한이 있는 관리자 계정에게 모든 권한을 부여하는 액세스 제어 모델을 구현합니다. 모든 권한을 보유한 사용자는 프로세스에 매핑된 코드와 데이터를 비롯하여 프로세스의 주소 공간을 보고 수정할 수 있습니다. 또한 프로세스에 스레드를 삽입할 수도 있습니다. 이러한 유형의 액세스 권한은 승인되지 않은 코드가 콘텐츠를 재생하고 있는 프로세스에 저장된 DRM(디지털 권한 관리) 키와 고화질 콘텐츠에 대한 액세스 권한을 획득하는 것이 가능하도록 할 수 있기 때문에 PMP의 요구 사항에 맞지 않습니다.

보호된 프로세스는 프로세스의 이미지 이름 쿼리 및 프로세스의 종료나 일시 중단을 포함한 일부 정보 및 프로세스 관리 인터페이스에 대한 액세스를 제한합니다. 그러나 시스템의 모든 프로세스에 관련된 데이터를 반환하는 커널의 일반 프로세스 쿼리 기능을 사용하면 보호된 프로세스에 대한 진단 정보를 사용하는 것이 가능하기 때문에 프로세스에 직접 액세스할 필요가 없습니다. 미디어 악용을 초래할 수 있는 액세스는 다른 보호된 프로세스에 의해서만 허용됩니다.

또한 내부로부터의 악용을 방지하기 위해, 실행 가능 이미지와 DLL을 포함하여 보호된 프로세스로 로드되는 모든 실행 가능 코드는 Microsoft WHQL에 의해 PE(보호 환경) 플래그로 서명을 받거나 Microsoft에서 얻은 DRM 서명 인증서를 통해 개발자로부터 서명을 받아야 합니다. 커널 모드 코드는 보호된 프로세스를 포함하여 모든 프로세스에 대한 모든 권한을 얻을 수 있으며 32비트 Windows에서는 서명되지 않은 커널 모드 코드를 로드하는 것이 허용되기 때문에 커널은 커널 모드 환경의 "무결성"을 확인하고 그 결과를 사용하여 서명되지 않은 코드가 로드되지 않은 경우에만 중요한 콘텐츠의 잠금을 해제하는 보호된 프로세스용 API를 제공합니다.

보호된 프로세스 식별

보호된 프로세스를 식별하는 별도의 전용 API는 없지만 보호된 프로세스에 대한 제한적인 정보와 관리자 계정을 사용해도 보호된 프로세스를 디버깅할 수 없다는 점을 이용하면 간접적으로 보호된 프로세스를 식별할 수 있습니다. CSS(Content Scramble System)로 인코딩된 DVD를 재생하는 데 사용되는 오디오 장치 그래프 격리 프로세스(%Systemroot%\System32\Audiodg.exe)는 관리자 권한으로 실행할 때도 작업 관리자에서 명령줄, 가상화 및 데이터 실행 방지 상태를 사용할 수 없다는 점을 감안할 때 보호된 프로세스라는 것을 알 수 있습니다.

보호된 프로세스인 audiodg가 표시된 작업 관리자(더 크게 보려면 이미지를 클릭하십시오.)

주소 공간 로드 불규칙화

데이터 실행 방지 및 향상된 컴파일러 오류 검사와 같은 대책에도 불구하고 맬웨어 작성자는 Internet Explorer®, Windows 서비스 및 타사 응용 프로그램과 같은 네트워크 관련 프로세스를 감염시켜 시스템 침투의 발판을 만들 수 있는 버퍼 오버플로 취약점을 파악하기 위해 계속 시도합니다. 그러나 프로세스를 감염시키더라도 사용자 데이터를 읽거나 사용자 또는 시스템 구성 설정을 수정하여 영구적인 침투 경로를 만드는 궁극적 목표를 달성하려면 Windows API를 사용할 수밖에 없습니다.

응용 프로그램을 DLL에서 내보낸 API 진입점과 연결하는 작업은 운영 체제 로더가 처리하는 것이 일반적이지만 이러한 유형의 맬웨어 감염은 로더 서비스를 이용하지 못합니다. 이전 버전의 Windows에서는 시스템 실행 가능 이미지와 DLL이 항상 동일한 위치에서 로드됩니다. 따라서 맬웨어는 API가 고정된 주소에 있는 것으로 가정할 수 있으므로 문제가 발생할 수 있었습니다.

하지만 Windows Vista의 ASLR(주소 공간 로드 불규칙화) 기능은 시스템이 부팅될 때마다 각기 다른 위치에서 시스템 DLL과 실행 파일을 로드하기 때문에 맬웨어가 API의 위치를 알아내는 것이 불가능합니다. 부팅 프로세스의 초기 단계에서 메모리 관리자가 사용자 모드 주소 공간 위쪽의 16MB 영역에 있는 256개의 64KB 정렬 주소 중 하나에서 임의의 DLL 이미지 로드 바이어스를 선택합니다. 이미지 헤더에 새로운 동적 재할당 플래그가 있는 DLL이 프로세스에 로드되면 메모리 관리자는 해당 이미지 로드 바이어스 주소에서 시작하여 이러한 DLL을 메모리에 압축합니다.

플래그가 설정된 실행 파일도 비슷하게 처리되어 이미지 헤더에 저장된 16MB의 기본 로드 주소 내에서 임의의 64KB 정렬 지점으로 로드됩니다. 또한 해당 DLL이나 실행 파일이 모든 프로세스에 의해 해제된 후 다시 로드되더라도 메모리 관리자는 로드할 위치를 무작위로 다시 선택합니다. 그림 7에서는 ASLR이 이미지 로드 바이어스와 실행 파일 로드 주소를 선택하는 영역을 포함하여 32비트 Windows Vista 시스템의 주소 공간 레이아웃 예제를 보여 줍니다.

그림 7** ASLR이 실행 파일 및 DLL 로드 주소에 미치는 영향 **(더 크게 보려면 이미지를 클릭하십시오.)

레거시 이미지를 이동하면 이미지 로드 위치에 대해 개발자가 세운 가정과 어긋나게 되므로 모든 Windows Vista DLL과 실행 파일을 포함하는 동적 재할당 플래그가 있는 이미지만 위치가 다시 지정됩니다. Visual Studio® 2005 SP1에서는 타사 개발자가 ASLR을 충분히 활용할 수 있도록 플래그 설정을 추가로 지원합니다.

DLL 로드 주소를 256개의 위치 중 하나로 불규칙화하더라도 맬웨어가 API의 정확한 위치를 전혀 추측할 수 없는 것은 아니지만 네트워크 웜의 전파 속도를 크게 낮출 수 있으며, 시스템을 감염시킬 기회가 한 번뿐인 맬웨어의 정상적 작동을 차단할 수 있습니다. 또한 ASLR의 위치 재할당 방법을 사용하면 주소 공간이 이전 버전의 Windows에 비해 더 강력하게 압축되므로 메모리 여유 공간을 더 많이 확보하여 지속적으로 메모리를 할당할 수 있으며 메모리 관리자가 주소 공간 레이아웃을 추적하기 위해 할당하는 페이지 테이블의 수를 줄일 수 있고 TLB(Translation Lookaside Buffer) 실패를 최소화할 수 있는 추가적인 이점도 얻을 수 있습니다.

서비스 보안 향상

Windows 서비스는 맬웨어가 자주 공격하는 대상입니다. 많은 수의 Windows 서비스가 해당 기능에 대한 네트워크 액세스를 허용하기 때문에 시스템에 대한 원격 액세스가 악용될 가능성이 있으며, 대부분의 서비스가 표준 사용자 계정보다 많은 권한의 계정으로 실행되기 때문에 맬웨어에 감염되면 로컬 시스템에서 권한이 승격될 위험성이 있습니다. 이러한 이유 때문에 Windows에서는 Windows XP SP2부터 서비스에 할당된 권한과 액세스 권한을 해당 서비스의 역할에 필요한 것으로 제한하기 시작했습니다. 예를 들어 Windows XP SP2에서는 이전에는 서비스 실행에 항상 사용되던 계정(로컬 시스템)이 사용할 수 있는 권한의 일부만 포함된 로컬 서비스 및 네트워크 서비스 계정이 도입되었습니다. 이를 통해 공격자가 서비스를 악용할 때 획득할 수 있는 액세스 권한이 최소화됩니다.

ASLR 실제 적용

Sysinternals의 Process Explorer와 같은 도구를 사용하여 서로 다른 두 가지 부팅 세션에서 프로세스의 DLL 로드 주소를 비교하면 ASLR의 이점을 쉽게 확인할 수 있습니다. 서로 다른 두 세션에서 가져온 다음 두 스크린 샷에서 Ntdll.dll은 처음에는 주소 0x77A30000에서 Explorer에 로드되고 다음에는 주소 0x77750000에서 로드됩니다.

ntdll.dll의 서로 다른 기본 주소(더 크게 보려면 이미지를 클릭하십시오.)

ntdll.dll의 서로 다른 기본 주소(더 크게 보려면 이미지를 클릭하십시오.)

이전 기사에서 필자는 서비스가 어떻게 자체 세션에서 다른 사용자 계정과 격리되어 실행되는지 설명했지만 Windows Vista에서는 파일, 레지스트리 키 및 대부분의 서비스에 할당하는 방화벽 포트에 대한 권한과 액세스 권한을 더 제한하여 최소 권한이라는 원칙을 더욱 폭넓게 적용합니다. Windows Vista에서는 각 서비스에 고유한 서비스 SID(보안 식별자)라는 새로운 그룹 계정을 정의합니다. 서비스는 자신의 리소스에 사용 권한을 설정하여 해당 서비스 SID만 액세스할 수 있도록 하고 서비스가 공격을 받더라도 동일한 사용자 계정에서 실행되고 있는 다른 서비스가 액세스 권한을 얻지 못하도록 할 수 있습니다. 그림 8에서 볼 수 있는 것처럼 sc showsid 명령과 서비스 이름을 사용하여 서비스의 SID를 확인할 수 있습니다.

그림 8** 서비스 SID 보기 **(더 크게 보려면 이미지를 클릭하십시오.)

서비스 SID는 특정 서비스가 소유한 리소스에 대한 액세스를 보호하지만 기본적으로 서비스는 해당 서비스를 실행하는 사용자 계정이 액세스할 수 있는 모든 개체에 대해 액세스 권한을 가집니다. 예를 들어 로컬 서비스 계정에서 실행되는 서비스는 서비스 SID를 참조하는 사용 권한으로 개체를 보호하는 다른 프로세스에서 로컬 서비스로 실행되는 다른 서비스가 만든 리소스에는 액세스할 수 없지만, 로컬 서비스 및 서비스 그룹과 같이 로컬 서비스가 속하는 모든 그룹이 사용 권한을 갖고 있는 모든 개체를 읽고 쓸 수 있습니다.

따라서 Windows Vista에서는 서비스 SID, Everyone 그룹 및 로그온 세션에 할당된 SID에 액세스할 수 있는 개체에만 서비스 쓰기 액세스 권한을 허용하는, 쓰기가 제한된 서비스라고 하는 새로운 유형의 제한된 서비스를 사용합니다. 이를 위해 Windows 2000에 도입된 SID 유형인 제한된 SID가 사용됩니다. 개체를 여는 프로세스가 쓰기가 제한된 서비스인 경우 제한된 형식과 제한되지 않은 형식 모두에서 프로세스에 할당되지 않은 SID가 프로세스에 개체에 대한 쓰기 액세스 권한을 부여하는 데 사용될 수 없도록 액세스 검사 알고리즘이 변경됩니다. 다음 명령을 사용하여 서비스가 제한되었는지 확인할 수 있습니다.

sc qsidtype [service]

또한 서비스가 자신이 만든 개체에 대해 동일한 계정에서 실행되는 다른 서비스가 액세스 권한을 갖는 것을 쉽게 차단할 수 있도록 변경되었습니다. 이전 버전의 Windows에서는 개체의 작성자가 곧 개체의 소유자이고 소유자는 자신이 만든 개체의 사용 권한을 읽고 변경할 수 있기 때문에 자신의 개체에 대해 모든 권한을 가집니다. Windows Vista에서는 새로운 소유자 권한 SID가 추가되었습니다. 개체의 사용 권한에 이 소유자 권한 SID가 있으면 소유자가 자신의 개체에 대해 갖는 액세스 권한을 제한할 수 있으며 사용 권한을 설정하고 쿼리하는 권한을 제거할 수도 있습니다.

Windows Vista에서는 서비스 보안 모델이 더욱 향상되었기 때문에 서비스 개발자는 서비스가 시스템에 등록될 때 서비스의 작동에 필요한 보안 권한을 정확하게 지정할 수 있습니다. 예를 들어 서비스가 감사 이벤트를 생성해야 하는 경우 감사 권한을 나열할 수 있습니다.

서비스 제어 관리자는 하나 이상의 Windows 서비스를 호스팅하는 프로세스를 시작할 때 프로세스의 서비스에 필요한 권한만 포함된 프로세스용 보안 토큰을 만듭니다. 여기서 보안 토큰이란 프로세스 사용자 계정, 그룹 구성원 및 보안 권한을 나열하는 커널 개체입니다. 서비스가 해당 서비스가 실행되는 계정에서 사용할 수 없는 권한을 지정하면 서비스가 시작되지 않습니다. 예를 들어 로컬 서비스 계정에서 실행되는 서비스 중 프로그램 디버깅 권한이 필요한 서비스가 없는 경우 서비스 제어 관리자는 프로세스의 보안 토큰에서 해당 권한을 제거합니다. 따라서 서비스 프로세스가 공격을 받은 경우에도 악성 코드는 프로세스에서 실행되고 있는 서비스가 명시적으로 요청하지 않은 권한을 사용할 수 없습니다. sc qprivs 명령을 사용하면 서비스가 요청한 권한을 볼 수 있습니다.

결론

지금까지 3회에 걸쳐 Windows Vista 커널의 변경 내용에 대해 살펴봤습니다. 응용 프로그램 개발자를 위한 새로운 작업자 스레드 풀, 공유 판독기/기록기 잠금과 같은 새로운 동기화 메커니즘, 서비스 스레드 태그 지정, 온라인 NTFS 디스크 검사 및 볼륨 크기 조정의 지원 및 ALPC(Advanced Local Procedure Call)라고 하는 새로운 커널 IPC 메커니즘 등과 같이 기사에서 설명하거나 언급하지 않은 기능이나 구현 기술도 있습니다. 이러한 항목과 기타 기능에 대한 자세한 내용은 2007년 말 발간 예정인 Windows Internals의 새 버전에서 자세히 다루겠습니다.

쓰기 제한된 서비스 보기

Windows Vista에서 하나의 서비스 호스팅 프로세스만 제한된 서비스를 호스팅할 수 있으며 다음 명령줄을 사용할 수 있는 Process Explorer와 같은 프로세스 보기 도구로 이를 확인할 수 있습니다.

svchost -k LocalServiceNoNetwork

이 프로세스에서 실행하도록 구성된 서비스로는 기본 필터링 엔진, 진단 정책 서비스, Windows 방화벽, 성능 로그 및 경고, Windows Media® Center Service Starter 등이 있습니다.

이 화면에서는 기본 필터링 엔진의 서비스 SID인 NT SERVICE\BFE의 텍스트 형태를 제한됨 플래그가 있는 상태와 없는 상태에서 보여 줍니다. 없는 상태에서 이 프로세스는 해당 계정에서 액세스 가능한 리소스에 대해 액세스 권한을 가집니다. 하지만 일반적으로 로컬 서비스 계정이 액세스할 수 있는 다른 개체에는 액세스할 필요가 없습니다. 예를 들어 NT AUTHORITY\SERVICE 계정은 제한됨 플래그가 있는 프로세스 토큰에 나타나지 않기 때문에, 프로세스는 해당 계정에만 쓰기 액세스 권한이 부여되었고 제한됨 플래그가 있는 토큰의 다른 계정에는 부여되지 않은 개체를 수정할 수 없습니다.

속성 대화 상자 아래쪽에 나열된 권한이 로컬 서비스 계정에 사용 가능한 권한의 일부이기 때문에 이 프로세스에서 실행되는 서비스는 권한도 제한됩니다.

서비스의 SID 플래그(더 크게 보려면 이미지를 클릭하십시오.)

Mark Russinovich는 Microsoft의 플랫폼 및 서비스(Platform and Services) 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 Microsoft Tech•Ed 및 PDC를 비롯한 IT 및 개발자 회의의 단골 연설자이며 Microsoft에서 인수한 Winternals Software의 공동 설립자이기도 합니다. 그는 자신이 설립한 Sysinternals에서 Process Explorer, Filemon, Regmon 등 많이 사용되고 있는 여러 유틸리티를 개발하기도 했습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..