See how jasper project compares to other vendors in security performance
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.
Integer overflow in the jasmatrixcreate function in JasPer allows context-dependent attackers to have unspecified impact via a crafted JPEG 2000 image, related to integer multiplication for memory allocation.
An issue was discovered in JasPer 1.900.8, 1.900.9, 1.900.10, 1.900.11, 1.900.12, 1.900.13, 1.900.14, 1.900.15, 1.900.16, 1.900.17, 1.900.18, 1.900.19, 1.900.20, 1.900.21, 1.900.22, 1.900.23, 1.900.24, 1.900.25, 1.900.26, 1.900.27, 1.900.28, 1.900.29, 1.900.30, 1.900.31, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.12, 2.0.13, 2.0.14, 2.0.15, 2.0.16. There is a heap-based buffer over-read of size 8 in the function jasimagedepalettize in libjasper/base/jasimage.c.
An issue was discovered in JasPer 1.900.8, 1.900.9, 1.900.10, 1.900.11, 1.900.12, 1.900.13, 1.900.14, 1.900.15, 1.900.16, 1.900.17, 1.900.18, 1.900.19, 1.900.20, 1.900.21, 1.900.22, 1.900.23, 1.900.24, 1.900.25, 1.900.26, 1.900.27, 1.900.28, 1.900.29, 1.900.30, 1.900.31, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.12, 2.0.13, 2.0.14, 2.0.15, 2.0.16. There is a heap-based buffer overflow of size 1 in the function jasicctxtdescinput in libjasper/base/jasicc.c.
An invalid memory write issue in Jasper-Software Jasper v.4.1.1 and before allows a local attacker to execute arbitrary code.
A vulnerability was identified in JasPer up to 4.2.5. This affects the function jpcdecdump of the file src/libjasper/jpc/jpcdec.c of the component JPEG2000 File Handler. The manipulation leads to use after free. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named 8308060d3fbc1da10353ac8a95c8ea60eba9c25a. It is recommended to apply a patch to fix this issue.
Heap buffer overflow to out of bounds write in the jpc encoder's cpcreate() routine when resolution levels are greater than max.
Reference: https://github.com/jasper-software/jasper/issues/252
Upstream patch: https://github.com/jasper-software/jasper/pull/253
A double free vulnerability was found in memclose in jasstream.c triggered by invoking imginfo command on specially crafted image file.
CVE assignment:
http://www.openwall.com/lists/oss-security/2016/10/16/14
Memory allocation failure in jasmalloc triggered by crafted file was found.
CVE assignment:
http://seclists.org/oss-sec/2016/q4/214
A heap-buffer overflow vulnerability was found in QMFB code in JPC codec caused by buffer being allocated with too small size.
Upstream bugs:
https://github.com/mdadams/jasper/issues/93 https://github.com/mdadams/jasper/issues/94
Upstream patch:
https://github.com/mdadams/jasper/commit/4a59cfaf9ab3d48fca4a15c0d2674bf7138e3d1a
A stack-based buffer overflow vulnerability was found in jasper in jpctsfbgetbands2 function in jpctsfb.c triggered by parsing of a malicious file.
Upstream patch:
https://github.com/mdadams/jasper/commit/1abc2e5a401a4bf1d5ca4df91358ce5df111f495
References:
http://seclists.org/oss-sec/2016/q4/473
An integer overflow in jpcdecprocesssiz was found that can be triggered by crafted image file when given as input to imginfo
Upstream patch:
https://github.com/mdadams/jasper/commit/d91198abd00fc435a397fe6bad906a4c1748e9cf
CVE assignment:
http://seclists.org/oss-sec/2016/q4/441
An integer overflow vulnerability that results into use of uninitialized value in jpcpinextcprl was found.
Upstream patch:
https://github.com/mdadams/jasper/commit/1f0dfe5a42911b6880a1445f13f6d615ddb55387
Reference:
http://seclists.org/oss-sec/2017/q1/609
Integer overflow in the jpcdectiledecode function in jpcdec.c in JasPer before 1.900.12 allows remote attackers to have unspecified impact via a crafted image file, which triggers a heap-based buffer overflow.
Heap-based buffer overflow in the jpcdecdecodepkt function in jpct2dec.c in JasPer 2.0.10 allows remote attackers to have unspecified impact via a crafted image.
An out-of-bounds heap read vulnerability was found in jpcpinextpcrl() function of jasper when processing crafted input.
Upstream bug:
https://github.com/mdadams/jasper/issues/103
Upstream patch:
https://github.com/mdadams/jasper/commit/99a50593254d1b53002719bbecfc946c84b23d27
Acknowledgments:
Name: Liu Bingchang (IIE)
An issue was discovered in JasPer 2.0.14. There is a heap-based buffer over-read of size 8 in the function jp2decode in libjasper/jp2/jp2dec.c.
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.
An assertion failure was possible to trigger in JPCNOMINALGAIN.
CVE assignment:
http://seclists.org/oss-sec/2016/q4/441
An assertion failure was possible to trigger in jpcdequantize.
CVE assignment:
http://seclists.org/oss-sec/2016/q4/441
An assertion failure was possible to trigger in jpcfloorlog2.
CVE assignment:
http://seclists.org/oss-sec/2016/q4/441
Last updated 24 July 2024
An assertion failure was used in JPC bitstream code when integer larger than what can be handled is requested.
Upstream patch:
https://github.com/mdadams/jasper/commit/1e84674d95353c64e5c4c0e7232ae86fd6ea813b
CVE assignment:
http://seclists.org/oss-sec/2016/q4/441
Last updated 24 July 2024
JasPer 2.0.12 is vulnerable to a NULL pointer exception in the function jp2encode which failed to check to see if the image contained at least one component resulting in a denial-of-service.
An assertion test was used when ensuring the component domains are the same for the ICT/RCT in the JPC codec.
Upstream patch:
https://github.com/mdadams/jasper/commit/dee11ec440d7908d1daf69f40a3324b27cf213ba
CVE assignment:
http://seclists.org/oss-sec/2016/q4/441