Withsecure — Investor Presentation

73 slides from Withsecure's investor presentation

Slide 1: Polishing Chrome for Fun and Profit
Public EXTERNAL Polishing Chrome for Fun and Profit Nils & Jon 29/08/2013 Labs.mwrinfosecurity.com | © MWR Labs 1 Labs.mwrinfosecurity.com | © MWR Labs
Slide 2: Agenda Introduction Google Chrome
Public EXTERNAL Agenda • Introduction • Google Chrome • Pwn2Own Vulnerabilities • Demo Labs.mwrinfosecurity.com | © MWR Labs 2
Slide 3: Introduction Nils Jon
Public EXTERNAL Introduction Nils Jon • Head of Research • Security Researcher and Senior • MWR since 2009 Consultant • Previous research • Previous research • Android • Reverse engineering • Payment terminals • Exploitation Labs.mwrinfosecurity.com | © MWR Labs 3
Slide 5: • Widely considered to be the most secure web browser available • Designed from
Public EXTERNAL Google Chrome • Widely considered to be the most secure web browser available • Designed from the ground up with security in mind • Lots of security work ongoing – Code reviews – Fuzzing (own code & 3rd party) Labs.mwrinfosecurity.com | © MWR Labs 5
Slide 6: Google Chrome – Renderer • Used to use WebKit – Fast, but patchy code
Public EXTERNAL Google Chrome – Renderer • Used to use WebKit – Fast, but patchy code base – Multiple authors, varying code quality – Since forked by Google and renamed to Blink • Deals directly with attacker controlled, untrusted input – Popular entry point for previously disclosed browser bugs Lab
Slide 7: Google Chrome – Sandbox Protections • “High-risk” renderer component sandboxed – Restricted Windows security
Public EXTERNAL Google Chrome – Sandbox Protections • “High-risk” renderer component sandboxed – Restricted Windows security token – Runs under restrictive job object – Windows on alternate desktop – Renderers run as “untrusted” IL (Vista and later) • Communicates with sensitive broker process via I
Slide 8: Google Chrome – Sandbox Protections • Restricted renderer processes cannot perform all required actions
Public EXTERNAL Google Chrome – Sandbox Protections • Restricted renderer processes cannot perform all required actions • Privileged actions carried out by the browser process • Renderer requests are evaluated against a policy • If granted, browser performs the privileged action Labs.mwrinfosecurity
Slide 9: Google Chrome – Hypothetical Sandbox Bypass • At least two vulnerabilities required to gain
Public EXTERNAL Google Chrome – Hypothetical Sandbox Bypass • At least two vulnerabilities required to gain privileged code execution – One in the unprivileged renderer / plugin process • Large attack surface, deals directly with untrusted input – One to break out of the sandbox • Much more limited
Slide 11: • Conducted source code review – Bug found approximately 6 weeks after starting –
Public EXTERNAL WebKit • Conducted source code review – Bug found approximately 6 weeks after starting – Mostly gaining familiarity with a new, large codebase • Specifically looking at interaction between complex features – May lead to type confusion bugs Labs.mwrinfosecurity.com | © MWR Labs 11
Slide 12: • Class of vulnerability involving invalid casts of objects • Object of one class
Public EXTERNAL Type Confusion Vulnerabilities • Class of vulnerability involving invalid casts of objects • Object of one class is created, and cast to a different class • Layout of the two classes differs, results in undefined behaviour – Usually results in code execution • C++ casts handled using
Slide 13: • const_cast – Toggles the “const” property for a class, no cast • static_cast
Public EXTERNAL Explicit Type Casting • const_cast – Toggles the “const” property for a class, no cast • static_cast – Casts an object to it’s base or derived class • dynamic_cast – Casts a base class to one of it’s derived classes – Operates on pointers or references to objects – Requires RTTI Labs
Slide 14: • reinterpret_cast – Casts anything to anything! – E.g. Interpret an array of chars
Public EXTERNAL Explicit Type Casting • reinterpret_cast – Casts anything to anything! – E.g. Interpret an array of chars as a Bitmap object • C-style casts – Tries multiple casts until one succeeds! • const_cast • static_cast • static_cast followed by const_cast • reinterpret_cast • reinterpret_cas
Slide 15: • General rule: If cast can happen, it will • Checks should be done
Public EXTERNAL Type Confusion Vulnerabilities • General rule: If cast can happen, it will • Checks should be done before casting • Looking for casts with missing or incomplete checks Labs.mwrinfosecurity.com | © MWR Labs 15
Slide 16: • WebKit has common functions for checks before casts of document elements • Objects
Public EXTERNAL Type Confusion Vulnerabilities • WebKit has common functions for checks before casts of document elements • Objects are aware of certain properties – localName • The name of the tag, e.g. div – namespaceURI • The namespace of the object, e.g. SVG • namespaceURI + localName = Qualifie
Slide 17: • 3 common check patterns – hasTagName(QualifiedName) – hasLocalName(QualifiedName)
Public EXTERNAL Type Confusion Vulnerabilities • 3 common check patterns – hasTagName(QualifiedName) – hasLocalName(QualifiedName) – Manual checks • Tag.localName == tag • Tag.namespaceURI == namespace Labs.mwrinfosecurity.com | © MWR Labs 17
Slide 18: • Safe check • Checks both the namespaceURI and localName of a tag
Public EXTERNAL hasTagName • Safe check • Checks both the namespaceURI and localName of a tag if (node->hasTagName(inputTag)) HTMLInputElement* input = static_cast<HTMLInputElement*>(node); Labs.mwrinfosecurity.com | © MWR Labs 18
Slide 19: • Unsafe check • Only checks the localName of a tag, not the namespaceURI
Public EXTERNAL hasLocalName • Unsafe check • Only checks the localName of a tag, not the namespaceURI CVE-2013-2839 – Chrome (V8Clipboard::setDragImageMethodCustom) if (toElement(node)->hasLocalName(HTMLNames::imgTag) clipboard->setDragImage(static_cast<HTMLImageElement*>(node)); Labs.mwrinfosecuri
Slide 20: • Safety depends on usage • Generally, not using hasTagName implies incomplete checking or
Public EXTERNAL Manual Checks • Safety depends on usage • Generally, not using hasTagName implies incomplete checking or lack of code familiarity – Both good indicators of potential bugs Labs.mwrinfosecurity.com | © MWR Labs 20
Slide 21: • Select a sub-component of the target software – WebKit, minus non-default features e.g.
Public EXTERNAL Methodology • Select a sub-component of the target software – WebKit, minus non-default features e.g. accessibility • Understand what methods WebKit provides for checking cast validity • Audit all identified casts for safety Labs.mwrinfosecurity.com | © MWR Labs 21
Slide 22: • Format’s the current SVG document as a tree (DOM) • Selects an element
Public EXTERNAL CVE-2013-0912 return static_cast<SVGElement*>(m_contextElement->treeScope()->getElementById(m_viewTargetString)); • Format’s the current SVG document as a tree (DOM) • Selects an element from the DOM using an ID – ID provided as the “viewTarget” attribute of the SVG document Labs.mwr
Slide 23: • Selected element is cast to an SVG element – No checks • Assumption
Public EXTERNAL CVE-2013-0912 return static_cast<SVGElement*>(m_contextElement->treeScope()->getElementById(m_viewTargetString)); • Selected element is cast to an SVG element – No checks • Assumption is that the element is SVG • Doesn’t account for non-SVG objects embedded in e.g. foreignObject tag
Slide 24: • On construction, viewTarget is an HTMLUnknownElement • After casting, it is interpreted as
Public EXTERNAL CVE-2013-0912 - Trigger <svg xmlns="http://www.w3.org/2000/svg"> <foreignobject x="10" y="10" width="100" height="150"> <body xmlns="http://www.w3.org/1999/xhtml"> <feColorMatrix id="viewTarget"></feColorMatrix> </body> </foreignobject> </svg> • On construction, viewTarget is an HTML
Slide 25: • Bug wouldn’t trigger if the SVG document was created dynamically • V8 caches
Public EXTERNAL Sidenote: V8 Reference Caching • Bug wouldn’t trigger if the SVG document was created dynamically • V8 caches object references on object creation • Retrieving the “viewTarget” of an identical, dynamically created SVG document returns a reference to an HTML element • Makes fuzzing th
Slide 27: • Place an object containing important information adjacent to the “confused” object – Read
Public EXTERNAL Exploitation • Place an object containing important information adjacent to the “confused” object – Read a pointer in the object to bypass ASLR – Corrupt the state of the object to read / write arbitrary memory – Corrupt the virtual function table pointer to gain code execution • No
Slide 28: Read a pointer from an adjacent object Read backwards in memory to base address
Public EXTERNAL Exploitation Steps 1. Read a pointer from an adjacent object 2. Read backwards in memory to base address 3. Read memory of chrome DLL 4. Dynamically calculate ROP chain 5. Overwrite virtual function table pointer Labs.mwrinfosecurity.com | © MWR Labs 28
Slide 29: We can manipulate the heap using JavaScript Aim to place an object next to
Public EXTERNAL Leaking A Pointer • We can manipulate the heap using JavaScript • Aim to place an object next to our “confused” object – Leak the vtable pointer, from chrome.dll • Want to avoid heap spraying • Few allocations, check for success Labs.mwrinfosecurity.com | © MWR Labs 29
Slide 30: Problem – Is It A Div? We can check if the value we leak
Public EXTERNAL Problem – Is It A Div? • We can check if the value we leak is sane – Above the minimum load address, less than kernel space • How can we be sure it’s not a pointer to something else? Labs.mwrinfosecurity.com | © MWR Labs 30
Slide 31: See what else in the object we can leak… For a div, we can
Public EXTERNAL Solution • See what else in the object we can leak… • For a div, we can leak the lastChild pointer • Should be blank for one we just created – Add a child to the divs and check that this value changes • BONUS: The lastChild value is a pointer to the new child object – Store that for
Slide 32: We have a pointer in chrome.dll We could subtract a static value to determine
Public EXTERNAL Calculate The Base Address • We have a pointer in chrome.dll • We could subtract a static value to determine the library’s base – That would be amateur  • Find a “confused” object with a vector property • Manipulate the adjacent memory to place that vector over a specific, page-alig
Slide 33: We have the base address of chrome.dll Set up the adjacent memory to place
Public EXTERNAL Disclose The Contents Of Chrome.dll • We have the base address of chrome.dll • Set up the adjacent memory to place a vector over the .text segment of chrome.dll • Read in the bytes – Approx. 40Mb Labs.mwrinfosecurity.com | © MWR Labs 33
Slide 34: Problem – Floats The vectors we found only contained float values Interpreting arbitrary hex
Public EXTERNAL Problem – Floats • The vectors we found only contained float values • Interpreting arbitrary hex bytes as floats is error-prone • Converting floats back to their hexadecimal representation in JavaScript is non-trivial Labs.mwrinfosecurity.com | © MWR Labs 34
Slide 35: Finally, a practical use for HTML5! Create an ArrayBuffer, and two views over it
Public EXTERNAL Solution • Finally, a practical use for HTML5! • Create an ArrayBuffer, and two views over it • One Uint32ArrayBuffer, one Float32ArrayBuffer • Assign floats to the Float view, retrieve them with the Uint32 view • Assume null when ambiguous float values are encountered – +-Infinity,
Slide 36: We could add static offsets for ROP gadgets – Again, amateur! Take the bytes
Public EXTERNAL Dynamically Calculate ROP Gadgets • We could add static offsets for ROP gadgets – Again, amateur! • Take the bytes of chrome.dll’s .text segment • Use native JavaScript string functions to find byte patterns dynamically – Very fast, 100,000 gadgets in under a second • Store the resul
Slide 37: We have our dynamic ROP chain, and we know where it is in memory
Public EXTERNAL Controlling a VTable Pointer • We have our dynamic ROP chain, and we know where it is in memory • Now to hijack the flow of execution – Simplest stage by far • Manipulate the adjacent memory to our “confused” object • Point one of the vtables to our ROP chain – Adjust for the offset
Slide 38: Despite the fairly intricate gadget finding, we only ended up needing a small number
Public EXTERNAL ROP Chain • Despite the fairly intricate gadget finding, we only ended up needing a small number – Stack pivots • Ended up needing two due to memory layout – Allocated some RWX memory – Copied in the bytes for the remaining gadgets, as well as the kernel shellcode Labs.mwrinfosecurit
Slide 40: • We execute arbitrary instructions • Three options: Chrome
Public EXTERNAL We are still in the Sandbox • We execute arbitrary instructions • Three options: Chrome Applications Kernel Labs.mwrinfosecurity.com | © MWR Labs 40
Slide 41: Chrome • Chrome browser process – Supports the render
Public EXTERNAL Chrome • Chrome browser process – Supports the render • Extensive amount of communication to Renderer • All implemented in native code • Other people took this route before • We considered it – Jon was code reviewing again Labs.mwrinfosecurity.com | © MWR Labs 41
Slide 42: Chrome? • Proactive about security…
Public EXTERNAL Chrome? • Proactive about security… Labs.mwrinfosecurity.com | © MWR Labs 42
Slide 43: Chrome? • Proactive about security…
Public EXTERNAL Chrome? • Proactive about security… Labs.mwrinfosecurity.com | © MWR Labs 43
Slide 44: Applications • Windows Messaging – Extensive Comms between Applications
Public EXTERNAL Applications • Windows Messaging – Extensive Comms between Applications • Shatter attacks anyone? – Get Admin/System • Similar use in Sandbox breakout • Chrome protects against this – Alternative Desktop Labs.mwrinfosecurity.com | © MWR Labs 44
Slide 45: Kernel • Huge attack surface – Core kernel
Public EXTERNAL Kernel • Huge attack surface – Core kernel • 450 system calls – Win32k.sys – Graphical subsystem • >900 system calls • Incredibly complex, e.g.: – Font parsing in the kernel – Kernel mode callbacks Labs.mwrinfosecurity.com | © MWR Labs 45
Slide 46: Kernel • Reverse engineering?
Public EXTERNAL Kernel • Reverse engineering? Labs.mwrinfosecurity.com | © MWR Labs 46
Slide 47: Kernel • Fuzzing • “Doesn’t Microsoft use Fuzzing?”
Public EXTERNAL Kernel • Fuzzing • “Doesn’t Microsoft use Fuzzing?” • A lot of presentations – Font fuzzers – System call fuzzers • So is it even worth trying? Labs.mwrinfosecurity.com | © MWR Labs 47
Slide 48: For any reasonably complex application your Fuzzer can’t be complex enough
Public EXTERNAL Kernel - Fuzzing “Secret” about fuzzing: For any reasonably complex application your Fuzzer can’t be complex enough Labs.mwrinfosecurity.com | © MWR Labs 48
Slide 49: 1. You found all the bugs 2. Your current Fuzzer needs improving
Public EXTERNAL Kernel - Fuzzing If your Fuzzer stops finding vulnerabilities: 1. You found all the bugs 2. Your current Fuzzer needs improving Labs.mwrinfosecurity.com | © MWR Labs 49
Slide 50: Kernel - Fuzzing • Let’s look at system calls • Previous attempts
Public EXTERNAL Kernel - Fuzzing • Let’s look at system calls • Previous attempts – Focus on single system calls • NtSystemCall(“aaaaaa”, “x”, 0xffffffff); – Not series of calls Labs.mwrinfosecurity.com | © MWR Labs 50
Slide 51: Kernel - Fuzzing • We just have to have a more complex Fuzzer •
Public EXTERNAL Kernel - Fuzzing • We just have to have a more complex Fuzzer • A few ideas – Creating valid Menu structures – User mode callback hooking – Knowledge about arguments – Everything is a Handle – HMENU, HFONT, HCURSOR, HWND Labs.mwrinfosecurity.com | © MWR Labs 51
Slide 53: Kernel – Fuzzing Results
Public EXTERNAL Kernel – Fuzzing Results Jazz Hands! Labs.mwrinfosecurity.com | © MWR Labs 53
Slide 54: Kernel - Fuzzing • Automation Tricky – Important
Public EXTERNAL Kernel - Fuzzing • Automation Tricky – Important – VM’s with Snapshots • Reproducibility – Logging • Extremely slow – We worked from crash dumps Labs.mwrinfosecurity.com | © MWR Labs 54
Slide 55: Kernel – The vulnerability
Public EXTERNAL Kernel – The vulnerability • Crash dump: nt!ExpReleasePoolQuota+0x21: 82aca424 8a07 mov al,byte ptr [edi] ds:0023:00410041=?? 00000008 ffb80530 00000000 nt!ExpReleasePoolQuota+0x21 fd6b7168 00000000 ffb80530 nt!ExFreePoolWithTag+0x779 ffb80530 00000000 2ba8aa2a win32k!UnlinkSendListS
Slide 56: Kernel – The vulnerability
Public EXTERNAL Kernel – The vulnerability • System call to trigger crash: NtUserMessageCall(HWND, WM_GETTEXT, 0x8, // Buffer size in kernel ! ptr, // user mode 0x0, 0x2b3, 0x2); // ASCII boolean/flag Labs.mwrinfosecurity.com | © MWR Labs 56
Slide 57: Kernel – The vulnerability
Public EXTERNAL Kernel – The vulnerability • Requirements for trigger – Message to be send between threads • ASCII window object as receiving thread (HWND) – ASCII boolean value has to be even (not 0x0) – WM_GETTEXT response larger than (size/2) Labs.mwrinfosecurity.com | © MWR Labs 57
Slide 58: Kernel – The vulnerability
Public EXTERNAL Kernel – The vulnerability • The allocation: win32k!xxxInterSendMsgEx win32k!xxxSendMessageTimeout+0x13b win32k!xxxSendMessageEx+0xec win32k!NtUserfnOUTSTRING+0xa7 win32k!NtUserMessageCall+0xc9 • Algorithm to figure out buffer allocation – Based on message type and window types – Fai
Slide 59: Kernel – The vulnerability
Public EXTERNAL Kernel – The vulnerability • The copy operation: win32k!CopyOutputString win32k!SfnOUTSTRING+0x336 win32k!xxxSendMessageToClient+0x175 win32k!xxxReceiveMessage+0x3b8 win32k!xxxRealInternalGetMessage+0x252 win32k!NtUserGetMessage+0x3f • Algorithm to figure out copy type • Last argumen
Slide 60: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • Blocks 16 byte aligned
Public EXTERNAL Pool Allocator with Quota Overflow Exploitation • Buffer layout: EPROCESS Meta TAG Data PTR • Blocks 16 byte aligned (without Meta and TAG) Labs.mwrinfosecurity.com | © MWR Labs 60
Slide 61: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • We control the allocation
Public EXTERNAL Pool Allocator with Quota Overflow Exploitation • Buffer layout: EPROCESS Meta TAG Data PTR • We control the allocation size • Buffer write will be (2*size) – ASCII to Widechar conversion Labs.mwrinfosecurity.com | © MWR Labs 61
Slide 62: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • Good buffer size: 8
Public EXTERNAL Pool Allocator with Quota Overflow Exploitation • Buffer layout: EPROCESS Meta TAG Data PTR • Good buffer size: 8 • data + quota ptr = 12 + 4 byte padding = 16 (aligned) • Overwrite (2*size): corrupt padding and quota ptr (no further heap corruption) Labs.mwrinfosecurity.com | © MWR
Slide 63: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • We are limited to
Public EXTERNAL Pool Allocator with Quota Overflow Exploitation • Buffer layout: 00aa00aa00aa00aa Meta TAG 00aa00aa00aa00aa 00xx00yy • We are limited to ASCII (not UTF8) -> Widechar • Quota ptr can be 0x00xx00yy • Fake Quota structure in user mode Labs.mwrinfosecurity.com | © MWR Labs 63
Slide 64: Quota Process Overwrite Exploitations • See “Kernel Pool Exploitation on Windows 7”, Tarjei Mandt
Public EXTERNAL Quota Process Overwrite Exploitations • See “Kernel Pool Exploitation on Windows 7”, Tarjei Mandt • Place in user mode: kd> dt ntkrpamp!_EPROCESS ... +0x0d4 QuotaBlock : Ptr32 _EPROCESS_QUOTA_BLOCK ... Labs.mwrinfosecurity.com | © MWR Labs 64
Slide 65: Quota Process Overwrite Exploitations EPROCESS points to: typedef struct _EPROCESS_QUOTA_BLOCK {
Public EXTERNAL Quota Process Overwrite Exploitations EPROCESS points to: typedef struct _EPROCESS_QUOTA_BLOCK { EPROCESS_QUOTA_ENTRY QuotaEntry[3]; LIST_ENTRY QuotaList; ULONG ReferenceCount; ULONG ProcessCount; } EPROCESS_QUOTA_BLOCK, *PEPROCESS_QUOTA_BLOCK; Labs.mwrinfosecurity.com | © MWR Labs 6
Slide 66: Kernel - Exploitation • We could have _EPROCESS_QUOTA_BLOCK in user mode • ReferenceCount or
Public EXTERNAL Kernel - Exploitation • We could have _EPROCESS_QUOTA_BLOCK in user mode • ReferenceCount or ProcessCount are decremented on free • If either == 0 we get code execution • However this won’t be in the context of the syscall – Painful to exploit • What can we decrement in kernel mode?
Slide 67: Quota Process Overwrite Exploitations kd> dt win32k!tagWND +0x000 head
Public EXTERNAL Quota Process Overwrite Exploitations kd> dt win32k!tagWND +0x000 head : _THRDESKHEAD +0x014 state : Uint4B +0x014 bHasMeun : Pos 0, 1 Bit ... +0x014 bServerSideWindowProc : Pos 18, 1 Bit +0x014 bAnsiWindowProc : Pos 19, 1 Bit +0x014 bBeingActivated : Pos 20, 1 Bit ... +0x014 bMaximi
Slide 68: Kernel - Exploitation • Create a new Window • Specify custom user mode window
Public EXTERNAL Kernel - Exploitation • Create a new Window • Specify custom user mode window procedure • Get window kernel address through shared table in GDI • Point EPROCESS_QUOTA_BLOCK to state of window object • Trigger exploit a few times (100% reliable) • => bServerSideWindowProc will be True
Slide 69: Kernel - Exploitation • The Window procedure:
Public EXTERNAL Kernel - Exploitation • The Window procedure: WORD um=0; __asm { mov ax, cs mov um, ax } if(um == 0x1b) { // USER MODE } else { // KERNEL MODE CODE EXECUTION Labs.mwrinfosecurity.com | © MWR Labs 69
Slide 70: Kernel - Exploitation • "Easy local Windows Kernel exploitation" by Cesar Cerrudo – Nulling
Public EXTERNAL Kernel - Exploitation • "Easy local Windows Kernel exploitation" by Cesar Cerrudo – Nulling out ACLs • Ended up nulling ACL of winlogon.exe – System Process – User Desktop • Then CreateRemoteThread into winlogon.exe Labs.mwrinfosecurity.com | © MWR Labs 70
Slide 71: Kernel - Shellcode mov eax, hwnd // WND mov eax, [eax+8] // THREADINFO
Public EXTERNAL Kernel - Shellcode mov eax, hwnd // WND mov eax, [eax+8] // THREADINFO mov eax, [eax] // ETHREAD mov eax, [eax+0x150] // KPROCESS mov eax, [eax+0xb8] // flink procloop: lea edx, [eax-0xb8] // KPROCESS mov eax, [eax] add edx, 0x16c // module name cmp dword ptr [edx], 0x6c707865 // exp
Slide 73: Thanks For Listening Questions?
Public EXTERNAL Thanks For Listening Questions? Labs.mwrinfosecurity.com | © MWR Labs 73

Withsecure — Investor Presentation on 6ix

Withsecure — Investor Presentation

Slide 1: Polishing Chrome for Fun and Profit

Slide 2: Agenda Introduction Google Chrome

Slide 3: Introduction Nils Jon

Slide 4: Google Chrome

Slide 5: • Widely considered to be the most secure web browser available • Designed from

Slide 6: Google Chrome – Renderer • Used to use WebKit – Fast, but patchy code

Slide 7: Google Chrome – Sandbox Protections • “High-risk” renderer component sandboxed – Restricted Windows security

Slide 8: Google Chrome – Sandbox Protections • Restricted renderer processes cannot perform all required actions

Slide 9: Google Chrome – Hypothetical Sandbox Bypass • At least two vulnerabilities required to gain

Slide 10: Pwn2Own Vulnerabilities

Slide 11: • Conducted source code review – Bug found approximately 6 weeks after starting –

Slide 12: • Class of vulnerability involving invalid casts of objects • Object of one class

Slide 13: • const_cast – Toggles the “const” property for a class, no cast • static_cast

Slide 14: • reinterpret_cast – Casts anything to anything! – E.g. Interpret an array of chars

Slide 15: • General rule: If cast can happen, it will • Checks should be done

Slide 16: • WebKit has common functions for checks before casts of document elements • Objects

Slide 17: • 3 common check patterns – hasTagName(QualifiedName) – hasLocalName(QualifiedName)

Slide 18: • Safe check • Checks both the namespaceURI and localName of a tag

Slide 19: • Unsafe check • Only checks the localName of a tag, not the namespaceURI

Slide 20: • Safety depends on usage • Generally, not using hasTagName implies incomplete checking or

Slide 21: • Select a sub-component of the target software – WebKit, minus non-default features e.g.

Slide 22: • Format’s the current SVG document as a tree (DOM) • Selects an element

Slide 23: • Selected element is cast to an SVG element – No checks • Assumption

Slide 24: • On construction, viewTarget is an HTMLUnknownElement • After casting, it is interpreted as

Slide 25: • Bug wouldn’t trigger if the SVG document was created dynamically • V8 caches

Slide 26: Demo

Slide 27: • Place an object containing important information adjacent to the “confused” object – Read

Slide 28: Read a pointer from an adjacent object Read backwards in memory to base address

Slide 29: We can manipulate the heap using JavaScript Aim to place an object next to

Slide 30: Problem – Is It A Div? We can check if the value we leak

Slide 31: See what else in the object we can leak… For a div, we can

Slide 32: We have a pointer in chrome.dll We could subtract a static value to determine

Slide 33: We have the base address of chrome.dll Set up the adjacent memory to place

Slide 34: Problem – Floats The vectors we found only contained float values Interpreting arbitrary hex

Slide 35: Finally, a practical use for HTML5! Create an ArrayBuffer, and two views over it

Slide 36: We could add static offsets for ROP gadgets – Again, amateur! Take the bytes

Slide 37: We have our dynamic ROP chain, and we know where it is in memory

Slide 38: Despite the fairly intricate gadget finding, we only ended up needing a small number

Slide 39: Code Execution!

Slide 40: • We execute arbitrary instructions • Three options: Chrome

Slide 41: Chrome • Chrome browser process – Supports the render

Slide 42: Chrome? • Proactive about security…

Slide 43: Chrome? • Proactive about security…

Slide 44: Applications • Windows Messaging – Extensive Comms between Applications

Slide 45: Kernel • Huge attack surface – Core kernel

Slide 46: Kernel • Reverse engineering?

Slide 47: Kernel • Fuzzing • “Doesn’t Microsoft use Fuzzing?”

Slide 48: For any reasonably complex application your Fuzzer can’t be complex enough

Slide 49: 1. You found all the bugs 2. Your current Fuzzer needs improving

Slide 50: Kernel - Fuzzing • Let’s look at system calls • Previous attempts

Slide 51: Kernel - Fuzzing • We just have to have a more complex Fuzzer •

Slide 52: Kernel - Fuzzing

Slide 53: Kernel – Fuzzing Results

Slide 54: Kernel - Fuzzing • Automation Tricky – Important

Slide 55: Kernel – The vulnerability

Slide 56: Kernel – The vulnerability

Slide 57: Kernel – The vulnerability

Slide 58: Kernel – The vulnerability

Slide 59: Kernel – The vulnerability

Slide 60: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • Blocks 16 byte aligned

Slide 61: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • We control the allocation

Slide 62: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • Good buffer size: 8

Slide 63: Pool Allocator with Quota Overflow Exploitation • Buffer layout: • We are limited to

Slide 64: Quota Process Overwrite Exploitations • See “Kernel Pool Exploitation on Windows 7”, Tarjei Mandt

Slide 65: Quota Process Overwrite Exploitations EPROCESS points to: typedef struct _EPROCESS_QUOTA_BLOCK {

Slide 66: Kernel - Exploitation • We could have _EPROCESS_QUOTA_BLOCK in user mode • ReferenceCount or

Slide 67: Quota Process Overwrite Exploitations kd> dt win32k!tagWND +0x000 head

Slide 68: Kernel - Exploitation • Create a new Window • Specify custom user mode window

Slide 69: Kernel - Exploitation • The Window procedure:

Slide 70: Kernel - Exploitation • "Easy local Windows Kernel exploitation" by Cesar Cerrudo – Nulling

Slide 71: Kernel - Shellcode mov eax, hwnd // WND mov eax, [eax+8] // THREADINFO

Slide 72: Demo

Slide 73: Thanks For Listening Questions?