|
Message-Id: <20160918154533.28FC16C579F@smtpvmsrv1.mitre.org> Date: Sun, 18 Sep 2016 11:45:33 -0400 (EDT) From: cve-assign@...re.org To: bfriesen@...ple.dallas.tx.us Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: GraphicsMagick 1.3.25 fixes some security issues -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Date: Tue, 6 Sep 2016 20:50:23 -0500 (CDT) > Yesterday GraphicsMagick 1.3.25 was released. It fixes several > security issues: > 1. A last instance of CVE-2016-2317 (heap buffer overflow) in the MVG > rendering code (also impacts SVG). This problem was originally > reported by Gustavo Grieco. CVE does not support the concept of a different "instance" of an ID number that has different affected versions. For the aspect of the heap buffer overflow issue in MVG/SVG rendering that remained present in the 1.3.24 release (and was not fixed until 1.3.25), use CVE-2016-7446. This should be considered a clarification to the following NEWS excerpts: http://www.graphicsmagick.org/NEWS.html#may-30-2016 1.3.24 (May 30, 2016) SVG: Fixed heap and stack buffer overflows, as well as segmentation violations (CVE-2016-2317 and CVE-2016-2318). http://www.graphicsmagick.org/NEWS.html#september-5-2016 1.3.25 (September 5, 2016) SVG/MVG: Fix another case of CVE-2016-2317 (heap buffer overflow) in the MVG rendering code (also impacts SVG). > 2. A possible heap overflow of the EscapeParenthesis() function. > While I was not able to reproduce it for myself, the implementation is > replaced with a different algorithm. This problem was reported by > Gustavo Grieco. Use CVE-2016-7447. > 3. The Utah RLE reader did not validate that header information was > reasonable given the file size and so it could cause huge memory > allocations and/or consume huge amounts of CPU. This problem was > reported by Agostino Sarubbo. Use CVE-2016-7448. > 4. The TIFF reader had a bug pertaining to use of TIFFGetField() when > a 'count' value is returned. The bug caused a heap read overflow (due > to using strlcpy() to copy a possibly unterminated string) which could > allow an untrusted file to crash the software. >> Fix heap buffer read overflow while copying sized TIFF attributes. >> http://hg.code.sf.net/p/graphicsmagick/code/rev/eb58028dacf5 >>> https://blogs.gentoo.org/ago/2016/08/23/graphicsmagick-two-heap-based-buffer-overflow-in-readtiffimage-tiff-c/ >>> https://blogs.gentoo.org/ago/2016/09/07/graphicsmagick-null-pointer-dereference-in-magickstrlcpy-utility-c/ >>>> The problem was due to the definition of strlcpy() in that it is >>>> supposed to return the number of characters which would have been >>>> copied if the destination buffer was large enough. To satisfy this >>>> requirement, strlcpy() needs to continue scanning memory until it >>>> encounters a null byte in memory. >>>> >>>> The strlcpy() function has very nice properties but this weakness is >>>> something that developers need to be aware of. Use CVE-2016-7449 for all of these reported TIFF problems. The ultimate vulnerability was use of: strlcpy(attribute,text,Min(sizeof(attribute),(count+1))); three times in coders/tiff.c, where strlcpy is not an appropriate function choice for this type of scenario of untrusted-data copying. - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJX3rYOAAoJEHb/MwWLVhi2T8AP/2FLvqniHnnBY6teYw5BlnFI CfQhTDZnh9Y1/yKcHci9A3QPtcuNRkhpwTXIV3pBNsTLIm+/E+/q28YZzS+j9pzJ wdURRmR40Hg1fCztO+VRpoe2WTu1qwKiC7nVcnol2fGqtx+umy25Frtwo6TaQ6q6 D1YpbHwP4u5S91KX2dC3BStKY4jwgRtMCCOiojelKftvpxYu8oLXsVwBwKGOZPr9 Kk4SJiFdSKQrJzzZKB8srIwLkDjA8fXz3KV7nfSznt6TGwQyx0hMJdHm/bif9oVt ILZ6/IKXlAgN3z+gVdEhPaqzMjyUXskfiX1+8UZx2d9cumSlW9xbaQUBrdhIbC3w 6d0Mwcs/fG0zYULNpIiVCJrQFNjkAsIEL9wcEqaUoQmifXqgFZ4g1FPJi1xyjUNg hrkSOn4N/e2Y7LYlPgJeCUEjl+f00FA5/2rWSyk8V78vz5cLpFV5tQ2+5mRhXJCO mcmfo0TPeboyYidBXlLWj9BVPHSJySeylYdH6yHnhD1ZjC1C4gQVHhIcYezkFIiO KspZxgBpo+FC6uXnm4Pn3tR2o+XdgDvg8oe7pW4ZNb1lB6qMd90sMnWGIW+4XSWQ JQurAylyajRnZ0MN8pHR9fel++8aaIXqY/QK1JwUC3MIBZdwHs1OH6t2VBu4eNff Lk+EMJgP868wTRmhGWwK =DLQk -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.