linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leonard den Ottolander <leonard-lists-2Avth2y2NeLyQNdsBcn8aGZHpeb/A1Y/@public.gmane.org>
To: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: binfmts.h MAX_ARG_STRINGS excessive value allows heap spraying
Date: Thu, 09 Mar 2017 15:14:14 +0100	[thread overview]
Message-ID: <1489068854.1026.14.camel@quad> (raw)
In-Reply-To: <f16cd7f8-f996-cf66-d640-50b0ccee06c7-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

--- a/include/uapi/linux/binfmts.h	2016-11-23 21:02:31.000000000 +0100
+++ b/include/uapi/linux/binfmts.h	2017-03-09 01:52:14.716319950 +0100
@@ -9,10 +9,15 @@ struct pt_regs;
  * These are the maximum length and maximum number of strings passed to the
  * execve() system call.  MAX_ARG_STRLEN is essentially random but serves to
  * prevent the kernel from being unduly impacted by misaddressed pointers.
- * MAX_ARG_STRINGS is chosen to fit in a signed 32-bit integer.
+ * MAX_ARG_STRINGS * MAX_ARG_STRLEN should be smaller than the 4GiB
+ *  address space on 32 bit to avoid heap spraying.
+ * MAX_ARG_STRSLEN to the rescue - the MAX_ARG_PAGES concept was there
+ *  for a reason.
+ * We can now safely increase STRINGS * STRLEN beyond 4GiB if need be.
  */
-#define MAX_ARG_STRLEN (PAGE_SIZE * 32)
-#define MAX_ARG_STRINGS 0x7FFFFFFF
+#define MAX_ARG_STRSLEN 262144
+#define MAX_ARG_STRLEN 65536
+#define MAX_ARG_STRINGS 4096
 
 /* sizeof(linux_binprm->buf) */
 #define BINPRM_BUF_SIZE 128
--- a/fs/exec.c	2017-02-20 08:04:43.000000000 +0100
+++ b/fs/exec.c	2017-03-09 01:54:25.931476370 +0100
@@ -459,6 +459,7 @@ static int copy_strings(int argc, struct
 	char *kaddr = NULL;
 	unsigned long kpos = 0;
 	int ret;
+	int total_bytes = 0;
 
 	while (argc-- > 0) {
 		const char __user *str;
@@ -478,6 +479,11 @@ static int copy_strings(int argc, struct
 		if (!valid_arg_len(bprm, len))
 			goto out;
 
+		/* -E2BIG is fine for now */
+		total_bytes += len;
+		if (total_bytes > MAX_ARG_STRSLEN)
+			goto out;
+
 		/* We're going to work our way backwords. */
 		pos = bprm->p;
 		str += len;

I've successfully built a kernel on a system with a kernel using above
values.

As we have now introduced a safeguard (MAX_ARG_STRSLEN capping the total
amount of memory reserved) the values of MAX_ARG_STRLEN and
MAX_ARG_STRINGS can be increased beyond where their multiplication
reaches 2^32.

So if we really want to support lets say users having directories of
128k files we can now safely set MAX_ARG_STRINGS to 131072 and assuming
an average file name length of 32 set MAX_ARG_STRSLEN to 4194304.

Seems a little excessive to me for a default, but it is now safe.

Regards,
Leonard.

  parent reply	other threads:[~2017-03-09 14:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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=1489068854.1026.14.camel@quad \
    --to=leonard-lists-2avth2y2nelyqndsbcn8agzhpeb/a1y/@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).