LinuxQuestions.org - Bash "shellshock" CVE-2014-6271 CVE-2014-7169

Page 1 of 2

Show 50 post(s) from this thread on one page

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - rated 10 ! (https://www.linuxquestions.org/questions/linux-security-4/bash-shellshock-cve-2014-6271-cve-2014-7169-rated-10-a-4175519975/)

syg00

09-24-2014 07:52 PM

Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - rated 10 !

http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-6271

Worse than Heartbleed due to the number of exposed systems some claim.

ilesterg

09-25-2014 01:39 AM

Bash Remote Code Execution Vulnerability (Shellshock)

Ok, so this news got me this morning. Basically, it says bash can be exploited to gain control of the shell.

From what I have gathered to far, the following can be used to test if your machine is vulnerable:

Code:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

CentOS has immediately released a patch solve this issue.

CentOS update

Refs:
CERT
GNU

Can anyone please share what they know about this bug?

yooy	09-25-2014 03:25 AM

i run all upgrades on my ubuntu but according to test it is still vulnerable.

evo2	09-25-2014 03:34 AM

Hi,

Quote:

Originally Posted by yooy (Post 5243987)

i run all upgrades on my ubuntu but according to test it is still vulnerable.

The Ubuntu Security Notice USN-2362-1 indicates they have fixes for the LTS releases.

Evo2.

Guttorm

09-25-2014 03:49 AM

For this bug to be exploitable from remote, you need to have a bash script that can be run from remote. A cgi script using bash is vulnerable. Fortunatly, the default shell is usually not bash anymore, and bash cgi scripts are not common.

I worry more about embedded systems with web interfaces.

tux100

09-25-2014 07:22 AM

Shellshock Patching RHEL

$ env var='() { ignore this;}; echo vulnerable' bash -c /bin/true

My servers are RHEL 6.

If the bash is vulnerable, should I

A) download the latest patched bash rpm and install it ?

B) or can I safely yum upgrade ONLY the patched bash package ?
I do not want to update/upgrade anything other than bash.

C) Some sources say a reboot is required, some say a ldconfig will suffice. Does option A or B require a reboot or an ldconfig only ?

sag47

09-25-2014 07:47 AM

First determine if you're affected. Do you have restricted users connecting via public key auth forced to execute a script rather than be dropped into a shell? If not then this vulnerability doesn't affect you much.

If so first update and determine if it has already been fixed.

Code:

# https://access.redhat.com/node/1207723

sudo yum update bash

sudo /sbin/ldconfig

rpm -q --changelog bash | grep CVE-2014-6271

If you can't do that then switch the shell of the user away from bash to csh, ksh, or zsh.

szboardstretcher

09-25-2014 09:35 AM

Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - Shell shock patching?

This has not been updated since yesterday, so realize that there is more information out there about the bug, and more fixes and patches now. Go seek them.

This is a good starting point, but IT IS NOT an exhaustive resource.

Vulnerability:
Shell shock - Bash Bug - Bash Attack

CVE
http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-6271

Breakdown:

Quote:

The vulnerability is caused by the ability to create environment variables with values before calling the bash shell. The variables that are passed can contain code, which are executed before the shell is actually invoked. The vulnerability is then exposed in the ability to add extra code to the end of these functions.

More info:
The bug can currently be exploited through externally facing WEB servers as well as anything that listens to the world at large and sends variable info to bash. Current 0-day's include vuln scanning for Cpanel and other well known CGI scripts on the net.

The CURRENT primary attack vector is old CGI scripts.

http://seclists.org/oss-sec/2014/q3/650

There is already a worm being found based on the exploit:
https://gist.github.com/anonymous/929d622f3b36b00c0be1

As of last night there is a metasploit module to exploit the bug (brace yourselves for the script kiddies):
https://github.com/rapid7/metasploit...faf4c0d6912575

Additional info:
https://community.rapid7.com/communi...-cve-2014-6271
https://securityblog.redhat.com/2014...ection-attack/
http://lcamtuf.blogspot.com/2014/09/...ts-impact.html
http://www.smittix.co.uk/fedora-20-u...cve-2014-6271/
http://arstechnica.com/security/2014...ith-nix-in-it/
https://access.redhat.com/articles/1200223

Options:

Upgrade BASH to a patched version
Use a different shell than BASH
Disable mod_cgi
Use rules to block nefarious requests

Patches:
MANUAL Patch for Debian 6:

Code:

# check to ensure vulnerable

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

