CVE-2016-7742: Arbitrary write to an uninitialized stack variable

--[ 1. Summary

A bug exists in the Apple version of the open source xar project. A
malformed archive file can cause the dereference and subsequent
arbitrary write to an uninitialized stack variable.

--[ 2. Discussion

The issue exists in the xar_unserialize function of lib/archive.c. Under
normal circumstances, the xml table of contents describing the files
contained within the archive is parsed without issue in lines 1501 to
1554. However, xar supports the concept of "subdocs" wherein a table of
contents can reference further xml to index file items in the xar
"heap". This next section of code appears incomplete (due to unused
variables) and is where the bug resides. The following is the section of
code containing the issue:

    1554    } else {
[1] 1555        xar_subdoc_t s;
    ....
    1561        i = xmlTextReaderAttributeCount(reader);
    1562        if( i > 0 ) {
    1563            for(i = xmlTextReaderMoveToFirstAttribute(reader); \
                        i == 1; \
                        i = xmlTextReaderMoveToNextAttribute(reader)) {
    ....
[2] 1568                if( aname && (strcmp("subdoc_name", aname) == 0) ) {
    1569                    name = (const unsigned char *)avalue;
    1570                } else {
[3] 1571                    a = xar_attr_new();
    1572                    XAR_ATTR(a)->key = strdup(aname);
    1573                    XAR_ATTR(a)->value = strdup(avalue);
[4] 1574                    XAR_ATTR(a)->next = XAR_SUBDOC(s)->attrs;
    1575                    XAR_SUBDOC(s)->attrs = XAR_ATTR(a);
    1576                }
    ....
    1580        s = xar_subdoc_new(x, (const char *)name);

At [1], on line 1555 the "xar_subdoc_t s" variable (which is actually
typedef'ed to a __xar_subdoc_t* pointer) is declared uninitialized. We
then enter a loop over the attributes of the xml element being parsed.
There is a check for an expected element "subdoc_name" at [2] but if
this fails, the code assumes that we are in a subdoc and we drop in to
code which appears to be copying attributes from the subdoc. The code
creates a new instance of a xar_attr at [3] then on line [4] attempts to
dereference and copy the attributes from the uninitialized
"xar_subdoc_ts".

It is my belief that given appropriate grooming of the stack by
iterating around the outer toc loop a number of times, this stack
pointer could be groomed to point to an attacker controlled section of
memory and allow an arbitrary write of data taken from the table of
contents. Below is the backtrace of the crash:

    #0  0x000000000040a204 in xar_unserialize
            (x=0x631bf0) at lib/archive.c:1575
    #1  0x0000000000406e14 in xar_open
            (file=0x7fffffffe49f "/tmp/crashes/crashes/crash1.xar",
                flags=0) at lib/archive.c:292
    #2  0x0000000000404047 in extract
            (filename=0x7fffffffe49f "/tmp/crashes/crashes/crash1.xar",
                arglen=0, args=0x6302a0)
            at src/xar.c:358
    #3  0x000000000040647e in main
            (argc=3, argv=0x7fffffffe178) at src/xar.c:1099

--[ 3. Resolution

As previously mentioned, this section of code appears incomplete so I
recommend revisiting the entire section, however, at a minimum, I
suggest ensuring that the xar_subdoc_t s pointer is initialized and
validated before use.