Ken

 Johnson,  Ma,  Miller  

Microso1  Security  Engineering  Center  (MSEC)  
 
 
Black  Hat  USA  2012  
 
 
 Acknowledgements  
Many  individuals  have  worked  very  hard  to  deliver  the  improvements  we  will  discuss  

Charles  Chen,  Greg  Colombo,  Jason  Garms,  Stephen  Hufnagel,  Arun  Kishan,  Joe  Laughlin,  Pavel  
Windows   Lebedynskiy,  John  Lin,  Gov  Maharaj,  Hari  Pulapaka,  Pierre-­‐Yves  Santerre,  Neeraj  Singh,  Evan  Tice,  
Valeriy  Tsuryk,  Suma  Uppuluri,  Landy  Wang,  Ma,hew  Woolman  

CLR/Silverlight   Reid  Borsuk,  Jesse  Collins,  Jeffrey  Cooperstein,  Nick  Kramer  

Jonathan  Caves,  Tanveer  Gani,  Mark  Hall,  Lawrence  Joel,  Louis  Lafreniere,  Mark  Levine,  Steve  
Visual  Studio   Lucco,  Mark  Roberts,  Andre  Vachon,  YongKang  Zhu  

Internet  Explorer   David  Fields,  Forbes  Higman,  Eric  Lawrence,  Zach  Murphy,  JusYn  Rogers  

MicrosoA  Research   Richard  Black,  Miguel  Castro,  Manuel  Costa,  Ben  Livshits,  Jay  Stokes,  Ben  Zorn  

MicrosoA  Security   Eugene  Bobukh,  Tim  Burrell,  Thomas  Garnier,  NiYn  Kumar  Goel,  Ken  Johnson,  John  Lambert,  Ma,  
Engineering  Center   Miller,  Dave  Probert,  Tony  Rice,  Richard  Shupak,  Julien  Vanegue,  Greg  Wroblewski  

2  
 Windows  8  Security  Overview  

The  development  of  Windows  8  followed  the     Windows  8  includes  new  protecYons  against  
Security  Development  Lifecycle  (SDL)    which   root  and  boot  kits.  UEFI  systems  prevent  
defines  best  pracYces  for  secure  so1ware   malware  from  starYng  before  Windows  and  
design,  implementaYon,  and  tesYng.   protects  the  remainder  of  the  boot  process,  
including  early  launch  anYmalware  so1ware.  

Windows  8  includes  numerous  security   Windows  Defender  is  shipped  with  every  
features,  such  as  miYgaYons,  that  make  it   ediYon  of  Windows  8  and  Internet  Explorer’s  
difficult  and  costly  for  malware  authors  to   ApplicaYon  reputaYon  features  have  been  
develop  reliable  exploits  for  vulnerabiliYes.     such  that  users  are  
moved  into  the  placorm  
protected  regardless  of  the  browser  they  use.    

3  
 Framing  the  problem  with  exploit  economics  
Use  sandboxing  to  
protect  user  privacy   Cheaply  find  
Find  and  eliminate  
&  data   vulnerabiliDes  (they  
vulnerability  classes  
only  need  one)  
A,ackers  want  to  
maximize  ROI  

Gains  per  use   Cost  to  acquire  vulnerability  

   
A,acker   -­‐  
=   X   +  
Return  
   
OpportuniYes  to  use   Cost  to  weaponize  

We  want  to  
minimize  ROI   Maximize  
Use  telemetry  
the   to   Break  cookbook  
window  
minimize  
of  Dme  
aJack  
for   Cheaply  develop  
techniques  &  make  
using  an  
window  
exploit   exploits  
exploits  unreliable  
Today  we  will  describe  exploit  miYgaYon  improvements  in  Windows  8  
that  increase  the  cost  of  developing  reliable  exploits  

4  
History  of  exploit  miYgaYons  on  Windows  
VOID Function(LPCSTR Input) {
Stack-­‐based     CHAR Buffer[256];
vulnerability   strcpy(Buffer, Input);
}

Stack-­‐based  exploitaYon  
and  miYgaYon    
techniques  
Linear  return   Linear  local   Linear   Linear     Non-­‐linear/backward  
address   variable   parameter   SEH  record   overwrites  
overwrite   overwrite   overwrite   overwrite   (e.g.  a[n]  =  0)  

GS  v1  
(2002)  

GS  v1.1   SafeSEH  
(2003)   (2003)  

GS  v2  
(2005)  
SEHOP  
(2008)  
GS  v3  
(2010)  

Control  of    
InstrucDon  Pointer  

5  
 History  of  exploit  miYgaYons  on  Windows  
