[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080306201633.GM27983@randombit.net>
Date: Thu, 6 Mar 2008 15:16:33 -0500
From: Jack Lloyd <lloyd@...dombit.net>
To: gcc@....gnu.org, linux-kernel@...r.kernel.org
Subject: Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists