New issue
Advanced search Search tips

Issue 823 link

Starred by 4 users

Issue metadata

Status: Fixed
Closed: Jul 2016

Sign in to add a comment

Symantec: PowerPoint misaligned stream-cache remote stack buffer overflow CVE-2016-2209

Project Member Reported by, May 11 2016

Issue description

A PowerPoint PPT file is a complicated OLE compound document comprising of a series of streams. The format is described by Microsoft in [MS-PPT].

Symantec have implemented an I/O abstraction layer for seeking within the streams of a compound document, which they use to extract embedded objects like VBA macros and so on. Unfortunately, a bug in this I/O abstraction results in a critical security vulnerability. The bug occurs when a read request can be satisfied from the cache, but from a non-zero start offset. In this case, the request size is always rounded to (CACHE_SIZE - Offset), which may not be correct.

For example, a read request that can be satisfied from the stream cache in these ways:

|        CACHE            |

1.              <--------->   Non-zero offset, but entire cache needed.
2. <------>                   Zero offset, but not the entire cache.
3. <---------------------->   Entire cache.
4.         <---->             Non-zero offset and not entire cache.

All of these cases work fine except 4, where a buffer overflow occurs, because the request is rounded up to (CACHE_SIZE - Offset). It seems incredible that this bug wasn't found during testing or even on ITW documents just by chance. Nevertheless, by carefully constructing a powerpoint file with a series of records that massage the cache with a series of records, we can trigger a stack buffer overflow of attacker controlled data.

The easiest way to do this is via PPFindRecSet in libdec2ss (this is part of ccScanw.dll on Windows). Early on when processing powerpoint documents Symantec attempt to find the last edit via RT_UserEditAtom, then extract a set of records for RT_List and RT_ExternalObjectList allowing us to massage the stream cache appropriately.

Naturally, Symantec disable /GS on Windows and do not use -fstack-protector, making exploitation absolutely trivial. The attached document redirects execution to 0x41414141 reliably on Windows.

0:065> g
(1074.a14): Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=000025a0 ecx=00000200 edx=000025a0 esi=0396e358 edi=00002524
eip=41414141 esp=056df558 ebp=00000000 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
41414141 ??              ???
0:065> lmv m ccScanW
start    end        module name
65820000 65a4f000   ccScanw    (deferred)             
    Image path: C:\Program Files (x86)\Norton Security\Engine\\ccScanw.dll
    Image name: ccScanw.dll
    Timestamp:        Tue Jan 26 13:51:55 2016 (56A7EA7B)
    CheckSum:         0022B3ED
    ImageSize:        0022F000
    File version:
    Product version:
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Symantec Corporation
    ProductName:      Symantec Security Technologies
    InternalName:     ccScan
    OriginalFilename: CCSCAN.DLL
    FileDescription:  Symantec Scan Engine
    LegalCopyright:   Copyright (c) 2015 Symantec Corporation. All rights reserved.

The fix is simply to round up requests to MIN(RequestSize, CACHE_SIZE).

I verified this bug exists on the following products:

* Norton Antivirus (All Platforms)
* Symantec Endpoint (All Platforms)
* Symantec Scan Engine (All Platforms)
* Symantec Email Security (All Platforms)

And probably all other Symantec and Norton branded products.


PPGetVBAEmbedListInfo() uses PPFindRecSet(), which is definitely the easiest way to exploit this. The prototype is something like:

int PPFindRecSet(tagSS_STREAM *stream,
                 unsigned StartOffset,
                 unsigned EndOffset,
                 short count,
                 short *RequiredRecordTypes,
                 unsigned *RecordOffsets,
                 int *RecordLengths);

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

95.9 KB View Download
119 KB View Download
Project Member

Comment 1 by, Jun 14 2016

Here is an exploit for this issue that reliably jumps execution to an int3 instruction.

$ make
nasm -O0 -f bin -o streamppt.txt streamppt.asm
streamppt.asm:40: warning: Target: Norton Antivirus Windows, ccscanw version
13.3 KB Download
Project Member

Comment 2 by, Jun 14 2016

I had a phone call with Symantec Security. Because so many products are affected by this issue they're unable to release updates at the same time and plan to do so over a two week period starting June 14 and finishing on June 28.

They're also unable to liveupdate all of their products, some products will require that administrators take action and install an update manually.

That is really not good.

Project Member

Comment 3 by, Jun 28 2016

Labels: -Restrict-View-Commit
The disclosure date is today, unrestricting bugs.

Also about to unrestrict more Symantec Memory corruption vulnerabilities in  issue 810 , issue 813,  issue 814 ,  issue 816 ,  issue 818 ,  issue 819  and  issue 821 . 

Symantec are planning to release an advisory shortly.
Project Member

Comment 4 by, Jun 28 2016

Summary: Symantec: PowerPoint misaligned stream-cache remote stack buffer overflow CVE-2016-2209 (was: Symantec: PowerPoint misaligned stream-cache remote stack buffer overflow)
Project Member

Comment 5 by, Jun 28 2016

Issue 813 has been merged into this issue.

Comment 6 Deleted

Project Member

Comment 7 by, Jul 5 2016

Status: Fixed (was: New)
comment 1 has a working proof of concept.

Comment 8 Deleted

Comment 9 Deleted

Sign in to add a comment