Schneier on Security

Carmine • July 4, 2024 12:31 PM

A co-worker once managed to convince a group of us that signals are not “evil”; and, that given the historical context in which they were developed, they even kind of make sense. Still, they remain quite problematic and poorly understood, and I feel like they’re an area in which the system offers little help. Remember the early days of multi-threading on Unix systems, before POSIX decided that every thread needed its own ‘errno’ value? Kind of like that; one’s almost fighting the design to use it. Had multi-threading and thread-local storage existed when signals were developed, signals would probably look quite different.

I think system libraries can and should be more helpful. For example, if library code could know whether it’s executing from a signal handler, all of the functions that aren’t valid to call in that context—that is, almost all system functions—could refuse to run. This could be done by having the system add a dummy in-signal-handler flag to a thread’s signal mask on entry, or by using a thread-local entry/exit counter. (longjmp() and such might need special-case code to handle these: it’s sometimes valid to use them to jump out of a signal handler, and possibly into another signal handler.) Maybe we could also automatically save and restore ‘errno’—a common source of trouble—if allowed by POSIX.

Also little-known is that, if fork() is called in a multi-threaded program, only async-signal-safe functions may be called before executing a new program. I don’t know of any system that enforces that either.

Actually enforcing these documented restrictions would reveal a multitude of problems, I’m sure. An integrated system such as OpenBSD, though, might be a good place to start. And, yes, I’m aware that this specific OpenSSH code was not present on OpenBSD; that’s because OpenBSD provides syslog_r(), an async-signal-safe variant of syslog(), and OpenSSH uses it when handling signals. The manual says “syslog_r() and the other reentrant functions should only be used where reentrancy is required (for instance, in a signal handler). syslog() being not reentrant, only syslog_r() should be used here.” But why should syslog_r() not be used everywhere? They don’t say. And why can’t they just make syslog() safe, maybe by having it call syslog_r() when used from a signal handler?

POSIX, and the systems implementing it, seem way too willing to create little “traps” for the programmer. With a little more ambition, instead of saying “all hell will break loose if you make a tiny mistake and overlook this detail”, they could require the bad stuff to actually be caught. Till then, catching such things is very much allowed wherever POSIX says “undefined”.

Carmine • July 5, 2024 3:37 PM

@ Clive Robinson

You mean the, “There be dragons here” Type warnings

Yes and no. As you say, asynchronous events bring a certain amount of complexity that cannot be avoided. But, in general, complex systems have a mix of “inherent” and “artificial” complexity.

If you compare how processors handle hardware interrupts, there are significant differences in ease of use. For example, some can automatically switch stacks, save registers, manage nesting and priorities, and so on. Others leave all that stuff to the operating system designer. For x86, one can consider the difficulty of handling double-faults (such as kernel stack overflows), the subtle security vulnerabilities related to SYSRET, the non-nestability of SWAPGS, and basically all the details Intel’s “FRED” is intended to fix.

There are really several classes of “dragons” relating to Unix signals. One is just arbitrary historical differences. It’s understandable given the history, and while POSIX could’ve done a better job (like by refusing to standardise ill-defined functions, including signal(), and by using a prefix for the replacements), these problems are basically avoidable: use sigaction()—and set SA_RESTART—instead of signal(), pthread_sigmask() instead of sigprocmask(), etc. But then there’s the whole idea of handlers being per-process rather than per-thread, which makes them very difficult to use in libraries (which, as a bonus, can’t assume their application set SA_RESTART). That’s just bad design, still not fixed, that’s not inherent in the nature of interrutibility. The same goes for the refusal to save errno; the problems could’ve been easily predicted. I saw an interesting and related story on Hacker News yesterday: the fields of siginfo_t overlap on some systems, few people know what’s valid when, and the implementors of Java screwed it up. For reference:

If the signal was not generated by one of the functions or events listed above, si_code shall be set either to one of the signal-specific values described in XBD <signal.h>, or to an implementation-defined value that is not equal to any of the values defined above.

If si_code is SI_USER or SI_QUEUE, [XSI] [Option Start] or any value less than or equal to 0, [Option End] then the signal was generated by a process and si_pid and si_uid shall be set to the process ID and the real user ID of the sender, respectively.

In addition, si_addr, si_pid, si_status, and si_uid shall be set for certain signal-specific values of si_code, as described in XBD <signal.h>.

If si_code is one of SI_QUEUE, SI_TIMER, SI_ASYNCIO, or SI_MESGQ, then si_value shall contain the application-specified signal value. Otherwise, the contents of si_value are undefined.

Got that? The separate page for signal.h says a bit more: “In addition, the following signal-specific information shall be available”, and si_addr is listed for SIGSEGV and SIGBUS, but it’s not actually true on Linux! Is that a Linux defect, or should the specification have said it’s only valid for system-generated signals of those types? The latter, I suspect, because POSIX doesn’t give any way to set si_addr when sending a signal, and it does kind of describe the opposite case:

On systems not supporting the XSI option, the si_pid and si_uid members of siginfo_t are only required to be valid when si_code is SI_USER or SI_QUEUE. On XSI-conforming systems, they are also valid for all si_code values less than or equal to 0; however, it is unspecified whether SI_USER and SI_QUEUE have values less than or equal to zero, and therefore XSI applications should check whether si_code has the value SI_USER or SI_QUEUE or is less than or equal to 0 to tell whether si_pid and si_uid are valid.

Here’s a fun one: “If the process is multi-threaded, or if the process is single-threaded and a signal handler is executed other than as the result of [any of several synchronous function calls,] the behavior is undefined if the signal handler refers to any object other than errno with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t”. Note that only assigning a value is allowed; no variable apart from errno may be read, even if it’s declared _Atomic or const. And that type may not be large enough to store a pointer. In this case, we’re lucky no compiler is so strict.

A signal-like interface will never be easy, but this is a real mess, and much of it’s fixable. Like, sigaction(SA_THREAD | signum, …) could get and set a per-thread handler, for which SIG_DFL would reference the per-process handler. Easy to implement and understand, with a very low chance of breaking anything. And we could require pid and uid in siginfo_t to be -1 when not available; the definitions of fork() and setreuid() make those values effectively reserved already (making the fields contain -1 may break binary-compatibilty, thereby being about as difficult as the time64 transition; but having POSIX define siginfo_get_uid() and such would be trivial and would benefit new code).

Carmine • July 10, 2024 12:28 PM

Often what those diving in chose to do/select goes wrong due to side effects etc, so they “quick fix” again, which also has the habit of “going wrong” in a different way.

It’s an interesting theory, but apparently false in this case. It seems that Solar Designer, being privy to the previous “embargoed” report, looked for similar problems and found one; then agreed to delay the publication, for the convenience of the packagers.

Now that the reports are public, “everyone” will be combing through the signal handlers of OpenSSH and other important software projects, open-source or not.

It’s a common pattern in security research. Remember the original publication of the “Meltdown” and “Spectre” vulnerabilities, 6.5 years ago? They were the first-known major ones of that type that were not caused by hyper-threading; and, since then, we’ve seen a constant stream of such attacks. Older people may remember the original publication of “Smashing The Stack for Fun and Profit” and the decade of easy stack-smashing attacks that followed (which, due to compiler hardening and such, have turned into much harder—thus less fun but more profitable—stack-smashing attacks).

I’ll be surprised if this stops at any small odd number. I expect the attacks will just migrate to progressively less important software. “Sanitizers” and other system-level mitigations will come; the only question is whether the “good guys” will have them.