Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » A reason to bash linux? Get it?

This thread is locked; no one can reply to it. rss feed Print
 1   2 
A reason to bash linux? Get it?
Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Serious new security flaw called Shellshock discovered in the bash shell, that allows hackers to install malware and take remote control of computers running the shell.

Overview here :
http://www.bbc.com/news/technology-29361794

Still think *NIX is secure?

Anybody know a good firewall for linux? We're running Ubuntu 14.04 off of flash drives in our OS class.

And guess what our next assignment is? To write a basic shell! :D HAHAHA

Discuss

MiquelFire
Member #3,110
January 2003
avatar

Run this:

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

If you get this, you need to patch:

vulnerable
this is a test

If you get this, you have the latest patch:

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

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

William Labbett
Member #4,486
March 2004
avatar

The thing that confuses me is that it's widely known that absolute security is impossible but people talk about things either being secure or not.

Am I wrong ?

bamccaig
Member #7,536
July 2006
avatar

The only reason these bugs get so much attention is because there's no publicly traded corporation threatening to sue everybody. The bug is serious, but it's not as serious as they make it out to be. Based on what I've looked at it should only affect systems that run software that invokes a bash process with an environment based on user input. I'm assuming the expected attack vector is Web servers supporting interfaces like CGI that put HTTP request information into environment variables (albeit, whether or not bash is typically involved I can't say).

I don't suspect that my server is vulnerable.. Or my desktop system(s). All of them have been updated anyway (a fix in Debian at least is already out, but whether it completely fixes the issue I can't say). My phone is anybody's guess, but I fucking hope it isn't doing anything like that (there's no reason it should be). A router seems like a good candidate to be vulnerable to this bug because they tend to have Web interfaces and they tend to be very rudimentary and shitty. Which is mildly concerning only because updating router software is generally a manual, messy operation. That said, hopefully most home routers only accept Web connections from local physical connections, which should eliminate most of the threat from remote attackers.

I'm not too worried about this. It's really sickening how the media spins these FLOSS bugs like the FLOSS movement is some horrible, bug decrepit rotting mess, when in reality all software has bugs, and the FLOSS community is probably better at finding and fixing them promptly than any proprietary vendor...

Arthur Kalliokoski
Second in Command
February 2005
avatar

The thing that confuses me is that it's widely known that absolute security is impossible but people talk about things either being secure or not.

It's whether it's secure enough that you can relax a bit, not worrying about failure to the exclusion of getting work done. After all, the hard drive could fail at any minute, or the computer could fail to boot at all.

Although there are plenty of systems out there that are spamming the internet with Nigerian emails and hammering credit card databases without their owner knowing or caring.

They all watch too much MSNBC... they get ideas.

Matthew Leverton
Supreme Loser
January 1999
avatar

OS X is vulnerable too. :'(

Elias
Member #358
May 2000

If you get this, you have the latest patch:

No, that's not the case at all. That means you have the very first patch, which did not work at all (just slightly modifying the exploit and it would still work). Right now there's at least 8 patches after that:

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

And from looking at the bash source it also seems that it's even worse then OpenSSL with serious bugs left and right :P Only good solution at this point is to entirely remove bash from your server, I'd say.

--
"Either help out or stop whining" - Evert

bamccaig
Member #7,536
July 2006
avatar

It would really surprise me if there's literally only one person maintaining bash... They should probably have a setup similar to Linux. A hierarchy of trusted people at the top scrutinizing every patch... I mean, bash is in everything. It's nearly as important as the kernel. Sure you can change shell software, but are the alternatives any more robust?

Chris Katko
Member #1,881
January 2002
avatar

Still think *NIX is secure?

Yes, yes, I do.

And I'm writing this from my job as a C# programmer on a Windows 8 laptop.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

More details on the bug can be found here :
http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html

Quote:

And so, the bug we're dealing with stems from the observation that trying to parse function-like strings received in HTTP_* variables could have some unintended side effects in that shell - namely, it could easily lead to your server executing arbitrary commands trivially supplied in a HTTP header by random people on the Internet.

I don't think this bug will be as serious as it seems, or at least that its seriousness will be mitigated by quick action. It is dangerous as a zero-day exploit, but as long as admins are aware and up to date on their patches it shouldn't be too big of a problem. The maintainers are already scrambling to fix the shell and make it more robust.

bamccaig
Member #7,536
July 2006
avatar

I don't think you understand what "zero-day" means. ;) I don't know how long bash has been vulnerable to this attack, but I'm guessing it has been a long time. The cause is two-fold..

  • Lazily parsing variable values that look like embedded functions, just passing the entire string on to what looks like a higher-level parser used to normally parse the core language, which allows a command after a function definition.


  • Third party software (e.g., Web servers) using the environment to store user input, presumably based on the premise that variables are harmless (which would be a reasonable assumption which brings us to the subcause:).


    • The shell designers not recognizing the potential abuse of making what appears to be harmless data automatically turn into executable code. Even with the patch installed, which should prevent the commands after the embedded function definition from executing (at least until the next oops-regression), the variable will still turn into an executable function in the shell. And you might be able to coerce other code to execute it by using a popular command name...

I don't know what the legitimate uses for this functionality are, but I'd probably be in favor of just purely disabling that feature entirely by default and requiring an explicit configuration option to enable it... As a hack, I can see the Web server software authors patching to remove "()" from the beginning of headers before pushing them into the environment (or maybe regardless). I can't imagine a legitimate use for it so it's a relatively harmless workaround.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

bamccaig
Member #7,536
July 2006
avatar

Jeez, nitpick much?

You haven't fixed anything. ;) By your definition all exploits are zero-day. Zero-day refers to how long it takes crackers to exploit your software (generally applies to proprietary software, and generally is only relevant if crackers are trying). I think that zero-day implies that crackers exploited it before it is even released, or at the very least on the same day of release (e.g., see Xbox consoles).

There probably isn't a definitive answer regarding when this exploit was first discovered, but something I read implied that bash has been vulnerable for like 10 or 15 years (I have ZERO clue how accurate that is, it seems far-fetched). In any case, if it did take like 10 years for this to be discovered by anyone then that is actually good in a way. It beats zero-day by like 5475 days. :P

m c
Member #5,337
December 2004
avatar

As stupid as this may sound, this news actually makes me feel a little good, or rather made me feel justified.

Sometimes I would not use bash at all but change the shells to tcsh or ksh. Sometimes I wouldn't bother to change it.

Even though I assume this won't happen again with bash? I think I am going to make a point of always using a different shell from now on. I just have to decide what.

(\ /)
(O.o)
(> <)

bamccaig
Member #7,536
July 2006
avatar

I think you're missing the point, m c. All software has bugs. The fact that bash happened to have this bug doesn't make it any more vulnerable than any other shell. At least this vulnerability has been found and patched. Changing shells because of this could just lure you into the trap of a different shell's vulnerability. There are grounds for wanting to change shells, but this isn't really one of them. By all means, if you happen to know that a different shell has a better code base then that would be grounds, but odds are they are all about as bad. I wonder if there are any fully-functional UNIX shells that compile down to native (or at least efficient) code that are written in a higher higher-level language. Not that it matters particularly... Well maintained C code can be secure, but it does take a bit more vigilance when maintaining binary or string data.

Arthur Kalliokoski
Second in Command
February 2005
avatar

bamccaig said:

By all means, if you happen to know that a different shell has a better code base then that would be grounds, but odds are they are all about as bad.

<cough>cmd.exe</cough>

They all watch too much MSNBC... they get ideas.

bamccaig
Member #7,536
July 2006
avatar

m c
Member #5,337
December 2004
avatar

Yeah wouldn't it be funny: If bash never has any more major vuln's, because this one lead to bigger scrutiny of the code base. And then there is actually a big exploit in another shell and you move from bash to the other shell and then you get stung.

When I think about what shells I have been using, I think my FreeBSD servers weren't using bash. I should have a hdd somewhere with arch set to use zsh on it, but almost all my systems are debian running bash, or dash or w/e.

I got a PC that uses ksh by default, but don't use that as it often as it consumes 270watts of power. I got a system that runs bourne by default and you have to manually choose csh or ksh if you want a better interactive environment. I don't know, I don' think bash is even available unless you compile it yourself or download a 3rd party package.

(\ /)
(O.o)
(> <)

Gideon Weems
Member #3,925
October 2003

bamccaig said:

It's really sickening how the media spins these FLOSS bugs like the FLOSS movement is some horrible, bug decrepit rotting mess...

I wouldn't worry too much about this, as the people who would believe such media aren't exactly worthwhile to begin with.

bamccaig
Member #7,536
July 2006
avatar

Unfortunately, excluding the top 1% that doesn't even count, these "not worthwhile" people collectively wield the majority of the money and therefore power...

furinkan
Member #10,271
October 2008
avatar

Elias said:

Only good solution at this point is to entirely remove bash from your server, I'd say.

Less heavily handed would be to just deny bash to the web services group until it is (fully) patched. This hardly affects desktop users, though, as you shouldn't be running anything that would allow remote users to invoke your bash shell with environment variables set to arbitrary values.

I wouldn't worry too much about this, as the people who would believe such media aren't exactly worthwhile to begin with.

While I agree in sentiment, we should remain aware that most people don't have the computer know-how to distinguish between hype and reality. Half my clients don't know what an OS or a browser is. They can name examples: Windows and IE. Most people aren't savvy enough to understand what this actually means for them.

Gideon Weems
Member #3,925
October 2003

Related story: A coworker yesterday didn't realize the difference between an image file and the program she wanted to run. It was a reality check.

I speak not so much of the computationally illiterate as of those who blindly trust the media (though I admit there's probably a lot of overlap). I apologize if you have such people for clients and certainly hope they trust you more than some article they read online.

furinkan
Member #10,271
October 2008
avatar

@Gideon: ;D That's kinda sad...

I apologize if you have such people for clients and certainly hope they trust you more than some article they read online.

I just lost a client because they wouldn't listen to my advice. Granted, my closing argument was "Plus, it's just a stupid fucking idea." :P

Elias
Member #358
May 2000

furinkan said:

you shouldn't be running anything that would allow remote users to invoke your bash shell with environment variables set to arbitrary values.

I didn't follow too closely, but from what I understand that's exactly what makes the bug so bad. Your web server will set an environment variable with your GET request since that's how it's always done. And then executing any command (by calling popen or system or so from php) will run bash (because that's again just how it's done) and trigger the bug.

--
"Either help out or stop whining" - Evert

furinkan
Member #10,271
October 2008
avatar

@Elias: Yea, I read through some of the security threads. The scariest part is that there is tons of software around that uses the shell and modifies environment variables. They were discussing CUPS print servers as one attack vector, remote X sessions as another... pretty much any network service could potentially be an attack vector. :-/

I'm worried about my Gateway, personally. Who's gonna update that? AT&T certainly isn't going to give me root access to my gateway. >:(

 1   2 


Go to: