If you’re a bad guy, and you found it, you wouldn’t advertise it. If you’re a good guy, well, somebody found it by poking at it. But yes, it’s 22 years old. There’s a 25 year old X11 bug that came out a few months back. The Heartbleed bug had been there a while, too, and was, in part, due to legacy cruft, IIRC.
Many eyes don’t make for shallow bugs. Many *motivated* eyes make for shallow bugs. Microsoft has their SDL wherein they look for this sort of thing, because they’ve been spanked. OSS just assumes that somebody will get bored and find it, yes. From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ken Hohhof via Af Sent: Monday, September 29, 2014 3:07 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-craftedenvironment variablescodeinjection attack Supposedly bash has been vulnerable since around 1992. That’s 22 years. You want to tell me no one, absolutely no one (not even the NSA) has found and exploited this previously? And not shared it publicly? From: Josh Reynolds via Af <mailto:af@afmug.com> Sent: Monday, September 29, 2014 1:56 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-craftedenvironment variablescodeinjection attack FWIW, there is a *new* bash CVE out today. Time to upgrade again :) Josh Reynolds, Chief Information Officer SPITwSPOTS, www.spitwspots.com On 09/29/2014 10:08 AM, Ken Hohhof via Af wrote: Scary, looking at my bookshelf I see boxes for RHL 8.0 and RHEL 2, 3 and 4. RHEL 4 came out in 2005 and went on extended support in 2012. Needless to say, I’m not paying for an extended support contract. So this is ancient stuff. But you’re not exactly going to build a new server for legacy customers of a service you stopped offering 5 years ago. At some point you move them to a reseller service, or just tell them it’s time to move on. The newer CentOS distributions have I think about 10 years of updates, that’s the main difference for RHEL and CentOS from other Linux distributions, they tend to have longer life cycles since they are aimed at enterprise. The downside is they are typically several steps back from the latest versions of packages. For example, don’t try using the version of BIND that comes with even the newest distribution. It’s like Windows, you still find a lot of Win7 in the enterprise market, Microsoft pretty much had to force them off XP. From: Timothy D. McNabb via Af <mailto:af@afmug.com> Sent: Monday, September 29, 2014 12:33 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-craftedenvironment variablescodeinjection attack TBH there is one thing I love most about a CentOS distro over Windows. IPTables. Windows firewall is pretty lame in comparison, with open ports you will “possibly” use. At least IP tables initially comes with a “block all” setup and you just go in and poke the tiny holes you need. Obviously a security-conscious person is going to shutdown system services you don’t need, but for the initial setup IPtables is pretty badass (and far more simple). @Ken, I am in the same boat as you. We applied updates Thursday and again Friday for bash on our CentOS 5/6 boxes. So far so good though, I’ve been monitoring the logs of our boxes running httpd and so far nothing out of the ordinary has appeared. -Tim From: Af [mailto:af-bounces+tim=velociter....@afmug.com] On Behalf Of Shayne Lebrun via Af Sent: Monday, September 29, 2014 4:51 AM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack Originally, I responded to this: Ø “I think the articles have maybe overstated the risk a bit, since you would need to either authenticate (at least as a regular user) to get to a shell, or find a publicly exposed script that will pass an environment variable to bash for you. And asked you not to think about security in those terms. Don’t assume you understand all the possible attack vectors, don’t assume that because certain other things need to happen, you’re invulnerable, etc etc. When you get right down to it, though, UNIX really wants to land you at a shell, and bash is the default shell in a lot of places. You’re certainly listed a whole bunch of issues in the software world at large, dedicated applicances, etc etc and I certainly sympathize with a lot of the issues you’ve raised. Of course, the slightly less empathetic sysadmin in me says ‘too bad; you put public-facing server on the Internet, you have an obligation, and a responsibility to maintain it properly.’ I argue in my head with him A LOT. Yes, absolutely, you can mitigate the issues you raised in your last email to a very reasonable degree with proper firewalling, internal processes, etc etc. And it sounds like you’re cognizant of the need to do that, so that’s great too. From: Af [mailto:af-bounces+slebrun=muskoka....@afmug.com] On Behalf Of Ken Hohhof via Af Sent: Sunday, September 28, 2014 9:55 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack You are preaching rather than listening. What if it is an appliance with a distribution that is frozen in time on CentOS4 with no updates. Note that RHEL4 updates are only available via paid extended support, and CentOS4 is EOL. Doing a yum update on a CentOS4 box won’t get you anywhere, and I don’t believe RHEL4 even used yum, it used Redhat Network to get RPMs. All my new stuff on CentOS5 and 6 has been updated. What I was asking for an opinion on was whether the RPM that Oracle made available was likely to work, or to brick the box. Keep in mind that bricking your command shell could be difficult to recover from, especially on a headless appliance at a remote site. I’m guessing that creating another user with a different shell like csh or ksh might offer a failsafe. I would have to see what other shells are available on the device. So this is a Tyan kiosk type server with BlueQuartz installed, long ago defunct. Nuonce was maintaining repositories but stopped a long time ago. Other people are going to face similar situations. Not every server is built from scratch loading the OS and then the applications. Sometimes you use an all-in-one install disk, like CactiEZ or some of the Asterisk/FreePBX distributions. I’m evaluating the PBX appliances from Grandstream, clearly they run Asterisk and probably Linux under the hood, but you can’t even get to the command line, so any software updates would have to be from the web GUI with updates from Grandstream. So I’m thinking if that’s a problem, being totally dependent on the vendor, I guess stuff like routers are the same. But you can’t just go and do a yum update on everything that has Linux inside, or recompile the source code with the patch and install it yourself, even assuming you feel comfortable doing that. From: Shayne Lebrun via Af <mailto:af@afmug.com> Sent: Sunday, September 28, 2014 7:00 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack Quite honestly, who cares? There’s zero downside to closing the security hole. Hopefully you’re closing all your other security holes too, especially for things like DNS or NTP that are almost public facing by default. Why not close this one at the same time? What happens in six months when you, or somebody, stick another service on that machine? From: Af [mailto:af-bounces+slebrun=muskoka....@afmug.com] On Behalf Of Ken Hohhof via Af Sent: Sunday, September 28, 2014 10:38 AM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variables codeinjection attack Why? Take the case of a dedicated server that only does let’s say DHCP or DNS or NTP. It only has one port open to the Internet, and there’s no way to get to a bash shell via that port. How the hell is someone going to pass an environment variable to a bash shell on that server? From: Shayne Lebrun via Af <mailto:af@afmug.com> Sent: Sunday, September 28, 2014 8:40 AM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variables codeinjection attack Ø I think the articles have maybe overstated the risk a bit, since you would need to either authenticate (at least as a regular user) to get to a shell, or find a publicly exposed script that will pass an environment variable to bash for you. Please don’t think like this. From: Af [mailto:af-bounces+slebrun=muskoka....@afmug.com] On Behalf Of Ken Hohhof via Af Sent: Saturday, September 27, 2014 1:38 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variables code injection attack So maybe I won’t do that. The newer servers where I could just do a yum update have been straightforward, as you’d expect. I think the articles have maybe overstated the risk a bit, since you would need to either authenticate (at least as a regular user) to get to a shell, or find a publicly exposed script that will pass an environment variable to bash for you. From: Jeremy via Af <mailto:af@afmug.com> Sent: Saturday, September 27, 2014 12:13 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variables code injection attack Our webserver was vulnerable. Tried to fix it without backing it up first....yeah, I know. Lost it all. So I guess I will be building a new website from my 2013 backup this weekend. It's a good thing I carpet bombed my website to prevent anyone from messing with it! On Sat, Sep 27, 2014 at 10:25 AM, Ken Hohhof via Af <af@afmug.com> wrote: Unfortunately I have a couple old servers running RHEL4 and one old BlueQuartz webhosting appliance based on CentOS4. I’m a little reluctant to try compiling the patch myself unless I switch to a difference shell first, if I screw up my command shell it might be difficult to fix. Any guess if I’d be safe using the RPM cited in this thread: http://serverfault.com/questions/631055/how-do-i-patch-rhel-4-for-the-bash-vulnerabilities-in-cve-2014-6271-and-cve-2014 the RPM it points to is: http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/bash-3.0-27.0.2.el4.i386.rpm From: Ty Featherling via Af <mailto:af@afmug.com> Sent: Saturday, September 27, 2014 10:52 AM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variables code injection attack Yeah probably the NSA! Hahaha! -Ty On Sep 26, 2014 10:36 PM, "That One Guy via Af" <af@afmug.com> wrote: Man I bet theres some guy whose been exploiting this for 20 years who is pissed right now On Fri, Sep 26, 2014 at 1:54 PM, Ty Featherling via Af <af@afmug.com> wrote: CentOS on some, Ubuntu on others. Already got the answers in this thread though, thanks. -Ty On Fri, Sep 26, 2014 at 11:54 AM, Mike Hammett via Af <af@afmug.com> wrote: Which distribution? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com _____ From: "Ty Featherling via Af" <af@afmug.com> To: af@afmug.com Sent: Thursday, September 25, 2014 2:42:31 PM Subject: Re: [AFMUG] Bash specially-crafted environment variables code injection attack Noob question but how can I easiest update my linux boxes to get the latest patches? -Ty On Thu, Sep 25, 2014 at 1:59 PM, Josh Reynolds via Af <af@afmug.com> wrote: Upgraded our systems at 6am yesterday for this. Also pulled the bash .deb out of debian-stable/security for our ubiquiti edgerouters. (I made on a post on the UBNT forum with the CVE info yesterday.) Side note: TONS of things are affected by this... Josh Reynolds, Chief Information Officer SPITwSPOTS, www.spitwspots.com On 09/25/2014 10:25 AM, Peter Kranz via Af wrote: PS.. This vulnerability can be exploited via HTTP/Apache attack vectors, so you need to patch any vulnerable system running Apache. Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 <tel:510-868-1614%20x100> Mobile: 510-207-0000 pkr...@unwiredltd.com -----Original Message----- From: Af [mailto:af-bounces+pkranz=unwiredltd....@afmug.com] On Behalf Of Matt via Af Sent: Thursday, September 25, 2014 10:27 AM To: af@afmug.com Subject: [AFMUG] Bash specially-crafted environment variables code injection attack Bash specially-crafted environment variables code injection attack https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925
