In-Depth
Security Briefs: JavaScript Worm, IBM DB2 Vulnerability, NIST Performance Metrics
Dealing with an e-mail worm targeting a Web application, and a vulnerability in IBM DB2. Plus, how to create a performance metrics program.
Symantec Details JavaScript Worm
The typical worm arrives via e-mail as an attachment a user must open and run on their PC.
Now there’s something different: a JavaScript worm recently discovered in the wild and dubbed Yamanner, which exploited a vulnerability in Yahoo’s Web-based e-mail application.
Yahoo has since patched the vulnerability. “We have taken steps to resolve the issue and protect our users from further attacks of this worm,” said Yahoo spokeswoman Kelley Podboy in a statement. She also noted the fix “requires no additional action on the part of the user.”
Yet with the growth in Web applications, including a recently released online spreadsheet application from Google, this type of JavaScript worm—targeting an online application which uses JavaScript to improve the user experience—is an interesting development. “This worm is a twist on the traditional mass-mailing worms that we have seen in recent years,” notes Dave Cole, a director at Symantec. “Unlike its predecessors, which would require the user to open an attachment in order to launch and propagate,” Yamanner instead utilized “a previously unknown security hole in the Yahoo Web mail program,” while also harvesting additional “user information for possible future attacks.”
According to Symantec, while Yahoo typically blocks scripts from its e-mail servers, the worm exploited “a vulnerability that enables scripts embedded in HTML e-mails to be run by the user’s browser.” When a user opened an e-mail infected by the worm, it could send itself to everyone on the user’s Yahoo e-mail contacts list.
Vulnerability: IBM DB2 Database
Imperva, a data security vendor, announced it discovered a critical buffer-overrun vulnerability in IBM DB2 version 8 databases. In a statement, Imperva says this flaw “enables any attacker with network access to the database server to take down or even run arbitrary code on the server’s machine.”
IBM says the flaw is a “buffer overflow condition” on the database server which arises “because of [a] bad connect request [which] could cause memory corruption and crash the instance.” In particular, “a malicious ‘connect’ or ‘attach’ request sent to a DB2 server may cause a buffer overflow and instance crash, resulting in a denial of service.” The flaw affects all versions of DB2 version 8.
The flaw can be exploited without attackers needing database credentials, and wouldn’t necessarily leave clues. “Since this is a network-level flaw, attacks elude DB2’s built-in auditing mechanism,” notes Imperva.
To fix the flaw, IBM released version 8 FixPak 12 for DB2, and it recommends users upgrade immediately. If that’s not feasible, one workaround, it says, is to “disable or restrict remote access to the database server.” Another workaround is to “disable the DB2 TCP/IP listener if not required,” or to “use a firewall to restrict connections to the DB2 TCP/IP listener port.”
NIST Drafts Performance Metrics
How do you gauge the success or failure of your security program? The answer: by generating security effectiveness metrics.
For help, look to the “Guide for Developing Performance Metrics for Information Security” (Special Publication 800-80), recently released in draft form by the Computer Security Division of the U.S. National Institute for Standards and Technology (NIST).
According to NIST, “the methodology links information security program performance to agency performance.” Though the guide is intended for government agencies, many private and public companies adapt aspects of the NIST 800-series publications for their own information security practices.
Of course, organizations can’t just generate metrics. They must first identify what security data to track and create a baseline of current performance. Then they’ll require some strategic-level thinking to determine desired performance criteria.
Note this NIST report bases its performance metrics on the security controls detailed in “Recommended Security Controls for Federal Information Systems” (NIST SP 800-53). In particular, the guide “provides templates, including at least one candidate metric for each of the security control families described in NIST SP 800-53.”
Related Articles:
About the Author
Mathew Schwartz is a Contributing Editor for Enterprise Systems and is its Security Strategies column, as well as being a long-time contributor to the company's print publications. Mr. Schwartz is also a security and technology freelance writer.