DISA updates don't eliminate vulnerability in Unix security review scripts, expert says
Connecting state and local government leaders
Unix Readiness Review Scripts that ran untrusted applications with root privileges, leaving computers vulnerable to malicious code, have been updated by DISA. However, the analyst who discovered the vulnerability says it's still there.
The Defense Information Systems Agency (DISA) has updated the Security Readiness Review (SSR) scripts used to evaluate Unix computers in an attempt to correct a vulnerability that could allow untrusted applications to install malicious software.
But the analyst who discovered the vulnerability in September says the problem persists in the new scripts.
Security analyst Frank Stuart notified DISA and the U.S. Computer Emergency Readiness Team (US-CERT) early Dec. 9 about the continuing issue.
“Unfortunately, although some changes were made it is still vulnerable to the issue described in CVE-2009-4211,” Stuart wrote, referring to the Common Vulnerabilities and Exposures (CVE) list. “The CVE should be updated to reflect that the December 2009 version is also vulnerable. The script should be re-evaluated to remove any invocations of untrusted programs (especially any done as root). Users should continue to avoid running the Unix SRR script until a fixed version is available.”
DISA, which had posted updated scripts earlier in the day, has temporarily removed them again, saying that they are under review.
Use of the scripts is required for military and many Defense Department contractor systems to verify compliance with DOD security implementation guidelines. But because of a vulnerability reported in September to US-CERT, the DISA Field Security Operation division on Dec. 5 warned users not to run the scripts until they were corrected.
DISA develops Security Technical Implementation Guides (STIGs) for DOD users to standardize the secure configuration and operations of hardware and software through the life cycle of the device or program. DISA also publishes SRR scripts to verify STIG compliance for a variety of operating systems. The scripts are run as root — with administrative privileges — on the machine being reviewed. During the review, the script searches for Potential Discrepancy Items that could create vulnerabilities, and checks the release version of applications. In order to check the version of applications including Java, OpenSSL, PHP, Snort, Tshark, VNCserver, and Wireshark, the scripts run the application.
If an attacker is able to put into the file system a malicious file labeled as one of these programs, it could install malicious software such as a root kit on the computer when executed by the SRR script, and cover its tracks by telling the script that the proper version was found and that everything is all right.
Following the second removal of the SRR scripts from the Web site, DISA issued a statement.
“The Unix scripts in question were a residual part of an earlier tool set that did not go through the same rigorous security testing as the more recent [Information Assurance] tools,” said William Keely, chief of DISA’s Field Security Operations (FSO) division. “We are reviewing all of the older tool sets to ensure that they all exceed our current security requirements. When the review is complete we will repost [the scripts].”
Jamie Adams, senior engineer with Trusted Computer Solutions who has been following this issue, likened the practice of running an application with administrative privileges in order to determine its version to putting your hand on a stove to see if it is turned on. DISA has been using this technique in the SRR scripts for years, he said.
Although scripts have been modified to eliminate the vulnerability, fundamental changes in the approach are needed, Adams said. Instead of running the application, the scripts should look for metadata and ask questions about the application, “doing all the things except execute it,” he said.
According to notes from the Field Security Operation division, the UNIX SRR Scripts support Solaris 8 through Solaris 10 (unzoned); HP-UX 11.0 and HP-UX 11i-v1/v2 and Red Hat Enterprise Linux versions 3 and 4.
“Vendor versions not explicitly listed are considered as ‘other’ and are not supported by the scripts,” FSO states. “FSO cannot guarantee the accuracy of these scripts if they are used on ‘other’ UNIX versions. For any/all unsupported vendor OS versions, a Checklist Manual Review should be performed.”