3 ms·

> While the vulnerability was found by code auditing, it was also detected once by https://syzkaller.appspot.com/bug?id=a53b68e5178eec469534aca80fca1735fb3d8071

by tremon 5y ago

> While the vulnerability was found by code auditing, it was also detected once by https://syzkaller.appspot.com/bug?id=a53b68e5178eec469534aca80fca1735fb3d8071 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?

OneLessThing 5y ago
Did this line get removed from the blog post?
- tremon 5y ago
  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/advisories/GHSA-xxx5-8mvq-3528 https://github.com/google/security-research/security/advisor... [1] https://news.ycombinator.com/item?id=27842381 https://news.ycombinator.com/item?id=27842381
Leparamour 5y ago
Perhaps the difference between merely observing a crash while fuzzing and being able to exploit it for RCE or whatever?
markjdb 5y ago
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.

by tremon 5y ago

OneLessThing 5y ago

Did this line get removed from the blog post?

tremon 5y ago
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/advisories/GHSA-xxx5-8mvq-3528 https://github.com/google/security-research/security/advisor... [1] https://news.ycombinator.com/item?id=27842381 https://news.ycombinator.com/item?id=27842381

Leparamour 5y ago

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

markjdb 5y ago

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.