linux-kernel - Re: [PATCH v5 12/15] binfmt_flat: allow compressed flat binary format to work on MMU systems

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.LFD.2.20.1607241612480.1594@knanqh.ubzr>
Date:	Sun, 24 Jul 2016 16:25:16 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
cc:	linux-arm-kernel@...ts.infradead.org,
	Greg Ungerer <gerg@...ux-m68k.org>,
	linux-fsdevel@...r.kernel.org,
	Alan Cox <gnomes@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>,
	linux-m68k@...ts.linux-m68k.org,
	Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v5 12/15] binfmt_flat: allow compressed flat binary format
 to work on MMU systems

On Sun, 24 Jul 2016, Arnd Bergmann wrote:

> On Sunday, July 24, 2016 11:30:26 AM CEST Nicolas Pitre wrote:
> > +#else
> > +                       /*
> > +                        * This is used on MMU systems mainly for testing.
> > +                        * Let's use a kernel buffer to simplify things.
> > +                        */
> > +                       long unz_text_len = text_len - sizeof(struct flat_hdr);
> > +                       long unz_len = unz_text_len + full_data;
> > +                       char *unz_data = vmalloc(unz_len);
> > +                       if (!unz_data) {
> > +                               result = -ENOMEM;
> > 
> 
> Is there a risk of a malicious user exhausting vmalloc space with a
> binary that has forged headers? If there is, maybe put an upper bound on
> the size of allocation.

Patch #3 enforces a cap on all parameters to avoid overflows and 
unreasonable section sizes.

Then vmalloc space is used here only for decompressing the binary into, 
after which the whole thing is copied to user space and the vmalloc area 
is freed right away.

> More broadly speaking, are there any other attacks that may get enabled
> through forged binaries? We've had a couple of vulnerabilities in
> binfmt_elf over the years, and I wonder how dangerous it might be
> if distros turn on binfmt_flat support by default.

That was Alan's concern too which prompted patch #3. But with a clamp on 
all parameters, everything else is done via user accessors.  So an 
executable still can crap onto itself or generate a segfault but I doubt 
we really care at that point.


Nicolas