-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGABRT in src/jp2image.cpp Safe::add #303
Comments
I can't reproduce this issue. I only receive following:
In what git commit are you executing? |
I think you need to set virtual memory to 1G. "ulimit -v 1048576" @fgeek |
Can't reproduce and it is completely normal that program like exiv2 takes lots amount of memory when you are executing it on fuzzed samples. These are denial of service issues in some context dependent cases, but I don't think there is any issue in this case. I tested in the latest commit bb20191. |
CVE-2018-10998 has been assigned for this issue (not requested by me), which I think should be REJECTED. It would be nice @legend-issue if you would first wait for upstream response before requesting CVEs and you should always focus your fuzzing efforts to the latest commit when fuzzing software like exiv2, which is quite heavily fuzzed already. |
Hi guys, thanks for the report. I just want to confirm that I could reproduce the issue and I get this:
|
Hum ... wait a second. Our code is throwing an exception intentionally in this piece of code:
And later the exiv2 app is not catching that exception. Honestly I do not know much about Linux security issues. I never thought if letting an exception reach the main() function would cause any risks from the security point of view. Should we try to catch that exception and exit gracefully? I would appreciate if you point me to some resources where I can learn about this topic. |
Letting an exception through is bad style, as an uncaught exception results in a call to I guess we should just catch the exception and return with 0. @legend-issue Please read the error message next time. This issue caused far too much noise than necessary, as the exception prevented actual bad stuff™ from happening. |
That is what I have always believe but I would also to know their opinion about this (I'm sure they know much more than me in that topic 🙈 ) When debugging the issue I thought about catching the exception at this point
|
The exception catching has been added by f4e8ed2. Exiv2 will now report that an exception was not caught by any of the actions and print its |
command: exiv2 -et [poc]
https://github.com/legend-issue/pocs/blob/master/exiv2/id:000008%2Csig:06%2Csrc:000335%2Cop:int32%2Cpos:62%2Cval:-1
The text was updated successfully, but these errors were encountered: