Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Artur Skawina <art_k at o2 dot pl>]

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