From: Dave Martin <[email protected]>
To: "Maciej W. Rozycki" <[email protected]>
Cc: Ralf Baechle <[email protected]>, James Hogan <[email protected]>,
Subject: Re: [PATCH 4/5] MIPS: Execute any partial write of the last register
with PTRACE_SETREGSET
In-Reply-To: <[email protected]>
On Thu, Nov 30, 2017 at 07:38:25PM +0000, Maciej W. Rozycki wrote:
[...]
> > If we can end up with that somehow, then this patch reintroduces the
> > issue d614fd58a283 aims to fix, whereby fpr_val can contain
> > uninitialised kernel stack which userspace can then obtain via
> > PTRACE_GETREGSET.
>
> That wasn't actually clarified in the referred commit's description,
> which it should in the first place, and I wasn't able to track down any
> review of your change as submitted, which would be the potential second
> source of such support information. The description isn't even correct,
> as it states that if a short buffer is supplied, then the old values held
> in thread's registers are preserved, which clearly isn't correct as
> individual registers do get written from the beginning of the regset up to
> the point no more data is available to fill a whole register.
FYI, this this patch wasn't discussed on the public lists because of the
security implications of kernel stack exposure. IIRC, James and Ralf
were Cc'd on the discussion.
There's an awkward balance to be struck between giving a full
description of the change and the motivation for it, and avoiding
announcing publicly exactly how to exploit the bug. Opinions differ on
where the correct balance lies.
So, the commit message was intentionally kept vague, but could have
been better in this instance, since it doesn't correctly describe the
change as committed.
Cheers
---Dave
On Fri, 1 Dec 2017, Dave Martin wrote:
> > That wasn't actually clarified in the referred commit's description,
> > which it should in the first place, and I wasn't able to track down any
> > review of your change as submitted, which would be the potential second
> > source of such support information. The description isn't even correct,
> > as it states that if a short buffer is supplied, then the old values held
> > in thread's registers are preserved, which clearly isn't correct as
> > individual registers do get written from the beginning of the regset up to
> > the point no more data is available to fill a whole register.
>
> FYI, this this patch wasn't discussed on the public lists because of the
> security implications of kernel stack exposure. IIRC, James and Ralf
> were Cc'd on the discussion.
That's security by obscurity, I'm afraid.
While I do agree publicly discussing an exploitable vulnerability while
no remedy has been yet made is considered a bad practice, I see no point
in keeping it hidden once a fix has been developed and published.
Moreover actually publishing all the details of the vulnerability itself
(rather than just the fix) is often considered a good way to urge binary
software distributors to release patched versions.
So I think a commit description should still be as accurate as usually.
> There's an awkward balance to be struck between giving a full
> description of the change and the motivation for it, and avoiding
> announcing publicly exactly how to exploit the bug. Opinions differ on
> where the correct balance lies.
Well, in this situation to exploit this bug you still have to figure out
how you can use this potential information leak in practice, so having the
mention of a stack variable being partially initialised in the fix's
description is IMO hardly a recipe for the potential attacker, while it
lets the next reader understand what is really going on there.
> So, the commit message was intentionally kept vague, but could have
> been better in this instance, since it doesn't correctly describe the
> change as committed.
Ack.
Maciej