Exiv2

That certainly fixes my testcase. I'll check the other cases, thanks for the quick response.

Unfortunately (sorry!) I didn't look carefully enough the first time. Here's some more possible issues:

asfvideo.cpp:560/570/580, riffvideo.cpp:764/786/856 might have the same problem. riffvideo.cpp:654 also looks unsafe (the size comes from line 572?).

riffvideo.cpp:927 might be unsafe in 32-bit builds because the allocation on riffvideo.cpp:868 looks like it can be overflowed (if I provide a size of -1).

Obviously I'm not very familiar with the exiv2 code, but a lot of the other code uses a separate buffer and passes that buf.size_ to the io_->read calls, so there's no chance of a heap overflow. Perhaps it might be worth doing that in some of these cases.

Alyssa Milburn wrote:

That certainly fixes my testcase. I'll check the other cases, thanks for the quick response.

Unfortunately (sorry!) I didn't look carefully enough the first time. Here's some more possible issues:

Don't worry. We are happy to have you here, reporting these issues.
Lets keep this issue open till all the bugs are solved.

It is better that we take some more time on analyzing and fixing bugs right now, than having major program crashes later.
Thank you for analyzing Exiv2, and helping in making it more sturdy and robust.

I will keep on patching the issues that you may find, meanwhile I will expect you to find more.

I'd like to thank both of you for working on this stuff. Fuzzing and hardening the code is good for everybody. Thank you both for working on this.

A couple of questions for Alyssa:
1) Would it help you if we grant you write access to the depot?
2) There's a corrupted file being discussed in Forum topic 1477
http://dev.exiv2.org/boards/3/topics/1477

I'm going to take a look at Aleksandr's file this evening. If you have time and interest to investigate, I would very much appreciate your analysis.

Robin

If Abhinav or others familiar with the project can find the time to fix these bugs, then I think it's a much better idea for them to make the fixes, since they're in a much better position to test the code (and are presumably going to be maintaining it in the long-term). If you need suggested patches for any of these issues then I can make an attempt, though.

Beware that I'm not running an actual fuzzer, and there might well be other obvious bugs which would be caught by one; my filed bugs are just the result of my glancing through the source code and seeing if I spot any suspicious-looking code.

(The file in the forum post seems to be corrupt/truncated as diagnosed; I don't think I can add anything to what's already been said.)

Hi Alyssa,
I have submitted some new commits. Please ensure that the bugs that you noticed before have been taken care off.
If you think there are some more vulnerable issues, then please inform us whenever you get time.

Else I would like to close both the issue #890 and #888.