Security
Email privacy
An interesting look at the arguments made by the US Government in a email privacy case serve as yet another reminder that email is not private. For both technical and, now, potentially legal reasons, email that you send is not protected from prying eyes. Even for jurisdictions that have a bit more regard for privacy than the US does, the cleartext nature of email communication should be enough incentive to use encryption, at least on sensitive emails. But, even among highly technical users, email encryption is quite rare.
In the article, attorney Mark Rasch describes what privacy is, from a constitutional standpoint, as well as the test the US Supreme Court used to determine privacy rights. "Constitutional privacy" simply governs whether the government is required to get a warrant before using a particular piece of evidence against a defendant, which is a bit different than the usual definition. In the current case, the government seeks to introduce email that it gathered without a warrant – its claim is that none is required.
The case that essentially created privacy rights in the US was a 1963 case involving payphone privacy and the Supreme Court decided on a two question test to determine whether there was a privacy right or not. Those questions boil down to whether the person believed what they were doing was private and whether society as a whole would agree. In the current case, the government is arguing that because the terms of service (TOS) of an ISP allow the ISP to monitor email, anyone using that service has no reasonable expectation of privacy. Thus, a subpoena, rather than a warrant, is all that is required to use the defendant's email against him.
A subpoena is much easier to get, with much less specificity about what kind of evidence is being sought. A prosecutor could subpoena someone's entire stored email archive from an ISP, but a warrant would need to indicate what kind of evidence, for which alleged crimes, was being sought. Email that was evidence of a different crime would not be admissible. At least in theory.
This would appear to be an end run around the Electronic Communications Privacy Act (ECPA), which was passed to specifically protect electronic communications in the same way that telephone calls are protected. The current administration's assault on telephone privacy notwithstanding, ECPA clearly extends the wiretapping laws and warrant requirements into the realm of internet communications. A regulation passed by Congress can add additional privacy safeguards, beyond what the Supreme Court decided, as long as the safeguards are not unconstitutional themselves. How the Justice Department intends to circumvent ECPA is not clear, but hopefully the defendant's lawyers and the judge won't ignore it as well as the Justice Department has. A decision in the case is still pending.
Perhaps the most chilling portion of the government's argument is that it didn't even need a subpoena; that the email could be introduced as evidence no matter how it was acquired. Their argument once again rests on the TOS that folks agree to with their email providers (ISPs or on-line services like GMail), which, because it gives the provider the right to look at the email, makes email inherently non-private. So the government can collect it in secret rooms at AT&T and use it as they see fit. That's not quite how they put it in their arguments, but that is the upshot.
With luck, the courts will see things just a tad differently, especially in light of ECPA. This will hopefully leave us with only the technical side of email privacy to deal with. For that, there are plenty of tools available, they just don't seem to see much use.
Most modern mail user agents have some kind of encryption capability, usually in the form of an OpenPGP (RFC 2440) compliant message handler. This open encryption standard has been around for a long time, is well-supported, and not too terribly difficult to use. So why do the vast majority of emails go out unencrypted?
There are a number of reasons, probably. For one thing, the vast majority of email is spam these days; encryption probably lessens their impact, though it may help them avoid spam filters in the future. Of the rest, most of what is sent as email probably doesn't seem to require much in the way of privacy. Some of it is going to public mailing lists, others are reminding the spouse to get milk on the way home, and the rest is one of several bad jokes that have now been forwarded enough times that the indentation level puts the actual text on a monitor next door. But, seriously, it is only a small subset of email that needs encryption.
Even that small subset is probably not encrypted, at least in the author's experience. Certainly the Tor eavesdropping exercise indicated that even governments tend not to use encryption for at least some of their diplomatic traffic. It almost certainly comes down to convenience; dealing with keys, key exchanges, and key management is more trouble than it is worth. Unfortunately, there is no silver bullet solution to that problem; in order to have good encryption, you must have good keys.
Encrypted email should be fairly private, but it is certainly not bulletproof. Because it is so rarely used today, sending encrypted email might attract unwanted attention from entities monitoring internet traffic. But, as long as both parties maintain the secrecy of their keys, possibly under the threat of imprisonment for contempt of court, there is no known method for decrypting the message in a reasonable timeframe (key-length and cipher-strength dependent, of course). If we really want privacy for our emails, encryption is the right path.
Security reports
Daniel Bernstein: ten years of qmail security
Daniel J. Bernstein has posted a paper looking back at the security of qmail [PDF], ten years after 1.0 came out. "In retrospect, some of qmail's "security" mechanisms were half-baked ideas that didn't actually accomplish anything and that could have been omitted with no loss of security. Other mechanisms have been responsible for qmail's successful security track record. My main goal in this paper is to explain how this difference could have been recognized in advance--how software-engineering techniques can be measured for their long-term security impact."
New vulnerabilities
conga: denial of service
Package(s): | conga | CVE #(s): | CVE-2007-4136 | ||||||||
Created: | November 7, 2007 | Updated: | November 22, 2007 | ||||||||
Description: | A flaw was found in ricci during a code audit. A remote attacker who is able to connect to ricci could cause ricci to temporarily refuse additional connections, a denial of service (CVE-2007-4136). | ||||||||||
Alerts: |
|
coolkey: temporary file vulnerability
Package(s): | coolkey | CVE #(s): | CVE-2007-4129 | ||||
Created: | November 7, 2007 | Updated: | November 7, 2007 | ||||
Description: | Steve Grubb discovered a flaw in the way coolkey created a temporary directory. A local attacker could perform a symlink attack and cause arbitrary files to be overwritten. (CVE-2007-4129) | ||||||
Alerts: |
|
firefox: multiple vulnerabilities
Package(s): | firefox | CVE #(s): | |||||
Created: | November 6, 2007 | Updated: | November 7, 2007 | ||||
Description: | update to 1.5.0.12 | ||||||
Alerts: |
|
gftp: buffer overflows
Package(s): | gftp | CVE #(s): | CVE-2007-3962 CVE-2007-3961 | ||||||||
Created: | November 2, 2007 | Updated: | January 22, 2008 | ||||||||
Description: | Kalle Olavi Niemitalo discovered two boundary errors in fsplib code included in gFTP when processing overly long directory or file names. A remote attacker could trigger these vulnerabilities by enticing a user to download a file with a specially crafted directory or file name, possibly resulting in the execution of arbitrary code (CVE-2007-3962) or a Denial of Service (CVE-2007-3961). | ||||||||||
Alerts: |
|
hugin: unsafe temporary file usage
Package(s): | hugin | CVE #(s): | CVE-2007-5200 | ||||||||||||
Created: | November 6, 2007 | Updated: | December 6, 2007 | ||||||||||||
Description: | hugin in SUSE openSUSE 10.2 and 10.3 allows local users to overwrite arbitrary files via a symlink attack on a temporary file. | ||||||||||||||
Alerts: |
|
liferea: weak permissions
Package(s): | liferea | CVE #(s): | CVE-2007-5751 | ||||||||||||||||||||||||||||||||||||||||||||
Created: | November 2, 2007 | Updated: | December 22, 2008 | ||||||||||||||||||||||||||||||||||||||||||||
Description: | Liferea before 1.4.6 uses weak permissions (0644) for the feedlist.opml backup file, which allows local users to obtain credentials. | ||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
mcstrans: denial of service
Package(s): | mcstrans | CVE #(s): | CVE-2007-4570 | ||||
Created: | November 7, 2007 | Updated: | November 7, 2007 | ||||
Description: | An algorithmic complexity weakness was found in the way the mcstrans daemon handled ranges of compartments in sensitivity labels. A local user could trigger this flaw causing mctransd to temporarily stop responding to other requests; a partial denial of service. (CVE-2007-4570) | ||||||
Alerts: |
|
mono: arbitrary code execution via integer overflow
Package(s): | mono | CVE #(s): | CVE-2007-5197 | ||||||||||||||||||||||||||||||||
Created: | November 6, 2007 | Updated: | December 7, 2009 | ||||||||||||||||||||||||||||||||
Description: | From the Debian advisory: An integer overflow in the BigInteger data type implementation has been discovered in the free .NET runtime Mono. | ||||||||||||||||||||||||||||||||||
Alerts: |
|
nagios-plugins: check_snmp buffer overflow
Package(s): | nagios-plugins | CVE #(s): | CVE-2007-5623 | ||||||||||||||||||||||||||||||||||||
Created: | November 2, 2007 | Updated: | April 17, 2008 | ||||||||||||||||||||||||||||||||||||
Description: | Buffer overflow in the check_snmp function in Nagios Plugins (nagios-plugins) 1.4.10 allows remote attackers to cause a denial of service (crash) via crafted snmpget replies. | ||||||||||||||||||||||||||||||||||||||
Alerts: |
|
pcre: two arbitrary code execution vulnerabilities
Package(s): | pcre | CVE #(s): | CVE-2007-1659 CVE-2007-1660 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Created: | November 6, 2007 | Updated: | July 16, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description: | Multiple flaws were found in the way pcre handles certain malformed regular expressions. If an application linked against pcre, such as Konqueror, parses a malicious regular expression, it may be possible to run arbitrary code as the user running the application. (CVE-2007-1659, CVE-2007-1660) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
perdition: arbitrary code execution via crafted IMAP tag
Package(s): | perdition | CVE #(s): | CVE-2007-5740 | ||||
Created: | November 6, 2007 | Updated: | November 7, 2007 | ||||
Description: | From the Debian advisory: Bernhard Mueller of SEC Consult has discovered a format string vulnerability in perdition, an IMAP proxy. This vulnerability could allow an unauthenticated remote user to run arbitrary code on the perdition server by providing a specially formatted IMAP tag. | ||||||
Alerts: |
|
perl: arbitrary code execution
Package(s): | Perl | CVE #(s): | CVE-2007-5116 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Created: | November 6, 2007 | Updated: | December 5, 2007 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description: | A flaw was found in Perl's regular expression engine. Specially crafted input to a regular expression can cause Perl to improperly allocate memory, possibly resulting in arbitrary code running with the permissions of the user running Perl. (CVE-2007-5116) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
phpMyAdmin: cross-site scripting vulnerabilities
Package(s): | phpMyAdmin | CVE #(s): | CVE-2007-5386 CVE-2007-5589 | ||||||||||||||||||||
Created: | November 2, 2007 | Updated: | March 14, 2008 | ||||||||||||||||||||
Description: | Cross-site scripting (XSS) vulnerability in scripts/setup.php in phpMyAdmin
2.11.1, when accessed by a browser that does not URL-encode requests,
allows remote attackers to inject arbitrary web script or HTML via the
query string.
Multiple cross-site scripting (XSS) vulnerabilities in phpMyAdmin before 2.11.1.2 allow remote attackers to inject arbitrary web script or HTML via certain input available in (1) PHP_SELF in (a) server_status.php, and (b) grab_globals.lib.php, (c) display_change_password.lib.php, and (d) common.lib.php in libraries/; and certain input available in PHP_SELF and (2) PATH_INFO in libraries/common.inc.php. NOTE: there might also be other vectors related to (3) REQUEST_URI. | ||||||||||||||||||||||
Alerts: |
|
pidgin: denial of service
Package(s): | pidgin | CVE #(s): | CVE-2007-4999 | ||||||||||||
Created: | November 2, 2007 | Updated: | November 29, 2007 | ||||||||||||
Description: | libpurple in Pidgin 2.1.0 through 2.2.1, when using HTML logging, allows remote attackers to cause a denial of service (NULL dereference and application crash) via a message that contains invalid HTML data, a different vector than CVE-2007-4996. | ||||||||||||||
Alerts: |
|
sitebar: multiple vulnerabilities
Package(s): | sitebar | CVE #(s): | CVE-2007-5491 CVE-2007-5694 CVE-2007-5492 CVE-2007-5693 CVE-2007-5695 CVE-2007-5692 | ||||||||
Created: | November 7, 2007 | Updated: | December 7, 2007 | ||||||||
Description: | Tim Brown discovered these multiple issues: the translation module does not properly sanitize the value to the "dir" parameter (CVE-2007-5491, CVE-2007-5694); the translation module also does not sanitize the values of the "edit" and "value" parameters which it passes to eval() and include() (CVE-2007-5492, CVE-2007-5693); the log-in command does not validate the URL to redirect users to after logging in (CVE-2007-5695); SiteBar also contains several cross-site scripting vulnerabilities (CVE-2007-5692). | ||||||||||
Alerts: |
|
thunderbird: multiple vulnerabilities
Package(s): | thunderbird | CVE #(s): | |||||
Created: | November 6, 2007 | Updated: | November 7, 2007 | ||||
Description: | update to 1.5.0.12 | ||||||
Alerts: |
|
Page editor: Jake Edge
Next page:
Kernel development>>