VOID Function(LPCSTR Input) {
Heap-­‐based   PCHAR *Buffer = malloc(256);
vulnerability   strcpy(Buffer, Input);
}

Coalesce   LFH   ApplicaDon   Use-­‐aAer-­‐free/  

FreeList[]   Lookaside  list   Heap  cache  
unlink   FreeEntryOffset   specific  data   Double  free/  
aJacks   aJacks   aJacks  
overwrite   aJack   overwrites   Dangling  pointer  

Safe  
unlinking   Vista  heap  hardening  
(2006)  
(2004)  

Overwrite  or  
Heap-­‐based  exploitaYon   control  a  funcDon  
and  miYgaYon     pointer  
techniques  

Control  of    
InstrucDon  Pointer  

6  
 History  of  exploit  miYgaYons  on  Windows  
Control  of     eip=41414141 esp=0023f7dc ebp=0023f808…
cs=0023 ss=002b ds=002b es=002b fs=…
InstrucDon  Pointer  
41414141 ?? ???

Execute  code    
Execute  code   Execute  JIT’d  code  
from  heap     Execute  code  from  a  loaded  image  
from  stack   (JIT  spray)  
(incl.  heap  spray)  

DEP  
(2004)  

IE9  JS  JIT   Return  oriented  

Return-­‐into-­‐libc  
programming  
miDgaDons   (many  variants)  
(ROP)  
(2011)  

ASLR  
(2006)  

Predictable  
ExecuYng  arbitrary  code  
mappings/info  leaks  
a1er  gaining  control  of  EIP  

Arbitrary  code  
execuDon  
7  
 The  state  of  memory  safety  exploits  
• About  6%  of  MSRT  detecYons  were  likely  caused  by  exploits  [29]  
Most  systems  are  not  
• Updates  were  available  for  more  than  a  year  for  most  of  the  exploited  
compromised  by  exploits   issues  [29]  

Most  exploits  target  third   • 11  of  13  CVEs  targeted  by  popular  exploit  kits  in  2011  were  for  issues  in  
party  applicaYons   non-­‐Microso1  applicaYons  [27]  

Most  exploits  target  older   • Only  5%  of  184  sampled  exploits  succeeded  on  Windows  7  [28]  
versions  of  Windows  (e.g.  XP)   • ASLR  and  other  miYgaYons  in  Windows  7  make  exploitaYon  costly  [30]  

Most  exploits  fail  when   • 14  of  19  exploits  from  popular  exploit  kits  fail  with  DEP  enabled  [27]  
miYgaYons  are  enabled   • 89%  of  184  sampled  exploits  failed  with  EMET  enabled  on  XP  [28]  

Exploits  that  bypass  

• Zero-­‐day  issues  were  exploited  in  sophisYcated  a,acks  (Stuxnet,  Duqu)  
miYgaYons  &  target  the  latest   • Exploits  were  wri,en  for  Chrome  and  IE9  for  Pwn2Own  2012  
products  do  exist  

Bo,om  line:  we  must  conYnue  to  increase  the  cost  of  exploitaYon  for  a,ackers  
8  
 ObjecYves  &  focus  areas  in  Windows  8  
ObjecDves  
  Code  GeneraYon  Security  
MiYgate  enYre  
classes  of  
vulnerabiliYes   Address  Space  Layout  RandomizaYon  
 
Break  known  
exploitaYon   Windows  Heap  
techniques  
 
Increase     Windows  Kernel  
the  cost  of  
exploitaYon  in  
key  domains   Default  Setngs  

9  
Enhanced  /GS,  range  checks,  sealed  opYmizaYon,  and  virtual  table  guard  

CODE  GENERATION    

10  
 Enhanced  /GS  
• Enhanced  GS  stack  buffer  overrun  protecYon  
– Released  with  Visual  Studio  2010  [1]  
– Windows  8  is  built  with  this  enabled  

• GS  heurisYcs  now  protect  more  funcYons  

– Non-­‐pointer  arrays  and  POD  structures  

• GS  opYmizaYon  removes  unnecessary  checks  

– Safety  proof  means  no  check  is  needed  

• Closes  gaps  in  protecYon  

– MS04-­‐035,  MS06-­‐054,  MS07-­‐017  (ANI)  

11  
 Range  Checks  
• Compiler-­‐inserted  array  bounds  check  (via  /GS)  
CHAR Buffer[256];
UINT i; // possibly attacker controlled

if (i >= ARRAYSIZE(Buffer)) {  compiler inserted

__report_rangecheckfailure();
}

Buffer[i] = 0;

• Completely  miYgates  certain  vulnerabiliYes  