# make sure you are on debian 6

cat /etc/issue



# add the LTS sec repo

echo "#LTS security" >> /etc/apt/sources.list

echo "deb http://http.debian.net/debian/ squeeze-lts main contrib non-free" >> /etc/apt/sources.list

echo "deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free" >> /etc/apt/sources.list



# update and install patched bash

apt-get update

apt-get install bash



# run a new shell

bash

# check patch success

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

MANUAL Patch for Debian 7:

Code:

# check to ensure vulnerable

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

# make sure you are on debian 7

cat /etc/issue



# update and install patched bash

apt-get update

apt-get install bash



# run a new shell

bash

# check patch success

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

MANUAL patch for Centos 6/7

Code:

# check vulnerability

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"



yum -y install bash

or 

yum -y update



# check patch success

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Red Hat mod_security rules: (https://access.redhat.com/articles/1200223)

Code:

#The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as function #definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI #applications



#Request Header values:

SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

#SERVER_PROTOCOL values:

SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

#GET/POST names:

SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

#GET/POST values:

SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

#File names for uploads:

SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"



#These may result in false positives but it's unlikely, and they can log them and keep an eye on it. You may also want to avoid #logging as this could result in a significant amount of log files.

tests:
# check, if 'vulnerable' appears, then you are vulnerable

Code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

# rpm based systems

Code:

rpm -q --changelog bash | head

 # if you are running a patched version, you should see this:

 * Mon Sep 15 2014 Ondrej Oprala <ooprala@redhat.com - 4.1.2-15.1

 - Check for fishy environment

  Resolves: #1141645

suicidaleggroll

09-25-2014 10:15 AM

I do have a system with a web interface that runs a bash script, however the user on the web page has no control over the bash script that's run, arguments to it, environment variables that might be in place, etc. They just click a button and internally a bash script is called.

I can't imagine this would be susceptible since the user can't set any environment variables on the system before/during/after the script is called, but I would just like some confirmation.

Habitual

09-25-2014 10:49 AM

Quote:

Originally Posted by Guttorm (Post 5243995)

For this bug to be exploitable from remote, you need to have a bash script that can be run from remote.

Doesn't that require a login to the system?

szboardstretcher

09-25-2014 10:57 AM

No.

This "mainly" has to do with CGI scripts that call bash.

Of course, there are an indefinite number of other ways as well.

Remediation Steps 1 and 2 currently is to:

Update bash to a patched version
Disable mod_cgi if you can

And keep your ears open for any other attack vectors released, and patch those as well. I'm doing my best to update my post about it here: http://www.linuxquestions.org/questi...3/#post5244106

Habitual

09-25-2014 11:06 AM

Re: Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - Shell shock patching?

I support Sticky for this topic.

Guttorm

09-25-2014 11:23 AM

If you have a bash script in cgi-bin, you are vulnerable.

http://security.stackexchange.com/qu...d-be-exploited

Bottom comment shows an example. You don't need to login, and there is nothing the bash script can do to prevent it.

tux100

09-25-2014 11:39 AM

rhel 5.8 bash patching

rpm -qa |grep bash says RHEL 5.8 bash-3.2-32.el5

yum update bash will upgrade bash to 3.2-33. << Pretty sure this is not a patched bash.

==================================================================================
Package Arch Version Repository Size
==================================================================================
Updating:
bash x86_64 3.2-33.el5.1 rhel-x86_64-server-5 1.8 M

ilesterg

09-25-2014 11:50 AM

Quote:

Originally Posted by Guttorm (Post 5244148)

Wait, I thought only bash is vulnerable. One comment says ksh is also vulnerable. I tested my Unix machine, AIX 6.1, and it doesn't look infected using this testing string:

Code:

x='() { :;}; echo you are Vulnerable>/tmp/bashbug.out' bash -c "cat /tmp/bashbug.out || echo You are PATCHED"

szboardstretcher

09-25-2014 12:06 PM

That looks like the patched version (3.2-33.el5.1)

https://rhn.redhat.com/errata/RHSA-2014-1293.html

Once installed you can read about the patch with:

Code:

rpm -q --changelog bash | head

suicidaleggroll

09-25-2014 12:12 PM

Alright then I'm pretty sure mine are fine, the shell scripts are run using exec in mod_php, no cgi is involved, so as far as I understand it an attacker has no way of passing an environment variable through to the shell.

szboardstretcher

09-25-2014 12:15 PM

Correct:

Quote:

PHP scripts executed with mod_php are not affected even if they spawn subshells.

https://securityblog.redhat.com/2014...ection-attack/

jeremy

09-25-2014 12:46 PM

Re: Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - Shell shock patching?

I've posted a note to the Linux - News forum (and a couple other places). A sticky in Linux - Security may be in order, but I'm not sure a site wide notice is needed at this time.

--jeremy

suicidaleggroll

09-25-2014 01:24 PM

What I don't get is why the the bash developers EVER thought it would be a remotely good/safe idea to pull in function declarations from environment variables in the first place.

Even after this bug is fixed (which apparently it isn't yet), this is still a vulnerability in bash IMO.

Take the following code, running on a patched system, setting an environment variable to replace a standard Linux command with custom code:

Code:

$ env ls='() { echo this is a fake ls; }' bash -c "ls"

this is a fake ls

If an attacker puts that "ls" function declaration in an environment variable through cgi, they've effectively just replaced the "ls" command with their own code. They could replace ls, cd, read, even echo with custom code.

Code:

$ ls

$ env echo='() { touch file; }' bash -c "echo 5"

$ ls

file

Shellshock is a problem, bash should not execute commands after the function declaration, but why is this even a feature in the first place??? Even after shellshock is fixed, this "feature" just seems like a major security problem to me.

edit: apparently cgi prefixes any environment variables before setting them for the shell, so it's not as bad as I had feared. I still don't like the notion of cgi setting http headers as environment variables, and then bash turning environment variables into functions though.

Linux_Kidd

09-25-2014 03:35 PM

ShellShock

my centOS 6 repos dont even show the fix as available, what gives?

can we wrap bash to mitigate the issue ?

Linux_Kidd

09-25-2014 03:39 PM

Quote:

Originally Posted by tux100 (Post 5244160)

rpm -qa |grep bash says RHEL 5.8 bash-3.2-32.el5

yum update bash will upgrade bash to 3.2-33. << Pretty sure this is not a patched bash.

==================================================================================
Package Arch Version Repository Size
==================================================================================
Updating:
bash x86_64 3.2-33.el5.1 rhel-x86_64-server-5 1.8 M

see https://access.redhat.com/articles/1200223

i am wondering why the repos dont have the fixed package yet.

Linux_Kidd

09-25-2014 04:02 PM

Quote:

Originally Posted by suicidaleggroll (Post 5244224)

Code:

$ env ls='() { echo this is a fake ls; }' bash -c "ls"

this is a fake ls

what bash package exactly was installed as the "fix"?

suicidaleggroll

09-25-2014 04:08 PM

Quote:

Originally Posted by Linux_Kidd (Post 5244307)

what bash package exactly was installed as the "fix"?

I'm not sure what you're asking. Bash doesn't have packages, bash is the package. The initial fix for shellshock is right here:
http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-025

It's not complete, but it takes care of the primary vulnerability. Even once bash is fixed completely, attackers will still be able to define custom functions in any resulting bash shell by manipulating the environment though, which makes me uneasy.

Linux_Kidd

09-25-2014 04:11 PM

Quote:

Originally Posted by suicidaleggroll (Post 5244308)

what bash package exactly? the CentOS repo shows an available bash package, but one that is listed as vulnerable by RedHat.

the link shows c files from 12Sep and 14Sep, looks like it wasnt fixed yet at that time, or am i missing something? thus we are still waiting on a fix to handle the complete issue?

suicidaleggroll

09-25-2014 04:17 PM

CentOS back-ports security updates. So even though the bash version is "vulnerable" according to the reports, the shellshock fix has been back-ported to take care of the problem.

If you run

Code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

before and after running the yum update, you'll see that it takes care of the problem.

This vulnerability still hasn't been fixed though:

Code:

env X='() { (a)=>\' bash -c "echo date"; cat echo

Linux_Kidd

09-25-2014 04:20 PM

oddly, bash-4.1.2-15.el6_5.1.i686 is listed in my CentOS repo but not as a security fix !! yum check-update --security , no packages available.
but bash-4.1.2-15.el6_5.1.i686 is listed on RH site as vulnerable, so i guess the fix was bad and we are still waiting ??

suicidaleggroll

09-25-2014 04:24 PM

4.1.2-15.el6_5.1 does have the fix for vulnerability #1, that's the version installed on my CentOS 6.5 systems:

Code:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

this is a test

Linux_Kidd

09-25-2014 04:29 PM

Quote:

Originally Posted by suicidaleggroll (Post 5244318)

4.1.2-15.el6_5.1 does have the fix for vulnerability #1, that's the version installed on my CentOS 6.5 systems:

Code:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

this is a test

even after this ver of bash, still same issue, arbitrary code execution, no?

Linux_Kidd

09-25-2014 04:39 PM

Quote:

Originally Posted by suicidaleggroll (Post 5244313)

CentOS back-ports security updates. So even though the bash version is "vulnerable" according to the reports, the shellshock fix has been back-ported to take care of the problem.

If you run

Code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

before and after running the yum update, you'll see that it takes care of the problem.

This vulnerability still hasn't been fixed though:

Code:

env X='() { (a)=>\' sh -c "echo date"; cat echo

i run the 1st one after yum update bash, my bash is now bash-4.1.2-15.el6_5.1.i686, still same issue, i get "this is a test" returned to me.

the 2nd command, i get X syntax error, error importing function, etc

perhaps you have the two backwards ??
verified with rpm -qf /bin/bash

smallpond

09-25-2014 04:41 PM

The first patch rushed out to fix this was incomplete and I suspect RHEL paying customers are in line ahead of CentOS to get the second one. Here is the article:

https://securityblog.redhat.com/2014...ection-attack/
https://access.redhat.com/articles/1200223

suicidaleggroll

09-25-2014 04:49 PM

That's what it's supposed to do. A broken system would print

Code:

vulnerable

this is a test

That

Code:

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

is it catching the vulnerability.

anthony11

09-25-2014 06:33 PM

Quote:

Originally Posted by Linux_Kidd (Post 5244296)

see https://access.redhat.com/articles/1200223

i am wondering why the repos dont have the fixed package yet.

I found that here the RHEL 6 package came in long before the CentOS analogues made it to the mirror I use.

Safe travels.

turtlebay777

09-25-2014 07:37 PM

http://forums.linuxmint.com/viewtopic.php?f=47&t=178935

Mint 13 and 17 as well as LMDE are all patched now. Not that bash is used by default in any of the versions!

widget

09-25-2014 07:55 PM

Re: Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - Shell shock patching?

Thanks for this thread.

Great collection of links. Clear, concise details for dealing with the issue.

Most of all there is no silly dramatics.

tylerhoadley

09-25-2014 08:39 PM

Re: Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - Shell shock patching?

Thanks for the squeeze-lts packages, very much appreciated.

Cheers,[COLOR="Silver"]

BartMan__X

09-25-2014 09:23 PM

Re: Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - Shell shock patching?

Try all three of these tests before you think you're fixed:

env X='() { :;}; echo' /bin/cat /etc/passwd; echo 'Welcome to he Simple ShellShock Tester By Svieg';echo 'Your infos are at risk';

env x='() { :;}; echo Your system is vulnerable update ASAP' bash -c "echo Visit svieg.wordpress.com for update info"

env X='() { (a)=>\' bash -c "echo date"

The standard env test listed is not the only variable that needs to be patched!

although this thread helped patch one problem there are still more :

Quote:

root@BWS-NET:~# env X='() { :;}; echo' /bin/cat /etc/passwd; echo 'Welcome to he Simple ShellShock Tester By Svieg';echo 'Your infos are at risk';
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
smmta:x:101:103:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:102:104:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
bind:x:103:107::/var/cache/bind:/bin/false
fetchmail:x:104:65534::/var/lib/fetchmail:/bin/false
sshd:x:105:65534::/var/run/sshd:/usr/sbin/nologin
mysql:x:106:110:MySQL Server,,,:/var/lib/mysql:/bin/false
postfix:x:107:111::/var/spool/postfix:/bin/false
ftp:x:108:113:ftp daemon,,,:/srv/ftp:/bin/false
vsftpd:x:5001:33::/var/www/vhosts:/bin/false
vmail:x:5000:5000::/home/vmail:/bin/sh
Welcome to he Simple ShellShock Tester By Svieg
Your infos are at risk

NotAComputerGuy

09-26-2014 02:48 AM

Quote:

Originally Posted by turtlebay777 (Post 5244400)

http://forums.linuxmint.com/viewtopic.php?f=47&t=178935

Mint 13 and 17 as well as LMDE are all patched now. Not that bash is used by default in any of the versions!

I came here seeking advise regarding this topic and found this which applied to my LMDE systems. I don't think LMDE *is* patched, as I saw the news yesterday, switched my computer on this morning and immediately sought to update to fix this. No update has come through and running the 'tests' displayed on many sites around the web, my system is still vulnerable.

How do I find out if my system is patched or not? How likely is this to affect me?

Thanks :)

NotAComputerGuy

09-26-2014 02:57 AM

Update for other non-computer people. I found this thread here: http://forums.linuxmint.com/viewtopi...928313#p928313

This is what I did which might possibly fix the problem within LMDE (Linux Mint Debian Edition): Menu -> Update Manager -> Edit -> Software Sources -> Additonal Repositories -> Add New Repository -> Enter the follow text

Code:

deb http://ftp.debian.org/debian sid main contrib non-free

-> Then refresh cache in the top right corner. In a terminal enter

Code:

sudo apt-get install bash

.

Do not just "apt-get upgrade" as people are reporting this breaks their system.

Once installed, remove the repository that you added within Update Manager.

I sincerely hope if this is wrong that someone corrects me shortly..

DebianUser

09-26-2014 06:27 AM

Re: Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - Shell shock patching?

I just run the MANUAL Patch for Debian 6 and now when I get

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

so it appears to be fixed however my bash version still shows

GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)

