Re: [AFMUG] Bash specially-craftedenvironment variablescodeinjection attack
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: Sunda
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 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 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
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 <http://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 <mailto: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
Re: [AFMUG] Bash specially-craftedenvironment variablescodeinjection attack
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 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
