Re: possible bugs with colored-stats
On Thu, Oct 29, 2020 at 4:11 AM Arnaud wrote: > > Description: > I have colored my prompt with colors, using PS1 and PS0. > > PS1 ends with a color definition, so the command entered is > colored. > PS0 resets the color so the output has the standard colors. > I have actived colored-stats, so when I use tab completion, the > colors I use in the command doesn't show in the tab completion. > > Problem 1 > If the list starts with a file, only the 1st file is colored with > the PS1 color. > If the list starts with a folder, the colors are ok. > > Problem 2 > when I list the content of a folder with ls, the color is ok > (white in my case, until I reach a folder, > it then switches the color of the following files to grey. > > I tried looking in the bash code to try to find the problem, but I > cannot locate the part of the code for that (not experienced in C) > Normally, readline should be the part I am looking for, but I also > have readline installed in my system, so it should be in it? > (tried to remove the readline package in my system to be sure, but > it wants to remove systemd, so I didn't) > > it seems to also do this with 5.1-rc1 > > Repeat-By: > add "set colored-stats on" in ~/.inputrc (may need to restart the > shell) > add at the end of PS1: "(\[\€[38;5;220m\]" , for example > add for PS0: "\[\e[38;5;15m\]" > I can reproduce the similar issue with my bash 4.4.12 and PS0="\[\e[0m\]" fix it for me. -clark
Re: possible bugs with colored-stats
On 10/28/20 4:10 PM, Arnaud wrote: > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > Description: > I have colored my prompt with colors, using PS1 and PS0. > > PS1 ends with a color definition, so the command entered is colored. > PS0 resets the color so the output has the standard colors. I'm not sure what terminal emulator you're using, but that PS0 is what turns the `normal' color to light grey on mine. It's pretty tough to see. > I have actived colored-stats, so when I use tab completion, the > colors I use in the command doesn't show in the tab completion. > > Problem 1 > If the list starts with a file, only the 1st file is colored with the > PS1 color. > If the list starts with a folder, the colors are ok. I can't reproduce this. > Problem 2 > when I list the content of a folder with ls, the color is ok (white > in my case, until I reach a folder, > it then switches the color of the following files to grey. Nor this. > > I tried looking in the bash code to try to find the problem, but I > cannot locate the part of the code for that (not experienced in C) > Normally, readline should be the part I am looking for, but I also > have readline installed in my system, so it should be in it? This is part of readline, yes. -- ``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/
possible bugs with colored-stats
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -flto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-parentheses -Wno-format-security uname output: Linux localhost.localdomain 5.9.1-300.fc33.x86_64 #1 SMP Fri Oct 23 11:58:21 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release Description: I have colored my prompt with colors, using PS1 and PS0. PS1 ends with a color definition, so the command entered is colored. PS0 resets the color so the output has the standard colors. I have actived colored-stats, so when I use tab completion, the colors I use in the command doesn't show in the tab completion. Problem 1 If the list starts with a file, only the 1st file is colored with the PS1 color. If the list starts with a folder, the colors are ok. Problem 2 when I list the content of a folder with ls, the color is ok (white in my case, until I reach a folder, it then switches the color of the following files to grey. I tried looking in the bash code to try to find the problem, but I cannot locate the part of the code for that (not experienced in C) Normally, readline should be the part I am looking for, but I also have readline installed in my system, so it should be in it? (tried to remove the readline package in my system to be sure, but it wants to remove systemd, so I didn't) it seems to also do this with 5.1-rc1 Repeat-By: add "set colored-stats on" in ~/.inputrc (may need to restart the shell) add at the end of PS1: "(\[\€[38;5;220m\]" , for example add for PS0: "\[\e[38;5;15m\]" (I tried to send it with bashbug on my system, but I didn't see it coming in the list, so sending it again) OpenPGP_0xEA0DA251B671CC2A.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
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://exchange.xforce.ibmcloud.com/vulnerabilities/173116 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.eduhttp://tiswww.cwru.edu/~chet/
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://exchange.xforce.ibmcloud.com/vulnerabilities/173116 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. > https://packetstormsecurity.com/files/155687 > CVSS Base Score: 8.8 > CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) > There is no CVE identifier associated with the vulnerability and I've been > unable to determine whether there is a remediation available. Is anyone > aware of this vulnerability and where it may be tracked in Gnu Bash? I looked at your links. It seems this is a metasploit module of type "payload". Metasploit modules come in different types: - exploit: use a vulnerability to break into a system - payload: once the exploit is successful, inject shellcode into the system to do something malicious This specific payload uses a benevolent feature of GNU bash, subverted to evil purposes: the ability to run initialization commands when opening the terminal. In this case, the initialization command is a malware payload. There is no code execution vulnerability here, bash is a program that exists solely to performs code execution and you are supposed to treat your bash profile as security-sensitive. There is no way for an attacker to exploit this over the network. Bash does not read a profile from the network, and the profile is not accessible over the network. An attacker would need to first log in to your system with full privileges in order to install the malware. The malware would then run locally. Of course, any malware might itself contain a service to communicate over the network and receive updated attack instructions or open a backdoor. But this does not mean Bash itself is vulnerable to network attacks... ... In short: The IBM X-Force Exchange entry is completely incorrect and misunderstood the packetstorm link. The entry should be withdrawn entirely. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: GNU Bash profile code execution vulnerability enquiry
On Wed, Oct 28, 2020 at 05:11:42PM +, Rachel Alderman wrote: > I've been made aware of a GNU Bash profile code execution vulnerability > https://exchange.xforce.ibmcloud.com/vulnerabilities/173116 reported last > December (2019-12-16) This URL doesn't work without Javascript, and with Javascript enabled, it pops up a semi-translucent "please log in" window covering most of the text. The text that *is* visible appears to be only this: > 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. That doesn't tell us much. > https://packetstormsecurity.com/files/155687 That URL talks about writing something to the user's .bashrc so that next time they open bash, something bad happens. If you've got write access to the user's .bashrc file then sure, you can screw them up pretty badly. > There is no CVE identifier associated with the vulnerability ... so it's not even recognized as a real vulnerability by world experts? > and I've been > unable to determine whether there is a remediation available. Is anyone > aware of this vulnerability and where it may be tracked in Gnu Bash? "Remediation" for what, exactly? I'm not seeing any description of an actual exploit. Not even a vague one. Do you have any details on how this "exploit" is performed?
GNU Bash profile code execution vulnerability enquiry
Hi Bash Maintainers, I've been made aware of a GNU Bash profile code execution vulnerability https://exchange.xforce.ibmcloud.com/vulnerabilities/173116 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. https://packetstormsecurity.com/files/155687 CVSS Base Score: 8.8 CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) There is no CVE identifier associated with the vulnerability and I've been unable to determine whether there is a remediation available. Is anyone aware of this vulnerability and where it may be tracked in Gnu Bash? Many Thanks 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 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: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 10/28/20 10:51 AM, Dr. Werner Fink wrote: > On 2020/10/28 10:23:57 -0400, Chet Ramey wrote: >> On 10/16/20 9:28 AM, Chet Ramey wrote: >>> On 10/16/20 9:16 AM, Dr. Werner Fink wrote: >>> Also a warning hint in the manual page could help users before enabling this feature :) >>> >>> I agree, and the manual page in the release will reflect bracketed paste's >>> default setting. However, readline doesn't try to enable bracketed paste if >>> tcgetattr fails, which it will on an fd that's not a terminal, so I am >>> fairly sure that expect/pexpect use ptys to masquerade as terminals. >>> >>> The biggest problem with bracketed paste is that right now, there's simply >>> no way to determine whether or not a particular terminal supports it. >> >> I wonder if it would make sense for bash to compile its version of readline >> with bracketed paste on by default, but the standalone readline library >> version have it off. Or is that too clever by half? > > Ohmm ... this makes no diffference here as bash (and all other tools) > uses, if ever possible, the system libraries by policy. And the readline > library is a system library. That means if there is a security issue within > such a system library it has to be fixed only once. Then it seems like the best way to address these competing requirements is to allow readline to be configured with the default one way or another. I already added a #define that can be used to set the default value of enable-bracketed-paste. -- ``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/
Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 2020/10/28 10:23:57 -0400, Chet Ramey wrote: > On 10/16/20 9:28 AM, Chet Ramey wrote: > > On 10/16/20 9:16 AM, Dr. Werner Fink wrote: > > > >> Also a warning hint in the manual page could > >> help users before enabling this feature :) > > > > I agree, and the manual page in the release will reflect bracketed paste's > > default setting. However, readline doesn't try to enable bracketed paste if > > tcgetattr fails, which it will on an fd that's not a terminal, so I am > > fairly sure that expect/pexpect use ptys to masquerade as terminals. > > > > The biggest problem with bracketed paste is that right now, there's simply > > no way to determine whether or not a particular terminal supports it. > > I wonder if it would make sense for bash to compile its version of readline > with bracketed paste on by default, but the standalone readline library > version have it off. Or is that too clever by half? Ohmm ... this makes no diffference here as bash (and all other tools) uses, if ever possible, the system libraries by policy. And the readline library is a system library. That means if there is a security issue within such a system library it has to be fixed only once. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr signature.asc Description: PGP signature
Re: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 10/16/20 9:28 AM, Chet Ramey wrote: > On 10/16/20 9:16 AM, Dr. Werner Fink wrote: > >> Also a warning hint in the manual page could >> help users before enabling this feature :) > > I agree, and the manual page in the release will reflect bracketed paste's > default setting. However, readline doesn't try to enable bracketed paste if > tcgetattr fails, which it will on an fd that's not a terminal, so I am > fairly sure that expect/pexpect use ptys to masquerade as terminals. > > The biggest problem with bracketed paste is that right now, there's simply > no way to determine whether or not a particular terminal supports it. I wonder if it would make sense for bash to compile its version of readline with bracketed paste on by default, but the standalone readline library version have it off. Or is that too clever by half? -- ``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/
Re: read with very small timeout sometime hand on stdin
On 10/28/20 7:06 AM, felix wrote:
> Bash Version: 5.1
> Patch Level: 0
> Release Status: rc1
>
> Description:
> Trying to see limits of timeout with `read -t`, I encounter strange
> and unconstant result: sometime `read -t .01` don't consider
> timeout, when running fastly multiple time.
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
> Ok, then microsecond seem to by smallest value.
Yes, the smallest granularity is microseconds. The code uses interval
timers and timevals.
--
``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/
read with very small timeout sometime hand on stdin
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux medium 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 0
Release Status: rc1
Description:
Trying to see limits of timeout with `read -t`, I encounter strange
and unconstant result: sometime `read -t .01` don't consider
timeout, when running fastly multiple time.
From help:
-t timeout time out and return failure... may be a fractional...
... exit status is greater than 128 if the timeout is exceeded.
Repeat-By:
$ read -t .001 foo ; echo $?
1
$ read -t .01 foo ;echo $?
142
Ok, then microsecond seem to by smallest value.
$ tot=0; for i in {1..100} ;do
rt=${EPOCHREALTIME//.}
read -t .01 foo
((tot+=${EPOCHREALTIME//.}-rt))
sleep .002
done; echo ${tot:: -2}.${tot: -2}
If this not end after 1 second, hit , wait 1 second
and repeat (and count); You won't hit 100x !
Maybe this return correctly after ~0.2 seconds. If yes, try
again. Mostly I have to hit 3 - 8x for this 100 loop test.
$ tot=0; for i in {1..100} ;do
rt=${EPOCHREALTIME//.}
read -t .01 foo
((tot+=${EPOCHREALTIME//.}-rt))
done < <(
while :;do sleep 1;echo;done
);echo ${tot:: -2}.${tot: -2}
Correct output must be < 1000
--
Félix Hauri -- http://www.f-hauri.ch
