Jack Lloyd wrote: > But still: so the threat here is of a malicious process with the > ability to send arbitrary signals to any process using CAP_KILL (since > in any other case when a process can send a signal, it can do much > more damage in other ways), which could leverage that into > (potentially) uid==0 using misexecuted code in a signal handler. > > As a correctness issue, obviously this should be fixed/patched around, > if feasible. But as a security flaw? I'm not seeing much that is > compelling. > >> 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1) > > I don't understand how this is a problem - unless these setuid > programs, while not malicious, can be tricked into signalling a > process they did not intend to. (In which case they already have a > major bug, df bit being cleared or not).
think apps keeping crypto keys etc in ram and wiping them from signal handlers. eg gnupg does this; fortunately it seems to have moved from memset() to a open coded solution, so probably isn't affected. OTOH it wouldn't surprise me these days if the compiler would emit string ops even w/o an explicit mem* call. Copying a private memory region to some public buffer could also lead to interesting results... IOW being able to avoid a memset (or copying the wrong data) certainly could have security consequences. artur
