Bash updating for preventing from shellshock

2014-12-02 Thread bijay pant 
From: root

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: 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
-DRECYCLES_PIDS  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
uname output: Linux localhost 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1
01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 4.1
Patch Level: 2
Release Status: release


*Bijay Pant*

*ph- 9848422934*

*email- bijaypa...@gmail.com ,bijay_...@yahoo.com
*
*website- http://www.bijaypant.com.np *

Re: Bash updating for preventing from shellshock

2014-12-02 Thread Steve Simmons 

On Dec 2, 2014, at 4:24 AM, bijay pant  wrote:

> From: root
> 
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: 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 
> -DRECYCLES_PIDS  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
> uname output: Linux localhost 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 
> EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-redhat-linux-gnu
> 
> Bash Version: 4.1
> Patch Level: 2
> Release Status: release

I assume you're asking if you're vulnerable. Yes, you are. Upgrade to patch 
level 17. Source at ftp://ftp.gnu.org/gnu/bash. 

Steve

Re: Bash updating for preventing from shellshock

2014-12-02 Thread Greg Wooledge 
On Tue, Dec 02, 2014 at 03:09:23PM +0545, bijay pant wrote:
> Bash Version: 4.1
> Patch Level: 2
> Release Status: release

4.1.2 is vulnerable to shellshock.  If you're going to compile from
source, you should compile a newer version with all the patches applied.

Patches for bash-4.1 are found in http://ftp.gnu.org/gnu/bash/bash-4.1-patches/

If you're willing to upgrade to the latest version of bash (4.3.30)
you can find a tarball with all the patches applied at
http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz

Or you can apply the patches to bash-4.3.tar.gz, if you prefer.

Bash crashes on detaching Screen

2014-12-02 Thread Darshit Shah 

I use GNU Screen along with Bash for my SSH sessions.

While detaching my Screen sessions I came across a weird Bash bug and I'd like 
your help in debugging this issue.


When I attempt to detach a running Screen session using `screen -Drr ,session 
name` command, the original shell which contained the screen session does not 
return to a prompt. It instead remains hung and a while later I get the message:


Warning: Program '/bin/bash' crashed

I'm running Arch Linux with Bash 4.3.30(1) and Konsole. I attempted to detach 
and reattach a screen session from Terminator and did not experience any crashes 
in Bash.


However, when I attempted the same from a virtual Terminal instead of an 
emulator, upon remotely detaching the screen session, my terminal directly 
displayed a login prompt again. This leads me to believe that Bash did crash 
even then and caused the login prompt to reappear.



--
Thanking You,
Darshit Shah


pgpG5IVU_mRow.pgp
Description: PGP signature

Re: Bash crashes on detaching Screen

2014-12-02 Thread Darshit Shah 

On 12/02, Darshit Shah wrote:

I use GNU Screen along with Bash for my SSH sessions.

While detaching my Screen sessions I came across a weird Bash bug and 
I'd like your help in debugging this issue.


When I attempt to detach a running Screen session using `screen -Drr 
,session name` command, the original shell which contained the screen 
session does not return to a prompt. It instead remains hung and a 
while later I get the message:


Warning: Program '/bin/bash' crashed

I'm running Arch Linux with Bash 4.3.30(1) and Konsole. I attempted to 
detach and reattach a screen session from Terminator and did not 
experience any crashes in Bash.


However, when I attempted the same from a virtual Terminal instead of 
an emulator, upon remotely detaching the screen session, my terminal 
directly displayed a login prompt again. This leads me to believe that 
Bash did crash even then and caused the login prompt to reappear.





I just recompiled my Bash with debugging symbols and attempted to run Bash under 
gdb. Here is the trace I received:



[remote power detached from 19442.pts-1.mordor]

