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 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 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 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 firstyeah, 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 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
Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack
Its times like these I wish I had learned to code. i would write a malware to infect all the connected devices, refrigerators, light bulbs, cameras, well pump monitors, all of them, just sitting behind consumer grade routers infected, waiting, calling home now and then to get their updates, helping to build a database of what I have and how to exploit it. Then one day I would pull the trigger, penises on every computer screen in the world. It would be beautiful, I would have a tear in my eye. On Sun, Sep 28, 2014 at 8:55 PM, Ken Hohhof via Af wrote: > 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 > *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 > > *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
Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack
You're right, yum updates are probably a problem for those pesky RedHat/Centos distros. Move to debian :P Josh Reynolds, Chief Information Officer SPITwSPOTS, www.spitwspots.com <http://www.spitwspots.com> On 09/28/2014 05:55 PM, Ken Hohhof via Af wrote: 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 firstyeah, 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 <mailto:af@afmug.com
Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack
I’ll bet you have a favorite brand of gasoline too. From: Josh Reynolds via Af Sent: Sunday, September 28, 2014 10:30 PM To: af@afmug.com Subject: Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack You're right, yum updates are probably a problem for those pesky RedHat/Centos distros. Move to debian :P Josh Reynolds, Chief Information Officer SPITwSPOTS, www.spitwspots.com On 09/28/2014 05:55 PM, Ken Hohhof via Af wrote: 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 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 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 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 firstyeah, 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
Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack
Nope, I just use whatever works :) Josh Reynolds, Chief Information Officer SPITwSPOTS, www.spitwspots.com <http://www.spitwspots.com> On 09/28/2014 08:14 PM, Ken Hohhof via Af wrote: I’ll bet you have a favorite brand of gasoline too. *From:* Josh Reynolds via Af <mailto:af@afmug.com> *Sent:* Sunday, September 28, 2014 10:30 PM *To:* af@afmug.com <mailto:af@afmug.com> *Subject:* Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack You're right, yum updates are probably a problem for those pesky RedHat/Centos distros. Move to debian :P Josh Reynolds, Chief Information Officer SPITwSPOTS, www.spitwspots.com <http://www.spitwspots.com> On 09/28/2014 05:55 PM, Ken Hohhof via Af wrote: 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 <mailto: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 <mailto: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 <mailto: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@afmu
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.
Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack
Oh, and you mentioned a BlueQuartz server. Looks like there are options, including: http://www.blueonyx.it/, which seems to include migrating from BlueQuartz. 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 firstyeah, 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
Re: [AFMUG] Bash specially-crafted environment variablescodeinjection attack
Only time I have had issues with yum update is when there are third party repositories. On Sun, Sep 28, 2014 at 10:30 PM, Josh Reynolds via Af wrote: > You're right, yum updates are probably a problem for those pesky > RedHat/Centos distros. > > Move to debian :P > > Josh Reynolds, Chief Information Officer > SPITwSPOTS, www.spitwspots.com > > On 09/28/2014 05:55 PM, Ken Hohhof via Af wrote: > > 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 > 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 > > 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 > >
Re: [AFMUG] Bash specially-crafted environment 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<mailto: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
