Message-ID: <CA+YQQ6UxXHA18=oJV2NqiLTU-CRvM5keg9qsy=uYKFgo9Ok7Ng@mail.gmail.com>
Date: Wed, 21 May 2014 11:57:31 -0700
From: Tavis Ormandy <taviso@...xchg8b.com>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: [FD] NULL page mitigations on Windows 8 x86

Apparently I'm being lured into pointless discussions today, so here's another.

As I'm sure everyone is aware, Microsoft introduced basic NULL page
mitigations for Windows 8 (both x86 and x64), and even backported the
mitigation to Vista+ (On x64 only). There are some weaknesses, but
this is a topic for another time.

Interestingly, on Windows 8 x86, there is an intentional exception, if
an Administrator has installed the 16bit subsystem the mitigation is
worthless because you can run your exploit in the context of NTVDM
(simply use the technique I documented in CVE-2010-0232
http://www.exploit-db.com/exploits/11199/).

An Administrator can do this either on-demand by running an 16bit program, e.g.

C:\> debug

Or using fondue to install it manually:

C:\> fondue /enable-feature:ntvdm /hide-ux:all

Let's look at an example of a NULL dereference. It's obvious from the
code that win32k!GreSetPaletteEntries doesn't validate the MDCOBJA
call succeeds in the HDC list traversal, resulting in a very clean
NULL dereference.

.text:001EAF49                 lea     esi, [ebp+var_2C]            ;
out pointer
.text:001EAF4C                 call    ??0MDCOBJA@@QAE@...HDC__@@@Z ;
MDCOBJA::MDCOBJA(HDC__ *)
.text:001EAF51                 push    1
.text:001EAF53                 mov     edx, edi
.text:001EAF55                 call    _GreGetObjectOwner@8 ;
GreGetObjectOwner(x,x)
.text:001EAF5A                 mov     esi, eax
.text:001EAF5C                 call
ds:__imp__PsGetCurrentProcessId@0 ; PsGetCurrentProcessId()
.text:001EAF62                 and     eax, 0FFFFFFFCh
.text:001EAF65                 cmp     esi, eax
.text:001EAF67                 jnz     short loc_1EAFBA
.text:001EAF69                 and     [ebp+ms_exc.registration.TryLevel], 0
.text:001EAF6D                 mov     eax, [ebp+var_2C]            ;
load pointer
.text:001EAF70                 mov     ecx, [eax+38h]               ;
NULL dereference
.text:001EAF73                 mov     eax, [ecx+4]

Callers like GreIsRendering, GreSetDCOrg, GreGetBounds, etc, etc check
correctly for comparison. This better code is from win32k!GreSetDCOrg:

.text:00213DA2                 lea     esi, [ebp+var_C]             ;
out pointer
.text:00213DA5                 xor     ebx, ebx
.text:00213DA7                 call    ??0MDCOBJA@@QAE@...HDC__@@@Z ;
MDCOBJA::MDCOBJA(HDC__ *)
.text:00213DAC                 mov     edi, [ebp+var_C]             ;
load result
.text:00213DAF                 test    edi, edi                     ;
check for NULL
.text:00213DB1                 jz      short loc_213E15             ; error

This bug can be triggered with typical resource exhaustion patterns
(see my exploit for CVE-2013-3660 for reference
http://www.exploit-db.com/exploits/25912/). However, I have also
stumbled onto a Windows 8 specific technique that does not require
resource exhaustion, using the (undocumented) Xferable object flag.
See the attached code (the testcase is Windows 8+ on x86 specific,
although the bug affects other versions and platforms).

This seems exploitable on 32bit systems prior to Windows 8, but on
Windows 8 it's only exploitable (ignoring mitigation failures) with
NTVDM configured.

It's my understanding that Microsoft no longer consider this a
supported configuration, and are only interested in fixing NULL page
mitigation bypasses.

I'm not convinced this is a reasonable stance, what do other people think?

Tavis.

P.S. I think linux introduced it's mmap_min_addr mitigation to stable
around 2007? Seven years lag, I guess that's the power of the SDL ;-)
-- 
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------

View attachment "SetPalette.c" of type "text/x-csrc" (1902 bytes)


_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists