Description: LibRaw before 0.20-Beta3 has an out-of-bounds write in parse_exif() in metadata\exif_gps.cpp via an unrecognized AtomName and a zero value of tiff_nifds. Maintainer, please bump.
Beta there is highly unstable, rather not.
Reopening, changing to [upstream] since the upstream version is broken and won't be packaged
CVE-2020-15503: LibRaw before 0.20-RC1 lacks a thumbnail size range check. This affects decoders/unpack_thumb.cpp, postprocessing/mem_image.cpp, and utils/thumb_utils.cpp. For example, malloc(sizeof(libraw_processed_image_t)+T.tlength) occurs without validating T.tlength. Patch: https://github.com/LibRaw/LibRaw/commit/20ad21c0d87ca80217aee47533d91e633ce1864d
As per zlogene, these files don't exist in the version we have packaged in Gentoo. I guess the vulnerability was introduced in master at some point.
That's not true, if you'll read the CVE it doesn't have "min" version that was introduced. Files are not in master because author did a refactoring and split the same code into multiple places. If you'll read the changgelog (https://www.libraw.org/news/libraw-0-20-rc1): "dcraw_common.cpp and libraw_cxx.cpp are split into multiple code chunks placed in separate subfolders (decoders/ for raw data decoders, metadata/ for metadata parsers, etc)" So I would say that it is safe to say that current libraw is vulnerable. If then you would manually check the files in question in 0.19: you can find the vulnurable function here: https://github.com/LibRaw/LibRaw/blob/beeb572687270d49c16734c9ca620982151dbeff/src/libraw_cxx.cpp#L4235-L4241 and it's code is pretty much the same as it would be before the patch in current master. mem_image file's function is here: https://github.com/LibRaw/LibRaw/blob/beeb572687270d49c16734c9ca620982151dbeff/src/libraw_cxx.cpp#L3712-L3715 And function from thumb_utils is here: https://github.com/LibRaw/LibRaw/blob/beeb572687270d49c16734c9ca620982151dbeff/src/libraw_cxx.cpp#L3976-L3981
Also some distros (RHEL/Fedora) backported the patch: https://bugzilla.redhat.com/show_bug.cgi?id=1853477 Basically some one should have a look at the patch there and decide if it covers those CVEs. As the code was rearranged and support for some of the cameras are new to 0.20, so it would require some effort to backport and validate RHEL/Fedora approach
(In reply to Vladimir Smirnov from comment #6) > Also some distros (RHEL/Fedora) backported the patch: > https://bugzilla.redhat.com/show_bug.cgi?id=1853477 > > Basically some one should have a look at the patch there and decide if it > covers those CVEs. As the code was rearranged and support for some of the > cameras are new to 0.20, so it would require some effort to backport and > validate RHEL/Fedora approach As I told you in private cinversation it *may* fix one of two vulnerabilities, another is uncovered by distros at all. Will take a look later.