RuntimeException thrown from ImageReaders
See original GitHub issueHi Harald.
Extracting relevant Exceptions wasn’t a very easy task, as the original log file is has 144471 lines. I had to do it in several steps using heavy regex’ing and manual labour 😉 As a result I can have made some errors or duplicated some Exceptions because my memory has it’s limitations.
First I filtered the original log file to exclude “non relevant” stuff. This is the filtered log file:
Hopefully you won’t need that, but I attach it in case you need some more context or I forgot something.
I then tried to extract “one instance” of what seemed to me like the same “bug”. The result of this is here:
extractedRuntimeExceptions.txt
The calling code is usually either the same as that in #329 or a normal read()
. MemoryCacheImageInputStream
is used exclusively.
@Sami32 Can you upload the exact files used in extractedRuntimeExceptions.txt? The file name in question is always the one described in the single line following the stack trace (Adding new child…).
Issue Analytics
- State:
- Created 7 years ago
- Comments:7 (2 by maintainers)
Top GitHub Comments
There were actually a few bugs hidden in there…
Thank you for your patience! 😉
– Harald K
The more I think about it the more I think it’s false positives. These images has been specificly crafted to challenge image decoders, producing invalid indexes and producing buffer overflow and underruns. The trojan reported was one that could be embedded in images exploiting a bug i Windows Media Player. It’s very likely, as I see it, that the technique employed by this trojan is some specially crafted buffer overflow injecting code that way. Some of the anti-virus software probably simply does a generic check for an image with the same buffer overflow characteristics without checking if there’s any actual malicious payload, and thus some of these images are flagged.
For the interested: How security flaws work the buffer overflow.