– CVE-­‐2009-­‐2512,  CVE-­‐2010-­‐2555  
• Bounds  check  inserYon  is  limited  to  specific  scenarios  
– Assignment  of  NUL  to  a  fixed-­‐size  stack/global  array  

12  
 Sealed  opYmizaYon  
• OpYmizaYon  for  “sealed”  C++  types  &  methods  

• Virtual  method  calls  become  direct  calls  

Without  sealed   COptionElement *optionElement; With  sealed  
optionElement->IsEnabled();

mov rax,qword ptr [rcx]

call CElement::IsEnabled
call qword ptr [rax+920h]

• EliminaYng  indirect  calls  reduces  exploitaYon  a,ack  surface  

– Helps  miYgate  vulnerabiliYes  like  CVE-­‐2011-­‐1996  
– Devirtualized  ~4,500  calls  in  mshtml.dll  and  ~13,000  in  mso.dll  

13  
 Virtual  Table  Guard  
ProbabilisYc  miYgaYon  for  vulnerabiliYes  that  enable  vtable  ptr  corrupYon  

IE10  has  enabled  

this  for  a  handful  of  
Enabled  by  adding  an  annotaYon  to  a  C+
key  classes  in     +  class  
mshtml.dll  

mshtml!CElement::Doc:
CElement::`vftable’ 63700e70 mov eax,dword ptr [ecx]
VirtualMethod1 63700e72 cmp [eax+1B8h],offset mshtml!_vtguard
63700e7c jne mshtml!CElement::Doc+0x18 (63700e88)
VirtualMethod2
63700e7e call dword ptr [eax+0ACh]
VirtualMethod3 63700e84 mov eax,dword ptr [eax+0Ch]
VirtualMethod4 63700e87 ret
… 63700e88 call mshtml!__report_gsfailure
_vtguard

Extra  entry  added  to  vtable.     Check  added  at  virtual  method  call  sites.    
ASLR  makes  this  entry’s  value   If  vtable[vtguard_vte]  !=  vtguard    
unknown  to  the  aJacker.   then  terminate  the  process.  

14  
Force  ASLR,  bo,om-­‐up/top-­‐down  randomizaYon,  and  high  entropy  

ADDRESS  SPACE  LAYOUT  

RANDOMIZATION  

15  
 RetrospecYve:  ASLR  
• ASLR  was  first  introduced  in  Windows  Vista  
– Led  to  a  big  shi1  in  a,acker  mentality  
 
• A,ackers  now  depend  on  gaps  in  ASLR  
– EXEs/DLLs  not  linked  with  /DYNAMICBASE  [2]  
– Address  space  spraying  (heap/JIT)  [3]  
– Predictable  memory  regions  [4]  
– InformaYon  disclosures  [5]  

• ASLR  has  been  substanYally  improved  in  Windows  8  

16  
 Force  ASLR  
• Many  exploits  depend  on  non-­‐ASLR  DLLs  
0:000> !dh dirapi
...
4B4C111C time date stamp Mon Jan 11 22:05:16 2010
...
1000 base of code
----- new ----- Images  are  not    
68000000 image base
1000 section alignment randomized  unless  the    
...
00001000 size of heap commit DYNAMIC_BASE  bit  is  set  
0 DLL characteristics
187A80 [ 402F] address [size] of Export Directory
1869F4 [ C8] address [size] of Import Directory
19B000 [ 12178] address [size] of Resource Directory

• Processes  can  now  force  non-­‐ASLR  images  to  be  randomized  

– Behaves  as  if  an  image’s  preferred  base  is  not  available  
– Bo,om-­‐up  randomizaYon  provides  entropy  for  these  images  
• Processes  must  opt-­‐in  to  receive  this  behavior  
– Also  supported  on  Windows  7  with  KB2639308  installed  
Outcome:  a,ackers  can  no  longer  rely  on  non-­‐ASLR  images  
17  
Bo,om-­‐up  &  top-­‐down  randomizaYon  
Top-­‐down  allocaYons   Windows  7  
(PEBs,  TEBs,  MEM_TOP_DOWN)  
• Heaps  and  stacks  are  randomized  
• PEBs/TEBs  are  randomized,  but  with  limited  entropy  
• VirtualAlloc  and  MapViewOfFile  are  not  randomized  
• Predictable  memory  regions  can  exist  as  a  result  

Address  space  

Windows  8  
• All  bo,om-­‐up/top-­‐down  allocaYons  are  randomized  
• Accomplished  by  biasing  start  address  of  allocaYons  
Bo,om-­‐up  allocaYons   • PEBs/TEBs  now  receive  much  more  entropy  
(stacks,  heaps,  mapped  files,  VirtualAlloc,  etc)  
• Both  are  opt-­‐in  (EXE  must  be  dynamicbase)  

Outcome:  predictable  memory  regions  have  been  eliminated  

18  
 High  entropy  ASLR  for  64-­‐bit  processes  
ASLR  in  Windows  8  takes  advantage  of  the  large  address  space  (8TB)  of  64-­‐bit  processes    

High  entropy   • 1  TB  of  variance  in  bo,om-­‐up  start  address  

bo,om-­‐up   • Breaks  tradiYonal  address  space  spraying  (heap/JIT)  
randomizaYon   • Processes  must  opt-­‐in  to  receive  this  behavior    

High  entropy  
• 8  GB  of  variance  in  top-­‐down  start  address  
top-­‐down   • AutomaYcally  enabled  if  top-­‐down  randomizaYon  is  on  
randomizaYon  

High  entropy  
• Images  based  above  4  GB  receive  more  entropy  
image   • All  system  images  have  been  moved  above  4  GB  
randomizaYon  
Outcome:  probability  of  guessing  an  address  is  decreased  and  
disclosures  of  memory  addresses  must  include  more  than  the  low  32  bits  
19  
 ASLR  entropy  improvements  
  Windows  7   Windows  8  
Entropy  (in  bits)  by  region  
32-­‐bit   64-­‐bit   32-­‐bit   64-­‐bit   64-­‐bit  
(HE)  
Bo,om-­‐up  allocaYons  (opt-­‐in)   0   0   8   8   24  
Stacks   14   14   17   17   33  
Heaps   5   5   8   8   24  
Top-­‐down  allocaYons  (opt-­‐in)   0   0   8   17   17  
PEBs/TEBs   4   4   8   17   17  
EXE  images   8   8   8   17*   17*  
DLL  images   8   8   8   19*   19*  
Non-­‐ASLR  DLL  images  (opt-­‐in)   0   0   8   8   24  

*  64-­‐bit  DLLs  based  below   ASLR  entropy  is  the  same  for  both     64-­‐bit  processes  receive  much  more  
4GB  receive  14  bits,  EXEs   32-­‐bit  and  64-­‐bit  processes     entropy  on  Windows  8,  especially  with  
below  4GB  receive  8  bits   on  Windows  7   high  entropy  (HE)  enabled    

20  
 Removal  of  informaYon  disclosure  vectors  

• InformaYon  disclosures  can  be  used  to  bypass  ASLR  

 
• Disclosure  via  an  arbitrary  read  is  now  less  reliable  
– Predictable  mappings  have  been  eliminated  

• SharedUserData  is  sYll  predictable,  but  less  useful  

– Image  pointers  have  been  removed,  breaking  known  techniques  [4,6]  
0:000> u ntdll!NtWriteVirtualMemory L6
ntdll!NtWriteVirtualMemory:
6a214724 b802000000 mov eax,2
6a214729 e803000000 call ntdll!NtWriteVirtualMemory+0xd
(6a214731)
6a21472e c21400 ret 14h
6a214731 8bd4 mov edx,esp
6a214733 0f34 sysenter
6a214735 c3 ret
0:000> dd 7ffe0300 L1
7ffe0300 00000000 21  
Integrity  checks,  guard  pages,  and  allocaYon  order  randomizaYon  

WINDOWS  HEAP  

22  
 RetrospecYve:  Windows  Heap  
• Windows  Vista  heap  hardening  was  very  effecYve  [11]  
– Only  one  documented  exploit  that  corrupts  metadata  [9]  

• New  a,acks  have  been  proposed  by  researchers  

– CorrupYng  the  HEAP  data  structure  [7]  
– LFH  bucket  overwrite  [7]  
– LFH  FreeEntryOffset  corrupYon  and  depth  desync  [8,12]  

• Real-­‐world  exploits  target  app  data  on  the  heap  [10]  

– No  heap  safeguards  exist  today  for  this  
23  
 Windows  8  heap  architecture  
The  general  design  of  the  Windows  heap  is  unchanged  in  Windows  8  

HeapAlloc(heap, flags, size)

 
Frontend  allocator  (LFH)  
 
Used  for  sizes  <  16KB  
   
Backend  allocator  
 
Used  by  frontend  and  for  sizes  less  than  512K  (x86)  or  1MB  (x64)  
 
 
Virtual  memory  allocator  
 
Used  by  backend  and  for  large  allocaYon  sizes  
 
Kernel  memory  manager  
24  
LFH  design  changes  &  integrity  checks  
Change  in  Windows  8   Impact  
LFH  is  now  a  bitmap-­‐based  allocator   LinkOffset  corrupYon  no  longer  possible  [8]  
MulYple  catch-­‐all  EH  blocks  removed   ExcepYons  are  no  longer  swallowed  
Prevents  a,acks  that  try  to  corrupt  HEAP  
HEAP  handle  can  no  longer  be  freed  
handle  state  [7]  
Prevents  a,acks  that  enable  reliable  control  
HEAP  CommitRouYne  encoded  with  global  key  
of  the  CommitRouYne  pointer  [7]  
Prevents  unintended  free  of  in-­‐use  heap  
ValidaYon  of  extended  block  header  
blocks    [7]  
Prevents  various  a,acks  that  reallocate  an  
Busy  blocks  cannot  be  allocated  
in-­‐use  block  [8,11]  
Heap  encoding  is  now  enabled  in  kernel  mode   Be,er  protecYon  of  heap  entry  headers  [19]  

Outcome:  a,acking  metadata  used  by  the  heap  is  now  even  more  difficult  

25  
 Guard  pages  
• Guard  pages  are  now  used  to  parYYon  the  heap  
– Designed  to  prevent  &  localize  corrupYon  in  some  cases  
– Touching  a  guard  page  results  in  an  excepYon  
 
  …   Heap  memory   PAGE_NOACCESS  
Guard  page   Heap  memory   …  

• InserYon  points  for  guard  pages  are  constrained  

– Large  allocaYons  
– Heap  segments  
– Max-­‐sized  LFH  subsegments  (probabilisYc  on  32-­‐bit)  

26  
 AllocaYon  order  randomizaYon  
• AllocaYon  order  is  now  nondeterminisYc  (LFH  only)  
– Exploits  o1en  rely  on  surgical  heap  layout  manipulaYon  [10]  
– RandomizaYon  makes  heap  normalizaYon  unreliable  
Windows  7  LFH  block  allocaYon  behavior  
  O   T  

Windows  8  LFH  block  allocaYon  behavior  

T   O  

• Maximizing  reliability  is  more  challenging  

– ApplicaYon-­‐specific  and  vulnerability-­‐specific  
– May  require  corrupYng  more  data  (increasing  instability)  
– May  require  allocaYng  more  data  (triggering  guard  pages)  

27  
DEP,  ASLR,  SMEP/PXN,  NULL  dereference  protecYon,  and  pool  integrity  
checks  

WINDOWS  KERNEL  

28  
 RetrospecYve:  Windows  Kernel  
• Kernel  vulnerabiliYes  have  been  less  targeted  
– RelaYvely  few  remote  kernel  exploits  exist  
– User  mode  exploitaYon  is  be,er  researched  

• A,ack  focus  is  shi1ing  more  toward  the  kernel  

– Interest  in  sandbox  escapes  is  increasing  
– Local  kernel  exploitaYon  techniques  well-­‐understood  
– New  kernel  pool  a,acks  have  been  proposed  [13]  
– SophisYcated  remote  kernel  exploits  exist  [14,21]  

29  
 DEP  is  broadly  enabled  in  the  Windows  8  kernel  
Many  kernel  memory  regions  were  unnecessarily  executable  in  Windows  7  and  prior  
x86  (PAE)   x64   ARM  
Win7   Win8   Win7   Win8   Win8  
Paged  pool   X   X   NX   NX   NX   Windows  8  introduces  
NonPagedPoolNx  for  
Non-­‐paged  pool   X   X   X   X   X   non-­‐executable  non-­‐
Non-­‐paged  pool  (NX)   N/A   NX   N/A   NX   NX   paged  pool  allocaDons  
(default  on  ARM)  
Session  pool   X   X   NX   NX   NX  
Image  data  secYons   X   X   NX   NX   NX  
Kernel  stacks   NX   NX   NX   NX   NX  
Idle/DPC/IniYal  stacks   X   NX   X   NX   NX  
Page  table  pages   X   NX   X   NX   NX  
PFN  database   X   NX   X   NX   NX   NX  HAL  heap  and  
System  cache   X   NX   X   NX   NX   NonPagedPoolNx  break  
the  assumpDons  of  
Shared  user  data   X   NX   X   NX   NX   exploits  for  MS09-­‐050  
HAL  heap   X   NX   X   NX   NX  
X  =  executable      NX  =  non-­‐executable   30  
 Kernel  ASLR  improvements  
• Kernel  ASLR  was  first  added  in  Server  2008  RTM  
– 4  bits  of  entropy  for  drivers,  5  bits  for  NTOS/HAL  
– Driver  entropy  was  improved  in  Windows  7  

• Entropy  has  been  further  improved  in  Windows  8  

– Biasing  of  kernel  segment  base  
– NTOS/HAL  receive  22  bits  (64-­‐bit)  and  12  bits  (32-­‐bit)  
– Various  boot  regions  also  randomized  (P0  idle  stack)  

31  
 Support  for  SMEP/PXN  
• New  processor  security  feature  
– Prevents  supervisor  from  execuYng  code  in  user  
pages  
– Most  exploits  for  local  kernel  EOPs  rely  on  this  today  
– Requires  Intel  Ivy  Bridge  or  ARM  with  PXN  support  

• SMEP/PXN  +  DEP  make  exploitaYon  more  difficult  

– Strong  miYgaYon  for  some  issues  (CVE-­‐2010-­‐2743  from  Stuxnet)  
– A,ackers  need  to  leverage  code  in  kernel  images  [15]  

32  
 NULL  dereference  protecYon  
• Kernel  NULL  dereferences  are  a  common  issue  
– Examples  include  MS08-­‐025,  MS08-­‐061,  MS09-­‐001  

• Local  exploitaYon  is  generally  straighcorward  

– NULL  is  part  of  the  user  mode  address  space  
– Kernel  currently  allows  user  processes  to  map  NULL  page  

• Windows  8  prohibits  mapping  of  the  first  64K  

– All  kernel  NULL  dereferences  become  a  DoS  (not  EoP)  
– NTVDM  has  been  disabled  by  default  as  well  
– Enabling  NTVDM  will  disable  NULL  dereference  protecYon  

33  
 Kernel  pool  integrity  checks  
• The  kernel  pool  allocator  is  similar  to  the  heap  
– ImplementaYon  is  very  different,  though  

• New  integrity  checks  block  various  a,acks  [13]  

– Process  quota  pointer  encoding  
– Lookaside,  delay  free,  and  pool  page  cookies  
– PoolIndex  bounds  check  
– AddiYonal  safe  unlinking  checks  

34  
 Other  improvements  
• Safe  unlinking  has  been  enabled  globally  
– Previously  only  used  in  the  heap  and  kernel  pool  
– Now  applies  to  all  usage  of  LIST_ENTRY,  closing  known  gaps  [16]  
– New  “FastFail”  mechanism  enables  rapid  &  safe  process  terminaYon  

• Improved  entropy  for  GS  and  ASLR  

– Use  of  PRNG  seeded  by  TPM/RDRAND/other  sources  
– Hardcoded  GS  iniYalizaYon  is  overridden  by  the  OS  
– Addresses  weaknesses  described  in  a,ack  research  [17,18]  

• Object  manager  hardened  against  reference  count  overflows    

• Resolved  kernel  informaYon  disclosure  via  certain  system  calls  [22]  

35  
ARM,  Inbox,  Windows  8  style  apps,  IE  10,  the  new  Office,  and  other  applicaYons  

DEFAULT  SETTINGS  

36  
 ARM  default  setngs  
All  applicable  miYgaYons  are  enabled  on  ARM  
DEP   On   ARM  PE  images  
ASLR  (images)   On   must  opt-­‐in  to    
DEP  and  ASLR  
ASLR  (force  relocate)   N/A  (all  images  are  ASLR)    
ASLR  (bo,om-­‐up)   On   Kernel  will  fail  
to  load  images  
ASLR  (top-­‐down)   On  
that  do  not  
ASLR  (high  entropy)   N/A  (not  64-­‐bit)  
SEHOP   N/A  (not  needed)  
Heap  terminaYon   On  
Kernel  NULL  dereference     On  
Kernel  SMEP   On  

Lack  of  applicaYon  compaYbility  concerns  enables  us  to  be  more  aggressive  

37  
 ApplicaYon  default  setngs  
All  applicable  miYgaYons  are  enabled  for  Windows  8  UI  style  apps  
32  bit  (x86)   64  bit  (x64)  
Default  setngs  for    
Windows  8  client     Win8  UI   Inbox   IE10   Default   Win8  UI   Inbox   IE10   Default  
apps   apps  
DEP   On   On   On   OptIn   On   On   On   OptIn  
ASLR  (images)   On   On   On   OptIn   On   On   On   OptIn  
ASLR  (force  relocate)   On   OptIn   On   OptIn   On   OptIn   On   OptIn  
ASLR  (bo,om-­‐up)   On   On   On   OptIn   On   On   On   OptIn  
ASLR  (top-­‐down)   On   On   On   OptIn   On   On   On   OptIn  
ASLR  (high  entropy)   N/A   N/A   N/A   N/A   On   On   On   OptIn  
SEHOP   On   On   On   OptIn   N/A   N/A   N/A   N/A  
Heap  terminaYon   On   On   On   OptIn   On   On   On   On  

Internet  Explorer  10  and  the  new  Office  also  enable  all  applicable  miYgaYons  
38  
 Enabling  opt-­‐in  miYgaYons  
Opt-­‐in  methods  
• “MiYgaYonOpYons”  Image  File  ExecuYon  OpYon  (IFEO)  
• Process  creaYon  a,ribute  (via  UpdateProcThreadA,ribute)  
• SetProcessMiYgaYonPolicy  API  
• Linker  flag  

Opt-­‐in  miDgaDon   IFEO   Proc  AJr   API   Linker  flag  

Bo,om-­‐up  randomizaYon   Yes   Yes   No   /DYNAMICBASE  (on  EXE)  
Top-­‐down  randomizaYon   No   No   No   /DYNAMICBASE  (on  EXE)  
Bo,om-­‐up  randomizaYon     Yes   Yes   No   /HIGHENTROPYVA  (on  EXE)  
(high  entropy)  
ASLR   No   No   No   /DYNAMICBASE  
Force  ASLR   Yes   Yes   Yes   None  
DEP   Yes   Yes   Yes   /NXCOMPAT  (on  EXE)  
SEHOP   Yes   Yes   No   None*  
Heap  terminaYon   Yes   Yes   Yes   None*  
*  EXEs  with  a  subsystem  version  >=  6.2  will  automaYcally  enable  these  miYgaYons  
39  
ExpectaYons  for  exploits  on  Windows  8  
• WriYng  exploits  for  Windows  8  will  be  very  costly  
– Some  vulnerability  classes  are  now  enYrely  miYgated  
– Many  a,ack  techniques  are  now  broken  or  unreliable  

• A,ackers  will  likely  focus  their  a,enYon  on  

– Desktop  apps  that  do  not  enable  all  applicable  miYgaYons  
– Desktop  apps  running  on  previous  versions  of  Windows  
– Refining  methods  of  disclosing  address  space  informaYon  
– Researching  new  exploitaYon  techniques  [20]  

• We  will  conYnue  to  evolve  our  miYgaYon  technologies  

40  
 Call  to  acYon  
• Upgrade  to  Windows  8  and  IE  10  J  
– 64-­‐bit  is  best  from  a  miYgaYons  perspecYve  
– Enable  “Enhanced  Protected  Mode”  for  IE  10  

• So1ware  vendors  
– Build  your  applicaYons  with  Visual  Studio  2012  [31]  
– Enable  new  opt-­‐in  miYgaYons  

• Driver  writers  
– Port  your  drivers  to  use  NonPagedPoolNx  

41  
 Contact  us  at  [email protected]  

Were  you  fascinated  by  the  topics  discussed  in  this  presentaYon?  
 
We  are  hiring.  
 
h,p://www.microso1-­‐careers.com/go/Trustworthy-­‐CompuYng-­‐Jobs/194701/  
 

42  
43  
 References  
1. Enhanced  GS  in  Visual  Studio  2010.    Tim  Burrell.    March,  2009.  
h,p://blogs.technet.com/b/srd/archive/2009/03/20/enhanced-­‐gs-­‐in-­‐visual-­‐studio-­‐2010.aspx  
2. Adobe  CoolType  SING  Table  “uniqueName”  Stack  Buffer  Overflow  Exploit.    Metasploit.    Sep,  2010.    
h,p://dev.metasploit.com/redmine/projects/framework/repository/revisions/master/entry/modules/exploits/windows/
browser/adobe_cooltype_sing.rb  
3. Interpreter  ExploitaYon:  Pointer  Inference  and  JIT  Spraying.    Dionysus  Blazakis.    Black  Hat  Federal,  2010.    
h,p://www.semanYscope.com/research/BHDC2010/BHDC-­‐2010-­‐Paper.pdf  
4. Defeat  Windows  7  Browser  Memory  ProtecYon.    XiaBo  Chen,  Jun  Xie.    XCon  2010.      
5. Memory  Retrieval  VulnerabiliYes.    Derek  Soeder.    2006.  
h,p://www.eeye.com/eEyeDigitalSecurity/media/ResearchPapers/eeyeMRV-­‐Oct2006.pdf  
6. Win32  ASLR  round  2.    JusYn  Ferguson,    March,  2010.  h,p://nietmenja.blogspot.com/2010/03/win32-­‐aslr-­‐round-­‐2.html  
7. A,acking  the  Vista  Heap.    Ben  Hawkes.    Nov,  2008.  
h,p://www.lateralsecurity.com/downloads/hawkes_ruxcon-­‐nov-­‐2008.pdf  
8. Understanding  the  Low  FragmentaYon  Heap.    Chris  Valasek.    July,  2010.  
h,p://illmaYcs.com/Understanding_the_LFH_Slides.pdf.  
9. Modern  Heap  ExploitaYon  using  the  Low  FragmentaYon  Heap.    Chris  Valasek.    2011.  
10. Heap  Feng  Shui  in  JavaScript.    Alex  SoYrov.    2007.  h,p://www.phreedom.org/research/heap-­‐feng-­‐shui/heap-­‐feng-­‐shui.html  
11. PrevenYng  the  exploitaYon  of  user  mode  heap  corrupYon  vulnerabiliYes.    Ma,  Miller.  2009.  
h,p://blogs.technet.com/b/srd/archive/2009/08/04/prevenYng-­‐the-­‐exploitaYon-­‐of-­‐user-­‐mode-­‐heap-­‐corrupYon-­‐
vulnerabiliYes.aspx  
12. Ghost  in  the  Windows  7  Allocator.    Steven  Seeley,  2012.  
h,p://conference.hitb.org/hitbsecconf2012ams/materials/D2T2%20-­‐%20Steven%20Seeley%20-­‐%20Ghost%20In%20the
%20Windows%207%20Allocator.pdf  

44  
 References  
13. Kernel  Pool  ExploitaYon  on  Windows  7.    Tarjei  Mandt.    Black  Hat  DC,  2011.  
h,ps://media.blackhat.com/bh-­‐dc-­‐11/Mandt/BlackHat_DC_2011_Mandt_kernelpool-­‐wp.pdf.  
14. 351  packets  from  trampoline.    Piotr  Bania.    October,  2009.  
h,p://blog.piotrbania.com/2009/10/351-­‐packets-­‐from-­‐trampoline.html.  
15. SMEP:  What  is  it,  and  how  to  beat  it  on  Windows.    Mateusz  Jurczyk,  Gynvael  Coldwind.    June,  2011.  
h,p://j00ru.vexillium.org/?p=783.  
16. VEH.    Ben  Hawkes.    2011.  h,p://sota.gen.nz/veh/.  
17. Windows  Kernel-­‐mode  GS  Cookies  and  1  bit  of  entropy.    Mateusz  Jurczyk,  Gynvael  Coldwind.    January,  2011.  
h,p://j00ru.vexillium.org/?p=690.  
18. Reducing  the  effecYve  entropy  of  GS  cookies.    Skape.    May,  2007.  h,p://www.uninformed.org/?v=7&a=2&t=sumry.  
19. Kernel  A,acks  through  User-­‐Mode  Callbacks.    Tarjei  Mandt.    Black  Hat  USA,  2011.  
h,p://mista.nu/research/mandt-­‐win32k-­‐slides.pdf.  
20. Windows  8  Heap  Internals.    Chris  Valasek  and  Tarjei  Mandt.    Black  Hat  USA,  2012.  
21. More  informaYon  on  MS11-­‐087.    Chengyun  Chu,  Jonathan  Ness.    December,  2011.  
h,p://blogs.technet.com/b/srd/archive/2011/12/13/more-­‐informaYon-­‐on-­‐ms11-­‐087.aspx.  
22. Subtle  informaYon  disclosure  in  win32k.sys  syscall  return  values.    Mateusz  Jurczyk.    May,  2011.  
h,p://j00ru.vexillium.org/?p=762.  

45  
 References  
26. On  the  effecYveness  of  DEP  and  ASLR.    Microso1.    December,  2010.  
h,p://blogs.technet.com/b/srd/archive/2010/12/08/on-­‐the-­‐effecYveness-­‐of-­‐dep-­‐and-­‐aslr.aspx.  
27. The  Exploit  Intelligence  Project  v2.    Dan  Guido.    December,  2011.  h,p://vimeo.com/31548167.  
28. Microso1  Security  Intelligence  Report  (SIR):  Volume  12.    Microso1.    April,  2012.  
h,p://www.microso1.com/en-­‐us/download/details.aspx?id=29569.  
29. Microso1  Security  Intelligence  Report  (SIR):  Volume  11.    Microso1.    October,  2011.  
h,p://www.microso1.com/en-­‐us/download/details.aspx?id=27605.  
30. MiYgaYng  So1ware  VulnerabiliYes.    Microso1.    July,  2011.  
h,p://www.microso1.com/en-­‐us/download/details.aspx?id=26788.  
31. Compiler  Security  Enhancements  in  Visual  Studio  11.    Tim  Burrell.    December,  2011.  
h,p://blogs.msdn.com/b/sdl/archive/2011/12/02/security.aspx.  

46