Security
Brief items
Peer to Peer Freedom of Speech
One necessary precondition for true freedom of speech is a way to communicate that does not identify the speaker or the listener. Several projects are working to provide that ability through peer-to-peer networking protocols that use cryptography to enable this kind of communication: Freenet, Entropy, and GNUnet. The goals of these projects are quite similar, to provide for the free exchange of ideas while thwarting any attempts to censor the information or punish the participants.The basic framework for each of these networks is a decentralized, peer-to-peer communications model where a node in the network talks to some number of other nodes, sending requests to these peer nodes and handling requests that come from them. The messages sent between nodes are encrypted using a session key that has been negotiated between the nodes using public key encryption. This encryption should be sufficient to deny a 'man in the middle' from determining anything useful about the traffic (other than its existence).
When a node sends a request to one of its peers, there is no reason to assume that the request actually originated on that node as nodes will forward requests that they receive, but cannot satisfy. Any response that is generated to a node is likewise not necessarily ultimately bound for that node and could be the response to a request that was forwarded by the node. With a sufficient number of nodes and amount of traffic, no analysis of the traffic to or from nodes will reveal the true source and destinations of the requests. This stands in stark contrast to the more common peer-to-peer networks where, once the content is found, a direct connection is made from the destination to the source to retrieve the content.
Each node that fully participates in the network provides some local storage for information in the network and can immediately satisfy requests for any data that it has stored locally. In order to provide deniability for the operators of these nodes, this data is encrypted and the operators are unable to determine what content actually resides on their node at any given time. Cryptographic hash functions on the file contents are typically used to identify particular files that have been inserted into the network. These identifiers are not particularly user friendly - for instance a copy of Kevin Mitnick's book The Art of Deception can be found in the Entropy network using the identifier:
SSK@zpxOK~ounTzoDwJKguoUHib8G7sBCMA/ArtOfDeception//To make the system easier to use, various network users have put together directories of content to help navigation.
The popularity of a file governs how long it stays in the network and how often it is replicated. Each of the networks has limits on the amount of storage available to it (based on the number of active nodes and the amount of storage allocated to the nodes by each operator) and must sometimes prune content when new content is added. GNUnet tries to overcome the problem of 'freeloaders' (nodes that request content but do not serve any) by adding an 'economic' layer to its network. Each node keeps track of its 'opinion' of the other nodes that it has talked to; nodes that satisfy requests have a better reputation and will be treated preferentially under higher network loads.
Both Freenet and Entropy provide an HTTP proxy that allows the use of standard web browsers as clients to view some of the content on the network. Entropy also adopted the Freenet Client Protocol so that all of the client applications originally written for Freenet will work with Entropy as well. Frost is one of the most widely used clients and provides file sharing and message board functionality. GNUnet appears to mainly use command line tools, though gnunet-gtk provides a graphical front-end.
Security is clearly taking precedence over performance, as it should, but this causes the user experience browsing Freenet or Entropy (at least) to be fairly frustrating. Sites can take tens of minutes to load or fail to load altogether, presumably because the information has either dropped out of the network or any sites that contain the information are currently offline or too far away (in network, not geographic, terms).
Critics of these projects complain that they could be used by criminals for nefarious purposes and, obviously, that is true. There is no way to provide for anonymous communication that cannot be abused and these projects have decided that freedom of communication is more important than stopping illegal uses. In the end, these networks are tools like computers or phones and they can be used for good or for ill. It would be impossible and a serious affront to liberty to outlaw all tools that could be used to commit a crime.
Security reports
Savanna.gnu.org compromised too
If you go to Savannah, the GNU project's development server, you'll find a note stating that it, too, has been broken into. "The compromise seems to be of the same nature as the recent attacks on Debian project servers; the attacker seemed to operate identically." Savannah will be down until (at least) December 5. (Thanks to "sdoyon", who posted the news in an LWN comment).
New vulnerabilities
bind: cache poisoning
Package(s): | bind | CVE #(s): | CAN-2003-0914 | ||||||||||||||||||||||||
Created: | November 26, 2003 | Updated: | February 19, 2004 | ||||||||||||||||||||||||
Description: | A cache poisoning vulnerability in BIND may be exploited causing a temporary denial of service until the bad record expires from the cache. | ||||||||||||||||||||||||||
Alerts: |
|
GnuPG: ElGamal signing keys compromised
Package(s): | gnupg | CVE #(s): | CAN-2003-0971 | ||||||||||||||||||||||||||||||||||||||||
Created: | November 28, 2003 | Updated: | March 3, 2004 | ||||||||||||||||||||||||||||||||||||||||
Description: | A severe vulnerability was discovered in GnuPG by Phong Nguyen relating to
ElGamal sign+encrypt keys. This
email message from Werner Koch contains more information. "Phong Nguyen identified a severe bug in the way GnuPG creates and uses ElGamal keys for signing. This is a significant security failure which can lead to a compromise of almost all ElGamal keys used for signing. Note that this is a real world vulnerability which will reveal your private key within a few seconds." | ||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
kernel: local root exploit in 2.4.22
Package(s): | kernel | CVE #(s): | CAN-2003-0961 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Created: | December 1, 2003 | Updated: | April 5, 2004 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description: | A vulnerability was discovered in the Linux kernel versions 2.4.22 and
previous. A flaw in bounds checking in the do_brk() function can allow a
local attacker to gain root privileges. This vulnerability is known to be
exploitable.
The 2.4.23 kernel contains the fix. For more details on how this vulnerability works, see this LWN article. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
Net-SNMP: security bugs in versions before 5.0.9
Package(s): | Net-SNMP | CVE #(s): | CAN-2003-0935 | ||||||||||||||||
Created: | December 2, 2003 | Updated: | February 13, 2004 | ||||||||||||||||
Description: | The Net-SNMP project includes various Simple Network Management Protocol
(SNMP) tools. A security issue in Net-SNMP versions before 5.0.9 could
allow an existing user/community to gain access to data in MIB objects that
were explicitly excluded from their view.
Version 5.0.9 of Net-SNMP is not vulnerable to this issue. In addition, Net-SNMP 5.0.9 fixes a number of other minor bugs. | ||||||||||||||||||
Alerts: |
|
screen: privilege escalation
Package(s): | screen | CVE #(s): | CAN-2003-0972 | ||||||||||||||||||||||||
Created: | November 28, 2003 | Updated: | March 3, 2004 | ||||||||||||||||||||||||
Description: | According to
this advisory a buffer overflow in GNU screen allows privilege
escalation for local users. Usually screen is installed either setgid-utmp
or setuid-root.
It also has some potential for remote attacks or getting control of another user's screen. The problem is that you have to transfer around 2-3 gigabytes of data to user's screen to exploit this vulnerability. 4.0.1, 3.9.15 and older versions are vulnerable. | ||||||||||||||||||||||||||
Alerts: |
|
stunnel: file descriptor leak
Package(s): | stunnel | CVE #(s): | CAN-2003-0740 | ||||||||
Created: | November 26, 2003 | Updated: | December 3, 2003 | ||||||||
Description: | A vulnerability was discovered in stunnel versions 3.24 and earlier, as well as 4.00, by Steve Grubb. It was found that stunnel leaks a critical file descriptor that can be used to hijack stunnel's services. See this advisory for more information. | ||||||||||
Alerts: |
|
Resources
A mailing list for secure application development
A new mailing list (called "SC-L") has been set up for the discussion of secure application development. It is a moderated list. Click below for the full announcement, and instructions for signing up.
Page editor: Jonathan Corbet
Next page:
Kernel development>>