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 <af@afmug.com> 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 <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 <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
> <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 <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 <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
>
> Mobile: 510-207-0000
>
> pkr...@unwiredltd.com
>
>
>
> -----Original Message-----
>
> From: Af [mailto:af-bounces+pkranz=unwiredltd....@afmug.com 
> <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
>
>
>



-- 
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

Reply via email to