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
