Date: Wed, 1 Nov 2017 08:10:33 +0200
From: Maor Shwartz <maors@...ondsecurity.com>
To: fulldisclosure@...lists.org
Cc: SecuriTeam Secure Disclosure <ssd@...ondsecurity.com>
Subject: [FD] SSD Advisory – GraphicsMagick Multiple Vulnerabilities

SSD Advisory – GraphicsMagick Multiple Vulnerabilities

Full report: https://blogs.securiteam.com/index.php/archives/3494
Twitter: @SecuriTeam_SSD
Weibo: SecuriTeam_SSD

Vulnerabilities summary
The following advisory describes two (2) vulnerabilities found in
GraphicsMagick.

GraphicsMagick is “The swiss army knife of image processing. Comprised of
267K physical lines (according to David A. Wheeler’s SLOCCount) of source
code in the base package (or 1,225K including 3rd party libraries) it
provides a robust and efficient collection of tools and libraries which
support reading, writing, and manipulating an image in over 88 major
formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG,
PDF, PNM, and TIFF.”

The vulnerabilities found are:

Memory Information Disclosure
Heap Overflow

Credit
An independent security researchers, Jeremy Heng (@nn_amon) and Terry Chia
(Ayrx), has reported this vulnerability to Beyond Security’s SecuriTeam
Secure Disclosure program

Vendor response
The vendor has released patches to address these vulnerabilities
(15237:e4e1c2a581d8 and 15238:7292230dd18).

For more details:
ftp://ftp.graphicsmagick.org/pub/GraphicsMagick/snapshots/ChangeLog.txt

Vulnerabilities details

Memory Information Disclosure
GraphicsMagick is vulnerable to a memory information disclosure
vulnerability found in DescribeImagefunction of the magick/describe.c file.

The portion of the code containing the vulnerability responsible of
printing the IPTC Profile information contained in the image.

This vulnerability can be triggered with a specially crafted MIFF file.

The code which triggers the vulnerable code path is:

===

```c
 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 profile_length variable is set in the following field in the
MIFF header: profile-iptc=8

There is an out-of-bounds buffer dereference whenever profile[i] is
accessed because the increments of i is never checked.

If we break on line 738 of describe.c, we can explore what is present on
the heap during the strncpyoperation.

===

gef➤  x/2xg profile

0x8be210:    0x08000a001c414141    0x00007ffff690fba8

===

The 8 bytes 0x08000a001c414141 is the profile payload present in the
specially crafted MIFF file.

===

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

===

Now we can calculate the offset to libc base – 0x3c4b98

--
Thanks
Maor Shwartz
Beyond Security
GPG Key ID: 93CC36E2DE7FF514

Download attachment "SSD Advisory – GraphicsMagick Multiple Vulnerabilities – SecuriTeam Blogs.pdf" of type "application/pdf" (173611 bytes)


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists