seduction
 Language:
Welcome, Guest. Please login or register.
Did you miss your activation email?
2019/12/15, 05:38:08


Help

Author [EN] [PL] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: bash compromised (mostly important if you run a webserver) (EDIT)  (Read 3092 times)

0 Members and 1 Guest are viewing this topic.

Offline michaa7

  • User
  • Posts: 2.126
DE only:

http://www.heise.de/newsticker/meldung/Standard-Unix-Shell-Bash-erlaubt-das-Ausfuehren-von-Schadcode-2403305.html


EN:
https://lists.debian.org/debian-security-announce/2014/msg00220.html

In short:
Bash is compromised:

Test:
Code: [Select]
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
--> update to 4.2+dfsg-0.1+deb7u1


EDIT:
I am unsure if the version in sid did really fix the problem as the test still triggers the warning!

« Last Edit: 2014/09/24, 20:45:57 by michaa7 »
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

Offline GoinEasy9

  • User
  • Posts: 461
My version of bash:
$ apt-cache policy bash
bash:
  Installed: 4.3-9
  Candidate: 4.3-9
  Version table:
 *** 4.3-9 0
        500 http://http.debian.net/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status

But it hasn't been updated recently.  While the security announcement usually lists whether or not the vulnerability has been fixed in unstable, this announcement only says that it has been fixed in wheezy.  So, I'm going under the assumption that it still hasn't been fixed for sid.
Linux Counter number 348347

Offline GoinEasy9

  • User
  • Posts: 461
Seems fixed version is now in incoming.

http://incoming.debian.org/debian-buildd/pool/main/b/bash/

bash 4.3-9.1
Linux Counter number 348347

Offline der_bud

  • User
  • Posts: 896
  • member
is fixed
« Reply #3 on: 2014/09/25, 08:18:47 »
Seems fixed version is now in incoming.

http://incoming.debian.org/debian-buildd/pool/main/b/bash/

bash 4.3-9.1
... and is meanwhile in the regular repos, so comes with next dist-upgrade. From changelog:
  * Non-maintainer upload by the security team
  * Apply upstream patch bash43-025, fixing CVE-2014-6271
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

Offline der_bud

  • User
  • Posts: 896
  • member
As of Debian Bug #762760 from today, the patch applied yesterday was not sufficient enough and bash is still considered vulnerable. I am sure this will be fixed soon, as always.
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.

Offline clubex

  • User
  • Posts: 265
I thought dash was supposed to be the default shell on Debian. If siduction is based Debian I would presume siduction's default shell would also be dash.
But on my siduction machine (dist-upgraded for some years)

Code: [Select]
echo $SHELL
returns
Code: [Select]
/bin/bash

Is this correct and if not should I change the default shell on my machine to dash?

Offline dibl

  • siduction community member
  • Global Moderator
  • User
  • *****
  • Posts: 1.934
    • Land of the Buckeye
Code: [Select]
don@imerabox:/$ ls -la /bin | grep sh
-rwxr-xr-x  1 root root 1033720 Sep 25 17:48 bash
-rwxr-xr-x  1 root root  117176 Jan 10  2014 dash
lrwxrwxrwx  1 root root       4 Sep 25 17:48 rbash -> bash
lrwxrwxrwx  1 root root       4 Jan 10  2014 sh -> dash


"sh" is a symlink to dash.
Asus ROG STRIX X299-E, Core i7-7740X, Nvidia GTX-1060, dual monitors, SSD 860 EVO, 2@WD1003FZEX in BTRFS

Offline melmarker

  • Global Moderator
  • User
  • *****
  • Posts: 2.781
    • g-com.eu
The fact that bash was vulnerable should not lead to panic 8) - the most important part is: cgi and bash.

If one don't use this mechanisms and is sure about it - one is not vulnerable first hand. Unfortunally there could be old and mostly forgotten cgi-scripts with #!/bin/bash instead of #!/bin/sh - bingo, in that case your webserver is vulnerable.

Beside of that installations in the wild local installations might (are) vulnerable too, but can only be attacked from within an organisation (via physical access) or ssh.

maybe i simplified that to much, but i don't think so
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline clubex

  • User
  • Posts: 265
Perhaps I didn't make myself clear. I not too worried about the bash vulnerability as I don't really have anything that would allow access anymore. But as my last post shows my default shell is bash whereas Debian's default is dash. Should I change my default to dash to bring it in line with Debian and maybe siduction?

Offline michaa7

  • User
  • Posts: 2.126
I thought dash was supposed to be the default shell on Debian. ...

I am confused, too. But from what I read in the net, my understanding is as follows:

Code: [Select]
echo $SHELLshows what shell you currently are logged in.
Quote
lrwxrwxrwx  1 root root       4 Jan 10  2014 sh -> dash
shows what a sh-script (#!/bin/sh) is actually using
Code: [Select]
cat   /etc/passwd | grep shshows you what various users use as default shell. It's *bash* here for root and normal users.

As to panic about this bug:
The point is, *I* don't feel really equipped to evaluate how easy this bug is exploitable. I read "remote", "webserver", "ssh" and my first reaction was: Is my test apache still runing by default (not sure whether or not cgi is activated ;-) ), and how affects this bug my always runing sshd (used in my LAN). And as I am sure I am visiting websites who's owner happily will try to find out what vulnerability they can discover behind my IP, I really want to update to a secure version of bash as quick as possible.
Quote
# apt-cache policy bash
bash:
  Installiert:           4.3-9.2
« Last Edit: 2014/09/26, 15:47:41 by michaa7 »
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

Offline melmarker

  • Global Moderator
  • User
  • *****
  • Posts: 2.781
    • g-com.eu
Clarification:
* debian use dash internally for the non-interactive things - because it is faster, not so complex etc
* debian use bash as interactive shell

so sh ->  dash . the debian maintainers fight also bashisms in scripts. That means: 99,9 % of scripts deliverd with debian use #!/bin/sh. the direct use of bash may be introduced by third party tools or the user himself :)
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. (Benjamin Franklin, November 11, 1755)
Never attribute to malice that which can be adequately explained by stupidity. (Hanlons razor)

Offline clubex

  • User
  • Posts: 265
Thanks for the info melmarker. The use of different shells for interactive and internal work makes sense to me.

Your second point is certainly true in my experience. I haven't seen a script headed with #!/bin/bash for a very, very long time.

Offline michaa7

  • User
  • Posts: 2.126
Still not solved, they found *three* other vulnerabilities. But it appears one of them is dealt with already without giving notice.

DE:
http://www.heise.de/newsticker/meldung/ShellShock-Teil-3-Noch-drei-Sicherheitsprobleme-bei-der-Bash-2404788.html

EN:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6277
http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unofficial-patch-now.html (thisone seems solved already with the latest, the second patch without telling us)

No reason to panic as stated above, but users who have runing a cgi-enabled webserver or doing fancy things with ssh or dhcp should keep their eyes open and make sure they update as quick as new bash versions arrive.
« Last Edit: 2014/09/28, 16:40:22 by michaa7 »
Ok, you can't code, but you still might be able to write a bug report for Debian's sake