Security
Brief items
The National Strategy to Secure Cyberspace
[This article was contributed by Tom Owen]
The Friday release of the National Strategy to Secure Cyberspace may have been overshadowed by the recent departure of Richard Clarke, President Bush's Cybersecurity advisor. It certainly didn't get a big build up. But now we have the "final" version of what will doubtless be a continuously evolving strategy.The draft released in September generated apathy and dismissal after widespread unsourced reports of tech firms lobbying to remove references to insecure "out of the box" configurations and wireless hazards. The biggest change over the draft is external: the Department of Homeland Security (DHS) now exists, with a budget and a head, and by far the majority of the action items fall on it.
The strategic objective is clear:
as is the purpose of the document:
The core of the strategy is the five national priorities
- A security response system
- A threat & vulnerability reduction system
- A Security awareness and training program
- Security within government operations
- National and International security co-operation
Some consistent themes inform the discussion of all priorities:
- The threat is real: the US depends on the integrity of cyberspace, and that integrity can now be undone by enemies.
- Most of what's needed is outside the scope of Government: beyond protecting its own operations and the commons, the work has to be done by corporations, colleges and the public.
- Public and private can, must, work together
- Privacy and liberty must be protected. It's not that prominent, but it's a pleasant surprise to see it at all.
Regarding the called-for national security response system:
The plan appears to be mandating DHS to co-ordinate between Government agencies, and academic and private sector agents. Obvious candidates would include CERT, the AV vendors' labs, disaster recovery providers and perhaps operators like Bugtraq.
The challenge is twofold. Firstly, to co-ordinate their work on attacks and vulnerabilities, before and even -- using fax, conferencing and and voicemail -- during an attack, and secondly, to ensure that the private sector is using the resources created. It appears that there will be an effort to remove antitrust obstacles to this co-operation.
Responding to security incidents is important, but so is preventing those incidents before they happen. The strategy asks private and government agencies to communicate better to find and protect against potential problems. Even before the recent "Slammer" worm, others like Nimda and Code Red had made it clear that threats, once released, spread faster than fixes. So it is important to find and fix vulnerabilities before they are exploited.
One stand out point is a clear intention to use criminal justice more aggressively: this might be a good time to stop writing stupid viruses for fun. The strategy gets more specific here. Examples of the work planned include
- Improving infrastructure: the Commerce Deptartment's review of a national transition to IPv6 and the DHS's intention to bang heads together to get progress on securing DNS and BGP, together with longer term efforts to to add source address verification and secure out-of-band management to the Internet
- Securing plant and equipment control networks to exclude terrorists from air-traffic control, dams and chemical plants.
- Addressing software vulnerabilities: establishing a neutral clearinghouse, with, interestingly, a national policy defining appropriate vulnerability disclosure, central testing for patches to Government systems, and promotion of tools and best practice for patch distribution.
Then, there is the call for a national security awareness and training program. This priority addresses a slightly broader range than most. The traditional targets for security training: users, admins and developers, are there, but the plan goes further:
Getting these people trained is not going to be easy. School curricula, awareness programs and certification and the other plan items can reach professionals and users, but getting informed discussion between corporate policymakers at the country club will take something more -- there may be a role for the insurers here.
Of course, the government must also worry about cleaning up its own act, so it is not surprising to see internal security as an important part of this plan. The plan in this area is blandly conventional, revealing that government practice is no better than the private sector. One of the few mentions of a specific technology, wireless, occurs under this heading.
The last item (national and international security coordination) seems like a bland commitment to improve international co-operation, encouraging foreign countries to achieve effective criminal law and participate in information-sharing programs. But early on comes this jaw-dropper:
The strategy doesn't expand on this point, and responsibility for that action falls on no specific agency, but when it happens, it'll be on the evening news.
Given the source, the document as a whole is at least as good as could have been hoped. Part of the value comes from what's left out:
- Theres no hysteria about encryption or crackers
- No plan to wall off the US and unplug those nasty foreigners
- No dramatic legislative program
- No mandation or prohibition of specific technologies and vendors
High-level strategic planning can be used to hide a lot of vagueness and unreality, as the broad scope needed in the language and objectives makes it hard to visualise what is intended. This hasn't happened here. The Department of Homeland Security's interest in the network comes into clearer focus. Some of the organisations and networks which will protect cyberspace are making their first appearance here. And we can see that some people are asking the right questions.
February CRYPTO-GRAM Newsletter
Bruce Schneier's CRYPTO-GRAM newsletter for February is out. It looks at Matt Blaze's lock-picking disclosure (and the reaction to it), SQL Slammer worm notes, the importance of authentication, and more. "I'd rather have as much information as I can to make an informed decision about security. I'd rather have the information I need to pressure vendors to improve security. I don't want to live in a world where locksmiths can sell me a master key system that they know doesn't work or where the government can implement security measures without accountability."
New vulnerabilities
mailman: mailman 2.1 cross site scripting vulnerabilities
| Package(s): | mailman | CVE #(s): | |||||
| Created: | February 18, 2003 | Updated: | February 19, 2003 | ||||
| Description: | The email variable and the default error page in mailman 2.1 contains
cross site scripting vulnerabilities.
Read the the full advisory for the details. | ||||||
| Alerts: |
| ||||||
nethack: buffer overflow
| Package(s): | nethack, slashem, falconseye | CVE #(s): | CAN-2003-0358 CAN-2003-0359 | ||||||||||||||||||||
| Created: | February 18, 2003 | Updated: | July 15, 2003 | ||||||||||||||||||||
| Description: | Overflowing a buffer in nethack may lead to privilege escalation to games
uid.
Read the the full advisory for the details. Note that falconseye does not contain the file permission error CAN-2003-0359 which affected some other nethack packages. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
OpenSSL: plaintext exposure vulnerability
| Package(s): | openssl | CVE #(s): | CAN-2003-0078 | ||||||||||||||||||||||||||||||||||||
| Created: | February 19, 2003 | Updated: | March 6, 2003 | ||||||||||||||||||||||||||||||||||||
| Description: | A vulnerability has been found in OpenSSL that, given the right conditions, could lead to the exposure of transactions in plain text. This problem looks difficult to exploit (it requires a man-in-the-middle attack, among other things), but one can't be too sure, so the OpenSSL project has released versions 0.9.7a (with the fix and some new features) and 0.9.6i (with fixes only). See the announcement for details. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
pam_xauth: root exploit
| Package(s): | pam_xauth | CVE #(s): | CAN-2002-1160 | ||||||||||||
| Created: | February 13, 2003 | Updated: | July 10, 2003 | ||||||||||||
| Description: | The pam_xauth module is used to forward xauth information from user to user
in applications such as 'su'.
Andreas Beck discovered that versions of pam_xauth supplied with Red Hat Linux since version 7.1 would forward authorization information from the root account to unprivileged users. This could be used by a local attacker to gain access to an administrator's X session. In order to exploit this vulnerability, the attacker would have to get the administrator, as root, to use su to the account belonging to the attacker. | ||||||||||||||
| Alerts: |
| ||||||||||||||
php: arbitrary file access and code execution
| Package(s): | php, mod_php | CVE #(s): | |||||||||
| Created: | February 18, 2003 | Updated: | February 19, 2003 | ||||||||
| Description: | Kosmas Skiadopoulos discovered a serious security vulnerability [0] in the
CGI SAPI of PHP version 4.3.0. PHP [1] contains code for preventing direct
access to the CGI binary with configure option
"--enable-force-cgi-redirect" and php.ini option "cgi.force_redirect". In
PHP 4.3.0 there is a bug which renders these options useless. Please note
that this bug does NOT affect any of the other SAPI modules such as the
Apache or ISAPI modules.
Anyone with access to websites hosted on a web server which employs the CGI module may exploit this vulnerability to gain access to any file readable by the user under which the webserver runs. A remote attacker could also trick PHP into executing arbitrary PHP code if attacker is able to inject the code into files accessible by the CGI. This could be for example the web server access-logs.
References: | ||||||||||
| Alerts: |
| ||||||||||
syslinux: security issues in installer
| Package(s): | syslinux | CVE #(s): | |||||
| Created: | February 18, 2003 | Updated: | February 19, 2003 | ||||
| Description: | From the syslinux changelog:
"Security flaws have been found in the SYSLINUX installer when running setuid root. Rewrite the SYSLINUX installer so it uses mtools instead. It therefore now requires mtools (specifically mcopy and mattrib) to exist on your system, but it will not require root privileges and SHOULD NOT be setuid." | ||||||
| Alerts: |
| ||||||
util-linux: predictable mcookie results
| Package(s): | util-linux | CVE #(s): | |||||
| Created: | February 14, 2003 | Updated: | February 19, 2003 | ||||
| Description: | The util-linux package provides the mcookie utility, a tool for generating random cookies that can be used for X authentication. The util-linux packages that were distributed with Mandrake Linux 8.2 and 9.0 had a patch that made it use /dev/urandom instead of /dev/random, which resulted in the mcookie being more predictable than it would otherwise be. This patch has been removed in these updates, giving mcookie a better source of entropy and making the generated cookies less predictable. Thanks to Dirk Mueller for pointing this out. | ||||||
| Alerts: |
| ||||||
Resources
Egress filtering for a healthier Internet.
This issue of "Linux Security: Tips, Tricks, and Hackery" looks at egress filtering as a way of protecting the net against mass attacks.
Events
The First Honeyd Challenge
The first Honeyd Challenge has been announced along with the 0.5 release of the Honeyd virtual honeypot system. "The goal of this challenge is to develop interesting feature additions to Honeyd. Possible improvements are forensic analysis tools for Honeyd log files, passive fingerprinting of connections, realistic routing topologies, etc."
ACNS 2003
The first MiAn International Conference on Applied Cryptography and Network Security will be held October 16 to 19 in Kunming, China. The submission deadline is May 1 for those who would like to present there.NSPW 2003 Call For Papers
The New Security Paradigms Workshop 2003 will be held August 18 to 21 in Ascona, Switzerland. The Call For Papers has gone out, with a submission deadline of April 4.
Page editor: Jonathan Corbet
Next page:
Kernel development>>