"Shellshock" bash bug

[Colin Law]

On 27 September 2014 17:05, Rashkae <ubuntu at tigershaunt.com> wrote:
> On 14-09-27 11:39 AM, Colin Law wrote:
>>
>> That is an interesting idea that I had not considered. Is that
>> intrinsically safer than ssh using keys? Also it occurs to me that the next
>> vulnerability found might be in VPN, who knows. Cheers Colin
>
>
> I think it's a silly suggestion.. adding a vpn only adds much complexity.. I
> rather only use ssh wherever I can get away with it. (including using tcp
> tunnels where I only need a few ports opened to the client.)
>
> As far as this bash bug goes, AFAIK, it is not exploitable over ssh, unless
> you are also using ssh in conjunction with a config that attempts to limit
> what can be done over ssh, (examples: rsh shell, or specially crafted public
> keys that run only the specified command.  I haven verified if these can be
> worked around with the vulnerable bash, but if ssh is being used only by
> users with who can login to a shell, it doesn't matter, since they can
> already execute any command without having to use environment variables.)
>
> But I'm only complicating the discussion. On systems without untrusted ssh
> users, the issue is moot.  If ssh port is the only access from internet,
> you're fine.
>
> Caveat: it's bad practice to leave systems that are exploitable from inside
> the network.  In theory, a compromise of an otherwise inconsequential and
> ignored device inside your network can allow an attacker to probe other
> computers from inside the firewall.

OK, thanks for that.  Good point about not having exploitable systems
inside in case another device becomes compromised.  In my particular
case the only open port in the network is ssh into this server.  Also
since, as I mentioned in an earlier post, I have recompiled bash with
the patches and so have closed the loophole.  The whole discussion has
been very informative though, I have certainly learnt some useful
things.

Cheers

Colin