Re: binfmts.h MAX_ARG_STRINGS excessive value allows heap spraying

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