Shell Command Injection with the hostname
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| bash (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
If the HOSTNAME of the pc contains a shell command ,
the command will run every time you start a terminal, tty or xterm.
The command will also executed every time when you type in some command.
If you for example change the directory , it will run again.
Exploit Demo :
1) edit "/etc/hosts" to this :
127.0.0.1 localhost
127.0.1.1 `ls>bug`
2) edit "/etc/hostname" to this :
`ls>bug`
3) reboot
4) start a terminal
5) Now a file with the name "bug" will in your home folder !
6) Change the directory to Downloads with "cd Downloads/"
7) Now a file with the name "bug" is in your Downloads !
8) Remove the file with "rm bug"
9) The file "bug" is still there !
Have a look on the screenshot i have attached.
Solution:
The hostname should be checked if there are shell commands inside !!
By the way :
The hostname is not always in the hands of the root.
Some people rent "vservers" and the hostname is in the hands of the isp.
ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: bash 4.3-14ubuntu1
ProcVersionSign
Uname: Linux 4.2.0-15-generic x86_64
ApportVersion: 2.19.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Oct 16 22:31:46 2015
InstallationDate: Installed on 2015-10-09 (6 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20151009)
SourcePackage: bash
UpgradeStatus: No upgrade log present (probably fresh install)
Bernd Dietzel (l-ubuntuone1104) wrote : | #1 |
information type: | Private Security → Public Security |
Seth Arnold (seth-arnold) wrote : | #2 |
Bernd Dietzel (l-ubuntuone1104) wrote : | #3 |
I agree,
i think the hostname should be in the hands of the kernel only.
Should not be overwritten by /etc/hostname.sh.
Bernd Dietzel (l-ubuntuone1104) wrote : | #4 |
typo ... the path is
/etc/init.
Bernd Dietzel (l-ubuntuone1104) wrote : | #5 |
german demo video
https:/
Bernd Dietzel (l-ubuntuone1104) wrote : | #6 |
Patch :
HOSTNAME=
Bernd Dietzel (l-ubuntuone1104) wrote : | #7 |
Thats better ... (the "-" was wrong in my previous posting )
HOSTNAME=
i attached a modified hostname.sh wich uses bash.
it can be startet manualy with
sudo /etc/init.
The command should somehow run at startup ... but does not by default ?
Bernd Dietzel (l-ubuntuone1104) wrote : | #8 |
Workaround ...
to make my modified "hostname.sh" script run at startup, i changed the file /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
/etc/init.
exit 0
Bernd Dietzel (l-ubuntuone1104) wrote : | #9 |
#! /bin/sh
# run this as root early in the boot order. No other script like hostname.sh should run later
HOSTNAME=
Bernd Dietzel (l-ubuntuone1104) wrote : | #10 |
script
Marc Deslauriers (mdeslaur) wrote : | #11 |
I'm not sure what the attack vector here is. /etc/hostname is only writeable by root.
Is there any way for an attacker to control /etc/hostname?
Bernd Dietzel (l-ubuntuone1104) wrote : | #12 |
@Marc
Yes , if some application has a bug , for example MintNanny :
https:/
Tyler Hicks (tyhicks) wrote : | #13 |
This issue was assigned CVE-2016-0634. See the oss-security notice here:
Launchpad Janitor (janitor) wrote : | #14 |
This bug was fixed in the package bash - 4.3-15ubuntu1.1
---------------
bash (4.3-15ubuntu1.1) yakkety-security; urgency=medium
* SECURITY UPDATE: word expansions on the prompt strings (LP: #1507025)
- debian/
- CVE-2016-0634
* SECURITY UPDATE: code execution via crafted SHELLOPTS and PS4
(LP: #1689304)
- debian/
- CVE-2016-7543
* SECURITY UPDATE: restricted shell bypass via use-after-free
- debian/
builtins/
- CVE-2016-9401
-- Marc Deslauriers <email address hidden> Tue, 16 May 2017 07:44:56 -0400
Changed in bash (Ubuntu): | |
status: | New → Fix Released |
Launchpad Janitor (janitor) wrote : | #15 |
This bug was fixed in the package bash - 4.3-7ubuntu1.7
---------------
bash (4.3-7ubuntu1.7) trusty-security; urgency=medium
* SECURITY UPDATE: word expansions on the prompt strings (LP: #1507025)
- debian/
- CVE-2016-0634
* SECURITY UPDATE: code execution via crafted SHELLOPTS and PS4
(LP: #1689304)
- debian/
- CVE-2016-7543
* SECURITY UPDATE: restricted shell bypass via use-after-free
- debian/
builtins/
- CVE-2016-9401
-- Marc Deslauriers <email address hidden> Tue, 16 May 2017 07:52:48 -0400
Changed in bash (Ubuntu): | |
status: | New → Fix Released |
Launchpad Janitor (janitor) wrote : | #16 |
This bug was fixed in the package bash - 4.3-14ubuntu1.2
---------------
bash (4.3-14ubuntu1.2) xenial-security; urgency=medium
* SECURITY UPDATE: word expansions on the prompt strings (LP: #1507025)
- debian/
- CVE-2016-0634
* SECURITY UPDATE: code execution via crafted SHELLOPTS and PS4
(LP: #1689304)
- debian/
- CVE-2016-7543
* SECURITY UPDATE: restricted shell bypass via use-after-free
- debian/
builtins/
- CVE-2016-9401
-- Marc Deslauriers <email address hidden> Tue, 16 May 2017 07:51:45 -0400
Changed in bash (Ubuntu): | |
status: | New → Fix Released |
Alex Murray (alexmurray) wrote : | #18 |
Even our oldest supported (as extended security maintenance) release Ubuntu 12.04 had bash 4.2 (https:/
I can't imagine the effort involved in hardening all applications to treat the hostname as untrusted input.
ISPs that sell vservers are really no different from Intel or AMD or whoever makes your CPU -- you trust them completely and totally with your data, your executables, and your entire operating environment. They can inject anything they wish into your system's memory whenever they wish.
Making sure the dhcp clients don't allow setting these kinds of hostnames however, that might be a good idea. Enforcing the usual dns guidelines of a-zA-Z0-9-_ might be worthwhile..
Thanks