The SKIA image decoder for the ICO file format has an out-of-bounds read condition that can lead to a pixel-based information leak. Depending on how the SKIA library is used, this could lead to ASLR bypass attacks, or direct information leak attacks (i.e. exfiltrating sensitive data from the victim's heap to an attacker in some manner).
The following code snippet is from SkICOImageDecoder::onDecode (skia/src/images/SkImageDecoder_libico.cpp):
...
const size_t size = read4Bytes(buf, 14);
const size_t offset = read4Bytes(buf, 18);
if (offset > length || size > length || ((uint64_t)offset + size) > length) {
return kFailure;
}
{
SkMemoryStream subStream(buf + offset, size, false);
SkAutoTDelete<SkImageDecoder> otherDecoder(SkImageDecoder::Factory(&subStream));
if (otherDecoder.get() != NULL) {
...
}
}
...
int bitCount = read2Bytes(buf, offset+14);
...
int begin = SkToInt(offset + 40);
Note that the offset field can be set to a value that is in bounds when compared to "length", but is out of bounds when a constant is added to it (e.g. 40 in the case of "begin").
This can lead to pixel data being read from out-of-bounds heap memory that is adjacent to the input buffer. An example of this behavior in an Android application (running on AOSP master, displaying to an ImageView after being converted to a Bitmap) is attached (ico_leak01.jpg). The crafted ICO file that triggers this condition is also attached (ico_leak01.ico).
This issue should be fixed by checking that all arithmetic performed on the supplied "offset" value is in bounds with respect to "length".
This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
