[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200213232103.GJ1663@brightrain.aerifal.cx>
Date: Thu, 13 Feb 2020 18:21:03 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: execvp() behaviour with unrecognized file header
On Thu, Feb 13, 2020 at 09:11:03PM +0100, Markus Wichmann wrote:
> Hi all,
>
> so I had a look around at other implementations, since I thought the
> problem might be a solved one, and here's what I found:
>
> newlib does not support this behavior at all.
>
> bionic uses a VLA for the new argv[]. I didn't even know C++ had VLAs,
> so at least I learned something from this.
>
> glibc also uses a VLA.
>
> klibc also does not support this behavior.
>
> uclibc-ng is an interesting one. On architectures with MMU they allocate
> the necessary space with alloca(), but without an MMU, they will use
> mmap() directly to try and minimize the memory leak, as a comment
> directly before the code responsible tells us.
This makes no sense. alloca does not cause any memory leak; it just
blows away the stack if the stack isn't sufficiently large. On the
other hand mmap is a memory leak without some dirty tricks to get rid
of the leak. You could either use synchronization, taking advantage of
shared memory with parent, to allocate a single mmap that's reused
(and possibly resized) every time there's a vfork child calling
execvp, but otherwise left around (bounded usage so not a "leak"), or
you could stick a hook in the parent side of vfork that checks for a
thread-local mmap execvp buffer pointer and unmaps it before return in
the parent if it's found.
> So yeah, the competition appears to either not bother or just use VLAs.
> I guess it is not a huge problem in practice?
Using VLAs is worse than not supportint it at all -- it's an
exploitable vuln.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
