Re: binfmts.h MAX_ARG_STRINGS excessive value allows heap spraying

[Leonard den Ottolander <leonard-lists-2Avth2y2NeLyQNdsBcn8aGZHpeb/A1Y/@public.gmane.org>]

On Wed, 2017-03-08 at 12:54 -0500, Carlos O'Donell wrote:
> The most demanding application I've ever seen when playing with this is the
> compiler because it has to pass some very large strings from the driver
> to a subprocess. So much so that we have `@file` to use intermediate file
> storage to workaround kernel limits on various operating systems.

So a value that would satisfy glibc would suffice. Any problem with that
limit of 4096 arguments? The size of each individual argument is still
the old limit of 128KiB.

By the way, my kernel build example seems to already catch your
scenario. Kernel build uses a compiler.

> In glibc we limit setuid applications, for example sanitizing their
> environment where it would cause problems or alter behaviour in 
> unintended ways.
> 
> Can we avoid imposing a limit on all applications?

Not imposing a limit - btw, 0x7FFFFFFF *is* a limit albeit a ridiculous
and dangerously large limit - is a bad idea, because it allows the
aforementioned "heap-spraying" which is a serious attack vector.

Note that 128KiB * 4096 arguments still adds up to 512MiB!!!

If you don't feel the limit of 4096 arguments is sufficient please
provide us with an example where that limit is insufficient.

Regards,
Leonard.

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