Eliezer,

If we all lived in a perfect world like you're describing then there would never be any security vulnerability, and the letters CVE would have no meaning.

We don't live in that world.

There is no point someone scrutinizing every single line of code of something like OpenSSH just to see if there's a potential for it being used to trigger a vulnerability in a component so core as Bash.�� Even if they come back and say that there's no way it could be abused, there'll also be some level of configuration that breaks their presumptions (eg, maybe they decide that OpenSSH isn't vulnerable, but it calls some other program, which then calls another program, which uses bash.�� This is *very* likely once you start to think about PAM modules which OpenSSH has no direct control over.).

If you want to be safe, there's only one option here - update Bash.�� Well, maybe two options, but the second involves wire cutters.

You can like that answer or you can not like it - but in the world we live in, it's the only valid answer.

�� Scott

On Sat, Sep 27, 2014 at 3:01 PM, Eliezer Croitoru <eliezer@ngtech.co.il> wrote:

Well Volker I am pretty sure I understand the basic nature of the CVEs.. both rounds.

I also do understand that real threats will not be disclosed easily.
What I do expect is that for main distributions to state the basics about a default server installation vulnerability throw telnet\ssh\non_root_user_shell etc.
(OpenBSD should basically also be vulnerable to this CVEs but I assume that default installation mitigates the issue by other means)

Since the vulnerability is out there for years...(what year bash 1.X was released??)
I am pretty sure that efforts to fix it are there for some time and now it is maybe the time which the fix is already ready.
It might be true or not but it is sure right to fix something now.

Also if until now many systems was not compromised by this CVEs it is possible that default system installations are not affected by it.

I am not talking about admins that do not make sure that their scripts are not compromised or running "curl some_address|bash" since these are already vulnerable by intention or misunderstanding.
But for example if sshd by default is compromising the system by allowing injection of variables with root access to the system it might be nothing that bash should handle by default.
sshd for example should not allow the existence of "function injection" which is a much higher priority then actually patching bash.

If an admin wrote a cgi script that allows injection of functions into the bash environment then the cgi script should be fixed...
If the issue is the mod_cgi interface itself allowing all sort of stuff it is not 100% bash fault.

This issue is almost the same as php or other scripts that quotes a variable straight into a sql query and not using the "values" and "?"(question marks) to restrict the variables into a specific scope.

>From my point of view the php script should be fixed to prevent the sql injection rather then patching MySQL or any others.

All The Bests,
Eliezer

On 09/28/2014 12:22 AM, Volker Kuhlmann wrote:

Tough, your problem. Ditto with firmware for stuff from vendors which
don't know you any more.

Please keep on searching the Internet for more cases and explanations[1]
for why it was a good idea to patch yesterday. Or trust people like
Scott. What does a CVE rating of 10/10 mean?

Btw CVE-2014-6271 was just round one. See CVE-2014-7169 for round two!

HTH,

Volker

[1] There was some elaboration here:
http://lists.canterbury.ac.nz/pipermail/linux-users/

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog