Skip to content
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

[Feature-request] Triaging the crashes #3

Open
s0h3ck opened this issue Nov 17, 2019 · 1 comment
Open

[Feature-request] Triaging the crashes #3

s0h3ck opened this issue Nov 17, 2019 · 1 comment

Comments

@s0h3ck
Copy link

@s0h3ck s0h3ck commented Nov 17, 2019

The current behavior is to stop on the first crash. A feature that allows the user to capture all crashes could be useful.

A possible workaround is to catch all the exceptions, save them in a set, for example, and do the triage there.

I think it would be interesting to have pythonfuzz the capability to (1) record more than one crash, (2) indicate if the crash falls into the exploitable, probably exploitable, probably not exploitable, or unknown categories, and (3) give a rank of exploitability.

(4) It could be interesting to generate a ready-to-execute python file with the crash.

Example: While fuzzing beautifulsoup, I found the following crash:

  File "/usr/lib/python3.6/_markupbase.py", line 160, in parse_marked_section
    if not match:
UnboundLocalError: local variable 'match' referenced before assignment
crash was written to crash-f418412614989b460f037a19c290c98712347bfe05b11d98b817baea6d18c431
crash = 3c215b661b00

Here is an example of ready-to-execute python file.

from bs4 import BeautifulSoup
from pythonfuzz.main import PythonFuzz


def execute_crash(payload):
    soup = BeautifulSoup(payload, 'html.parser')


if __name__ == '__main__':
    hex_payload = "3c215b661b00"
    str_payload = bytes.fromhex(hex_payload).decode("ascii")

    execute_crash(str_payload)

(5) Bonus points could be to have an exploit code generated by pythonfuzz. :)

For your information, the crash has been reported in 2018. It looks like nobody care...

@yevgenypats
Copy link
Contributor

@yevgenypats yevgenypats commented Nov 17, 2019

hey @s0h3ck ,

Thanks for feature-request. I think this is a valid feature and might be useful but keep in mind that while a crash is not fixed the fuzzer might hit the same crash a lot which will slow down the fuzzer substantially as well the crash might mask additional crashes that will be "available" for the fuzzer only after the bug is fixed. As a quick workaround I suggest you just fix it on your local copy of beautiful soup and continue running your fuzz target.

2,3) Regarding exploitability - keep in mind that python is a safe language and most bugs are not exploitable like you may be used to in c/c++ (libfuzzer/AFL). So I currently don't see how this feature could be implemented or be of any use. pythonfuzz as well as other fuzzers for safe-languages are more directed to automatically find bugs, increase stability and find hangs/DoS crashes in critical component that can be seen as security issue as well.

(4) I think this feature can be added in some way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.