All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonard den Ottolander <leonard-lists@den.ottolander.nl>
To: linux-kernel@vger.kernel.org
Subject: binfmts.h MAX_ARG_STRINGS excessive value allows heap spraying
Date: Mon, 06 Mar 2017 16:29:26 +0100	[thread overview]
Message-ID: <1488814166.25747.27.camel@quad> (raw)

In the article 
https://googleprojectzero.blogspot.nl/2014/08/the-poisoned-nul-byte-2014-edition.html
the author describes launching an attack on an off by one NUL byte bug
in glibc.

He explains that both the memory leak in the option parsing of PolKits
pkexec.c and the excessive value of MAX_ARG_STRINGS in the kernels
include/uapi/linux/binfmts.h (#define MAX_ARG_STRINGS 0x7FFFFFFF)
enabled his attack.

The rationale for that excessive value is a bit odd:

"MAX_ARG_STRINGS is chosen to fit in a signed 32-bit integer."

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/binfmts.h?id=607ca46e97a1b6594b29647d98a32d545c24bdff

The fact that the integer is so large makes that on a 32 bit platform
the entire heap can be initialized with values the attacker provides,
given the memory leak in the option parsing of pkexec.c, an approach the
author calls "heap spraying".

(Note that two similar memory leaks exist in the option parsing of
pkexecs sibling pkcheck.c, so pkcheck will also allow an attacker to
heap spray its entire memory on a 32 bit system.)

If you compare http://www.linuxjournal.com/article/6060 you will see
that the TOTAL amount of memory reserved for command line arguments used
to be 32 pages, i.e. 128KiB (#define MAX_ARG_PAGES 32). The amount of
memory reserved for command line arguments in more current kernels is
the multiplication of MAX_ARG_STRINGS and MAX_ARG_STRLEN.

Both the memory leaks in pkexec.c and pkcheck.c seem very severe, but
their impact would be much less if MAX_ARG_STRINGS would hold a sensible
value.

After some experimentation with
$ rpmbuild -ba kernel.spec
on CentOS-7 I've come up with values that allow this kernel compilation.
As this kind of build is probably one of the most demanding actions in
relation to MAX_ARG_STRINGS and MAX_ARG_STRLEN I believe below values to
be sensible and much safer defaults:

#define MAX_ARG_STRLEN 65536
#define MAX_ARG_STRINGS 4096

Please let me know if this needs to be filed as a bug somewhere.

Regards,
Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

             reply	other threads:[~2017-03-06 15:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 15:29 Leonard den Ottolander [this message]
2017-03-07 14:44 binfmts.h MAX_ARG_STRINGS excessive value allows heap spraying Leonard den Ottolander
2017-03-08 17:54 ` Carlos O'Donell
     [not found]   ` <f7f9f60b-0f39-7dce-1778-3aa40ba198ef-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-08 18:18     ` Leonard den Ottolander
2017-03-08 18:21       ` Leonard den Ottolander
2017-03-08 20:47       ` Joseph Myers
2017-03-08 21:05       ` Carlos O'Donell
     [not found]         ` <f16cd7f8-f996-cf66-d640-50b0ccee06c7-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-09 14:04           ` Leonard den Ottolander
2017-03-09 14:35             ` Carlos O'Donell
2017-03-09 14:14           ` Leonard den Ottolander
2017-03-09 20:34             ` Carlos O'Donell
     [not found]               ` <81d8e14e-e110-4b96-5d45-8bb3b56f4866-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-10 12:10                 ` Leonard den Ottolander
2017-03-14  0:51                   ` Carlos O'Donell
     [not found]                     ` <b736f01f-ef0a-56de-bf57-c6d3d74262a4-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-03-17 13:12                       ` Leonard den Ottolander
2017-03-09 23:10             ` Joseph Myers
     [not found]               ` <alpine.DEB.2.20.1703092304110.23273-9YEB1lltEqivcGRMvF24k2I39yigxGEX@public.gmane.org>
2017-03-10  0:01                 ` Carlos O'Donell
2017-03-08 18:48     ` Leonard den Ottolander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1488814166.25747.27.camel@quad \
    --to=leonard-lists@den.ottolander.nl \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.