Program received signal SIGHUP, Hangup.
0x7743b58a in waitpid () from /usr/lib/libc.so.6
(gdb) bt
#0  0x7743b58a in waitpid () from /usr/lib/libc.so.6
#1  0x0043dcfe in waitchld (block=block@entry=1, wpid=16581) at 
jobs.c:3224
#2  0x0043efc3 in wait_for (pid=16581) at jobs.c:2485
#3  0x0042fc21 in execute_command_internal (command=0x7eec10, 
asynchronous=0, pipe_in=-1, pipe_out=-255, fds_to_close=0x7d3920) at 
execute_cmd.c:829
#4  0x0042fdce in execute_command (command=0x7eec10) at 
execute_cmd.c:390
#5  0x0042e16d in execute_if_command (if_command=) at 
execute_cmd.c:3430
#6  execute_command_internal (command=0x7eeaf0, asynchronous=8317728, 
pipe_in=-1, pipe_out=365, fds_to_close=0x6f9fb0) at execute_cmd.c:897
#7  0x0042e78f in execute_connection (fds_to_close=, pipe_out=, pipe_in=, asynchronous=, 
   command=) at execute_cmd.c:2496

#8  execute_command_internal (command=0x7a5e20, asynchronous=0, pipe_in=-1, 
pipe_out=-1, fds_to_close=0x6f9fb0) at execute_cmd.c:945
#9  0x0042e0d9 in execute_command_internal (command=0x6fa110, 
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x6f9fb0) at 
execute_cmd.c:937
#10 0x00431310 in execute_function (var=var@entry=0x7c9970, flags=flags@entry=0, fds_to_close=fds_to_close@entry=0x6f9fb0, async=async@entry=0, 
   subshell=subshell@entry=0, words=) at execute_cmd.c:4539

#11 0x0042d769 in execute_builtin_or_function (flags=0, 
fds_to_close=0x6f9fb0, redirects=, var=0x7c9970, builtin=0x0, 
words=0x7d4ff0)
   at execute_cmd.c:4769
#12 execute_simple_command (simple_command=, pipe_in=-1, 
pipe_out=-1, async=0, fds_to_close=0x6f9fb0) at execute_cmd.c:4170
#13 0x0042e5ff in execute_command_internal (command=0x7eae20, 
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x6f9fb0) at 
execute_cmd.c:787
#14 0x0042fdce in execute_command (command=0x7eae20) at 
execute_cmd.c:390
#15 0x0041aa9e in reader_loop () at eval.c:160
#16 0x0041933e in main (argc=1, argv=0x7fffe4e8, 
env=0x7fffe4f8) at shell.c:755



Do let me know if there's any other way in which I can help in debugging this 
issue.


--
Thanking You,
Darshit Shah


pgpK5NFBet0AE.pgp
Description: PGP signature

Re: Bash crashes on detaching Screen

2014-12-02 Thread Eduardo A . Bustamante López 
On Tue, Dec 02, 2014 at 11:29:59PM +0530, Darshit Shah wrote:
> On 12/02, Darshit Shah wrote:
[...]
> >When I attempt to detach a running Screen session using `screen -Drr
> >,session name` command, the original shell which contained the screen
> >session does not return to a prompt. It instead remains hung and a while
> >later I get the message:
> >
> >Warning: Program '/bin/bash' crashed

You're using screen's power detach (-D -r), from 'man screen':
|   -D -r   Reattach a session. If necessary detach and logout remotely 
first.

Notice the *logout* part.

