Date: Mon, 15 Aug 2016 22:43:19 +0100 From: Ibrahim el-sayed <i.elsayed92@...il.com> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com Subject: Fwd: Security vulnerability - read out-of-bounds leads to memory leak 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@...il.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@...tlecms.com> > > >> On Aug 15, 2016, at 10:32 PM, LittleCMS Support <info@...tlecms.com <mailto:info@...tlecms.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@...il.com <mailto:i.elsayed92@...il.com>] >> Sent: domingo, 14 de agosto de 2016 20:58 >> To: info@...tlecms.com <mailto:info@...tlecms.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@...il.com <mailto:i.elsayed92@...il.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/> [ CONTENT OF TYPE text/html SKIPPED ] [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