Buffer overflow in the jasstreamprintf function in libjasper/base/jasstream.c in JasPer 1.900.1 might allow context-dependent attackers to have an unknown impact via vectors related to the mifhdrput function and use of vsprintf.
Multiple integer overflows in JasPer 1.900.1 might allow context-dependent attackers to have an unknown impact via a crafted image file, related to integer multiplication for memory allocation.
A double free vulnerability in jasiccattrvaldestroy function in JasPer 1.900.1 and earlier allowing remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted ICC color profile in a JPEG 2000 image file was found.
Vulnerable code:
src/libjasper/base/jasicc.c: 258 jasiccproft jasiccprofload(jasstreamt in) 259 { ... 294 for (i = 0; i < numtags; ++i) { 295 tagtabent = &prof->tagtab.ents[i]; 296 if (tagtabent->off == JASCAST(jasiccuint32t, prevoff)) { 297 if (prevattrval) { 298 if (!(attrval = jasiccattrvalclone(prevattrval))) 299 goto error; 300 if (jasiccprofsetattr(prof, tagtabent->tag, attrval)) 301 goto error; 302 jasiccattrvaldestroy(attrval); 303 } else { 304 #if 0 305 jaseprintf("warning: skipping unknown tag type\n"); 306 #endif 307 } 308 continue; 309 } 310 reloff = tagtabent->off - curoff; 311 if (reloff > 0) { 312 if (jasstreamgobble(in, reloff) != reloff) 313 goto error; 314 curoff += reloff; 315 } else if (reloff < 0) { 316 / This should never happen since we read the tagged 317 element data in a single pass. / 318 abort(); 319 } 320 prevoff = curoff; 321 if (jasiccgetuint32(in, &type)) { 322 goto error; 323 } 324 if (jasstreamgobble(in, 4) != 4) { 325 goto error; 326 } 327 curoff += 8; 328 if (!(attrvalinfo = jasiccattrvalinfolookup(type))) { 329 #if 0 330 jaseprintf("warning: skipping unknown tag type\n"); 331 #endif 332 prevattrval = 0; 333 continue; 334 } 335 if (!(attrval = jasiccattrvalcreate(type))) { 336 goto error; 337 } ... 353 error: 354 if (prof) 355 jasiccprofdestroy(prof); 356 if (attrval) 357 jasiccattrvaldestroy(attrval); 358 return 0; 359 }
attrval variable is assigned on line 298 and freed with the call to jasiccattrvaldestroy() on line 302. If the tests on lines 312, 321, or 324 are true, the same pointer will be passed a second time to jasiccattrvaldestroy() on line 357.
Proposed patch:
http://seclists.org/oss-sec/2016/q1/att-507/CVE-2016-1577.patch
Public via:
http://seclists.org/oss-sec/2016/q1/507
A heap-based buffer overflow flaw was reported in JasPer's jpcdeccpsetfromcox() and jpcdeccpsetfromrgn() functions. Processing a specially-crafted image with an application that uses JasPer could cause the application to crash or, potentially, execute arbitrary code.
Acknowledgements:
Red Hat would like to thank oCERT for reporting these issues. oCERT acknowledges Jose Duart of the Google Security Team as the original reporter.
Heap-based buffer overflow in the jp2decode function in JasPer 1.900.1 and earlier allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted JPEG 2000 file.
oCERT reports an issue in jasper discovered by pyddeh:
"""
jpcdec.c:1204:
dec->numhtiles = JPCCEILDIV(dec->xend - dec->tilexoff, dec->tilewidth); dec->numvtiles = JPCCEILDIV(dec->yend - dec->tileyoff, dec->tileheight); dec->numtiles = dec->numhtiles dec->numvtiles; if (!(dec->tiles = jasmalloc(dec->numtiles sizeof(jpcdectilet)))) { return -1; }
the dec->XXX in JPCCEILDIV are all directly from the codestream, so dec->numtiles can be 0. In that case, the minimum-sized chunk returned by malloc can, depending on the code stream, be used later. I think this can cause the same problems as a use after free. Fix proposal:
if ( dec->numtiles == 0 || !(dec->tiles = jasmalloc(dec->numtiles sizeof(jpcdectilet)))) { return -1; }
"""
Acknowledgement:
Red Hat would like to thank oCERT for reporting this issue. oCERT acknowledges pyddeh as the original reporter.
Race condition in the jasstreamtmpfile function in libjasper/base/jasstream.c in JasPer 1.900.1 allows local users to cause a denial of service (program exit) by creating the appropriate tmp.XXXXXXXXXX temporary file, which causes Jasper to exit. NOTE: this was originally reported as a symlink issue, but this was incorrect. NOTE: some vendors dispute the severity of this issue, but it satisfies CVE's requirements for inclusion.
Double free vulnerability in the jasiccattrvaldestroy function in JasPer 1.900.1 and earlier allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted ICC color profile in a JPEG 2000 image file.
Multiple stack-based buffer overflows in jpcqmfb.c in JasPer 1.900.1 and earlier allow remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted JPEG 2000 image.
A number of vulnerabilities were found and reported by CERT in JasPer which may allow a remote unauthenticated attacker to execute arbitrary code.
Reference: http://www.kb.cert.org/vuls/id/887409
The jpccrggetparms function in libjasper/jpc/jpccs.c in JasPer 1.900.1 uses an incorrect data type during a certain size calculation, which allows remote attackers to trigger a heap-based buffer overflow and execute arbitrary code, or cause a denial of service (heap memory corruption), via a crafted component registration (CRG) marker segment in a JPEG2000 file.
A vulnerability was found in the way the JasPer's jpcpinextcprl() function parses certain JPEG 2000 image files. A specially crafted file could cause an application using JasPer to crash.
Report with the reproducer attached: http://seclists.org/oss-sec/2016/q1/84
A vulnerability was found in the way the JasPer's jasmatrixclip() function parses certain JPEG 2000 image files. A specially crafted file could cause an application using JasPer to crash.
Original bug report (with reproducer attached):
http://seclists.org/oss-sec/2016/q1/233
CVE assignment:
http://seclists.org/oss-sec/2016/q1/235
Memory leak in jasiccprofcreatefrombuf function in JasPer 1.900.1 and earlier was found, allowing remote attackers to cause a denial of service (memory consumption) via a crafted ICC color profile in a JPEG 2000 image file.
Vulnerable code:
src/libjasper/base/jasicc.c: 1685 jasiccproft jasiccprofcreatefrombuf(uchar buf, int len) 1686 { 1687 jasstreamt in; 1688 jasiccproft prof; 1689 if (!(in = jasstreammemopen(JASCAST(char , buf), len))) 1690 goto error; 1691 if (!(prof = jasiccprofload(in))) 1692 goto error; 1693 jasstreamclose(in); 1694 return prof; 1695 error: 1696 return 0; 1697 }
jasstreamt allocated by the call to jasstreammemopen() is leaked if jasiccprofload() fails on line 1691.
Proposed patch:
http://seclists.org/oss-sec/2016/q1/att-507/CVE-2016-2116.patch
Public via (contains crash report):
http://seclists.org/oss-sec/2016/q1/507
A use-after-free which leads to double-free vulnerability was found in Jasper JPEG-2000 library, in src/libjasper/mif/mifcod.c file.
553 case MIFHSAMP: 554 cmpt->sampperx = atoi(jastvparsergetval(tvp)); 555 break; 556 case MIFVSAMP: 557 cmpt->samppery = atoi(jastvparsergetval(tvp)); 558 break;
572 jastvparserdestroy(tvp); 573 if (!cmpt->sampperx || !cmpt->samppery) { 574 goto error; 575 } 576 if (mifhdraddcmpt(hdr, hdr->numcmpts, cmpt)) { 577 goto error; 578 } 579 return 0; 580 581 error: 582 if (cmpt) { 583 mifcmptdestroy(cmpt); 584 } 585 if (tvp) { 586 jastvparserdestroy(tvp); 587 } 588 return -1;
Both tvp and tvp->buf are freed by jastvparserdestroy(tvp), but if one of the two following branch conditions is taken, a second call to jastvparserdestroy(tvp) occurs. It is a use-after-free because before calling free in jastvparserdestroy there is a check to tvp->buf, while tvp could have been freed. Two double free take place just after this check (on tvp->buf and tvp).
Public via:
http://seclists.org/oss-sec/2015/q3/408
Acknowledgements:
Name: Josselin Feist