DISA updates don't eliminate vulnerability in Unix security review scripts, expert says

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.”

About the Author

William Jackson is a Maryland-based freelance writer.

inside gcn

  • development (Shutterstock.com)

    Developing low-code apps for city services

Reader Comments

Thu, Dec 17, 2009 General 'Buck' Turgidson

NIST - Computer Security Division has release a bulletin. Warning: Do not run the SRR toolkit if you have downloaded, and plan to install a UNIX image from torrent site on a DoD server.

Thu, Dec 17, 2009

From the labeled IAO: I find it funny that a single person labeled a 'Security Analyst' can cause this "OMG the sky is falling attitude". The programs listed run as root, therefore the system would already be corrupted. What part didn't you understand that the executable binaries are checked against an existing MD5 signature. And BTW the issue is with the UNIX SRR toolkit, Windows platforms are checked by the Gold Disk, Database's are checked manually or by other automated tools.

Wed, Dec 16, 2009 Brian

I find it unbelievable that someone labeled an IAO thinks that the SRR is not at fault. The system explicitly runs executable files without validating them. If Microsoft or Oracle were to do that, DISA would be all over that along with the rest of the security world.

Wed, Dec 16, 2009

As a DISA security IAO I believe the security problem lies with the external software that was installed on the server, the lack of Virus scanning the software prior to installation or if the server was hacked, the lack of a proper firewall would have stopped the issue. Any DoD software installed must come from an approved source. Antivirus software is installed on all servers prior to network approval. Tripwire or other products that keep a baseline of the MD5 signature are also ran which alerts Security personnel to a possible compromise. Using the SRR toolkit as a skapegoat instead of using common security practices is a farce.

Mon, Dec 14, 2009

The SRR really needs to be looked at in deail. Currently it reports a number of bogus issues. One main example is complaining that Solaris 10 does not have an /etc/notrouter file. This file serves no purpose in Solaris 10 but the SRRs still report it as a finding. This has been the case for quite some time.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group