charly78

09-26-2014 06:49 AM

You can always do it by the source and patch using the latest patches

#check what you have for a version and sub in place of the 4.3 or 43
dpkg-query -l|grep bash
cd /usr/src
wget ftp://ftp.cwru.edu/pub/bash/bash-4.3.tar.gz
tar zxvf bash-4.3.tar.gz
cd bash-4.3

# download and apply all patches, including the latest one that patches
# note the 0 to 12 should be changed to the patches so if there are 0 to 59 patches you should have 0 59

for i in $(seq -f "%03g" 0 12); do
wget -nv ftp://ftp.cwru.edu/pub/bash/bash-4.3-patches/bash43-$i
patch -p0 < bash43-$i
done

# compile and install to /usr/local/bin/bash
./configure && make && make install

# point /bin/bash to the new binary
mv /bin/bash /bin/bash.old
ln -s /usr/local/bin/bash /bin/bash

# test by comparing the output of the following
env x='() { :;}; echo vulnerable' /bin/bash.old -c echo
env x='() { :;}; echo vulnerable' bash -c echo

#get rid of the problem bash file
rm /bin/bash.old

turtlebay777

09-26-2014 07:04 AM

Look on the Mint Forums site for details about Mint. Here, I've patched you through to the part talking about Bash Shellshock - http://forums.linuxmint.com/viewtopi...f=198&t=179002

