RE: GNU Bash profile code execution vulnerability enquiry
Thanks Chet and Greg for your swift replies. I'll park it as a non-vulnerability. Regards Rachel Rachel Alderman IBM Cloud Kubernetes Security Compliance IBM United Kingdom Limited, Mailpoint 211, Hursley, Winchester, SO21 2JN. Email: rachel_alder...@uk.ibm.com I work part-time and my working days are Wednesday, Thursday and Friday. IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU From: Chet Ramey To: Rachel Alderman , bug-bash@gnu.org Cc: chet.ra...@case.edu Date: 28/10/2020 18:21 Subject:[EXTERNAL] Re: GNU Bash profile code execution vulnerability enquiry On 10/28/20 1:11 PM, Rachel Alderman wrote: > Hi Bash Maintainers, > > I've been made aware of a GNU Bash profile code execution vulnerability > https://urldefense.proofpoint.com/v2/url?u=https-3A__exchange.xforce.ibmcloud.com_vulnerabilities_173116&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=n8y5uKM5g4nhsINWSXY-6PahOH6ZD7tHCCCT1n2Jwds&m=dD-fw0FFUuB8yk2vU9EDQMfpw9sR_9KXp1y1wqryDuI&s=exih7GRA372ne8AH5dBECaDKdYkAJ0DaOWfwxMExcFc&e= reported last > December (2019-12-16) > Description: GNU Bash could allow a remote attacker to execute arbitrary > code on the system, caused by improper access control by the Bash profile. > By persuading a victim to open the Bash terminal, an attacker could > exploit this vulnerability to execute arbitrary code on the system. Hi, Rachel. Thanks for the report. This does not describe a bash vulnerability. Executing a profile file at shell startup is a standard shell feature. If an attacker has write access to a user's profile file, they can modify it to include potentially malicious commands, but this does not constitute a bash vulnerability. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu https://urldefense.proofpoint.com/v2/url?u=http-3A__tiswww.cwru.edu_-7Echet_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=n8y5uKM5g4nhsINWSXY-6PahOH6ZD7tHCCCT1n2Jwds&m=dD-fw0FFUuB8yk2vU9EDQMfpw9sR_9KXp1y1wqryDuI&s=NRtTflYJyUK8VIImivppfYCSpSg7Nt65PYReNZRAiI0&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU smime.p7s Description: S/MIME Cryptographic Signature
Re: possible bugs with colored-stats
Le 29.10.20 à 06:54, Clark Wang a écrit : > > I can reproduce the similar issue with my bash 4.4.12 and PS0="\[\e[0m\]" > fix it for me. > > -clark > I had to change at one point the PS0="\[\e[0m\] to PS0="\[\e[38;5;15m\]. I tried again, it shows correctly the output of a command (grey is ok for me instead of white for 1st problem) but still shows the 1st file with the color of the command input with tab completion (2nd problem I have). It does it with bash 4.4-rc2, bash 5.0.18 and bash 5.1-rc1 on my system (fedora 33). I will try to look further in readline, to at least understand better. Thanks OpenPGP_0xEA0DA251B671CC2A.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: read with very small timeout sometime hand on stdin
On Wed, Oct 28, 2020 at 09:23:09AM -0400, Chet Ramey wrote:
>
> I can't reproduce this using the following stripped-down reproducer:
> trap 'echo $f ; exit' SIGINT
>
> for f in {1..1}; do
> read -t .01 v
> if [ $? -ne 142 ]; then
> echo $f: $?
> fi
> done
This is strange: $? seem to be alway 142! On my host:
Debian 10.4 - Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz - 32Gb ram
$ TIMEFORMAT="U:%U S:%S R:%R"
$ time for f in {1..1000};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..1000};do sleep 3;echo;done)
U:0.206 S:0.032 R:0.240
$ time for f in {1..1000};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..1000};do sleep 3;echo;done)
U:0.167 S:0.068 R:0.236
$ time for f in {1..1000};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..1000};do sleep 3;echo;done)
U:0.207 S:0.049 R:24.152
$ time for f in {1..1000};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..1000};do sleep 3;echo;done)
U:0.177 S:0.067 R:6.233
Where 6 second seem represent two `sleep 3;echo` ...
Same on my raspberry-pi (BCM2835 ARMv6-compatible rev 7 (v6l) - 512M),
Machine Type: armv6l-unknown-linux-gnueabihf - 5.1.0.rc1
...but with 100 loop and 10 second sleep:
$ TIMEFORMAT="U:%U S:%S R:%R"
$ time for f in {1..100};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..100};do sleep 10;echo;done )
U:0.447 S:0.021 R:0.995
$ time for f in {1..100};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..100};do sleep 10;echo;done )
U:8.589 S:0.108 R:10.918
$ time for f in {1..100};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..100};do sleep 10;echo;done )
U:0.445 S:0.022 R:0.999
$ time for f in {1..100};do read -t .01 v; [ $? -ne 142 ] &&
echo f:$f, v:$v, RC:$?. ; done < <(
for i in {1..100};do sleep 10;echo;done )
U:0.540 S:0.065 R:10.958
Again, no output! (Result code seem to be alway 142)
But clearly without `sleep 10; echo` loop as input, this test may hang...
until you hit ... maybe several times...
Nota: None of the host used to make this tests are really ``quiet'':
My host loadavg: 0.48 0.78 0.91 2/1074 15425
Raspbery load : 0.93 1.01 1.12 2/87 28120
This seem harder to reproduce on quiet system
Other host load: 0.00 0.04 0.00 1/772 468
U:0.015 S:0.008 R:0.023
U:0.021 S:0.000 R:0.023
U:0.021 S:0.000 R:0.022
U:0.015 S:0.010 R:3.023
U:0.015 S:0.004 R:0.020
U:0.018 S:0.004 R:0.023
U:0.010 S:0.008 R:0.019
U:0.010 S:0.012 R:0.023
U:0.023 S:0.000 R:0.024
U:0.015 S:0.004 R:0.020
U:0.019 S:0.000 R:0.020
U:0.015 S:0.008 R:0.023
U:0.038 S:0.008 R:3.023
U:0.023 S:0.000 R:0.023
U:0.030 S:0.000 R:3.025
U:0.009 S:0.008 R:0.018
U:0.020 S:0.007 R:3.031
--
Félix Hauri -- http://www.f-hauri.ch
Re: possible bugs with colored-stats
On 10/29/20 6:38 AM, Arnaud wrote: > Le 29.10.20 à 06:54, Clark Wang a écrit : >> >> I can reproduce the similar issue with my bash 4.4.12 and PS0="\[\e[0m\]" >> fix it for me. >> >> -clark >> > > I had to change at one point the PS0="\[\e[0m\] to PS0="\[\e[38;5;15m\]. Except for this changing the default color to light grey, which I have trouble seeing, everything looks fine. I'm testing on macOS Terminal. If you want to look further, my guess is that the terminal is still using the PS1 color when it prints the colored possible completions, and reverting to the "normal" color after printing each possible completion messes up the terminal's idea of the current color somehow. Either way, the functions you want to look at are colored_stat_start colored_stat_end which are called when the completion code prints colored possible completions. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
