2

Background: I'm fuzzing a long-lived process with afl-fuzz by passing to it the filename to process from a stub that afl-fuzz runs for each sample.

When the long-lived process crashes via SIGSEGV, I want the stub to also generate a SIGSEGV, so that afl-fuzz will mark the sample as interesting.

Will calling kill(stub_pid, SIGSEGV) from the long-lived process's SIGSEGV handler work ?

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
patraulea
  • 652
  • 2
  • 5
  • 26
  • 1
    Try it out. Why shouldn't it? – cadaniluk Oct 01 '15 at 14:16
  • 1
    According to [kill manual](http://man7.org/linux/man-pages/man2/kill.2.html) it will kill any any process if you have permission to do so. – Enzo Ferber Oct 01 '15 at 14:23
  • 1
    According the the signal.7 man page (http://man7.org/linux/man-pages/man7/signal.7.html), `kill()` is async-signal-safe, so it will work the same from a signal handler as it does in normal code. But by replacing your SIGSEGV handler, you won't generate a core file if you want one unless you invoke the default SIGSEGV handler in some manner. – Andrew Henle Oct 01 '15 at 14:25
  • 1
    You can, but make sure that the handler doesn't return, as returning from a SIGSEGV handler is UB. – Filipe Gonçalves Oct 01 '15 at 18:00
  • This is a non-problem. The answer is: don't crash. – wildplasser Oct 13 '15 at 23:19
  • 1
    @wildplasser: what do you mean? The user wants to make his program crash so that the fuzzer he uses would notice that the given input sample is interesting. What's wrong about that? – d33tah Oct 13 '15 at 23:28

3 Answers3

1

Will calling kill(stub_pid, SIGSEGV) from the long-lived process's SIGSEGV handler work ?

If a process ends up in a SIGSEGV-handler something very bad happened, which might include a completely destroyed stack and/or memory management.

It is not a good idea to rely on anything any more at this point, but just that the process goes down.

Trying to invoke any functionally beyond this point is likely to fail, that is unreliable.

A much safer approach to this would be to have the calling process monitor its child, and if the child happens to terminated unexpected (typically via SIGSEGV) start the appropriate actions.

Have a look at signal handling inside shell scripts (seach-key: "trap"), as such a script might be the parent to the process you want to monitor.

alk
  • 69,737
  • 10
  • 105
  • 255
0

not recommended to do this through SIGSEGV but you can do this if you have proper permission.

incompetent
  • 1,715
  • 18
  • 29
0

Instead of wondering how to cause a segmentation fault in your program so that AFL would notice something odd, just call abort(). SIGABRT is caught by AFL as well and is much easier to trigger.

d33tah
  • 10,999
  • 13
  • 68
  • 158
  • Any way of crashing would be ok, I was having trouble propagating the crash from the long-lived process (init took seconds, each sample took msecs) back to the stub that AFL calls. – patraulea Oct 14 '15 at 07:46
  • Ah! I think I understand it now. I assumed that you'd like to signal the crash from within the stub. – d33tah Oct 14 '15 at 12:09
  • @patraulea: on the other hand, wouldn't you be having problems with path detection this way? – d33tah Oct 14 '15 at 12:10