This post is more than 5 years old
4 Posts
0
88747
GNU Bash Environment Variable Handling Code Injection (Shellshock) idrac7 fw 1.57.57
Hi
When doing a Nessus scan today i get a critical security vulnerability when scanning our only idrac 7 system on our network. Nessus says that the vulnerability is confirmed. If this is a real vulnerability a patch must be released asap.
The idrac version is 1.57.57
Nessus plugin id: 77829
Description
The remote web server is affected by a remote code execution vulnerability due to an error in the Bash shell running on the remote host. A remote, unauthenticated attacker can execute arbitrary code on the remote host by sending a specially crafted request to a CGI script that passes environment variables.
Output
Nessus was able to verify the issue exists using the following request : GET / HTTP/1.1 Host: 192.168.20.3 Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1 Accept-Language: en Connection: Keep-Alive User-Agent: () { ignored; }; /bin/sleep 10; Pragma: no-cache Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* This produced the following output : ------------------------------ snip ------------------------------ The request produced a wait of 30 seconds ------------------------------ snip ------------------------------
surfarn
4 Posts
0
October 10th, 2014 04:00
I have done 2 rescans and i have not been able to reproduce this problem, so I think that nessus reported a false positive the first time the scan run.
DELL-Chris H
Moderator
Moderator
•
8.4K Posts
0
October 7th, 2014 09:00
Surfarn,
The issue you are seeing was seen upon the OpenSSL release on June 5. The vulnerabilities that are being shown are not currently using the affected modules in OpenSSL, However, due to the report of the vulnerabilities, Dell is going to go ahead and put out an update so it won't register that there is an issue. Any further.
Below is a copy of the release on June5th that addresses the issue.
/cfs-file/__key/communityserver-discussions-components-files/177/2021.Dell-Response-to-Latest-OpenSSL-Security-Advisory_5F00_05_5F00_June_5F00_2014_5F00_final.pdf
Let me know if this helps answer your question.
ray.corbin
1 Message
0
October 7th, 2014 11:00
I'm seeing the same thing from scans. This is specifically checking for shellshock CVE-2014-6271.
Kermit Short
2 Posts
0
October 7th, 2014 11:00
So neither PowerEdge servers nor iDRAC subsystems are being acknowledged on the current "affected product" tracking site:
Shellshock Bash Bug Remediation
<ADMIN NOTE: Broken link has been removed from this post by Dell>
The Chief Security Officer for Dell Global Security has a post on his blog:
Shellshock Bash Bug Vulnerability Alert
He's merely acknowledging that Dell products may be affected and points to the above link for details.
The comments indicate that Dell is still "actively investigating" and are updating information on the first link I posted above. Essentially, it looks like they have not gotten around to the iDRAC stuff yet, and are not saying anything conclusive about it. These OpenSSL bugs are frustrating in that so much technology utilizes the suite, and so it takes a very long time for changes to propagate.
-Kermit Short
Kermit Short
2 Posts
0
October 7th, 2014 11:00
Unfortunately, the Document you reference does not speak to the actual CVE that NESSUS is scanning for. The repsonse from Dell is in regards to:
CVE-2014-0224
CVE-2014-0221
CVE-2014-0195
CVE-2014-0198
CVE-2010-5298
CVE-2014-3470
CVE-2014-0076
The CVE that is showing up on NESSUS is CVE-2014-6271. If, indeed, the OpenSSL used by iDRAC 7 is reporting a false positive, we need a statement from an authorized Dell source stating such, otherwise Dell needs to fast track a hot fix or patch.
At this time I do not currently consider this particular CVE mitigated by any of the available patches, nor do I have an authortitative response from Dell.
-Kermit Short
surfarn
4 Posts
0
October 8th, 2014 02:00
The Shellshock vulnerability was disclosed the 24 september and i dont think it is related to the openssl vulnerability that you are talking about. This is a threat to the web server, not the ssl implementation
DELL-Chris H
Moderator
Moderator
•
8.4K Posts
0
October 8th, 2014 07:00
Sorry for the misunderstanding. That was the incorrect link.
As of this morning the testing is complete and the Drac 5, 7 and, 8 and are not being affected by the vulnerabilities. I expect the iDrac6 will be on the list shortly as well. As Kermit pointed out the list of NON effect devices can be found here - <ADMIN NOTE: Broken link has been removed from this post by Dell>
goslackware
1 Message
0
October 8th, 2014 07:00
surfarn,
You are correct that "Dell-Chris H" replied non-applicable link.
However, I tried to reproduce your results, but was unsuccessful.
The nessus command you're using is quite vague, as it is only verifying if a reply has a delay of 30 seconds.
There are a number of reasons for a delayed response from an iDrac, so for this case it seems to be a false positive.
Please do check further though.
I suggest to ssh into your idrac, run "racadm racreset soft", verify that it comes back online, then run the nesses scan 5 more times.
On a side note, from the ssh prompt "/bin/sleep" is not a valid command, but it could be possible from another shell.
(I don't work for dell so I wouldn't know that detail for certain.)
This page has been updated (10/8/2014 9AM EDT):
http://www.dell.com/learn/us/en/04/campaigns/shellshock-remediation
---
Products NOT Affected (sniplet below):
DRAC5 (Dell Remote Access Controller) All
iDRAC7 (integrated Dell Remote Access Controller) All
iDRAC8 (integrated Dell Remote Access Controller) All
Dell Lifecycle Controller All
Dell Lifecycle Controller Integration (DLCI) for Microsoft System Center Virtual Machine Manager (SCVMM) All
Dell Chassis Management Controller (CMC) All
---
Notice that iDrac6 hasn't been listed if vulnerable or not yet...
DELL-Doug I
11 Posts
0
October 10th, 2014 09:00
@surfarn
The Nessus test is liable to produce false positives. It attempts to run a command, “sleep 10”. It then checks for the response taking more than 30 seconds. The problem with this test is that anything that causes the request to take longer can be counted as a positive. The DRAC is a very slow processor by modern standards, and can take a while to respond for a number of other reasons.
Internally, we have tested this exact exploit and changed the “sleep 10” to a “touch /tmp/EXPLOIT”, which should produce the observable result of creating the file /tmp/EXPLOIT. Running the exploit attempt and then logging into debugging mode, we can verify that we are in no way affected by this exploit. We have also run code audits to ensure that nowhere in our HTTP stack are we ever running bash, so it is simply not possible to exploit the shellshock vulnerability using any HTTP request.
Hope this helps.
Doug Iler, iDRAC Product Manager