|
Brought to you by:
Suppliers of:
|
|
|
| |
| The U.S. Defense Information Systems Agency (DISA) publishes Security Readiness Review scripts (SRRs) to ensure systems and software meet security baselines required by the Department of Defense. Unprivileged local users can obtain root access on Unix systems where the DISA SRR scripts are run. |
| |
Credit:
The information has been provided by Frank Stuart.
|
| |
Vulnerable Systems:
* U.S. Defense Information Systems Agency (DISA) Security Unix Readiness Review scripts SRRs
This vulnerability report applies to the current (October 15, 2009) Unix SRR. It was tested on Solaris/x86 only but is expected to be applicable to all Unix/Linux versions supported by the software. DISA publishes SRR updates approximately once every two months and it is believed that many previous versions are also vulnerable. DISA also publishes SRR scripts for other software/operating systems (e.g. Windows Vista, Oracle database, Open VMS). These could contain similar vulnerabilities (I haven't gone looking for them).
The Unix SRR must be run as root and one of the first things it does is a global find from /. It then runs a series of modular scripts looking for specific vulnerabilities or Potential Discrepancy Items (PDIs).
Some of the PDIs include checks for specific versions of software. Unfortunately, in some cases, it runs these unknown/untrusted/suspect programs as root in an attempt to determine the version of the software it found.
The following programs are known to be run:
* java -version
* openssl version
* php -v
* snort -V
* tshark -v
* vncserver -help
* wireshark -v
An attacker can, for example, create an executable or shell script with a root kit installer called "php", anywhere in the filesystem. When the SRR is run, it will execute "php -v" as root and the root kit will be installed. A clever attacker could print out the "good" version string of php and silently install the root kit. A very clever attacker could do the above and then replace the fake php with the real one, covering his tracks.
Workaround
Do not run the DISA Unix SRR script until a fix is available.
The publisher should do a comprehensive review of their software to make sure they eliminate all cases where they execute unknown/untrusted/suspect code as root. Ideally, they should not execute such code at all, even as an unprivileged user. A better approach would be to use "strings" or something similar to look for a signature to try to determine the version of the software it found.
|
| Subject:
|
Interesting but... |
Date: |
13 Dec. 2009 |
| From: |
kilr0ylive.com |
Ok so this is possible, but there still remains the need to initially access the server in question, subvert any running HIDS, replace the file undetected and presumably do all this without already having root privileges. Sure this is potentially a hole in the SRR script, and possibly the solution is not to run the version checking logic with root privileges. None of this addresses the fact that the expected nefarious individual must already have access to the protected system.
What else is there to this exploit that makes the author feel the Unix SRR is the primary culprit sans other likely detectable action? Defense in Depth will likely prevent any problems, especially if the practitioner is serious about their layered security approach and is consistently monitoring activity a prescribed necessity in any network wherein the SRR applies. |
|
| Subject:
|
not bad |
Date: |
3 Mar. 2010 |
| From: |
sniper |
| this effort is not bad at all considering it could have been much worse like the live NASA.gov multiple server vulnerabilities posted at pinoysecurity... |
|
|
|
|
|
|