Soderlund

09-26-2014 07:46 AM

Are shells other than bash also affected by this?

smallpond

09-26-2014 08:11 AM

CentOS now is fully patched

Code:

# rpm -qi bash

Name        : bash                        Relocations: (not relocatable)

Version    : 4.1.2                            Vendor: CentOS

Release    : 15.el6_5.2                    Build Date: Thu 25 Sep 2014 10:15:25 PM EDT

# env x='() { :;}; echo vulnerable' bash -c echo



#

Toofle

09-26-2014 08:11 AM

I'm on debian: SID atm. And when i try the command:

Code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If your system is compromised you should be able to see "vulnerable" and "this is a test".
However. I can only see the part where it echo's "this is a test".

If the bash shell is patched it should give this error.

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

But it doesn't!

I have updated bash to latest version. Anyone have a clue?

ilesterg

09-26-2014 08:31 AM

Quote:

Originally Posted by Toofle (Post 5244679)

I'm on debian: SID atm. And when i try the command:

Code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Are you lost, my friend?

Toofle

09-26-2014 08:31 AM

Yes

ilesterg

09-26-2014 08:33 AM

Quote:

Originally Posted by Toofle (Post 5244691)

Yes

http://www.linuxquestions.org/questi...k-4175519998/?

ilesterg

09-26-2014 08:35 AM

Hi all, I just want to clarify, only bash is affected, right? and not ksh, tcsh and zsh?

Toofle

09-26-2014 08:36 AM

Quote:

Originally Posted by suicidaleggroll (Post 5244334)

That's what it's supposed to do. A broken system would print

Code:

vulnerable

this is a test

That

Code:

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

is it catching the vulnerability.

What if it only prints

Code:

this is a test

I updated and upgraded. And dist-upgraded. But none of these methods seem to help me. Any clues ?

Btw: I'm using debian: Sid

All times are GMT -5. The time now is 09:19 PM.

Page 1 of 2

Show 50 post(s) from this thread on one page