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

[Jack Lloyd <lloyd@randombit.net>]

On Thu, Mar 06, 2008 at 08:43:27PM +0100, Paolo Bonzini wrote:
> Jack Lloyd wrote:
> >On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> >>A process can send a signal via kill.  IOW, a malicious process can 
> >>*control when the process would be interrupted* in order to get it into 
> >>the signal handler with DF=1.
> >
> >If the malicious process can send a signal to another process, it
> >could also ptrace() it. Which is more useful, if you wanted to be
> >malicious?
> 
> 1) capabilities(7)

Ah you are right, I misinterpreted something from the man page
("non-root processes cannot trace processes that they cannot send
signals to") to mean something it did not (basically, that CAP_KILL
implied CAP_SYS_PTRACE, which from reading the kernel source is
clearly not the case...)

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).

-Jack