linux-kernel - Re: [PATCH 4/5] MIPS: Execute any partial write of the last register with PTRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1712011912120.31156@tp.orcam.me.uk>
Date:   Wed, 6 Dec 2017 18:32:56 +0000
From:   "Maciej W. Rozycki" <macro@...s.com>
To:     Dave Martin <Dave.Martin@....com>
CC:     Ralf Baechle <ralf@...ux-mips.org>,
        James Hogan <james.hogan@...s.com>,
        Paul Burton <Paul.Burton@...s.com>,
        Alex Smith <alex@...x-smith.me.uk>,
        "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH 4/5] MIPS: Execute any partial write of the last register
 with PTRACE_SETREGSET

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