bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bash history / ssh+sudo+reverse-i-search will execute the command found


From: Stein Arne Storslett
Subject: bash history / ssh+sudo+reverse-i-search will execute the command found if the ssh process is killed
Date: Wed, 19 Oct 2016 19:46:49 +0200

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
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin'  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic
uname output: Linux server1 3.10.0-327.18.2.el7.x86_64 #1 SMP Fri Apr
8 05:09:53 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 4.2
Patch Level: 46
Release Status: release

Description:
        Bash history / reverse-i-search will execute the command found
if the ssh process is killed.
        This happens with the combination of:
         - ssh into server
         - sudo su -
         - reverse-i-search   # <ctrl>+R

        I.e. a user in the middle of a bash reverse-i-search, and the
ssh process is killed
        i.e. due to a network outage.

        This can be critical if the command in the search history is
something harmful or potentially unwanted, like a server shutdown

        The chain of events during the kill, and how the sub processes
are killed might be the cause here, but nevertheless no signal
        should cause the bash history command to run.

Repeat-By:
        Pre-requisites: a user with a bash shell

        Log (SSH) in to a server (server1)

        On server1 type
            date > /tmp/file.txt
            rm /tmp/file.txt

        On server1 type
            <ctrl>+R "date"

        Log in to server1 on a second terminal / ssh window
            ps -ef | grep <address@hidden>
            kill <pid-of-sshd-process-for-first-login>
            ls -l /tmp/file.txt

        The /tmp/file.txt has now been created

Verified on (also):
         Ubuntu 16.04 LTS
        ================
        Machine: x86_64
        OS: linux-gnu
        Compiler: gcc
        Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL $
        uname output: Linux ubuntu1604 4.4.0-43-generic #63-Ubuntu SMP
Wed Oct 12 13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
        Machine Type: x86_64-pc-linux-gnu

        Bash Version: 4.3
        Patch Level: 46
        Release Status: release

        Bash Version: 4.3 Patch Level: 46 Release Status: release

        CentOS Linux release 7.2.1511 (Core)
        ===========
        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
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin'  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic
        uname output: Linux centos7 3.10.0-327.22.2.el7.x86_64 #1 SMP
Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
        Machine Type: x86_64-redhat-linux-gnu

        Bash Version: 4.2
        Patch Level: 46
        Release Status: release



Unable to reproduce with:
        - Local gnome terminal + bash in ubuntu
        - ssh to a user in two terminals, repeat steps and kill the
second terminal

        It seems that there is something happening when killing the
sshd process in combination with sudo

-- 
Stein Arne Storslett



reply via email to

[Prev in Thread] Current Thread [Next in Thread]