[Tfug] Do we need a new bash?

[Mr Brevity]

Hi Harry,

On 9/25/2014 11:42 PM, Harry McGregor wrote:
> This vulnerability really does NOT apply to "things".

I wouldn't be so quick to assume that.  The universe of "things" is REALLY
REALLY BIG!

> No embedded dev will waste flash memory space using DASH let alone BASH.

Again, there are lots of embedded devices besides routers and thermostats.
Many are NOT constrained by the cost of FLASH.  Others use NAND FLASH and
decompress an image at boot time (into RAM).

The problem will be:
- identifying vulnerable products (what if a product is no longer "current"?
   who is obligated to research an "old implementation"?)
- locating all instances of those products (good record keeping)
- getting a workable path in a deliverable form (not all products are easily
   updated)

> Many/most Debian and Ubuntu environments use DASH as /bin/sh and are NOT
> remotely vulnerable to this via Apache, etc, even though BASH is still installed.
>
> Almost every embedded linux device on the planet uses busybox to provide
> /bin/sh, and most other GNUish type utils.
>
> dd-wrt example:
>
> root at DD-WRT:~# which sh
> /bin/sh
> root at DD-WRT:~# ls -l /bin/sh
> lrwxrwxrwx    1 root     root             7 Dec  8  2011 /bin/sh -> busybox
> root at DD-WRT:~# ls -l /bin/busybox
> -rwxr-xr-x    1 root     root        416355 Dec  8  2011 /bin/busybox

I disagree.  You're thinking solely of consumer appliances (cost sensitive).

Do you really think the gas pump at your local filling station is concerned
about a few KILOBYTES of FLASH?  Or the controller at the well head that
pumps groundwater, treats it with chlorine and pushes it right out into your
neighborhood water main?  (ignore the "smart grid" and other aspects of
national infrastructure for the time being...)

The problem with FOSS (and any other software treated as "black boxes")
is that folks have no idea what's inside, how they work, how they can
be exploited, etc.  It looks like you're getting something (a working piece
of code) for no investment (development hours).  Don't look a gift horse in
the mouth!  :>

With all the alleged "eyes" that are (supposedly) looking at these OPEN
sources, one wonders how these sorts of bugs can sit there in plain sight?
(perhaps the eyes aren't "looking very hard")  At least you can claim
MS's problems are related to a LACK of "sufficient eyes" on the sources...

> Is this a major vulnerability, sure, will there be a very long tail on it due
> to some embedded devices having it exposed, sure, will it be a huge issue in
> the embedded world, no.

That's *my* world.  I suspect there are a lot of my colleagues looking at
their source trees -- maybe not for "bash.c" but, rather, any indication
that they've made the same mistake in implementing some aspect of their
system -- leaving a mechanism that allows "payload" ot be ferried across
a security/protection barrier.

> The worst thing from this will be the same as heartbleed, every non-technical
> manager type jumping up and down that this has to get fixed, even to the point
> of shutting systems down until they can get fixed... when the systems are
> test/internal systems that can only be reached by going through bastion hosts
> on the internal network...

+42

Just another example of people not knowing what they have.  How many shops
can accurately tell you what software they have on all their workstations
let alone EVERY device in the organization?  Why are there still web sites
that are vulnerable to HeartBleed (do these folks live in a cave?  are
they running some unique OS/distro for which a patch has NOT been released?
Or, do they not have the resources to bother fixing the servers??)

> If someone is exploiting this from within a very limited access part of your
> network, you have bigger problems.

Apparently, some exploits have already wormed their way past firewalls
(e.g., through web servers).

I don't imagine we'll hear of any real "victims" as no one wants the
publicity of being caught like this (we hear about Target, Home Depot, etc.
because they *have to* notify CC customers of the potential exposure; I'm
sure there are lots of other "losses" that never get discussed outside the
Board Room)