Fwd: Security vulnerability - read out-of-bounds leads to memory leak

[Ibrahim el-sayed <i.elsayed92 () gmail com>]

Hi CVE-Assignemnt Team,
I would like to request a CVE for a read out-of-bound in little cms which was fixed in the following upstream push
https://github.com/mm2/Little-CMS/commit/5ca71a7bc18b6897ab21d815d15e218e204581e2 
<https://github.com/mm2/Little-CMS/commit/5ca71a7bc18b6897ab21d815d15e218e204581e2>
The details of the vulnerability can be found in the forwarded email.

Best Regards
Ibrahim M. El-Sayed
Security Engineer
https://www.ibrahim-elsayed.com/ <https://www.ibrahim-elsayed.com/>
@ibrahim_mosaad

> Begin forwarded message:
>
> From: Ibrahim el-sayed <i.elsayed92 () gmail com>
> Subject: Re: Security vulnerability - read out-of-bounds leads to memory leak
> Date: August 15, 2016 at 10:40:15 PM GMT+1
> To: LittleCMS Support <info () littlecms com>
>
>
> > On Aug 15, 2016, at 10:32 PM, LittleCMS Support <info () littlecms com <mailto:info () littlecms com>> wrote:
> >
> >
> > Hi,
> >
> > Thanks for reporting, and sorry about the delay. August and a local festivity means everybody on holidays right now.
> No worries :)
> > This is a true bug, so many thanks for uncovering it. I have uploaded a fix to GIT.
> Thank you so much!  I can confirm the fix on GIT
> > After examining the case, it seems to me that the severity is low, since you need a crafted profile and execution of 
> > code to read the heap, also I have checked it to happen only when a profile is hold in memory. It does not happen 
> > when the profile is file-based.
> I have found the bug basically while fuzzing ImageMagick. The bug was triggered regardless of the command or the 
> option was passed to ImageMagick. Given the fact the ImageMagick is deployed heavily on many web servers and the 
> exploit is very easy, I give it a bit of a moderate rating just for the context ^^
>
> > Many thanks again for uncovering the bug.
> Thanks for fixing the bug.
> > Marti Maria
> > The LittleCMS project
> > http://www.littlecms.com <http://www.littlecms.com/>
> >
> > From: Ibrahim el-sayed [mailto:i.elsayed92 () gmail com <mailto:i.elsayed92 () gmail com>]
> > Sent: domingo, 14 de agosto de 2016 20:58
> > To: info () littlecms com <mailto:info () littlecms com>
> > Subject: Re: Security vulnerability - read out-of-bounds leads to memory leak
> >
> > ping!!
> > > On Aug 10, 2016, at 9:44 PM, Ibrahim el-sayed <i.elsayed92 () gmail com <mailto:i.elsayed92 () gmail com>> wrote:
> > >
> > > Hi guys,
> > > I was fuzzing ImageMagick and I ended up finding a vulnerability in lcms2. The vulnerability is read read-out-of 
> > > bounds which enables me to read most of the data in the heap.
> > >
> > >
> > > The vulnerabilities exists in cmstypes.c ==> function: Type_MLU_Read
> > > line 1454: if (!_cmsReadUInt32Number(io, &Offset)) goto Error;
> > >
> > > The function reads the offset from the provided ICC profile (exactly from location 0x158  to 0x15B in the attached 
> > > PoC)
> > >
> > > line 1460: BeginOfThisString = Offset - SizeOfHeader - 8;
> > > line 1464: mlu ->Entries[i].StrW = (BeginOfThisString * sizeof(wchar_t)) / sizeof(cmsUInt16Number);
> > >
> > > We can see from the previous lines that offset is basically used in the assignemnt of mlu->Entries[i].StrW which 
> > > means we can control StrW
> > >
> > > To trigger the vulnerability we do the following
> > >
> > > icc_profile = cmsOpenProfileFromMem(data, (cmsUInt32Number) res); // We read the parse the ICC Profile
> > > cmsGetProfileInfoASCII(icc_profile,cmsInfoCopyright, "en","US", info, Buf_Len); // then we read the profile info 
> > > into an ascii buffer
> > >
> > >
> > > To explain better, the backtrace is
> > >
> > > (gdb) bt
> > > #0  0x00007ffff7ba2593 in cmsMLUgetASCII (mlu=0x6043a0, LanguageCode=0x400da4 "en", CountryCode=0x400da1 "US", 
> > > Buffer=0x7fffffffd490 "", BufferSize=4096) at cmsnamed.c:378
> > > #1  0x00007ffff7b8c7ae in cmsGetProfileInfoASCII (hProfile=0x6034f0, Info=cmsInfoCopyright, LanguageCode=0x400da4 
> > > "en", CountryCode=0x400da1 "US", Buffer=0x7fffffffd490 "", BufferSize=4096) at cmsio1.c:1021
> > > #2  0x0000000000400c27 in main ()
> > >
> > >
> > > Inside cmsMLUgetASCII the following line executes
> > > cmsnamed.c:360  Wide = _cmsMLUgetWide(mlu, &StrLen, Lang, Cntry, NULL, NULL); //Wide contains the buffer which will 
> > > be copied from memory after being converted into ascii and returned to the user
> > >
> > >
> > > _cmsMLUgetWide basically returns the following ptr
> > > cmsnamed.c:324  (wchar_t*) ((cmsUInt8Number*) mlu ->MemPool + v -> StrW);
> > >
> > > and we have a control over StrW.
> > >
> > > Technically we can read any chunk of data starting from mlu ->MemPool+4 to     mlu ->MemPool+ 0x1ffffffc6
> > >
> > >
> > > You can find attached,
> > > PoC1 ==> ICC profile that generates a segfault
> > > PoC2 ==> ICC profile that dumps from mlu->MemPool + 0x148 # I can control 0x148 from the limits I mentioned above 
> > > (0x4 - 0x1ffffffc6)
> > > test.c ==> source code that produces the crash
> > >
> > >
> > >
> > > <Vuln.zip>
> > >
> > > Best Regards
> > > Ibrahim M. El-sayed
> > > Security Engineer
> > > @ibrahim_mosaad
> > > https://www.ibrahim-elsayed.com <https://www.ibrahim-elsayed.com/>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail