[Info-vax] And now bash has a vulnerability

[John E. Malmberg]

On 9/25/2014 7:43 AM, RobertsonEricW wrote:
> On Thursday, September 25, 2014 8:08:13 AM UTC-4, hb wrote:
>> On 09/25/2014 01:32 PM, RobertsonEricW wrote:
>>> Thanks for posting this information! OpenVMS bash is currently built using
>> Bash 4.3.24. I am assuming that this contains the incomplete fix. But I will
>> keep an eye out for any information on the Bash development site.

1. Yes GNV Bash 4.3.24 is vulnerable, so do not hack your web server to 
use it to run CGI scripts.

2. There is a GNU Bash 4.3.25 patch, but it does not completely fix the 
issue.  I have not tried building bash with it on VMS, and do not plan to.

3. The complete fix is expected to be in the Bash 4.3.26 patch.  When 
that becomes available, depending my schedule, I will look at generating 
new kits, mainly so that people do not have to be concerned.

4. Currently none of the known network facing products on VMS are aware 
of the GNV Bash shell or call it, and most probably can not be 
configured to call it in a way that will allow an exploit on VMS.

When GNV Bash is invoked from DCL, it ignores the logical names and DCL 
symbols that other C programs would treat as environment variables.

This includes launching GNV bash from LIB$SPAWN() as Perl normally does.

It is also likely that you can not do this exploit on VMS from a C 
program using "system()" or "popen()", but I have not done any tests to 
confirm or bust that theory, but these both appear to just call 
LIB$SPAWN() with out passing the environment array.

This exploit can not be triggered from a C program that does "execlp()", 
"execl()", "execvp()", or "execv()" as they do not pass the environment 
array to the child.

This leaves programs that call "execle()" or "execve()" as being able to 
launch bash in a way to exploit the vulnerability on VMS.

Regards,
-John
wb8tyw at qsl.network
Personal Opinion Only