BlueHat v17 || Corrupting Memory in Microsoft Office Protected-View Sandbox
1 like600 views
The document discusses the discovery of memory corruption vulnerabilities in the Microsoft Office 2016 protected-view sandbox through fuzzing techniques. It details the inter-process communication (IPC) mechanism of the protected-view environment, along with the results of the fuzzing efforts that identified multiple vulnerabilities, notably CVE-2017-8502 and CVE-2017-8692. The findings emphasize the need for improved security measures to protect against these exploitation opportunities in the Office applications.
![++
IPC Mechanism
Attack Surfaces
Kernel
System-Calls: “Generic” Escapes
AppContainer
User InterOp. Process (Med)
Logic Quirks: “Trendy” Escapes
Broker Process (Med)
IPC: “Old-School” Escapes
[*] https://medium.com/@mxatone/how-bad-design-decisions-created-the-least-secure-driver-on-windows-33e662a502fe
[*]](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-13-320.jpg)
![++
IPC Mechanism
• Broker does general checks on IPC message header
– NumberOfBytesRead of ReadFile() <= 2000h
– Header.MsgSize == NumberOfBytesRead
• Broker does sanity-checks on IPC message body
– Header.MsgSize == IPC static msg size, or
– Header.MsgSize >= IPC min (dynamic) msg size
– Update (WCHAR*, USTRING*, BYTE*, Array[], etc) pointers, if not NULL
Message Format
typedef struct _USTRING
{
UINT16 Len; //len of Buffer[], excld NULL
WCHAR Buffer[N]; //wide-character string
} USTRING;](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-22-320.jpg)
![++
IPC Mechanism
• Broker does sanity-checks on IPC message body
– Ptr_1 + Header.MsgSize == Ptr_2 + sizeof(s.fields) + sizeof(d.fields)
Message Format
Ptr_2
ULONG ulVirtualKey
ULONG ulMsgTag
ULONG ulMsgID
ULONG ulMsgSize
ULONG ulViewID
WCHAR* UStrInChars.Buffer
UINT8 ui8Unknown_18
UINT8 ui8Unknown_19
UINT16 ui16Padding
USTRING.UINT16 UStrInChars.Len
USTRING.WCHAR UStrInChars.Buffer[Len+1]
sizeof (static fields)
= 1Ch + 02h
= 1Eh
sizeof (dynamic fields)
= Len * 02h + 02h
Ptr_2
Ptr_1
+ ulMsgSize
Ptr_1
== ?](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-23-320.jpg)
![++
Results
CVE-2017-8502: Array Usage
Calls MSO_97() when dword_1461918 = 2Fh
• Calls sub_12B744() to get a pointer into 7Ch-obj array
• Note arg_0 = const 15h (from caller)
• [ecx+DCh] is the pointer to start of 7Ch-obj array, from dword_C0637C
• Offset into 7Ch-obj array = (15h-10h) * 7Ch = 26Ch
• Recall allocation size = 26Ch
• Therefore returns a pointer to end of 7Ch-obj array
Calls crash_sub() with ptr to end of 7Ch-obj array (ESI)
OOB dereference at offset 34h from end of 7Ch-obj array
Calling into
sub_12B744()…
Ret from
sub_12B744()…](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-40-320.jpg)
![++
Results
CVE-2017-8692: Trigger
ScriptItemize (
[in] pwcInChars = L"j(@-g?Mcav)MzM_<m+T[zA46ykI#V52Kj|42"
[in] cInChars = 0x00000004
[in] cMaxItems = 0x00000005
[in,opt] psControl = &(0x00800009)
[in,opt] psState = &(0x0001)
[out] pItems
[out] pcItems
)
EXCEL_071200 PvMsg = {};
PvMsg.UStrInChars.Buffer = 0x1;
PvMsg.ui8Unknown_18 = 0x2;
PvMsg.ui8Unknown_19 = 0x0;
PvMsg.ui16Padding = 0x00;
PVMsg.UStrInChars = {0x25, L"j(@-g?Mcav)MzM_<m+T[zA46ykI#V52Kj|42"};](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-44-320.jpg)
![++
Results
CVE-2017-8692: Trigger
crash in gdi32full!ScriptItemize() API
ScriptItemize (
[in] pwcInChars = L"j(@-g?Mcav)MzM_<m+T[zA46ykI#V52Kj|42"
[in] cInChars = 0x00000004
[in] cMaxItems = 0x00000005
[in,opt] psControl = &(0x00800009)
[in,opt] psState = &(0x0001)
[out] pItems
[out] pcItems
)
call HeapAllocWrapper2 (dwBytes, ppBufferOut)](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-45-320.jpg)
![++
Results
• MSDN ScriptItemize() Reference
– Responsibility fall on developers to allocate the sufficient sized buffer
• Recall: Size of pItems = cMaxItems * sizeof(SCRIPT_ITEM)
• But there should have been checks in ScriptItemize() API?
– “... while (*ppItems <= pItems_LastItem); ...”
– Loop should have terminated at pItems[-2]?
CVE-2017-8692: Summary](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-48-320.jpg)
![++
Conclusion
• Results
– Total issues: 4 (MSO.DLL), 2 (WWLIB.DLL), 3 (EXCEL.EXE), 0 (PPCORE.DLL)
– 3 security issues
– Vulnerabilities trend: Non-linear (buf[n] = x) heap corruption issues
Conclusion](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-52-320.jpg)
![++
Conclusion
• Most modern mitigations (eg: DisableWin32kSystemCalls) disabled
Conclusion
2007 2010 2013 2016
DEP:Enable OFF ON ON ON
DEP:DisableATL OFF OFF ON ON
ASLR:BottomUp ON ON ON ON
ASLR:ForceRelocate OFF OFF ON ON
ASLR:* OFF OFF OFF OFF
StrictHandle:RaiseExceptionOnInvalid OFF OFF OFF [B] : ON [S] OFF [B] : ON [S]
StrictHandle:HandleExceptionsPermanently OFF OFF OFF [B] : ON [S] OFF [B] : ON [S]
System Call:DisallowWin32kSysCalls OFF OFF OFF OFF
ExtensionPoint:DisableExtensionPoints OFF OFF OFF OFF
DynamicCode:* OFF OFF OFF OFF
CFG:* OFF OFF OFF OFF
BinarySignature:* OFF OFF OFF OFF
FontDisable:* OFF OFF OFF OFF
ImageLoad:* OFF OFF OFF OFF
[*] Results of ProcessMitigations 1.0.7 “Get-ProcessMitigation” on various (x86) MS Office](https://image.slidesharecdn.com/mwricorrupting-memory-in-ms-office-protected-viewv2-171220210640/85/BlueHat-v17-Corrupting-Memory-in-Microsoft-Office-Protected-View-Sandbox-53-320.jpg)
BlueHat v17 || Corrupting Memory in Microsoft Office Protected-View Sandbox
- 1. ++ Yong Chuan Koh 08th Nov 2017 Corrupting Memory In Microsoft Office Protected-View Sandbox BLUEHAT V17
- 2. ++ MWR Labs • Introduction • Inter-Process Communication (IPC) Mechanism • Fuzzer Implementation • Results • Conclusion and Future Work Outline
- 3. ++ • Yong Chuan, Koh (@yongchuank) • Security Researcher @ MWR Infosecurity (SG) since 2014 • Work: – Desktop Applications Security Assessments – Web + Mobile Applications Security Assessments – Malware RE + Analysis • Interests: – Vulnerability Research – Reverse Engineering #whoami
- 4. ++ Introduction • Motivation • Goals MS Office 2016 Protected-View Sandbox
- 5. ++ Introduction • Microsoft Office Bounty Program – 15 Mar to 15 Jun, extended to 31 Dec 2017 – $6000 to $15000, for Protected-View EOP • Received $0 bounty Motivation BOUNTY $$$
- 6. ++ Introduction • Missing puzzle piece in “sandbox-everything” trend – Edge, Chrome, IE, Adobe Reader • Increasing popularity in hacking contest – New categories in Pwn2Own 2017, Zer0Fest 2017 – MS Office with Protected-View Motivation
- 7. ++ Introduction • No advisories (AFAIK) on Protected-View memory corruptions – 100% secure code? • Experiment fuzzing technique on different targets – “Fuzzing the Windows Kernel”, HITB GSEC 2016 Motivation
- 8. ++ Introduction • Find all Protected-View memory corruptions – And fix them! • Hopefully increase cost for attackers – And hacking contest participants? – New and creative bypass techniques! • Learn about vulnerabilities trends • Have fun! Goals
- 9. ++ Introduction • Fuzzing and analysis of MS Office 16.0.4266.1001 (vanilla) – Reuse existing .idb with notes + comments – *Assumed* no new IPC messages introduced Baseline
- 10. ++ Inter-Process Communication (IPC) Mechanism • Attack Surfaces • IPC Internals • IPC Message Format MS Office 2016 Protected-View Sandbox
- 11. ++ IPC Mechanism • Unlike any other sandboxes – Aims to provide text-view of file content – Does not provide full features of application – Reduced attack surfaces (eg: no COM) – Only for MOTW files Attack Surfaces
- 12. ++ IPC Mechanism • Protected-View boundary – AppContainer SID – ALL_APP_PACKAGES SID (S-1-15-2-1) – Unknown MSOffice Capability SID (S-1-15-3-2929230137-1657469040) • Accessible securable objects – %UserProfile%AppDataLocalPackages<AC>* – HKCUSoftwareMicrosoftOffice* (KEY_READ) – HKLMSoftwareMicrosoftMSLicensingStore* (KEY_READ|KEY|WRITE) • Sensitive data exfiltration (if any) requires… – PV has no internet capabilities – IPC for broker to send data out as WER – Requires a compromised WER server, which doesn’t meet MSRC servicing bar Attack Surfaces
- 13. ++ IPC Mechanism Attack Surfaces Kernel System-Calls: “Generic” Escapes AppContainer User InterOp. Process (Med) Logic Quirks: “Trendy” Escapes Broker Process (Med) IPC: “Old-School” Escapes [*] https://medium.com/@mxatone/how-bad-design-decisions-created-the-least-secure-driver-on-windows-33e662a502fe [*]
- 14. ++ IPC Mechanism • All files are rendered in same PV process • Broker has to differentiate IPC msgs from each MOTW file IPC Internals
- 15. ++ IPC Mechanism IPC Internals PVFile (Dynamic) Array ThreadMgr lpMsgInOut lpPVStartUp lpSubMgr … SubMgr lpThreadMgr lpFileMgr … FileMgr lpThreadMgr ulNumInUse ulNumMax lpFileArray … PVFile_1 (free/busy) lpPVCoreObj … … … … PVFile_N (free/busy) lpPVCoreAttr … MsgInOut … PVStartUp … PVCoreAttr PVAppAttr … PVAppAttr … PVCoreAttr PVAppAttr … PVAppAttr … PVCoreAttr PVAppAttr … PVAppAttr … * Only relevant object fields are illustrated
- 16. ++ IPC Mechanism • Broker – “Core” Office App: Winword, Excel or Powerpoint • Sandbox – “Core” Office App: Winword, Excel or Powerpoint Protected-View Scenario: App Broker Serviced in MSO.DLL Servicing DLL depends on broker PVFile ulViewID hOPHWnd lpwzFileName lpwzTempFileName lpPVCoreAttr bSessionHyperlinks PVCoreAttr lpPVAppAttr hOPHParentWnd lpDRMStream lpTaskList PVAppAttr …
- 17. ++ IPC Mechanism • Broker – Outlook • Sandbox – “Core” Office App: Winword, Excel, Powerpoint or Visio Previewer Protected-View Scenario: Outlook Broker Serviced in MSO.DLL Servicing DLL depends on broker PVFile ulViewID hOPHWnd lpwzFileName lpwzTempFileName lpPVCoreAttr bSessionHyperlinks PVCoreAttr lpPVAppAttr hOPHParentWnd lpDRMStream lpTaskList PVAppAttr …
- 18. ++ IPC Mechanism Named-Pipe Properties Sandbox Process Broker Process • Name “pipeOfficeUser_OICE_16_974FA576_32C1D314_<ID>” – <ID> = rand_s() & 3FFFh (16k possible values) • Bidirectional (PIPE_ACCESS_DUPLEX) • Local Machine Client (PIPE_REJECT_REMOTE_CLIENTS) • Message Stream (PIPE_TYPE_MESSAGE) • Max In/Out Buffer Size 2000h
- 19. ++ IPC Mechanism • Protected-View Core (PVCore) – Independent of broker application – 16-bytes IPC message header – MSO.DLL • Protected-View App (PVApp) – Dependent on broker application (Word, Excel or Powerpoint) – 20-bytes IPC message header – WWLIB.DLL, EXCEL.EXE or PPCORE.DLL Message Format
- 20. ++ IPC Mechanism Message Format Message Header Message Body PVCore Header Format ULONG ulVirtualKey Subset of vkey codes, to query state GetAsyncKeyState() ULONG ulMsgTag Type of IPC message ULONG ulMsgID Matches IPC request to response; can be random ULONG ulMsgSize Total size of IPC message, including header PVApp Header Format ULONG ulVirtualKey Subset of vkey codes, to query state GetAsyncKeyState() ULONG ulMsgTag Type of IPC message ULONG ulMsgID Matches IPC request to response; can be random ULONG ulMsgSize Total size of IPC message, including header ULONG ulViewID Ordered sequence of file opened in Protected-View Body Format • Dependent on type of IPC message (MsgTag) • May be optional • May be fixed or varied size • Some PVCore messages also have ViewID in body
- 21. ++ IPC Mechanism Message Format WWLIB.DLL 15 WINWORD messages (0x001100 – 0x0E1100; +0x10000) 17 EXCEL messages (0x001200 – 0x101200; +0x10000) EXCEL.EXE PPCORE.DLL 17 POWERPNT messages (0x001300 – 0x101300; +0x10000) MSO.DLL 23 MSO (PVCore) messages (0x001000 – 0x161000; +0x10000) * IPC Sanity-Check Functions * IPC Service-Request Functions
- 22. ++ IPC Mechanism • Broker does general checks on IPC message header – NumberOfBytesRead of ReadFile() <= 2000h – Header.MsgSize == NumberOfBytesRead • Broker does sanity-checks on IPC message body – Header.MsgSize == IPC static msg size, or – Header.MsgSize >= IPC min (dynamic) msg size – Update (WCHAR*, USTRING*, BYTE*, Array[], etc) pointers, if not NULL Message Format typedef struct _USTRING { UINT16 Len; //len of Buffer[], excld NULL WCHAR Buffer[N]; //wide-character string } USTRING;
- 23. ++ IPC Mechanism • Broker does sanity-checks on IPC message body – Ptr_1 + Header.MsgSize == Ptr_2 + sizeof(s.fields) + sizeof(d.fields) Message Format Ptr_2 ULONG ulVirtualKey ULONG ulMsgTag ULONG ulMsgID ULONG ulMsgSize ULONG ulViewID WCHAR* UStrInChars.Buffer UINT8 ui8Unknown_18 UINT8 ui8Unknown_19 UINT16 ui16Padding USTRING.UINT16 UStrInChars.Len USTRING.WCHAR UStrInChars.Buffer[Len+1] sizeof (static fields) = 1Ch + 02h = 1Eh sizeof (dynamic fields) = Len * 02h + 02h Ptr_2 Ptr_1 + ulMsgSize Ptr_1 == ?
- 24. ++ Fuzzer Implementation • Fuzzing Decisions • Fuzzing Setup MS Office 2016 Protected-View Sandbox
- 25. ++ Fuzzer Implementation • App-broker: Higher code coverage of overall IPC messages – PVCore and PVApp (vs Outlook-broker: PVCore subset only) • Outlook-broker: (Possibly) Higher code coverage of PVCore (Subset 1) messages • Decision: Fuzz both scenarios, but dedicate longer fuzz time for App- broker Protected-View Scenario Serviced in MSO.DLL Servicing DLL depends on broker PVFile ulViewID hOPHWnd lpwzFileName lpwzTempFileName lpPVCoreAttr bSessionHyperlinks PVCoreAttr lpPVAppAttr hOPHParentWnd lpDRMStream lpTaskList PVAppAttr … IPC PVCore (Subset 1) Mgs IPC PVCore (Subset 2) Msgs IPC PVApp Msgs
- 26. ++ Fuzzer Implementation • Valid ViewID value of 1 – First Protected-View file • Valid MsgSize value – Fixed value for static-sized msg, or max 2000h for dynamic-sized msg • Valid MsgTag values – Depends on chosen Protected-View scenario • Valid USTRING structure, where applicable • Non-NULL arbitrary pointer value – Sanity-check functions will update accordingly Valid IPC Message Fields
- 27. ++ Fuzzer Implementation • RE message bodies to ↑ code-coverage, ↓ time • Only 72 (23 MSO+15 WWLIB+17 EXCEL+17 PPCORE) msgs ¯_(ツ)_/¯ Improve Fuzzing Efficiency typedef struct EXCEL_071200 : IpcHeader { WCHAR* UStrInChars.Buffer; //Non-NULL UINT8 ui8Unknown_18; //0-2, or others UINT8 ui8Unknown_19; //0-1, or others UINT16 ui16Padding; //unused USTRING UStrInChars; };
- 28. ++ Fuzzer Implementation • Sanity-checks would discard most dumb-fuzzed IPC mgs • Use sanity-checks for the fuzzer advantage… – Also verifies reverse-engineering + fuzzer code – Produces CVE-2017-8692! Cross-Check IPC Message Format
- 29. ++ Fuzzer Implementation • No sophisticated fuzzing framework • Enable page heap “gflags.exe /i <image> +hpa” • DLL injection of fuzzer DLL into Protected-View process • Randomly select valid PVCore + PVApp IPC message • Each IPC message is generated with as many valid fields as possible • Sends IPC message through Named-Pip “.pipeOfficeUser_OICE_16_ 974FA576_32C1D314_<****>” Fuzzing Algorithm
- 30. ++ Fuzzer Implementation • Manual reproduction of crash • Check if crash occurs in IPC-processing functions – If yes, identify this as PVTarget message • Rerun fuzzing, with biased selection for PVTarget message • *Pray* that crash can be reproduced after X period of time • Use DebugView for manual minimization – Log Header->MsgTag only Crash Reproduction
- 31. ++ Fuzzer Implementation Crash Minimization Has Crashed? Return N MsgTags to set Run fuzzer-RM Get set of MsgTags Remove N MsgTags from set Yes No Yes Min set to crash? Add code to log MsgBody No Last Run *Fuzzer-RM: Generate IPC msg from predefined list instead of random
- 32. ++ Fuzzer Implementation • Host: HP Elite Notebook – Intel i7-4600U CPU – 8 GB Memory • Guest: 1-4 VMWare Workstation Images – 1 CPU, 1 GB Memory – All crashes occur while testing fuzzer code with 1 Guest – “Scale up” fuzzing to 4 Guests, for ~5 days * ~9 hours Hardware
- 33. ++ Results • Statistics • Case Study: CVE-2017-8502 • Case Study: CVE-2017-8692 • MSRC 40761 MS Office 2016 Protected-View Sandbox
- 34. ++ Results Statistics MSO.DLL 45% WWLIB.DLL 22% EXCEL.EXE 33% PPCORE.DLL 0% • CVE-2017-8502: Mem Corruption Vulnerability • CVE-2017-8692: Uniscribe RCE • *NSI: RtlFailFast() DOS • MSRC 40761: Invalid Pointer Typecast (Open) • *NSI: RtlFailFast() DOS • *NSI: Stack Exhaustion DOS • *NSI: Dir Traversal via WER • *NSI: memcpy() Read-AV DOS • *NSI: Null-Ptr Dereference DOS * NSI: Non-Security Issue
- 35. ++ Results • Aka “Out-of-Boundary Array Access” • Affects only Excel Protected-View (PVApp) • Requires two 0E1200h IPC messages CVE-2017-8502: Memory Corruption Vulnerability sub_AA1C81(): Start service 0E1200h msg sub_91AE(): HeapAllocWrapper1 (dwBytes) Allocation size (dwBytes): 26Ch
- 36. ++ Results • First 0E1200h message CVE-2017-8502: Pre-Trigger EXCEL_0E1200 PvMsg = {}; PvMsg.bSetGlobalFlag = 1; PvMsg.ui32Unknown_18 = 0xFFFFFFFF; PvMsg.ui32Unknown_1C = 0xFFFFFFFF; PvMsg.ui32Unknown_20 = 0x29; PvMsg.ui32Unknown_24 = 0xFFFFFFFF; PvMsg.ui32Unknown_28 = 0xFFFFFFFF;
- 37. ++ Results • Second 0E1200h message CVE-2017-8502: Trigger EXCEL_0E1200 PvMsg = {}; PvMsg.bSetGlobalFlag = 0; PvMsg.ui32Unknown_18 = 0xFFFFFFFF; PvMsg.ui32Unknown_1C = 0xFFFFFFFF; PvMsg.ui32Unknown_20 = 0x23; PvMsg.ui32Unknown_24 = 0xFFFFFFFF; PvMsg.ui32Unknown_28 = 0xFFFFFFFF;
- 38. ++ Results • Allocation size = EAX * 7Ch – ie: allocates for an array of EAX number of unknown objects – Size of each unknown object = 7Ch • Second 0E1200h message – Allocation size = EAX (5) * 7Ch = 26Ch CVE-2017-8502: Array Allocation * Funfact: Addr EXCEL+10BC14 appeared in “!heap –p –a ecx” 3 slides earlier
- 39. ++ Results • Array pointer is assigned to global variable, dword_C0637C – poi(poi(poi(poi(poi(MSO+C0637Ch))+8))+DCh) • Initialization of all unk_obj in array is completed in MSO.sub_120304() loop CVE-2017-8502: Array Allocation
- 40. ++ Results CVE-2017-8502: Array Usage Calls MSO_97() when dword_1461918 = 2Fh • Calls sub_12B744() to get a pointer into 7Ch-obj array • Note arg_0 = const 15h (from caller) • [ecx+DCh] is the pointer to start of 7Ch-obj array, from dword_C0637C • Offset into 7Ch-obj array = (15h-10h) * 7Ch = 26Ch • Recall allocation size = 26Ch • Therefore returns a pointer to end of 7Ch-obj array Calls crash_sub() with ptr to end of 7Ch-obj array (ESI) OOB dereference at offset 34h from end of 7Ch-obj array Calling into sub_12B744()… Ret from sub_12B744()…
- 41. ++ Results CVE-2017-8502: Execution Trace List of Breakpoints First 0E1200h Message Second 0E1200h Message ECX = 38002D90 + 26C = 38002FFC = assumed-present 6th unk_obj
- 42. ++ Results • Root-cause – Excel assumes there are always (at least) 6 objects in the array when global dword_1461918 is 2Fh – Leading to out-of-boundary array dereference (aka memory corruption) • Exploitability CVE-2017-8502: Summary
- 43. ++ Results • Affects only Excel Protected-View (PVApp) • Aka “Out-of-Boundary Array Access” • Requires one 071200h IPC message – Part of Excel Protected-View design – Update formula bar with cell content, though editing still not allowed CVE-2017-8692: Uniscribe RCE Vulnerability IPC 071200h Message
- 44. ++ Results CVE-2017-8692: Trigger ScriptItemize ( [in] pwcInChars = L"j(@-g?Mcav)MzM_<m+T[zA46ykI#V52Kj|42" [in] cInChars = 0x00000004 [in] cMaxItems = 0x00000005 [in,opt] psControl = &(0x00800009) [in,opt] psState = &(0x0001) [out] pItems [out] pcItems ) EXCEL_071200 PvMsg = {}; PvMsg.UStrInChars.Buffer = 0x1; PvMsg.ui8Unknown_18 = 0x2; PvMsg.ui8Unknown_19 = 0x0; PvMsg.ui16Padding = 0x00; PVMsg.UStrInChars = {0x25, L"j(@-g?Mcav)MzM_<m+T[zA46ykI#V52Kj|42"};
- 45. ++ Results CVE-2017-8692: Trigger crash in gdi32full!ScriptItemize() API ScriptItemize ( [in] pwcInChars = L"j(@-g?Mcav)MzM_<m+T[zA46ykI#V52Kj|42" [in] cInChars = 0x00000004 [in] cMaxItems = 0x00000005 [in,opt] psControl = &(0x00800009) [in,opt] psState = &(0x0001) [out] pItems [out] pcItems ) call HeapAllocWrapper2 (dwBytes, ppBufferOut)
- 46. ++ Results CVE-2017-8692: Buffer pItems Allocation cMaxItems = cInChars > 2 ? (cInChars+1) : 2 = 5 Size of UnkBuf = cInChars * 4 * 3 = 30h bytes Size of pItems = (cMaxItems) * sizeof(SCRIPT_ITEM) = (cMaxItems) * 8 = 28h bytes cInChars = 4 30h bytes 28h bytes final_buffer pItems
- 47. ++ Results • Function loops pItems buffer to find matching SCRIPT_ITEM • Last SCRIPT_ITEM in pItems buffer is a End-of-Array marker CVE-2017-8692: gdi32full!FindMatchingPair() int __stdcall FindMatchingPair(SCRIPT_ITEM **ppItems, SCRIPT_ITEM *pItems_LastItem, ...) { ... SCRIPT_ITEM* var_10; if (*ppItems < pItems_LastItem) { do { var_10 = *ppItems; int iCharPosOfCurrScriptItem = (var_10 + 0)->iCharPos; int iCharPosOfNextScriptItem = (var_10 + 1)->iCharPos; //Out-Of-Bound Dereference int EDX = iCharPosOfNextScriptItem - iCharPosOfCurrScriptItem; if (var_10->a.eScript > 0x114) { ... } else if (var_10->a.eScript == 0x114) { ... } else { ... } (*ppItems)++; } while (*ppItems <= pItems_LastItem); } ... } Each loop dereferences current and next SCRIPT_ITEM Loop until last SCRIPT_ITEM(!)
- 48. ++ Results • MSDN ScriptItemize() Reference – Responsibility fall on developers to allocate the sufficient sized buffer • Recall: Size of pItems = cMaxItems * sizeof(SCRIPT_ITEM) • But there should have been checks in ScriptItemize() API? – “... while (*ppItems <= pItems_LastItem); ...” – Loop should have terminated at pItems[-2]? CVE-2017-8692: Summary
- 49. ++ Results • Case still open • Lucky bug discovered while minimizing for MSRC 40765 RtlFailFast() • Patch is scheduled for release Dec 2017/Jan 2018 • Will release technical details in due course… MSRC 40761: Invalid Pointer Typecast
- 50. ++ Conclusion MS Office 2016 Protected-View Sandbox
- 51. ++ Conclusion • Motivation and goals of this project • 3 attack surfaces for Protected-View sandbox escapes/bypass • IPC mechanism – Internal objects, scenarios and message formats – 72 (23 MSO+15 WWLIB+17 EXCEL+17 PPCORE) messages • Fuzzing optimizations to ↑ code-coverage, ↓ time Conclusion
- 52. ++ Conclusion • Results – Total issues: 4 (MSO.DLL), 2 (WWLIB.DLL), 3 (EXCEL.EXE), 0 (PPCORE.DLL) – 3 security issues – Vulnerabilities trend: Non-linear (buf[n] = x) heap corruption issues Conclusion
- 53. ++ Conclusion • Most modern mitigations (eg: DisableWin32kSystemCalls) disabled Conclusion 2007 2010 2013 2016 DEP:Enable OFF ON ON ON DEP:DisableATL OFF OFF ON ON ASLR:BottomUp ON ON ON ON ASLR:ForceRelocate OFF OFF ON ON ASLR:* OFF OFF OFF OFF StrictHandle:RaiseExceptionOnInvalid OFF OFF OFF [B] : ON [S] OFF [B] : ON [S] StrictHandle:HandleExceptionsPermanently OFF OFF OFF [B] : ON [S] OFF [B] : ON [S] System Call:DisallowWin32kSysCalls OFF OFF OFF OFF ExtensionPoint:DisableExtensionPoints OFF OFF OFF OFF DynamicCode:* OFF OFF OFF OFF CFG:* OFF OFF OFF OFF BinarySignature:* OFF OFF OFF OFF FontDisable:* OFF OFF OFF OFF ImageLoad:* OFF OFF OFF OFF [*] Results of ProcessMitigations 1.0.7 “Get-ProcessMitigation” on various (x86) MS Office
- 54. ++ Conclusion • Check for new Protected-View features – New IPC messages (rem 071200h:Update Formula Bar with Cell Content) • Remaining attack surfaces – Logic Quirks: “Trendy” Escapes – System-Calls: “Generic” Escapes Future Work
- 55. ++ MWR Labs • Questions? Thank You!