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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18517b44-0d3f-3f83-e327-60064c170c5a@stressinduktion.org>
Date:   Wed, 24 Aug 2016 22:36:08 +0200
From:   Hannes Frederic Sowa <hannes@...essinduktion.org>
To:     Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
        Al Viro <viro@...IV.linux.org.uk>
Cc:     Joe Perches <joe@...ches.com>, David Miller <davem@...emloft.net>,
        ben@...adent.org.uk, luis.henriques@...onical.com,
        avijitnsec@...eaurora.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: CVE-2014-9900 fix is not upstream

On 24.08.2016 16:03, Lennart Sorensen wrote:
> On Tue, Aug 23, 2016 at 10:25:45PM +0100, Al Viro wrote:
>> Sadly, sizeof is what we use when copying that sucker to userland.  So these
>> padding bits in the end would've leaked, true enough, and the case is somewhat
>> weaker.  And any normal architecture will have those, but then any such
>> architecture will have no more trouble zeroing a 32bit value than 16bit one.
> 
> Hmm, good point.  Too bad I don't see a compiler option of "zero all
> padding in structs".  Certainly generating the code should not really
> be that different.
> 
> I see someone did request it 2 years ago:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63479

I don't think this is sufficient. Basically if you write one field in a
struct after a memset again, the compiler is allowed by the standard to
write padding bytes again, causing them to be undefined.

If we want to go down this route, probably the only option is to add
__attribute__((pack)) those structs to just have no padding at all, thus
breaking uapi.

E.g. the x11 protocol implementation specifies padding bytes in their
binary representation of the wire protocol to limit the leaking:

https://cgit.freedesktop.org/xorg/proto/xproto/tree/Xproto.h

... which would be another option.

Bye,
Hannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