Talk:SIGWINCH

This redirect is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing

Linux

This redirect is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux

According to this mail archive, it can be a security risk when misused. Any insight? 62.167.117.242 (talk) 21:31, 28 April 2008 (UTC)[reply]

For example this. What the comment means is that in the minds of some people, any bug can be construed as a security risk. In that regard, it's not relevant to this topic. Tedickey (talk) 23:32, 28 April 2008 (UTC)[reply]

The misuse is in the ncurses-installed SIGWNCH handler modifying window-system internals (I think to insert a "SIGWNCH sent" message in the message chain). Because a signal can be received at any time, this could corrupt window-system internals leading to execution of arbitrary code. A possible attack could be a privilege-escalation on a suid root ncurses program (a package manager?); the attacker writes shellcode into a ncurses (keyboard?) buffer, puts the ncurses message loop under heavy load, then sends SIGWNCH at the right time to corrupt the message chain and transfer execution to the shellcode.

This isn't really SIGWNCH-related, though; any unsafe signal handler is a potential security hole. The only (useful) safe things to do in a signal handler are: set a sig_atomic_t variable, or write to a non-blocking pipe. EdC (talk) 23:33, 29 April 2008 (UTC)[reply]

Perhaps. But it's been 7 years since any OpenBSD developer sent any code-fixes to ncurses. They're very proactive of course. Tedickey (talk) 00:50, 30 April 2008 (UTC)[reply]

By the way, the example given isn't "message chain", but "screen chain". Multiple screens are rare in curses applications (screens correspond to different terminals). Theo's secondhand comment (from Todd) is that some unpredictable memory corruption might occur as a result of interrupting the store of a pointer. Speculating on that as an exploitable bug is best done on Slashdot Tedickey (talk) 00:57, 30 April 2008 (UTC)[reply]