Ars reports that a new bug has been found in GNU Bash allows remote attackers to execute arbitrary code by setting the process trailing strings after function definitions in the values of environment variables.
This bug is reported to be present in RHEL (ver 4 through 7), Fedora, CentOS (ver 5 through 7), Ubuntu (ver 10.04 LTS, 12.04 LTS, and 14.04 LTS), Debian, and even OS X Mavericks.
This bug is exploitable through Apache servers with mod_cgi and mod_cgid loaded, OpenSSH, malicious DHCP servers in a compromised wireless access point through dhclient, as well as the CUPS printing system.
The Ars also includes a simple single liner that will test your setup for the newly found discovery:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
A vulnerable system will output the following:
vulnerable
this is a test
While a patched or unaffected system outputs:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
A patch is already out, so administrators are advised to update Bash.
Editor's Update: Security Engineer Tavis Ormandy has said "The bash patch seems incomplete to me, function parsing is still brittle".
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
(Score: 1, Insightful) by Anonymous Coward on Thursday September 25 2014, @01:01AM
This was in my updates already today!
Now if this bug was in Windows, Adobe or Java - it would still be unfixed after 3 years.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:18AM
only insensitive clods expose java to the internetz. And I don't even expose the other two: I have linux, and no flash, and pdf.js.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:26AM
Do you use a distro that has already switched to systemd? Do you know if it's safe yet?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:43AM
no, but I guess its safer, because:
1. isolation. although being called monolithic, systemd does lots of cgroups stuff and so on.
2. non-root X. X is the goatse of display managers. nonrooting it mitigates that.
and its safe because:
3. its "only" a PID 1. Its not exposed to the internet directly. If you have access to nonpriv'd users, you can already install a permanent keylogger (for them) in desktop linux.
(Score: 2) by Geotti on Thursday September 25 2014, @12:53PM
it's safe because [...] it's not exposed to the internet directly [emphasis added]
I'll copy that to my notebook as quote of the year. Right next line after "They can spy all they want, I've got nothing to hide."
(Score: 2) by Tork on Thursday September 25 2014, @04:10AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by Geotti on Thursday September 25 2014, @12:56PM
You think DOS doesn't have exploits?
(Score: 3, Insightful) by Tork on Thursday September 25 2014, @04:04PM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by Geotti on Saturday September 27 2014, @12:33PM
I don't like explaining jokes, so I'll just leave it at "whoosh!"
(Score: 2) by Tork on Sunday September 28 2014, @02:03AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2, Interesting) by Hairyfeet on Thursday September 25 2014, @04:30PM
Gotta just love the logic disconnect, how they scream about every Windows bug but fucking cheer when they get yet more proof that "many eyes" is a load of horseshit...how many billions did heartbleed cost the planet? I rest my case. And folks wonder why I call 'em FOSSies, only ones more batshit are the Appleites, whom I've actually seen defend "you're holding it wrong" as a mark of superior design LOL!
So can we officially call "many eyes" a myth that is busted now? Because there is not a single piece of software in Linux that has had more view the code than Bash and today we saw that was worth exactly jack and squat, because the simple fact is it requires eyes that can not ONLY do low level debug of the software itself but ALSO of anything it calls AND redoing the whole thing with each change and as we have seen that just ain't happening. IRL everybody is just assuming "well somebody HAD to have done it" but nobody can actually name these mythical somebodies. Source code isn't magical, and I bet my last dollar if one was to look at how many times the source is downloaded for all the little pieces that make up your average Linux distro probably half of it is NEVER looked at by anybody but the guys that actually support it.
Show of hands, how many here have done a code audit of Gimp? Libre Office? Anybody here done a security audit of the Gecko engine that powers Firefox? And just think those are the most popular ones and for every one of those you have 30 "googly eyes" and font managers and other unsexy crap nobody ever thinks about. Many eyes probably worked....in 1993 when the entire OS along with the source fit on a single floppy, now that the kernel alone is something like 10 million LOC? Not a chance in hell, its a myth.
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 3) by No.Limit on Thursday September 25 2014, @05:54PM
I kinda agree with you that non-FOSS software gets bashed too hard over security holes (though with non-FOSS software you have no chance to fix it, while with FOSS software you can. Whether one is more secure than the other is quite hard to tell).
However, doing a conclusion from just one horrific example just isn't scientific. So no, the 'many eyes' myth isn't busted now.
It's much rather the case that the 'many eyes' argument isn't even proven in the first place. So we can simply see it as a theory that sounds logical, but isn't necessarily true. And here we have another indicator against it.
Technically, all we can say is that neither FOSS nor non-FOSS software is secure. But that's not really useful for people that want to compare the security of the two ideologies.
(Score: 2) by Hairyfeet on Friday September 26 2014, @12:22AM
It doesn't even SOUND logical if you take more than 5 seconds to think about it, yet its trotted out as a fucking FEATURE of Linux and FOSS! Right now the plans for the MIG15 are online, why don't you build me one and have it ready by Thursday....what is that? you don't have the skills nor the manpower? DING DING DING we have a winner johnny!
Handing somebody like ohh say me or you, whom I assume don't have a masters in CompSci and 15+ years in low level C coding under your belt? Worthless, completely fucking worthless, yet because Joe "I don't know jack shit more than I learnt in that VB class I took 15 years ago" Blow can download the source for bash this somehow magically means that somebody with the skills of a Bruce Schneier has done and continues to do in depth code audits of the same code.....WTF? this is as batshit as saying "Because vampires COULD exist and there are people that disappear forever each year that means vampires DO exist and are turning people"....doesn't matter that we have exactly ZERO evidence this is going on, no proof whatsoever that this is happening, the simple fact that it COULD happen means that it IS happening.
So I'm sorry but they can waste modpoints all they want I'm throwing a flag, delusional bullshit on the field! We have seen exactly ZERO evidence of "many eyes" happening and a mountain of evidence that many eyes is bullshit, because if it were real why is there major exploitable bugs being found in this software that if many eyes were real should have been vetted a hundred times over...hmm? Remember folks source code isn't magical despite what the more batshit FOSSies would have you believe, it doesn't magically perform code audits on itself, it doesn't magically give you the skils to debug itself AND the things it calls AND anything calling it, in fact we can only show with any certainty ONE and only ONE benefit to having source and that is the fact that IF a piece of software is abandoned AND you can build up a team to support it you CAN keep it afloat. We have evidence of this with KDE 3 so this is something we can say with certainty is possible? many eyes? We have the same amount of evidence for many eyes being real as we do for alien abduction, namely anecdotes and bullshit.
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 2) by choose another one on Thursday September 25 2014, @08:02AM
You do know, having looked at the vulnerable versions, that this bug is over 20 years old, right ?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @09:03PM
You mean the various patches that have been found not to actually fix it?
This isn't a fucking ego-trip about OS or a circle-jerk about how fucking *wonderful* your facile choice of OS is. This is a bug that affects about twenty accumulative years' worth of Unix OSs (and any Windows that happens to have Bash on it as well). It's to be fixed, not to be used by some smug adolescent prick to fallaciously justify his choice of OS as wank fodder.
Grow the fucking hell up, for God's sake. Seriously, and without any intent towards flamebait, just fucking Grow. Up. You're pathetic.
(Score: 2) by frojack on Thursday September 25 2014, @01:20AM
This bug is reported to be present in RHEL (ver 4 through 7), Fedora, CentOS (ver 5 through 7), Ubuntu (ver 10.04 LTS, 12.04 LTS, and 14.04 LTS), Debian, and even OS X Mavericks.
As well as every version of Opensuse SLED, SLES, OpenBSD, NetBSD.
EARLY patches are still said to be problematic "brittle" was the word used.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by SNK on Thursday September 25 2014, @07:50AM
The default installations of FreeBSD/OpenBSD/NetBSD are not affected, since they do not include bash.
(Score: 2) by frojack on Thursday September 25 2014, @06:33PM
The default installations of FreeBSD/OpenBSD/NetBSD are not affected, since they do not include bash.
Not sure I believe that, because bash is on my openbsd 5.5 system. I might have put it there explicitly, but I don't recall doing that.
But if you have bash installed on openbsd it is STILL vulnerable today, and no patch seems to be available.
On NetBSD, where it is also commonly installed, it has been fixed as of this morning.
No, you are mistaken. I've always had this sig.
(Score: 1) by SNK on Friday September 26 2014, @08:12AM
If not installed explicitly, then bash was probably installed as a dependency for another port.
You are right that *BSD is affected if bash is installed. However, the attack vector is different, since /bin/sh never links to /bin/bash, and bash is not installed by default.
(Score: 2) by fnj on Friday September 26 2014, @09:31AM
So the attack is pretty irrelevant to BSD, isn't it? Even if bash is installed, system() and popen() and dhclient are never going to call it. They call /bin/sh. The same goes for debian and ubuntu, where /bin/sh is symlinked to dash, not bash.
Sloppy system design counts (I'm looking at you, Redhat and Suse and lots of other distros, with your /bin/sh syml;inked to bash).
(Score: 2) by fnj on Friday September 26 2014, @09:18AM
It doesn't matter whether you believe it or not. It's true.
Now, as to BSD systems where you install bash. It still doesn't make /bin/sh a symlink to bash, like most linux distros do - a sloppy, brain dead practice. So as far as I know, even if bash is installed, BSD is not sysceptible to the exploit as it is explained.
P.S., debian doesn't have /bin/sh symlinked to bash either. It symlinks it to dash. I don't believe dash has the bug. At least it passes the test scripts I've tried. You have to modify the stupid test scripts to run /bin/sh, not bash. After all, that's what system() runs: /bin/sh, not bash. So as far as I can tell, debian is OK, too.
(Score: 5, Insightful) by Anonymous Coward on Thursday September 25 2014, @01:24AM
I'll be honest, this scares the living shit out of me.
Here we have bash, one of the oldest, most widely used pieces of GNU software out there. It's mature, it has seen lots of use, and its code has been picked through for decades now, yet still a serious bug like this can exist in it.
If software as mature and inspected as bash can have a flaw like this, then just think how many flaws could exist in newer and much less mature, yet still foundational, software like, say, systemd.
The major distros need to say "STOP!" to the efforts to integrate systemd. Especially Debian. Nobody should be integrating software like systemd into a distro until it has gone a very thorough review.
If Fedora and Red Hat really feel the need to integrate systemd, then let them. Let their users suffer first. But Debian and Ubuntu users should not be subjected to systemd until it is a proven technology, if it even ever manages to get to that point.
Bash has long been thought to be a stable, robust, reliable piece of software. And generally it has been. But if even it can have serious flaws like this, it really should make us all think twice or even thrice about using systemd.
(Score: 2) by Nerdfest on Thursday September 25 2014, @02:01AM
Not just serious, but quite simple and easily exploitable. The funny this is that almost all the buffer overflows, bounds checks, unterminated string checks, etc, had been found, then something silly and obvious like this pops up. AT least we can be thankful that it's patched quickly.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @08:55AM
If it's remotely exploitable via dhclient I'd consider it an exploit in dhclient than bash.
Same for openssh.
(Score: 3, Insightful) by Geotti on Thursday September 25 2014, @01:03PM
It's exploitable via user interaction. Do you consider this to be an exploit in our DNA now?
SSHd, CGI & co. are vectors. The bug is in bash.
(Score: 2) by fnj on Friday September 26 2014, @09:33AM
Yes, maybe we COULD be thankful, except for one itsy bitsy problem. The patch doesn't fucking fix the vulnerability.
(Score: 2) by Nerdfest on Friday September 26 2014, @03:09PM
the first one fixed some, but was brittle. It's patched now and the release is still faster than what you'd see with any other OS I think.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:01AM
Hey, a rant from an Anonymous Coward! We should all pay attention!
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:06AM
Yes, you're right, we should pay attention. Everything the GP says is correct.
(Score: 1, Insightful) by Anonymous Coward on Thursday September 25 2014, @02:10AM
Everything he says if FUD with no substance.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:13AM
Wrong-o, my dear friend. Bash is mature software. Systemd is young, immature software. If Bash can suffer from defects like this, then so can Systemd. We are more likely to find a problem in Systemd because it hasn't been checked as extensively as Bash has been. That earlier commenter is right: this is a dangerous situation and we all should be very worried!
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:18AM
In that case, you should be worried to turn on your computer at all.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:24AM
I was so worried that I installed OpenBSD earlier today. I'm done with Linux. I'm done with the risk of systemd. I'm done with bash. I'm only using OpenBSD from now on, because I value my security.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @03:29AM
if you are unable to use linux without systemd, i pity you
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @03:34AM
I'm about to switch to FreeBSD, too. I don't want to install Debian on my new system only to find out a couple of months from now that an upgrade will unexpectedly install systemd and my system will be busted. Even the risk of systemd eventually getting installed is just too great. At least I know that the BSD devs won't be stupid enough to adopt it.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @06:54AM
Oh yeah? Well I just installed M$ DOS 1.0 and it's WONDERFUL!!111
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @11:48AM
At least it doesn't include systemd. That makes it better than Fedora.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:38PM
Really? It can read your SATA HDD? It can read your USB sticks? Do you even have a floppy disk drive to boot from? (Are 3.5" floppy disk drives actually supported by MS DOS 1.0, or do you need a 5.25" one?)
(Score: 2) by cafebabe on Thursday September 25 2014, @01:53PM
They look the same to a host.
1702845791×2
(Score: 2) by tangomargarine on Thursday September 25 2014, @02:38PM
Because I'm sure dash or csh or zsh or whatever is so much more secure and well-written than bash...
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by FatPhil on Thursday September 25 2014, @06:59PM
How do I know this with the certainty that I do? Because the rate of bugs per line of code is remarkably constant, and there's more code in bash, so likely more bugs.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by tangomargarine on Thursday September 25 2014, @02:35PM
If you automatically dismiss every post from an AC, you'll miss out on a few gems. Can't we quit it with the "AC STFU" knee-jerk reactions already?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by fnj on Friday September 26 2014, @09:39AM
We'll quit dissing no-account cowards when the lazy bums get off their ass and sign up for an account, and then put their fragile egos on the line by making signed posts.
P.S., I do read cowards because I don't want to hide safely behind mommy's apron. But I will never quit making fun of the sniveling lightweights.
(Score: 2) by FatPhil on Thursday September 25 2014, @07:44PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 3, Interesting) by NotInHere on Thursday September 25 2014, @02:10AM
Back in the time bash was written, we didn't know that security holes are this important. Or nobody had in mind their software gets used in 2014. X for example had some issues with >4G buffers being exchanged. In the "who needs more than 64k" era this might have been secure, but now it isn't. New (good) software actually tries to avoid holes. really tries. And we never get most software hole-free. Most important thing is that when a hole is used, we find out about that and fix it very fast.
(Score: 3, Insightful) by bd on Thursday September 25 2014, @11:50AM
Much of the development of X was done before the morris worm in 1988, which I think was a pivotal moment in the perception of the importance of security in networked computer systems. The first release of bash was in 1989, after the morris worm, when people knew security holes are important. The core of the GNU system was subject to intense code review attention during the 1990's, when much of its development was done.
Still, I think the GNU system has one core weakness when compared to e.g. OpenBSD, which would seem to be the willingness to add complexity. GNU utilities always tend to include a large amount of features that are not strictly necessary and a lot of code neccessary to achieve broad portability. That makes code review more complex and increases the likelyhood of something incredibly stupid slipping through. Especially as the complexity of a program that a code reviewer can actually grasp is incredibly small in comparison to typical lines of code in a software project.
This mindset is not restricted to GNU of course. The transition from Apache 1 to Apache 2 being one example, sendmail, OpenSSL etc. also come to mind here. And systemd fits perfectly into this narrative. A piece of software written in an incredibly complex way for a simple task, at a highly vulnerable position in the overall operating system stack. What could possibly go wrong?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @05:03AM
I don't think anybody was ever under the impression that Bash was a bastion of security. War tested as much as anything common- sure, but there were no illusions about it's level of complexity adding to threat surfaces.
As for Debuntu- from my understanding, only users who opt for a default desktop configuration in the next major release will see this. I think you ought to take a step back from your rhetoric that makes it sound like everyone is being forced to use systemd. There are a million linux distros out there, not to mention plenty of Debuntu users interested in holding off on systemd for various amounts of time. This isn't like the government mandating a kill switch in phones that users can't opt out of. There is plenty of choice for everyone of our opinion that systemd could use more settling before the levels of adoption that it currently seems to enjoy. Of course, bash bugs like this don't really help systemd's case in that argument IMO. I.e. an init system relying on bash now looks a notch less attractive due to this bug. Which only increases the relative stature of systemd through no aspect of its self.
(Score: 2) by MrNemesis on Thursday September 25 2014, @11:56AM
I did a bare-minimum install from the latest jessie netinstall image the other day and systemd is now in there as default init regardless of whether you choose to install an X server or any DE (and you can't apt-pin it away on a new install like I have on my existing systems).
IIRC, init scripts on debian have been using /bin/dash as default /bin/sh for quite some time because it's faster and lighter weight than bash.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 1) by DNied on Thursday September 25 2014, @10:10AM
Yes, but who uses bash for CGI scripts? The real-world scenarios for this kind of exploit are so limited in practice, that the bug could live in the code for years and not really cause havoc.
Note how it hasn't been discovered after an attack.
(Score: 2) by choose another one on Thursday September 25 2014, @06:32PM
Note that it hasn't been discovered after an attack that we know about.
Also, exploits are now in the wild and attacks being reported, Git servers currently a known target - guess that is a "limited" real world scenario ?
(Score: 2) by FatPhil on Thursday September 25 2014, @06:56PM
And just because your script doesn't use them, that doesn't mean that one of the modules you use doesn't contain such code.
> Note how it hasn't been discovered after an attack.
That we know of. Ignorance is not bliss.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by Justin Case on Thursday September 25 2014, @11:50AM
But... systemd is NEW and... um... you don't want the Russians to get to the moon before WE do, do you?
Communist!
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:26PM
>Bash has long been thought to be a stable, robust, reliable piece of software.
As a scripting language BASH is a POSH that makes it a real pain to write anything other that a | b |c.
(Score: 2) by tangomargarine on Thursday September 25 2014, @02:41PM
is a POSH
Piece of Shit...Head? The only halfway-reasonable results I get from Acronym Finder are "Plain Old Semantic HTML" or "People Of Stupid Habits."
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @09:09PM
Are you trying to imply that Debian is a "major distro" but Red Hat isn't? I hate to break this to you, but Red Hat is the most profitable distribution out there - one of the very few companies making money out of Linux - while Debian is in commercial terms a total irrelevance. The fact you seem to think that Red Hat are pushing bleeding edge but "Ubuntu users" shouldn't "be subjected" to it is a pretty good sign of your utter ignorance -- RHEL is almost absurdly conservative, while Ubuntu has frequently, and without the slightest compunction, broken users' machines with bleeding edge changes.
(Score: 5, Informative) by McD on Thursday September 25 2014, @01:34AM
The latest patch is still exploitable as of this writing.
https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23 [redhat.com]
I've confirmed it by applying GNU's bash32-052 patch on OS X and recompiling, per instructions first seen here [bandlem.com]
(Score: 2, Interesting) by Anonymous Coward on Thursday September 25 2014, @01:37AM
Jesus Christ. This is a fucking disaster in every way.
I think it's time for the GNU tools to be rewritten to use C++. Modern C++ let's us write code that's safe, high level (unlike cryptic 1970s-era C code that GNUers seem to love), and just about as efficient and portable as C code.
GCC is already making the move. It's time for bash, coreutils, and the other projects to get into the present. C may have been the only practical option in the late 1980s, and even into the 1990s. But C++ is now mature, and it's just flat out a better option than C these days.
(Score: 4, Insightful) by Anonymous Coward on Thursday September 25 2014, @02:05AM
How would C++ prevent this?
(Score: 1, Insightful) by Anonymous Coward on Thursday September 25 2014, @02:25AM
It wouldn't in any way. This dude is trippin balls.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:29PM
I *think* he means use more modern ideas and practices. C++ does not get you that. Avoiding shortcuty language idioms does though. If its not clear it is hard to maintain. Take for example the libressl thing. They are going thru and refactoring. But a lot of what they are doing is yanking out 15 year old C compiler and CRT workarounds. Lots of bad decisions are falling out because of that. Not because of the language they are using. It is the same one.
Picking one language over another does not get you good practices. In fact some languages teach you bad practices in other languages (ie learning garbage collection and then thinking its ok to do in C++). Each language has its own set of 'best practices'. Either you use them or bitch about them. Bitching gets you nothing other than wasted time.
This is a case of someone did not sanitize the inputs. This is a problem in almost all languages. It is a design problem. Some languages make it harder to do but they all can do it. Especially when you are at the translation layer in your systems. Most SQL injection attacks do not attack the interpreter but the sql server on the other side by abusing the interpreter because it did not sanitize.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @03:32AM
Look at the patch. Look at what it fixes. They missed a case because they were using archaic C coding practices instead of writing modern C++. If that code were written in C++ the unhandled case would have been a lot more obvious and would have been caught during code reviews, before this faulty code went out to millions upon millions of systems across the globe.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @10:45AM
ROTFL... Pathetic.
(Score: 1, Funny) by Anonymous Coward on Thursday September 25 2014, @04:07AM
Bjarne please go. Repeating the word "modern" over and over again won't change the fact that C++'s standard is a bloated mess that's almost impossible to implement and full of pitfalls. Besides, if you really cared for modernity you'd be advocating Rust, Go, or D instead.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @12:18PM
Rust? Go? D? Really?
Rust, the language that's perpetually changing, where code you write today probably won't compile tomorrow? No thanks!
Go, the language with bad garbage collection and an awful syntax? No thanks!
D, the language with two standard libraries and that nobody actually uses? No thanks!
C++ is the only practical alternative to C. The languages you've mentioned are just toys.
(Score: 2) by tangomargarine on Thursday September 25 2014, @02:49PM
No no, Go is the one with the flying, startled burrito for a mascot.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by edIII on Friday September 26 2014, @01:25AM
You scream that C++ has no alternative, but then make the claim about D that has nothing to do with it.
It's like saying TOR has some fundamental flaw that leads towards poor performance when it's almost purely an issue of participation.
You offered a better explanation for the others.
Do you really not want the D?
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @10:23AM
Bullshit. Obviously, all you know about IT comes from skimming titles on geek news websites (mostly without really understanding them).
Don't turn in your geek card, because you were never given one.
(Score: 2) by tangomargarine on Thursday September 25 2014, @02:44PM
Modern C++ let's us write code that's safe, high level
Does it also have grammar checking that would've caught that apostrophe?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 1, Informative) by Anonymous Coward on Thursday September 25 2014, @03:29AM
Shit is getting serious now. This just in: https://access.redhat.com/articles/1200223 [redhat.com]
(Score: 1) by b on Thursday September 25 2014, @01:45AM
This was patched in Arch about 10 hours ago, 5 hours before the Ars article was published. I can confirm that the previous version (4.3.024-1) contains the vulnerability, while the new version (4.3.024-2) does not.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:46AM
Does it contain the vulnerabilities described at https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23 [redhat.com]?
(Score: 1) by J053 on Thursday September 25 2014, @01:55AM
(Score: 5, Informative) by Anonymous Coward on Thursday September 25 2014, @02:03AM
That returned the date, showing that it is NOT fixed.
(Score: 1) by b on Thursday September 25 2014, @02:10AM
Yes, unfortunately it does contain those vulnerabilities.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:15AM
Shiiiiiiiiiiiiiiiiiiiit. This is not good at all!
(Score: 1) by b on Friday September 26 2014, @08:55AM
And now Arch has patched this vulnerability too.
(Score: 3, Informative) by mendax on Thursday September 25 2014, @02:05AM
I just tried it on my iMac running Mavericks and it's implementation of bash is vulnerable, and Apple has not yet provided a patch via the Software Update feature. Sure, I could patch it myself but Apple is usually pretty quick about fixing such scary vulnerabilities as this.
It's really quite a simple choice: Life, Death, or Los Angeles.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:08AM
Oh, fuck... I've turned my Mac off and I'm not even going to use it until this is fixed. This is serious business, guys. I'm not going to frig around with this particular bug.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @07:14PM
I suggest you also shut off the power to your house at the mains...just to be sure. After that you should go hide under your bed until this is all over. You just can't be too careful these days.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @10:33PM
He doesn't have to do that. He can just use his Windows computer, which isn't affected by this.
(Score: 2, Informative) by gcrumb on Thursday September 25 2014, @03:19AM
You should be okay if you edit your /etc/sshd_config and comment out the Accept_Env line.
Crumb's Corollary: Never bring a knife to a bunfight
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @07:41AM
According to sshd_config(5), this is not enabled by default, and it even warns that enabling it will make it possible to bypass restricted user environments.
So, if somebody is stupid enough to enable this in a restricted user environment, even after being warned against doing so, how is this a vulnerability in bash?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @09:33AM
On my debian 7 and ubuntu 12.04 servers, in sshd_config:
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
That's the default install.
(Score: 2) by choose another one on Thursday September 25 2014, @09:46AM
Request a tty and I think $TERM may bypass AcceptEnv
(Score: 2) by LaminatorX on Thursday September 25 2014, @01:58PM
My Apple and SuSE machines at home are both vulnerable, but the only public service we've got running is dhcpd on our wifi. Frankly, if someone is sitting in my driveway attacking my wlan, I've got bigger problems than a bash exploit through dhcpd.
(Score: 2, Interesting) by Anonymous Coward on Thursday September 25 2014, @02:18AM
This is off-topic but I have a suggestion I want to make, and I refuse to use GitHub: There should be a button so that we can easily view all comments. It does the same as setting both dropdowns to -1, and clicking Change.
(Score: 1, Informative) by Anonymous Coward on Thursday September 25 2014, @03:43AM
this is one reason I also read PipeDot, because you can read entire discussions without clicking anything.
(Score: 2) by tangomargarine on Thursday September 25 2014, @02:46PM
Mostly because there are no comments on the articles
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by DeathMonkey on Thursday September 25 2014, @05:39PM
this is one reason I also read PipeDot, because you can read entire discussions without clicking anything.
Use the 'Nested' option at the top of the thread to see the whole discussion without clicking anything. I set this up in my profile to be default.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @10:36PM
A lot of us refuse to use profiles because signing up for yet another website is a stupid thing to do, even if it's our dear SoylentNews. This is an option that should be available to anyone, regardless of account status, or made easily accessible though a button.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @07:00AM
Every single time I read comments here I first set the threshold to -1 and the view to nested and then punch change. Gets kinda irksome, agreed.
(Score: 3, Informative) by zafiro17 on Thursday September 25 2014, @12:01PM
For what it's worth, the little plus and minus buttons here are useful, but are damned-near impossible to click on a tablet or phone UI.
Dad always thought laughter was the best medicine, which I guess is why several of us died of tuberculosis - Jack Handey
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @08:51PM
I only browse this site on a phone, and I didn't even see them until you pointed them out!
(Score: 3, Funny) by Anonymous Coward on Thursday September 25 2014, @05:13AM
Does the new version of bash, which we must have, require systemd yet?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @08:48AM
Ha HA!! KA-ZING.
(Score: 2) by Leebert on Thursday September 25 2014, @05:43AM
SUNWbash package untouched... It surprised me until I rememberd that Solaris is now owned by Oracle.
Oh well. At least /bin/sh is Korn shell, and someone has to be explicitly calling Bash.
And anyway, we're paying for support. That makes us safe, right?
I should probably go to bed now. I think I'm going to have a lot of management meetings in the morning, and I'm gonna need to dial that cynicism way down.
(Score: 1) by fooetc on Friday September 26 2014, @06:08AM
http://www.ibiblio.org/pub/packages/solaris/sparc/ [ibiblio.org]
ta,
Mark.
(Score: 1) by novak on Thursday September 25 2014, @05:57AM
This is one reason I'm always a fan of getting rid of non-essential features in software. Bash is the standard pretty much anywhere, and it's a pretty good one. I much prefer it over shells like tcsh, and have it at least installed on all my linux machines. But bash is also a fairly large piece of software, so of course there are occasional bugs, like this one.
Now, on one hand, the flaw is patched at least partially the same day so this isn't an attack on bash or some crap like that. But on the other, this is exactly why I prefer to use more minimal, (sometimes) worse software. Even in 2014, decades after everyone started laughing at microkernels, there's still something to be said for brevity.
I have a huge amount of respect for projects like OpenBSD where they run a tight, small ship. I also appreciate distros like alpine where they use musl libc to shrink the size of binaries. Partially because I love playing with embedded hardware, but also because minimalism can be a good thing for its own sake.
novak
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @11:54AM
Everyone laughs at microkernels because they're academic ivory tower wankery that just doesn't work in the real world.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @02:13PM
minix 3.3 begs to differ.
(Score: 2) by tangomargarine on Thursday September 25 2014, @02:52PM
And does anyone actually use Minix other than Tannenbaum and a few professors?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by choose another one on Thursday September 25 2014, @03:18PM
I think there was some student or other in Finland back in the 90s.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @04:30PM
We're still laughing at it. It's a toy OS, even if it tries desparately to be one of the big boys.
(Score: -1, Offtopic) by Anonymous Coward on Thursday September 25 2014, @06:50AM
Invalid form key: KqfiBKSLSG
Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form. Please try again. If the problem persists, and all other options have been tried, contact the site administrator.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @07:29AM
The summary seems to be describing a bug, not a vulnerability. Bash doesn't open any listening ports, you cannot connect to bash. If you have access to run bash, you already have full access under that userid, and bash is not setuid. If it was, that would be the hole. And any modern *nix ignores the setuid bit for scripts, so that can't be it either.
Ok, 15 years ago, we did write some cgi-scripts in bash or other shell script, but even back then, we knew that making a shell script accessible on the net was a security problem. It was never supposed to do that.
So, how does this bug make it possible to do anything that the user doesn't already have permissions to do?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @09:04AM
escaping limited shell in ssh, root access, etc (but each case seems to be possible with some specific configuration, for instance escaping ssh is possible only if you enables AccessEnv which is disabled by default)
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ [redhat.com]
(Score: 3, Informative) by choose another one on Thursday September 25 2014, @09:32AM
It is a vulnerability because environment variables cross process/user permission boundaries, and therefore the contents should be treated as untrusted. Bash, it appears, executes them as code, and moreover the environment variable can have any name. Environment variables should never be trusted precisely because they cross boundaries - think setuid. Whatever process sets the environment variable cannot possibly check for all possible malicious content for all possible programs that could be launched down the line with that environment - it is down to each process _reading_ an environment variable to do so with suitable care, and blindly executing it to define a function is not.
Certain standard services, such as cgi, put information from remote untrusted clients/servers into the environment. The cgi script itself obviously does not have to be a bash script - if it is launched through the shell or ever launches any other command via the shell (popen, system() etc.) then boom.
Other attack surfaces include ssh (think TERM), now think "locked down" ssh access for e.g. Git. Not so "locked down" now.
Now think about your DHCP client. How do you setup the interface configuration it does, some kind of script maybe ? What user might that script be running as, considering what it needs to do ? How does the client process pass the info it gets from the DHCP server into the script ? Ever connected to a public wi-fi ? Boom.
Make no mistake, this is big, possibly bigger than heartbleed, and people have likely only just scratched the surface of possible attack vectors. The NSA have probably had this one in the bank for years.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:58PM
On the other hand, for scripts you would use /bin/sh which at least on Debian systems is not bash. Also system() uses /bin/sh. So any Debian system using properly written scripts should be fine (unless dash is also vulnerable).
(Score: 2) by choose another one on Thursday September 25 2014, @03:14PM
Yep, /bin/sh != bash would be a start.
Not sure how much that will break on other systems. Might be better to ban bash from non-interactive use, or get rid of it entirely, the whole idea of parsing environment variables as code is an exploit waiting to happen - putting band-aids on the parser will be a temporary and fragile fix (as already shown).
(Score: 2) by PizzaRollPlinkett on Thursday September 25 2014, @02:43PM
How bad could a bash bug really be? The Internet echo chamber acts like this is the next apocalypse, worse than all the other headline-grabbing Internet issues rolled together. But ... bash? If someone can get a shell, your machine is probably compromised. And are there really any public-facing CGI programs written in bash these days? Even if this was never patched, how bad could it possibly be? I would put this slightly below "you already need root to exploit this bug" Linux issues on the severity scale.
Are people really using old CGI scripts these days? Written in bash?
(E-mail me if you want a pizza roll!)
(Score: 2) by choose another one on Thursday September 25 2014, @03:53PM
> Are people really using old CGI scripts these days? Written in bash?
Apparently cPanel. Don't think anyone uses that much these days though...
(Score: 2) by PizzaRollPlinkett on Thursday September 25 2014, @04:33PM
Even if cpanel uses bash (I have no idea), something like that wouldn't be available to the public, would it? It's a server admin tool.
Ars just published this:
http://arstechnica.com/security/2014/09/concern-over-bash-vulnerability-grows-as-exploit-reported-in-the-wild/ [arstechnica.com]
I just can't get a grasp of how serious this is yet.
(E-mail me if you want a pizza roll!)
(Score: 2) by urza9814 on Thursday September 25 2014, @05:50PM
It's been many years since I've seen cPanel, but when I did it was always on shared hosing. Mostly resellers, who would buy a couple server instances somewhere and sell them off to hundreds of users. Which means if you can use this through cPanel, then one user possibly use this to take full control of that server, or break into anyone else's account, right?
(Score: 2) by choose another one on Thursday September 25 2014, @06:17PM
Yep, take control of the shared hosting server. Once that's done, inject malware into all the sites it hosts, or just use it as part of a botnet, take your pick.
(Score: 1) by nishi.b on Thursday September 25 2014, @10:03PM
From what I understood, it is not necessary to have a bash shell at your disposal to trigger this.
Here is the example I read :
- a server runs Apache with CGI
- it uses a CGI module (a perl program, a C program, java, whatever)
- the URL parameters are transmitted to the program by Apache as environnement variables
- let's say your CGI calls an external command, such as system("echo >> > /myCounter.txt")
- An attacker goes to "http://site.com/script.cgi" and sets its "referrer" string to a bash function definition
- Your CGI script is executed, and runs the external command. This opens up a shell (bash) to run the provided command in the same environment, and *the env variables are interpreted by bash*.
- This means that any CGI that uses a system() command for example (so executes a bash shell) can be used to run arbitrary commands on the server.
I am not sure what happens with SSH, but I think it works like this :
you can define env vars before running ssh to connect to a server, and SSH will try to copy the variables to the shell on the remote host (for example, to keep your language settings). If the shell is bash, the code in the vars will be executed even if the user does not type any command in his shell window.
(Score: 2) by digitalaudiorock on Thursday September 25 2014, @03:13PM
Wow...there's a lot of news around this one, but very few mentioning what's already been pointed out here...that the "fix" was not complete:
https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23 [redhat.com]
I'm assuming there is in fact a correct fix, as an update on my Gentoo systems has corrected the second issue mentioned there:
...but the newest version in CentOS 6 is clearly not right yet:
Scary stuff.
(Score: 1) by captainClassLoader on Thursday September 25 2014, @10:06PM
I just updated bash on Cygwin to 4.1.11, and my tests match your results on CentOS. Issue 1 is fixed, issue 2 is not.
(Score: 2) by present_arms on Thursday September 25 2014, @11:00PM
grins [minus.com]
http://trinity.mypclinuxos.com/
(Score: 2) by present_arms on Thursday September 25 2014, @11:03PM
oops i meant grins [minus.com]
http://trinity.mypclinuxos.com/