Accessing or modifying shared objects in signal handlers can lead to race conditions, opening up security holes.
Non-Compliant Coding Example
#include <signal.h>
char *err_msg;
void handler() {
strcpy(err_msg, "SIGSEGV encountered.");
}
int main() {
signal(SIGSEGV, handler);
err_msg = malloc(24);
strcpy(err_msg, "No errors yet.");
/* main code loop */
return 0;
}
Compliant Solution
#include <signal.h>
char *err_msg;
int e_flag = 0;
void handler() {
e_flag = 1;
}
int main() {
signal(SIGSEGV, handler);
err_msg = malloc(24);
strcpy(err_msg, "No errors yet.");
/* main code loop */
if(e_flag)
strcpy(err_msg, "SIGSEGV received.");
return 0;
}
Risk Assessment
Depending on the code, this could lead to any number of attacks, many of which could give root access. For an overview of some software vulnerabilities, see Zalewski's signal article.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
SIGxx-C |
3 (high) |
3 (likely) |
1 (high) |
P9 |
L2 |
References
[[ISO/IEC 03]] "Signals and Interrupts"
[[Open Group 04]] longjmp
[OpenBSD] signal() Man Page
[Zalewski] http://lcamtuf.coredump.cx/signals.txt