Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> While the vulnerability was found by code auditing, it was also detected once by https://syzkaller.appspot.com/bug?id=a53b68e5178eec469534aca..., however not with a reproducible C code.

This made me pause. I had naively assumed (well, actually, never thought about it) that fuzzing would always expose a clear and obvious error path, but apparently there's a lot of manual digging required to find the error mode?



It depends on the bug. syzkaller does an excellent job finding race conditions, but it can be difficult to generate a reliable reproducer for them. It often succeeds nonetheless. In other cases there can be a wide gap between the proximate and root causes of a crash. For instance some system call bug might corrupt memory in a way that only results in a crash some time later, when some asynchronous task runs, in which case it's also difficult to find a reproducer. Sanitizers can help identify such bugs earlier and so reduce the amount of manual analysis needed in the absence of a reproducer.

I'm not sure what happened in this case. The linked report does indeed have an associated reproducer.


Perhaps the difference between merely observing a crash while fuzzing and being able to exploit it for RCE or whatever?


Did this line get removed from the blog post?


Sorry, it's from [0] linked further down in the comments. I didn't notice that when posting, or I would have made my comment a reply to that post [1].

[0] https://github.com/google/security-research/security/advisor...

[1] https://news.ycombinator.com/item?id=27842381




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: