unix: rework signal handling

[bnoordhuis]

There was a recent(ish) PoC where someone exploited a file write to /proc/self/fd/<n> to manipulate libuv's signal pipe. (I lost the link; it's in node's bug tracker somewhere but that place is such a swamp...)

Libuv's signal handler writes pointers to said pipe (something I never liked in the first place) and that's enough to get a jump-off point for further exploitation.

I've wanted for a long time to redo our signal handling and I did a work-in-progress first pass in bnoordhuis@120cf7c (tl;dr use atomics and per-signal queues of interested event loops)

If anyone has concerns about that approach, LMK. No ETA unless you want to sponsor me :-)

[richardlau]

There was a recent(ish) PoC where someone exploited a file write to /proc/self/fd/<n> to manipulate libuv's signal pipe. (I lost the link; it's in node's bug tracker somewhere but that place is such a swamp...)

FWIW It was in hackerone, not GH: https://hackerone.com/reports/2260337

[vtjnash]

Xref #2016 which is likely a similar issue on Windows, but affects most IO handles in most programs, due to fundamental design designs of IOCP

[aniwid]

It's probably this recent blog post by SonarSource that @bnoordhuis is probably referring to, which also references the HackerOne report.

[juanarbol]

I could take a look. @santigimeno would you give me some guidance on this one?

[abrownsword]

Would waitsignal or signalfd on Unix/Linux be of potential interest? If this area is going to receive attention, then more debugging support would be very much appreciated -- i.e. use the additional siginfo which is passed, and possibly generate a stack trace in cases where a signal handler is used.

[bnoordhuis]

waitsignal = sigwait/sigwaitinfo? They and signalfd don't work well with threads; all threads in a process must behave properly in order to get the right behavior. That's not an assumption a library can make.

Installing a process-wide signal handler, like libuv does, means the signal is always caught. It kind of precludes recording the siginfo_t though.

possibly generate a stack trace in cases where a signal handler is used

That won't work. Your uv_signal_cb doesn't run inside a signal context (isn't called from libuv's signal handler); the call stack at the time of the signal no longer exists.

[abrownsword]

Yes, I meant sigwaitinfo and signald. Fair enough about requiring all threads to cooperate. It works pretty well for some kinds of signals, but having uniform handling is probably more desireable in the library.

You’re writing signum to a pipe, why not write a struct instead?

I didn’t mean a stack trace from the callback, I meant from the libuv signal handler. It is called in a context (albeit not always the right one), and it could attempt some sort of stack and/or register recording as part of what it writes to the pipe. Only as a best effort debug feature (probably option), as such things can be flakey. It can be very useful for debugging obscure signalling issues (but would be secondary to preserving the siginfo_t).

[bnoordhuis]

You’re writing signum to a pipe, why not write a struct instead?

We're doing that currently (well, a pointer to a struct) but I'm trying to move away from that because of that blog post.

Another reason is that the signal pipe is precious real estate. Pipes have a limited capacity; if it's full, you lose events.

Collecting stack traces: that's fraught with peril (as in: crash or corrupt) and difficult to emulate on non-UNIX systems; same goes for siginfo_t. Let specialized libraries deal with that.