CVE-2014-7187 and CVE-2014-6278

[Jack]

As title, what difference between CVE-2014-7187 and CVE-2014-6278 ?
In CVE-2014-7187
 says,
the test case is probe='() { echo vulnerable; }' bash -c probe
but in Shellshocker  CVE-2014-6278
, both of them seems equally
.

Line is corrupted when pasting long string in vi mode with exit_attribute_mode prompt

[Jack Pearson]

To reproduce:

- Launch a bash shell in a terminal emulator (I've tested konsole and 
gnome-terminal on KDE 5.23.4 with X11, if that matters).


- Copy "Lorem ipsum dolor sit amet, consectetur adipiscing elit" 
(without the quotes) to your clipboard.


- Run these commands in the terminal:

  ```
  bash --norc --noprofile
  set -o vi
  PS1='$(tput sgr0)' # emit exit_attribute_mode capability string
  ```

- Press Ctrl-Shift-V to paste lipsum text into the terminal

- Press Esc

Observe that first six characters of the pasted string have been 
duplicated. If you try to delete them you'll notice you're unable to. 
They're in the same state as the characters that comprise the prompt, 
whatever state that is.


Occasionally I've been able to delete the duplicated characters in 
gnome-terminal.


I've noticed that the length of the string matters. Moderately short 
strings don't cause this issue. If you're unable to reproduce, maybe try 
a longer string.


GNU bash, version 5.1.12(1)-release (x86_64-pc-linux-gnu)



Thanks for all the great work you guys do,

Jack

Potential for a cumulative patch (or tarball)?

[Jack Nagel]

>From a package management standpoint it is somewhat cumbersome to
fetch the base 4.2 tarball and the 37 patches in order to build the
latest and greatest; it would simplify things greatly if there was a
cumulative patch (or a complete tarball, ideally).

Would something like this be possible? What are the reasons for the
current release/patch system?

Thanks.

Jack Nagel

time builtin handles backgrounding poorly

[Jack Lloyd]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE  -O2 -g -pipe 
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux wks9 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 3.1
Patch Level: 7
Release Status: release

Description:

The time builtin seems to be confused if something is
backgrounded, and prints immediately the time rather than
waiting for the job to complete. I found this very unexpected.

Repeat-By:

$ time sleep 5
# hit C-Z to stop the job before 5 seconds

[1]+  Stopped sleep 5

real0m0.525s
user0m0.000s
sys 0m0.000s
$ fg
sleep 5
# the 5 second sleep continues
$

Expected behavior is:

$ /usr/bin/time sleep 5
# hit C-Z to suspend
[2]+  Stopped /usr/bin/time sleep 5
# wait a little bit here
(wks9 ~)$ fg
/usr/bin/time sleep 5
0.00user 0.00system 0:05.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+184minor)pagefaults 0swaps

I want to emphasize that this report is *not* about the different
output formats of the bash builtin and GNU time, but that bash does
not wait for the job to complete before printing the output. Instead
it seems to print as soon the prompt returns (?) - except this does
work OK:

$ time sleep 5 &
[2] 20220
$ # wait for 5 seconds
real0m5.017s
user0m0.000s
sys 0m0.004s

[2]-  Donetime sleep 5
$ 

Instead of using C-Z to suspend, you can also send a SIGSTOP to the
sleep process, same result.

I know 3.1.7 is old, but I didn't see anything in the changelog that
suggested this behavior had changed in 3.2. Apologies if it is already
known and/or fixed.

Re: time builtin handles backgrounding poorly

[Jack Lloyd]

On Thu, Sep 13, 2007 at 10:21:26PM -0400, Chet Ramey wrote:
> 
> `time' is not a builtin; it is a shell reserved word that causes timing
> information to be printed when `waitpid' returns.  It's a synchronous
> operation that doesn't interact as you'd like with job control.

Ah, I see. Is there any recommended way to disable time entirely?

alias time="command time"

seems to work, just wondering if there is a better solution.

-Jack

Re: Is this the expected behaviour for nameref in Bash 4.4 now?

[Jack Kuan]

Thanks for replying.

I was expecting that in the second iteration of the loop, the
local var=var_123  command would make var a normal variable again with
value "var_123"
and then the local -n var=$var would make var again a nameref to var_123.
This seems
to be the behavior of Bash 4.3.

But anyway, it's easy to work around by introducing another variable rather
than redefining the nameref var:

set -x

var_123=123
f() {
while (( $# )); do
shift
local var=var_123
local -n var_ref=$var
done
}

f one two


On Thu, Oct 20, 2016 at 4:02 PM, Dan Douglas  wrote:

> Yes that was an intentional change to require valid identifiers. I can't
> say it will always be that way or that there won't at some point be a
> workaround. You can stiill use `${!param}' for now to refer to positional
> parameters as you always could, but as usual that isn't useful if you
> want to assign by reference.
>

Re: Is this the expected behaviour for nameref in Bash 4.4 now?

[Jack Kuan]

thank you for the insight, it's very helpful!

On Oct 28, 2016 10:01 AM, "Chet Ramey"  wrote:

On 10/20/16 2:45 PM, kjk...@gmail.com wrote:
> set -x
>
> var_123=123
> f() {
> while (( $# )); do
> shift
> local var=var_123
> local -n var=$var; : status is $?
> local -p
> : var is $var
> done
> }
>
> f one two
>
>
> Running above script gives the follow output:
>
> + var_123=123
> + f one two
> + ((  2  ))
> + shift
> + local var=var_123
> + local -n var=var_123

`var' is a local nameref with value var_123

> + : status is 0
> + local -p
> var=var_123
> + : var is 123

Since var is a nameref, it expands to $var_123, which is 123

> + ((  1  ))
> + shift
> + local var=var_123

var doesn't get unset; it's still a nameref with value var_123.  Setting
the local attribute on an existing local variable doesn't unset any of
the variable's attributes.  You have to actually unset the variable to
do that.

> + local -n var=123
> ./x.sh: line 10: local: `123': invalid variable name for name reference

So now you try to assign `123' as the value of a nameref.  That would
cause subsequent attempts to assign to var to attempt to create and
assign to a variable named `123', which is invalid.  Bash-4.3 didn't
have enough error checking and would create variables with invalid names
in situations like this.

> + : status is 1
> + local -p
> var=var_123

This is probably where the confusion comes.  `local -p' doesn't print other
variable attributes.  If you had used `declare -p | grep var=' between the
two calls to `local' you would have seen that `var' had the nameref
attribute.

> + : var is 123
> + ((  0  ))

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~
chet/

Re: Line is corrupted when pasting long string in vi mode with exit_attribute_mode prompt

[Jack Pearson via Bug reports for the GNU Bourne Again SHell]

Ahh my bad, didn't read that section of the manual carefully enough. Thanks 
Andreas!

Jack

On December 18, 2021 8:03:17 AM PST, Andreas Schwab  
wrote:
>On Dez 17 2021, Jack Pearson wrote:
>
>>   PS1='$(tput sgr0)' # emit exit_attribute_mode capability string
>
>Non-printable characters in the prompt must be bracketed by \[ \].
>
>PS1='\[$(tput sgr0)\]'
>
>-- 
>Andreas Schwab, sch...@linux-m68k.org
>GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
>"And now for something completely different."