|
Hold onto your groins, after HeartBleed we get a new bleed that allows someone to execute malicious code in linux enviromental. This also works through CGI scripts on web-servers since they can write into your env variables at will. To check if your system is vunerable simply post this code... code:This also affects Mac systems, just fyi. e: Some sources https://access.redhat.com/articles/1200223 http://blog.erratasec.com/2014/09/bash-bug-as-big-as-heartbleed.html e: Update Patches that have been issued still do not fix the issue completely. Companies panicing. Mass hysteria. Worse than HeartBleed. Stay safe. Michaellaneous fucked around with this message at 21:17 on Sep 25, 2014 |
#
?
Sep 25, 2014 07:51
|
|
|
|
| # ? Apr 16, 2024 20:53 |
|
|
Shellshock is a better name fyi. FreeBSD is not affected as it doesn't bundle bash. XBMC is vulnerable because it does. Windows is not vulnerable except if you have github for windows installed, because git bash is.
|
|
#
?
Sep 25, 2014 11:14
|
|
|
Note all the current fixes released do not fully fix the issue. https://twitter.com/taviso/status/514887394294652929 Further fixes are coming later today (at least from Ubuntu and Redhat who have both commented on this further exploit).
|
|
#
?
Sep 25, 2014 13:47
|
|
|
If I wasn't a moron and don't have shell based CGI scripts, and don't have PHP or whatever scripts that use unsanitized input to exec a shell, there's really no remote vulnerability, right? I know there is a OpenSSH vector with ForceCommand, but I don't use that either.
|
|
#
?
Sep 25, 2014 14:03
|
|
|
Do you have any embedded devices that have a web front end? Then you are likely vulnerable. Web server side of things shouldn't be that bad, as most people don't have CGI scripts on a normal website. Cpanel are saying they have tested and aren't vulnerable to it, which is good hope its the case for the rest. Edit: just reading that in fact its not just a theoretical risk with just PHP, all web application languages are vulnerable e.g. NodeJs, Django, etc. Would imagine there are lots of people having a field day exploiting this, especially given a proper fix might be a while coming. ukle fucked around with this message at 14:34 on Sep 25, 2014 |
|
#
?
Sep 25, 2014 14:11
|
|
|
From what I understand so far, "typical" installations of Apache/PHP where there's no use of CGI, and the apache module is disabled, are not affected. However, if you use something like Apache/Nginx + php-fpm which does invoke CGI, then you may be at risk (haven't tested yet, just speculating from all I've read so far) What I don't really understand is how something like this managed to remain unknown for so long until yesterday. I'm not real big into bash scripting, but once one would understand that a) commands are executed when declared after a function definition in an env var, and b) most CGI implementations throw web parameters into env vars, then you could put 1 and 1 together to realize the exploit. Was it that point "a" from above was pretty much unknown until yesterday?
|
|
#
?
Sep 25, 2014 14:52
|
|
|
Might want to put "ShellShock" in the subject too; that's how most articles I'm seeing are referencing it. MSP helpdesk here - we are pretty much at the mercy of 3rd parties to release patches for poo poo. SonicWalls, Asterisk, things like that. I'm sure there's a ton of other poo poo I haven't thought of like NAS devices that are probably vulnerable, but I'll lose my poo poo if I find any of those are open to the external web at any of my clients. I feel a bit of urgency to put all of my engineers on alert to watch for patches. Do we really think it's feasible that some type of worm/bot will quickly propagate that will be scanning everything it can find and branch out a la Blaster worm? Yes, probably. /coffee
|
|
#
?
Sep 25, 2014 15:25
|
|
|
Michaellaneous posted:
Stupud question, but what should this output if the system is vulnerable/not vulnerable?
|
|
#
?
Sep 25, 2014 15:33
|
|
|
gallop w/a boner posted:Stupud question, but what should this output if the system is vulnerable/not vulnerable? This means vulnerable code:code:
|
|
#
?
Sep 25, 2014 15:42
|
|
|
gallop w/a boner posted:Stupud question, but what should this output if the system is vulnerable/not vulnerable? For Vulnerable Vulnerable this is a test None Vulnerable bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test ^beaten Remember this is only testing the original fix, its not testing the wider problem which isn't fixed at all yet.
|
|
#
?
Sep 25, 2014 15:43
|
|
|
Dumb question: how does this affect regular computer users? Also: if I'm running Mac OS X on my home computer, how would I patch that?
|
|
#
?
Sep 25, 2014 15:58
|
|
|
fart blood posted:Dumb question: how does this affect regular computer users? It doesn't affect "regular" users. It also doesn't affect a lot of public services. It could affect anything that shells out for any reason (bad/old CGI stuff, system() in php, restricted logins for git users, dhcp scripts, vpn logon scripts). Apple is historically terrible about patching this stuff. I'd probably just grab bash from brew and replace /bin/bash in /etc/shells with /usr/local/bin/bash. Or just copy over the binary
|
|
#
?
Sep 25, 2014 16:23
|
|
|
Evidence that its already being exploited - http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3505#p23987 Patch ASAP. Note that exact malware is exploiting the same flaw in Busybox, to take over routers to be DDoS bots. ukle fucked around with this message at 16:34 on Sep 25, 2014 |
|
#
?
Sep 25, 2014 16:29
|
|
|
Nam Taf posted:FreeBSD is not affected as it doesn't bundle bash. This is incorrect, it's vulnerable if you have bash installed. See here for vulnerable versions.
|
|
#
?
Sep 25, 2014 17:20
|
|
|
Saw this on the news last night. The talking heads said "malware in the l-eye-nix computer system could allow hackers to take over your computer! This affects all computers running the bash program and mac computers." After I finished laughing at how fear-based and uninformed the report was, and confirmed that my systems were affected, I patched my entire infrastructure (~200 machines) in about 5 minutes, thanks to Puppet. Edit: adding to the conversation This vulnerability only affects the following version of BASH: bash-4.2.45-5.el7_0.2 bash-4.1.2-15.el6_5.1 bash-4.1.2-15.el6_5.1.sjis.1 bash-4.1.2-9.el6_2.1 bash-4.1.2-15.el6_4.1 bash-3.2-33.el5.1 bash-3.2-33.el5_11.1.sjis.1 bash-3.2-24.el5_6.1 bash-3.2-32.el5_9.2 bash-3.0-27.el4.2 Fat Dallas fucked around with this message at 18:04 on Sep 25, 2014 |
|
#
?
Sep 25, 2014 18:01
|
|
|
Fat Dallas posted:This vulnerability only affects the following version of BASH: And uh... everything earlier too.
|
|
#
?
Sep 25, 2014 18:18
|
|
|
It also affects Busybox as well, which is where the first seen in the wild use of this exploit was found. Remember as well that the exploit still isn't fully patched, although hopefully that 'final' fix is probably due any time now.
|
|
#
?
Sep 25, 2014 18:20
|
|
|
alo posted:And uh... everything earlier too. Fair point... But if you're running anything earlier than v.3.0, then you have bigger problems.
|
|
#
?
Sep 25, 2014 18:26
|
|
|
ukle posted:It also affects Busybox as well, which is where the first seen in the wild use of this exploit was found. I don't believe this is true (I hope). Fat Dallas posted:Fair point... But if you're running anything earlier than v.3.0, then you have bigger problems. Which is why this is kind of a big thing in the long term for older appliances that will never see anything newer than bash 2.95. A lot of older appliances that are connected to the Internet are just going to keep connecting to botnets until their power supplies die. The heartbleed vulnerability was limited to a 2 year window. Almost every appliance affected was still vendor supported.
|
|
#
?
Sep 25, 2014 19:50
|
|
|
Fat Dallas posted:This vulnerability only affects the following version of BASH: NVD says 4.3 is affected, too
|
|
#
?
Sep 25, 2014 19:51
|
|
|
Thanks to the mod renaming the title. BashBleed was the name I heard about it, didn't know they had a second name for it as well. Also, Red Hat has stated that most of the patches that are being spread now still do not fully protect against ShellShock. I will try to keep you guys informed and read some more news, but currently we seem to be stuck at "This is literally the worst thing ever!"
|
|
#
?
Sep 25, 2014 21:16
|
|
|
alo posted:I don't believe this is true (I hope). Pretty sure it isn't. Busybox uses the Almquist shell, which from my personal testing doesn't appear to be vulnerable.
|
|
#
?
Sep 25, 2014 21:28
|
|
|
Michaellaneous posted:Thanks to the mod renaming the title. BashBleed was the name I heard about it, didn't know they had a second name for it as well. Mostly because CGI is awful. The original patch fully covered "ShellShock". The "Shock" part now is how disturbingly fragile the readline/parsing code is, how fragile redirection can be, how any tiny change in behavior can break large areas, and how bad the security is all over the place once people start looking for it. They're plugging vulnerabilities. They're just finding more while they do it. Technogeek posted:Pretty sure it isn't. Busybox uses the Almquist shell, which from my personal testing doesn't appear to be vulnerable. *by default There is no reason why busybox couldn't be using bash, and a number of busybox spins are.
|
|
#
?
Sep 25, 2014 21:32
|
|
|
I'm just glad that our stuff is all behind SSH...pipe what little bash stuff we do over tunnels. If they're inside that perimeter, we're already hosed.
|
|
#
?
Sep 25, 2014 21:42
|
|
|
Digitalpope posted:I'm just glad that our stuff is all behind SSH...pipe what little bash stuff we do over tunnels. If they're inside that perimeter, we're already hosed. Bash isn't remote anyway. This vulnerability is basically a few things: CGI calls for metavariables. These are almost always done as environment variables. FastCGI and other app servers avoid this in different ways, but anything that's plain CGI which calls out to system() or a shell, ever, is vulnerable. DHCP client scripts. But if someone gets a rogue DHCP server, you have bigger problems anyway. Things which rely on any shell feature for security. Git frontend software which allows SSH as your user but isn't nologin, then uses the shell in any way. Gitolite and gitlab were both affected, through SSH. Embedded systems, appliances, or things you don't control (xenserver, aws, firewall appliances, some storage appliances, etc) which are subject to the same CGI/other vulnerabilities. Almost everything eventually hits the system somewhere. Probably standard system utilities, probably by invoking a shell. If you've written your stack from the bottom up to only use glibc/ioctls/whatever instead of re-using system utilities, you're probably ok. If you have a public-facing service using a dynamic language anywhere, you may be in trouble.
|
|
#
?
Sep 25, 2014 21:58
|
|
|
Debian has released a package (for stable). https://security-tracker.debian.org/tracker/CVE-2014-7169
|
|
#
?
Sep 25, 2014 22:42
|
|
|
Brought this to the attention of my sysadmins today. "Oh gently caress!"  It's going to be interesting to figure out how to patch all this poo poo. The fact that BusyBox is using a bash shell under the hood is a serious nightmare because there are TONS of embedded systems that are now horked.
|
|
#
?
Sep 26, 2014 00:12
|
|
|
Ubuntu patches are out. http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7169.html I'm waiting on redhat for our shop.
|
|
#
?
Sep 26, 2014 00:54
|
|
|
CuddleChunks posted:The fact that BusyBox is using a bash shell under the hood is a serious nightmare because there are TONS of embedded systems that are now horked. Unless it's a default spin of busybox which Technogeek above pointed out uses ash. xarph posted:Ubuntu patches are out. Gah, thank gently caress. Any idea if it's propagated to Xubuntu et al?
|
|
#
?
Sep 26, 2014 00:57
|
|
|
What is the coverage on web servers being affected? All the news articles are a little vague on protecting against the attack. I already have examples in my lighty logslighty posted:209.126.230.72 - - [24/Sep/2014:18:39:52 -0400] "GET / HTTP/1.0" 400 349 "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-s
|
|
#
?
Sep 26, 2014 01:05
|
|
|
Soon, the entire Internet will be mining Bitcoins.evol262 posted:CGI calls for metavariables. These are almost always done as environment variables. FastCGI and other app servers avoid this in different ways, but anything that's plain CGI which calls out to system() or a shell, ever, is vulnerable.
|
|
#
?
Sep 26, 2014 01:36
|
|
|
MrMoo posted:What is the coverage on web servers being affected? All the news articles are a little vague on protecting against the attack. I already have examples in my lighty logs If you use traditional CGI, you have problems. xarph posted:Ubuntu patches are out. These are not a complete fix and canonical knows it. There is ongoing public discussion about how to mitigate more problems, and we (red hat) are waiting for it. Which sucks, for us (as a company), for you, and for me (since I'm responsible for rhel-guest-images and I don't want to be building and testing 4 images at midnight on a Thursday.
|
|
#
?
Sep 26, 2014 01:39
|
|
|
There was some talk that GitHub Bash on Windows was vulnerable, (as 'vulnerable' as anything is) which is apparently true: http://security.stackexchange.com/questions/68214/githubs-bash-shell-for-windows-is-vulnerable-to-shellshock-can-it-do-any-harm But a later comment by one of the GitHub for Windows developers says that it can't really be exploited.
|
|
#
?
Sep 26, 2014 01:45
|
|
|
OneEightHundred posted:Soon, the entire Internet will be mining Bitcoins. setenv where? By the time you can setenv, the environment has already been parsed and you're dead. They're passed that way because it's trivial for applications to read there environment and it hasn't been a security problem so far. Reworking CGI handling to deal with a shell problem is unlikely, and the webserver can't be expected to know what headers/variables may be malicious. The problem isn't in the way the variables are passed, but bash. And there's no good way to change it without reworking a metric ton of legacy code that expects environment variables. It's no-win.
|
|
#
?
Sep 26, 2014 01:48
|
|
|
evol262 posted:setenv where?
|
|
#
?
Sep 26, 2014 01:58
|
|
|
evol262 posted:If you use traditional CGI, you have problems. Does that include fast-cgi with only PHP?
|
|
#
?
Sep 26, 2014 02:03
|
|
|
MrMoo posted:Does that include fast-cgi with only PHP? Fastcgi is safe, AFAIK OneEightHundred posted:I guess I'm not really grasping how this works. I was under the impression this required setting environment variables through a call to the shell like system(), which using something like setenv would avoid, or is that not true? No. When the CGI script is invoked, the metavars from the webserver are already set as environment variables. Child processes (including system()) inherit the parent's environ. So CGI calls php. PHP pulls whatever out of the environment. It calls system() to do whatever. Shell is invoked. Shell gets environment. Shell executes BAD_VAR=... Headers added with curl (or whatever) will pass through, which is how this works
|
|
#
?
Sep 26, 2014 02:20
|
|
|
Kazinsal posted:Gah, thank gently caress. Any idea if it's propagated to Xubuntu et al? The Ubuntu flavours use the same repositories.
|
|
#
?
Sep 26, 2014 03:15
|
|
|
Random thought: Might this (and Heartbleed) be a counterpoint to the idea of security through obscurity being bad, since something like this happening on a closed platform would probably have been either quietly patched out during a maintenance update or patched out as a completely non-specific vulnerability instead of being announced to the whole world with instructions on day zero?
|
|
#
?
Sep 26, 2014 06:10
|
|
|
|
| # ? Apr 16, 2024 20:53 |
|
|
OneEightHundred posted:Random thought: Might this (and Heartbleed) be a counterpoint to the idea of security through obscurity being bad, since something like this happening on a closed platform would probably have been either quietly patched out during a maintenance update or patched out as a completely non-specific vulnerability instead of being announced to the whole world with instructions on day zero? It wasn't announced on day zero. Heartbleed didn't go through responsible disclosure because of multiple independent discoveries. This did. The problem here is that publicizing it (after releasing patches and packages) got people to realize it was an incomplete fix by experimenting with similar tests, which is just as likely to happen to closed-source software. The problem isn't so much "through obscurity" as "almost nobody actually looks at this code and the people who do tend to miss it because they're so familiar with it that they don't have fresh eyes or they're looking to fix an unrelated bug, not security problems." This is why code review matters. This is why you shouldn't just trust any software. Open source software isn't infallible, but it's like the bystander problem -- everyone assumes someone else is doing it. Almost all the bugs I get come from our QE team, not users. 99% of patches come from people with @someproject (redhat, canonical, Intel, IBM, depending on the codebase), not @gmail or @yourcompany You can contribute, test, and read the code. You probably don't. That's OK. But nobody else is either, besides the developers, and that's the same paradigm as Microsoft.
|
|
#
?
Sep 26, 2014 06:22
|
|