Re: bash builtins mapfile issue - Unexpected parameter passing of causes rce

[Martin D Kealey]

You seem to be implying that execstr contains a value that's under the
control of the input stream in a way that would allow malicious data on the
input stream to cause the shell to invoke arbitrary code.

I read the run_callback() function, and I don't see that as plausible,
unless you claiming there's a bug in sh_single_quote().

If that's the case, please be clear, and please provide a transcript of a
session where sh_single_quote() returns an improperly protected string,
either using mapfile or otherwise.

Otherwise it is not appropriate to issue a CVE where no vulnerability
exists.

To be clear, it is not the shell's job to stop scripts from intentionally
doing stupid things. Your "whoami" example just proves that the shell is
working exactly as it should.

If you have a case where a script provides an uncontrolled value as the
argument to -C, that warrants a CVE be issued against the script, not
against Bash.

-Martin

On Sat, 14 Sep 2024, 21:46 ~ via Bug reports for the GNU Bourne Again
SHell, <bug-bash@gnu.org> wrote:

> Dear bug-bash team:
> &nbsp;&nbsp;I hope this email finds you well. During my recent security
> assessment of bash, I identified a potential security vulnerability that I
> believe may impact the security of your product and its users.
> here is details:
> 1、mapfile -C xxx will call run_callback
> 2、evil "execstr" parameter&nbsp; passing&nbsp;causes rce
> mapfile.def
>
> for example in bash shell:
> echo -e
> "line1\nline2\nline3\nline4\nline5\nline6\nline7\nline8\nline9\nline10"
> &gt; test.txt
> mapfile -t -C "whoami #111" -c 5 my_array < test.txt&nbsp;
>
>
>
> I want to assign a CVE ID to the vulnerability
>
>
> I look forward to working with you to address this matter promptly and
> securely.&nbsp; Please feel free to contact me directly if you have any
> questions or need further information.
>
>
> Thank you for your attention to this matter.