INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Linux => Topic started by: JimH on September 25, 2014, 11:03:48 am
-
I can't confirm this, but it appears to be serious:
http://www.tomsguide.com/us/shellshock-osx-linux,news-19614.html
-
I can't confirm this, but it appears to be serious:
http://www.tomsguide.com/us/shellshock-osx-linux,news-19614.html
I saw a bash patch come through one of my updates last night and wondered "what could they be changing in a 25 year old shell scripting language?" Arch and Debian at least are taking it seriously enough to update bash immediately (and Red Hat too, it sounds like)
It's all over the computer security news now (ZDNet picked it up). Run, don't walk to fix it, especially on anything that's network accessible...
-
It's not 100% fixed yet even after the patches.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
-
Pretty dumb.
I'd like to see how that applies to real-world exploits.
I don't see anyone opening up their machines to the outside world with bash scripts. Does anyone use those in any web services?
-
Its apparently easily exploitable if you use cgi based web services, since bash does the hand-over in the middle, which is a pretty common setup for many scripting languages.
-
Its apparently easily exploitable if you use cgi based web services, since bash does the hand-over in the middle, which is a pretty common setup for many scripting languages.
Interesting.
So the php scripts are executed by bash.
More likely by the system shell of the user the webserver is running under which isn't necessarily bash, dash is more commonly linked to the /bin/sh now.
I wonder if it's got the same issue?
-
Interesting.
So the php scripts are executed by bash.
More likely by the system shell of the user the webserver is running under
My understanding is that you get the same permissions as the user you're using to get in, you can execute whatever, say, the "apache" user is capable of executing.
which isn't necessarily bash, dash is more commonly linked to the /bin/sh now.
I wonder if it's got the same issue?
The newsmedia are reporting dash is not vulnerable (http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/), but according to some users on Reddit who tried the exploit on their Debian and Ubuntu systems, they were not immune to the exploit, so I'm not sure how to reconcile that.
And dash is only the default on Debian based distros, I think; Red Hat and many other distros (e.g Arch) still use bash as system default.
-
Here's a good write-up if you want the details
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
-
The debian distros were updated again this morning.
It SEEMS to have taken care of the problem (for now).
There are already active hacking attempts going on out there.
-
The debian distros were updated again this morning.
It SEEMS to have taken care of the problem (for now).
There are already active hacking attempts going on out there.
Was that in sid, testing, or somewhere else? I haven't seen a second update come through this morning on my Debian Jessie box and I've been updating and dist-upgrading every few hours.
Edit: never mind it's in Sid, I just found it.
-
Was that in sid, testing, or somewhere else? I haven't seen a second update come through this morning on my Debian Jessie box and I've been updating and dist-upgrading every few hours.
Edit: ever mind it's in Sid, I just found it.
It's in wheezy as well
-
It's in wheezy as well
Weird, it still hasn't hit Jessie; I guess they are pretty explicit that testing doesn't necessarily get security updates as fast as stable.
-
Weird, it still hasn't hit Jessie; I guess they are pretty explicit that testing doesn't necessarily get security updates as fast as stable.
They do warn you about that on the downloads page. Only stable is maintained by the security team.
-
They do warn you about that on the downloads page. Only stable is maintained by the security team.
Yeah, it's one of the hazards of unstable, they just pushed through the initial patch so fast yesterday I thought they might push the second one through at the same speed. I pulled in the fix from sid, so i'm not too worried about it on my systems. If anyone reading this is running Debian Jessie or testing, only the first of two patches has made it in so far, you may still be exposed.
-
It's baaaack:
http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/
The patch to the patch apparently isn't good either. Looks pretty fundamental, and they're patching at the edges.
-
It's baaaack:
http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/
The patch to the patch apparently isn't good either. Looks pretty fundamental, and they're patching at the edges.
Bloody hell.
May be time to uninstall it.
-
Bloody hell.
May be time to uninstall it.
My understanding is that the gnu gcc toolchain relies heavily on bash, so if you remove it you may have trouble compiling if you use gcc. Debian's tried to eliminate bash dependence from official packages, but that's not guaranteed, and that obviously doesn't extend to packages you build yourself.
At least Debian users could give it a shot; the Arch admins have more or less suggested that uninstalling bash would break their packaging/update system entirely.
-
My understanding is that the gnu gcc toolchain relies heavily on bash, so if you remove it you may have trouble compiling if you use gcc.
You could, also, if you do use gcc, try switching to Clang/LLVM (http://www.phoronix.com/scan.php?page=news_item&px=MTE4NDQ). It is probably faster anyway, and has a more liberal license.
Of course, that doesn't help if dpkg and apt are both totally broken. :-\
-
You could, also, if you do use gcc, try switching to Clang/LLVM (http://www.phoronix.com/scan.php?page=news_item&px=MTE4NDQ). It is probably faster anyway, and has a more liberal license.
Yeah that's a perfectly good workaround for systems that can run bashless, although, for my personal uses, I prefer gcc because it's still (for the moment) generally faster at runtime if not at compile time. Based on the trajectory of the benchmarks, in another year or two, clang will probably become completely superior all the way around.
Of course, that doesn't help if dpkg and apt are both totally broken. :-\
Just so nobody gets confused, I think Debian's packaging system generally works fine without bash because Debian's made a conscious effort to migrate away from bash (it's just not guaranteed that everything will work sans bash). What I meant by my comment above was that the Arch Linux devs basically indicated that parts of Arch's packaging system would not work without bash at the moment, and I think the same thing is true of Red Hat (which is one of the reasons they're leading the charge to get this patched).
-
He might already be using it, since they need it to compile on OSX anyway. It'd be easier to target one compiler, wouldn't it?
-
I prefer gcc because it's still (for the moment) generally faster at runtime if not at compile time.
The benchmarks I've seen, for C at least, the last couple of revisions have been very back and forth. LLVM/Clang is a bit ahead in some places, tied in others, behind in a few, then a new dev gcc comes along and it is a bit ahead in some places, tied in others, behind in a few. Though, I can't really speak incredibly intelligently about the places where one or the other is important, so... :-\
I don't know much about how it handles C++, though. Mostly what I've looked at lately is the unbelievable gains in Swift performance, which have been nothing less than stunning over the course of development since announcement.
The LLVM system, of course, has other benefits. But, gcc is so longstanding that even if it didn't often win benchmarks, it would be very hard to displace en masse.
-
Currently using GCC.
There isn't very good clang support in eclipse though since Hendrik made our new and improved build system it'd probably be pretty simple to switch.