Dear Maintainer,

I am reporting on behalf of an engineer at Quarkslab, an out-of-bounds read and heap out-of-bounds write in antiword 0.37-17 when decoding OLE PPS directory entry names.

In wordole.c, bGetPPS obtains the name length directly from offset 0x40 of the attacker-controlled 128-byte PPS directory entry:

    tNameSize = (size_t)usGetWord(0x40, aucBytes);
    tNameSize = (tNameSize + 1) / 2;
    vName2String(atPPSlist[iIndex].szName, aucBytes, tNameSize);

The resulting tNameSize is then passed to vName2String without validating it against either the input PPS entry size or the size of the destination buffer.

The destination, szName, is a fixed 32-byte field:

    for (tIndex = 0, pcChar = szName;
         tIndex < 2 * tNameSize;
         tIndex += 2, pcChar++)
        *pcChar = (char)aucBytes[tIndex];

    szName[tNameSize - 1] = '\0';

Since the source length is a 16-bit document-controlled value, the loop can both read beyond the 128-byte PPS entry and write far beyond the 32-byte destination field.

CWE: CWE-787  (Out-of-bounds Write)
             CWE-125  (Out-of-bounds Read)
             CWE-1284 (Improper Validation of Specified Quantity in Input)
             CWE-120  (Buffer Copy without Checking Size of Input)

Security impact
===============

The out-of-bounds write can corrupt heap memory following the PPS list.
When the affected entry is the final element in the allocated array, the write can reach metadata belonging to the following heap chunk.

Our analysis indicates that this constitutes a potentially exploitable heap-corruption primitive. Reliable arbitrary code execution has not been demonstrated.

Reproduction
============

With the attached PoC document:

    antiword -a a4 ./sample_oob_write_3.doc

Expected behavior:
The PPS name length should be validated against both the source entry and the fixed-size destination before copying.

The issue was reproduced with antiword 0.37-17.

I have attached the PoC document and a detailed technical report.

Regards,
Salwa Souaf
Quarkslab VulnReport Team