If you check screen.c (from GNU screen's source code), you will find:
| 1896  *D_POWERSIG_POWER_BYE  power detach -- attacher kills his parent
| 1897  *D_REMOTE_POWER SIG_POWER_BYE  remote power detach -- both

Then, in attacher.c, function Attach(how):
 185   if (ret == SIG_POWER_BYE)
 186 {
 187   int ppid;
 188   if (setgid(real_gid) || setuid(real_uid))
 189 Panic(errno, "setuid/gid");
 190   if ((ppid = getppid()) > 1)
 191 Kill(ppid, SIGHUP); /* notice this part */
 192   exit(0);
 193 }

It sends a SIGHUP to the parent process, i.e. bash.


So, now that we know that, let's test it:

Shell 1:
dualbus@hp:~$ PS1='remote> '
remote> echo "$BASH_VERSION"
4.3.30(1)-maint
remote> screen -S bug -s ~/local/bin/bash
[... screen issues a clear screen... ]
dualbus@hp:~$

Shell 2:
dualbus@hp:~$ PS1='attacher> '
attacher> screen -Drr bug
[... gets the cleared screen from before ...]
dualbus@hp:~$

Shell 1:
[remote power detached from 3739.bug]
zsh: hangup ~/local/bin/bash
 ^ this tells us that bash was killed by a SIGHUP


Now, let's try again, ignoring SIGHUP:

Shell 1:
dualbus@hp:~$ PS1='$$ remote> '
3994 remote> trap '' HUP # ignore SIGHUP
3994 remote> screen -S bug -s ~/local/bin/bash
[.. again screen clears the terminal ..]
dualbus@hp:~$

Shell 2:
dualbus@hp:~$ PS1='$$ attacher> '
3954 attacher> screen -Drr bug
[.. we get the cleared screen ..]
dualbus@hp:~$

Shell 1:
[remote power detached from 4043.bug]
3994 remote> echo I am alive
I am alive


#1 shell survived the power detach, because we ignored the SIGHUP sent by
screen to its parent. Now... what does this mean?


I means that:
* It's not a bash bug. Bash is supposed to die from SIGHUP if you're not doing
  anything to handle it. In fact, if you're using that screen's feature, it's
  *supposed* to log out/kill its parent shell.
* It happens to other shells.


> I just recompiled my Bash with debugging symbols and attempted to run Bash
> under gdb. Here is the trace I received:
> 
> 
> [remote power detached from 19442.pts-1.mordor]
> 
> Program received signal SIGHUP, Hangup.
Yep, dies from SIGHUP. Don't use screen's power detach (-D -r) if you don't
want this to happen. I normally use (-d -r), which doesn't have this effect.

Re: Bash crashes on detaching Screen

2014-12-02 Thread Chet Ramey 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/2/14, 12:59 PM, Darshit Shah wrote:

>> However, when I attempted the same from a virtual Terminal instead of an
>> emulator, upon remotely detaching the screen session, my terminal
>> directly displayed a login prompt again. This leads me to believe that
>> Bash did crash even then and caused the login prompt to reappear.
>>
>>
> 
> I just recompiled my Bash with debugging symbols and attempted to run Bash
> under gdb. Here is the trace I received:
> 
> 
> [remote power detached from 19442.pts-1.mordor]
> 
> Program received signal SIGHUP, Hangup.

The shell received SIGHUP, presumably sent by screen or the vty driver.
SIGHUP is a fatal signal; the shell catches it, cleans up, restores the
default signal handler, and resends SIGHUP to itself, which results in
bash exiting due to the SIGHUP.

This is not a bug.

- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAlR+FrMACgkQu1hp8GTqdKtO8wCeLT+SAznAczjfUuko5fBmcWnm
87EAn1k4Ps7hrTGULjP+2ysstxDYeW8S
=7ZUh
-END PGP SIGNATURE-

bug with multiline strings parsing and single-quoted !

2014-12-02 Thread gennady . kupava 
This looks like a bug:

gena@note2:~$ echo "a
> b" | echo '!'
bash: !': event not found
> ^C
gena@note2:~$ 

Is it?

Gennady

Re: bug with multiline strings parsing and single-quoted !

2014-12-02 Thread Ángel González 
gennady.kupava wrote:
> This looks like a bug:
> 
> gena@note2:~$ echo "a
> > b" | echo '!'
> bash: !': event not found
> > ^C
> gena@note2:~$ 
> 
> Is it?
> 
> Gennady

IMHO it is. Confirmed in 4.3.30

Re: Bash crashes on detaching Screen

2014-12-02 Thread Darshit Shah 

On 12/02, Eduardo A. Bustamante López wrote:

On Tue, Dec 02, 2014 at 11:29:59PM +0530, Darshit Shah wrote:

On 12/02, Darshit Shah wrote:

[...]

>When I attempt to detach a running Screen session using `screen -Drr
>,session name` command, the original shell which contained the screen
>session does not return to a prompt. It instead remains hung and a while
>later I get the message:
>
>Warning: Program '/bin/bash' crashed


You're using screen's power detach (-D -r), from 'man screen':
|   -D -r   Reattach a session. If necessary detach and logout remotely 
first.

Notice the *logout* part.

If you check screen.c (from GNU screen's source code), you will find:
| 1896  *D_POWERSIG_POWER_BYE  power detach -- attacher kills his parent
| 1897  *D_REMOTE_POWER SIG_POWER_BYE  remote power detach -- both

Then, in attacher.c, function Attach(how):
185   if (ret == SIG_POWER_BYE)
186 {
187   int ppid;
188   if (setgid(real_gid) || setuid(real_uid))
189 Panic(errno, "setuid/gid");
190   if ((ppid = getppid()) > 1)
191 Kill(ppid, SIGHUP); /* notice this part */
192   exit(0);
193 }

It sends a SIGHUP to the parent process, i.e. bash.


So, now that we know that, let's test it:

Shell 1:
dualbus@hp:~$ PS1='remote> '
remote> echo "$BASH_VERSION"
4.3.30(1)-maint
remote> screen -S bug -s ~/local/bin/bash
[... screen issues a clear screen... ]
dualbus@hp:~$

Shell 2:
dualbus@hp:~$ PS1='attacher> '
attacher> screen -Drr bug
[... gets the cleared screen from before ...]
dualbus@hp:~$

Shell 1:
[remote power detached from 3739.bug]
zsh: hangup ~/local/bin/bash
^ this tells us that bash was killed by a SIGHUP


Now, let's try again, ignoring SIGHUP:

Shell 1:
dualbus@hp:~$ PS1='$$ remote> '
3994 remote> trap '' HUP # ignore SIGHUP
3994 remote> screen -S bug -s ~/local/bin/bash
[.. again screen clears the terminal ..]
dualbus@hp:~$

Shell 2:
dualbus@hp:~$ PS1='$$ attacher> '
3954 attacher> screen -Drr bug
[.. we get the cleared screen ..]
dualbus@hp:~$

Shell 1:
[remote power detached from 4043.bug]
3994 remote> echo I am alive
I am alive


#1 shell survived the power detach, because we ignored the SIGHUP sent by
screen to its parent. Now... what does this mean?


I means that:
* It's not a bash bug. Bash is supposed to die from SIGHUP if you're not doing
 anything to handle it. In fact, if you're using that screen's feature, it's
 *supposed* to log out/kill its parent shell.
* It happens to other shells.



I just recompiled my Bash with debugging symbols and attempted to run Bash
under gdb. Here is the trace I received:


[remote power detached from 19442.pts-1.mordor]

Program received signal SIGHUP, Hangup.

Yep, dies from SIGHUP. Don't use screen's power detach (-D -r) if you don't
want this to happen. I normally use (-d -r), which doesn't have this effect.


Hey Eduardo,

Thanks a lot for such a detailed explanation of why this happens. I guess I 
didn't read the Screen Man page correctly and started using power detach.


For a long time I had no issues, but it seems like Konsole has problems when 
Bash suddenly exits like that. None of the other emulators gave any serious 
problems, but Konsole would be stuck with a crash notice. It was this crash 
notice which led me to believe that the fault is in Bash.


I'll start using the normal detach, -d -r, and also report this issue to the 
Konsole team and see such exits can be handled more gracefully by them.


--
Thanking You,
Darshit Shah


pgplVLO8rdo1o.pgp
Description: PGP signature

Re: bug with multiline strings parsing and single-quoted !

2014-12-02 Thread Piotr Grzybowski 
Hey,

 I think in this case, history_expand lib/readline/histexpand.c:905 is
invoked with hstring="b\" | echo '!'", and goes wrongly into history
expansion.
 Not that I know how to fix it ;-)

cheers,
pg



On Tue, Dec 2, 2014 at 10:02 PM,   wrote:
> This looks like a bug:
>
> gena@note2:~$ echo "a
>> b" | echo '!'
> bash: !': event not found
>> ^C
> gena@note2:~$
>
> Is it?
>
> Gennady