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

[Greg Wooledge]

On Sat, Sep 14, 2024 at 19:46:21 +0800, ~ via Bug reports for the GNU Bourne 
Again SHell wrote:
> Dear bug-bash team:
>   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  passing causes rce
> mapfile.def
> 
> for example in bash shell:
> echo -e 
> "line1\nline2\nline3\nline4\nline5\nline6\nline7\nline8\nline9\nline10" > 
> test.txt
> mapfile -t -C "whoami #111" -c 5 my_array < test.txt 
> 
> I want to assign a CVE ID to the vulnerability

What vulnerability?  If you use an option that passes a command to be
evaluated, and then that command gets evaluated, it's working as you
requested.

If you don't want mapfile to run a callback after reading items, then
don't use the callback option.

Also, please stop posting in HTML.  Your message is difficult to read.

Re: Readline Documentation

[G. Branden Robinson]

At 2024-09-13T15:24:15-0400, Chet Ramey wrote:
> It has no effects in its default state. If you don't change it, nothing
> happens. If you change it, you change `bell-style' instead.
> 
> > The fact that its usage continues suggests documenting it as
> > deprecated would be beneficial.
> 
> Maybe. Or maybe it's just time to remove it once and for all.

I am reminded of
. :)

Regards,
Branden


signature.asc
Description: PGP signature

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,  wrote:

> Dear bug-bash team:
>   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  passing causes rce
> mapfile.def
>
> for example in bash shell:
> echo -e
> "line1\nline2\nline3\nline4\nline5\nline6\nline7\nline8\nline9\nline10"
> > test.txt
> mapfile -t -C "whoami #111" -c 5 my_array < test.txt 
>
>
>
> I want to assign a CVE ID to the vulnerability
>
>
> I look forward to working with you to address this matter promptly and
> securely.  Please feel free to contact me directly if you have any
> questions or need further information.
>
>
> Thank you for your attention to this matter.