User: Password:
|
|
Subscribe / Log in / New account

Security

Sovereign Keys for certificate verification

November 23, 2011

This article was contributed by Nathan Willis

The certificate-authority (CA)-based approach to identity-checking on the web is under heavy fire these days. In theory, when a client like a web browser initiates a secure connection to a remote server, it relies on a chain of trusted cryptographic signatures presented by the server to verify that the public-key encryption certificate belongs to who the browser is expecting. But as the Electronic Frontier Foundation (EFF) has pointed out numerous times in public, the CA system is too-easily circumvented by fake CAs or attackers intercepting and replacing credentials during the handshake.

The problem affects SSL/TLS, SMTPS, and other secure protocols. There are plenty of proposals for replacing the CA portion of system, including Convergence, MonkeySphere, and Public Key Pinning. EFF's chief technologist Peter Eckersley has proposed a new framework called Sovereign Keys that is intended to securely verify associations between domain names and cryptographic keys in a way that is more robust than the CA system in use today, but can piggyback on it.

The Sovereign Key system allows clients to verify the validity of a server's X.509 certificate by referencing a persistent, append-only database mirrored around the world. The Sovereign Key service is designed to prevent man-in-the-middle and server-impersonation attacks — even those where an attacker has compromised a CA — and provides a safe workaround when an attack on SSL/TLS would trigger one of those certificate warning messages that users have grown accustomed to ignoring. Although in theory it could be used to replace the CA system outright, the proposal instead presents it as a way to augment existing techniques, which maximizes compatibility with existing HTTPS and SSL/TLS infrastructure.

A November 18 blog post outlines the Sovereign Keys proposal at a high level, including the weaknesses in the current CA model and links to research showing the ineffectiveness of certificate warnings in modern web browsers. The proposal itself is hosted in the EFF Git repository, although Eckersley warns that it is in draft form only, and not a complete specification. In particular, it does not detail protocol encodings and numerical parameters that would be required before undertaking a real-world implementation.

There is also a set of "issues" with the current design that are also hosted in the repository. Currently five in number, they outline possible attack vectors and transitional or pragmatic hurdles in the way of possible adoption. Eckersley said that the EFF is working toward a real-world test, but that because of the scope involved, it is still too soon to announce.

The design

As the proposal outlines it, there are two chief problems with the CA system in use today. First, it is vulnerable to variety of attacks, including a compromised CA itself, a CA pressured by a government into maliciously replacing a certificate, a compromised router near either the client or the CA, or even a compromised DNS server in between the client and CA. Second, the default way for browsers to warn users about potential attacks is with a certificate warning message. But research has shown that the majority of certificate warnings are generated by "bureaucratic" non-attack incidents like mismatches and self-signed certificates, which has trained users to ignore the warnings.

The first goal of the Sovereign Keys design is to allow clients to check the validity of a server's certificate without relying on any third-party that could be compromised like the CA system can. The second is to provide an alternate method for clients to securely connect to the correct server in case the validity check fails (meaning the server the client actually wants to connect to, even if the server originally seen is an impostor).

In the Sovereign Keys system, a definitive "sovereign key" key-pair exists for each service on the Internet. There is a public, master database of all of the (public key) sovereign keys, and any client could use it to check the signature on a particular server's SSL/TLS certificate. The certificate could be changed, but as long as the verified sovereign key signs the new one, the clients would consider it valid. What makes the Sovereign Keys database more trustworthy than a chain of CA-signatures is that it is verifiably read-append-only — meaning that all clients can query it, but that the database server can only append new records, not modify old ones — and replicated by a set of global mirrors.

Because it can be appended to but not changed, the database is a "timeline" that includes a complete record of new sovereign key registrations, revocations, and other incidents. In the event that a timeline server experiences a fault (such as two events being recorded out-of-sequence), any client can recognize it, flag it as renegade, and stop trusting it. The timeline is a bit like the distributed, public transaction record used by Bitcoin — its authenticity is designed to be verifiable by clients and mirrors. Each entry includes a strictly-incrementing serial number and a monotonically-increasing timestamp, and the entries are cryptographically signed.

The other half of the design is what a client is meant to do if a server's certificate fails the sovereign key-verification test. Rather than allow the user to continue to connect (which may be a man-in-the-middle attack, but even if it is not, reinforces the behavior that continuing to connect is acceptable), the client takes the sovereign key found in the timeline for the service, computes an SHA1 hash of the key, and attempts to connect to that hash value as a hidden .onion service via Tor. If the service does not accept connections on the .onion address, the client is to stop, and not connect at all. In other words, it may ultimately fail to connect, but that is better than making an unsafe connection.

Of course, the use of Tor as an alternate method for connecting to a service introduces its own set of additional requirements. The client must be running Tor and have a proxy set up to properly redirect requests using the .onion pseudo-domain. The server must also be configured to run the hidden service, because the system uses Tor routing rather than DNS or IP addressing to route traffic.

Multiple timelines?

The integrity of the timeline is paramount to making the Sovereign Keys system work. Although, technically speaking, there are multiple trusted timelines, one for each timeline server. The timeline servers inform each other of events, but in keeping with the append-only nature of the timeline, each timeline server has its own timestamp. There are separate record types to distinguish between events that happen on the timeline server and those that are relayed from a peer.

The process starts when the owner of a domain registers a sovereign key for a new service (officially, this registration calls for both a protocol — say, HTTPS or SMTPS — and a domain) with a nearby timeline server. According to the proposal, the registrant must present evidence that he or she controls the domain at the time of the registration. The evidence can be either "a CA-signed DER-encoded X.509 certificate associating the name with the Sovereign Key, or DANE DNSSEC evidence associating the name with the Sovereign Key, if that is available for this TLD [top-level domain]." The timeline server must verify the evidence. The evidence is logged in the timeline entry along with other pertinent data: the timeline's serial number and timestamp, the sovereign key itself, the domain name and protocol(s) registered for it, an optional expiration date, and two auxiliary fields, "wildcard" and "inheriting name(s)."

The proposal estimates that the space required to store such timeline entries for all of the 200 million domains currently in existence is around 300GB (although no estimate is made for how quickly this set of domains is growing, which could also prove relevant). The wildcard field is set by the registrant; if 0 then the sovereign key applies only the exact domain name listed; if 1 then the sovereign key is considered valid for matching subdomains as well. The "inheriting name(s)" are an optional list of other sovereign keys that are granted the right to register a new sovereign key for this domain if and when this current sovereign key is later revoked. Only self-signed revocations are accepted, so, in theory, designating "heirs" at the time of registration prevents later hijacking.

Apart from new sovereign key registrations, the timeline contains three types of entries: registrations-by-reference (registrations that were initiated at other timeline servers), revocations, and reissuances (which might change parameters like the protocols accepted). These entries are shorter, consisting of (in the registration-by-reference example) the original timeline server's id, serial number, and timestamp data, plus the serial number and timestamp that the reference was logged at in this timeline.

The design calls for a set number of timeline servers (10-30); having multiple root timeline servers should increase performance and make the network more reliable, particularly if they are located in different geographic and network regions. The proposal does not address how they are bootstrapped, but they seem to require a priori knowledge of each other in order to propagate registrations-by-reference and other important timeline events. Mirrors, on the other hand, also increase availability and performance from the clients' perspective, but mirrors do not record any new events to the timeline, they only synchronize with the authoritative timeline servers.

Conflicts, mirrors, and sharing

Space in the proposal is dedicated to what happens when one timeline server seems to violate the rules, such as storing two entries in its timeline with the same or out-of-order serial numbers, recording a lower timestamp than a previous entry, or registering a new sovereign key without verifiable credentials. Because clients are expected to query the mirror servers and not the root timeline servers directly, mirrors are expected to catch the misbehavior first. They then record the incident (including the problematic timeline entries), stop trusting the timeline server, and propagate the incident to clients that ask. Mirrors are also supposed to propagate this "renegation" information to each other; presumably the managers of the root timeline servers would be notified as well.

A longer discussion is devoted to the mirroring and mirror-querying protocol. Clients are supposed to trust the oldest sovereign key found for a domain in all of the valid timelines — plus whatever revocations and renewals follow it — so replicating the entire timeline could be important to verifying any particular transaction. How long clients and mirrors should cache information is both a performance and security consideration. The proposal recommends a series of trust stages from 24 hours to two weeks in length.

It also discusses how Sovereign Keys could be implemented in parallel with the existing SSL/TLS CA system. Because clients can do sovereign key verification by checking one signature on the certificate presented by a server, the CA system is not needed at all, but Eckersley recommends implementing it at first with sovereign key signatures added-on to existing CA-signed (or self-signed) server certificates.

Issues

The issues/ directory in the Git repository discusses technical and practical problems with the proposal, including concerns with such a CA/Sovereign Keys transitional system. The first is that an attacker who compromises a victim's DNS or web server can generate fraudulent sovereign key registrations complete with the DANE or CA-backed credentials the system is supposed to trust. The authors recommend that domain owners combat this potential attack by preemptively creating a sovereign key with no associated protocols, and outline a series of steps that root timeline server administrators could take to protect against rogue registrations.

There are several potential problems with timeline management discussed as well, including attackers compromising a timeline server (which is particularly troublesome since the timeline servers trust each other unless a renegation is spotted), false alarms caused by system time adjustments, and clock synchronization problems. A separate issue addresses the assumption that the set of authoritative timeline servers is small and well-known. This assumption has implications for renegation tracking and synchronization, but it also limits the decentralization of the Sovereign Keys framework, and in a real sense places critical (if not ultimate) trust in the timeline overseers.

Two attack vectors are considered: denial of service by flooding the timeline servers with registrations or the timeline servers and mirrors with queries, and a Sybil attack against a client by overloading its list of Sovereign Keys mirrors with compromised servers.

Of the vulnerabilities discussed, the false registrations created by breaking the existing CA or DANE DNSSEC system clearly has the largest attack surface. After all, the Internet could not be "switched over" to Sovereign Keys instantaneously even if every server and CA decided to do so. In the meantime, as EFF's other publications regularly show, there are enough attacks on (and security holes in) the CA system now that the Sovereign Keys proposal's reliance on CA as the trust authority for new sovereign key registrations sounds almost illogical. The proposal details ideas for bootstrapping mirror servers in a secure way, but creating verifiable sovereign keys for the 200 million domains is a much larger problem to solve.

It is clear that the current CA system is seriously flawed, and it is clear that browser certificate warnings are an ineffective tool to prevent users from falling victim to attackers. Some parts of the draft Sovereign Keys proposal are intriguing (such as the verifiable, public timeline record), but in other ways to most end users it may sound like replacing one remote authority with another. Falling back on Tor might be good from a technical perspective, but will be a challenge to implement. On either of the two goals of the project, then, its future will depend on how it is received by those outside of the EFF.

Comments (8 posted)

Brief items

Security quotes of the week

Most consumers don't care until they get their first $1,000 phone bill because their pirated Angry Birds has been calling Estonia all month.
-- Chester Wisniewski

If you read an analyst report about 'viruses' infecting ios, android or rim, you now know that analyst firm is not honest and is staffed with charlatans. There is probably an exception, but extraordinary claims need extraordinary evidence.

If you read a report from a vendor that [tries] to sell you something based on protecting android, rim or ios from viruses they are also likely as not to be scammers and charlatans.

-- Chris DiBona

CarrierIQ as seen in real world usage (HTC Devices especially) is nothing like the stock copies shown on the first page. All menus have been stripped, hiding it from users presence without advanced knowledge. The service also runs as user Root in ramdisk. It checks in to a server (or receives commands through other various access) with commands to allow someone undetected access.
-- Trevor Eckhart reports on a rootkit installed in many mobile phones by the carriers

Happily, [Trevor] Eckhart was not cowed by this ham-fisted effort to suppress his findings. Instead, he reached out to EFF. We're glad he did. As we explained in a letter (pdf) to Carrier IQ today, Eckhart's research is protected by fair use and the First Amendment right to free expression. He posted the training materials to teach the public about software that many consumers don't know about, even though it monitors their everyday activities and raises substantial privacy concerns.
-- Electronic Frontier Foundation (EFF) steps in to help defend against a Carrier IQ cease-and-desist

So on the exact same day, Adobe said "we recommend you upgrade, as the version you are using is vulnerable" and "we offer you no way to upgrade".

I'm left with the conclusion that Adobe's aggregate corporate message is "users of desktops based on free software should immediately uninstall AIR and stop using it".

If Adobe's software was free, and they had a community around it, they could turn over support to the community if they found it too burdensome. Instead, once again, users of proprietary tools on free systems get screwed by the proprietary vendor.

-- Daniel Kahn Gillmor (Thanks to Paul Wise.)

Comments (1 posted)

BIND 9 denial of service being seen in the wild

The BIND 9 DNS name server is undergoing a concerted denial of service attack, according to this Internet Systems Consortium advisory. "Organizations across the Internet reported crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crashed after logging an error in query.c with the following message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" Multiple versions were reported being affected, including all currently supported release versions of ISC BIND 9. [...] An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached. At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit." We should be seeing distributions releasing updated versions soon.

Comments (10 posted)

Certificate fraud: Protection against future "DigiNotars" (The H)

The H looks at a proposal from Google to protect against rogue or compromised certificate authorities. "[Google product manager Ian] Fette said that after that affair, other companies asked Google for a way to protect themselves against bogus certificates. As there are numerous CAs, the possibility that similar illegitimate certificates could be issued remains, explained the developer. However, Fette said that embedding the certification policy for all potential parties into browsers doesn't scale, and that he and his colleagues, Chris Evans and Chris Palmer, therefore advocate the dynamic pinning of public keys." The article goes on to look at the proposal and some complaints about it, along with an alternative based on DNSSEC.

Comments (9 posted)

Tool kills hidden Linux bugs, vulnerabilities (SC Magazine)

SC Magazine looks at a tool to help look for holes in Linux. "It identifies similar source files based on file names and content to identify relationships between source packages. Fuzzy hashing using ssdeep produces hashes that can be used to determine similar packages. Graph Theory is used to perform the analysis."

Comments (25 posted)

New vulnerabilities

bind9: denial of service

Package(s):bind9 CVE #(s):CVE-2011-4313
Created:November 17, 2011 Updated:November 30, 2011
Description:

From the ISC advisory:

Organizations across the Internet reported crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crashed after logging an error in query.c with the following message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" Multiple versions were reported being affected, including all currently supported release versions of ISC BIND 9.

[...]

An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached. At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit.

Alerts:
Gentoo 201206-01 bind 2012-06-02
CentOS CESA-2011:1496 bind 2011-11-29
Oracle ELSA-2011-1496 bind 2011-11-30
SUSE SUSE-SU-2011:1270-3 bind 2011-11-30
Scientific Linux SL-bind-20111129 bind 2011-11-29
CentOS CESA-2011:1496 bind 2011-11-29
Red Hat RHSA-2011:1496-01 bind 2011-11-29
Fedora FEDORA-2011-16002 bind 2011-11-17
Fedora FEDORA-2011-16036 bind 2011-11-17
SUSE SUSE-SU-2011:1270-2 bind 2011-11-23
SUSE SUSE-SU-2011:1270-1 bind 2011-11-22
SUSE SUSE-SU-2011:1268-1 bind 2011-11-22
openSUSE openSUSE-SU-2011:1272-1 bind 2011-11-22
Oracle ELSA-2011-1459 bind97 2011-11-18
Oracle ELSA-2011-1458 bind 2011-11-18
CentOS CESA-2011:1459 bind97 2011-11-18
Scientific Linux SL-bind-20111117 bind97 2011-11-17
Mandriva MDVSA-2011:176-1 bind 2011-11-17
Red Hat RHSA-2011:1458-01 bind 2011-11-17
Debian DSA-2347-1 bind9 2011-11-16
Fedora FEDORA-2011-16057 bind 2011-11-17
Oracle ELSA-2011-1458 bind 2011-11-18
CentOS CESA-2011:1458 bind 2011-11-18
Scientific Linux SL-bind-20111117 bind 2011-11-17
Mandriva MDVSA-2011:176-2 bind 2011-11-18
Red Hat RHSA-2011:1459-01 bind97 2011-11-17
Ubuntu USN-1264-1 bind9 2011-11-16
Mandriva MDVSA-2011:176 bind 2011-11-16

Comments (none posted)

chromium: multiple vulnerabilities

Package(s):chromium CVE #(s):CVE-2011-3892 CVE-2011-3893 CVE-2011-3894 CVE-2011-3895 CVE-2011-3896 CVE-2011-3897 CVE-2011-3898 CVE-2011-3900
Created:November 21, 2011 Updated:August 30, 2012
Description: From the Gentoo advisory:

Multiple vulnerabilities have been discovered in Chromium and V8. A context-dependent attacker could entice a user to open a specially crafted web site or JavaScript program using Chromium or V8, possibly resulting in the execution of arbitrary code with the privileges of the process, or a Denial of Service condition. The attacker also could cause a Java applet to run without user confirmation.

Alerts:
Gentoo 201310-12 ffmpeg 2013-10-25
Mandriva MDVSA-2012:148 ffmpeg 2012-08-30
Mandriva MDVSA-2012:074-1 ffmpeg 2012-08-30
Mageia MGASA-2012-0218 avidemux 2012-08-18
Mageia MGASA-2012-0204 avidemux 2012-08-06
Mandriva MDVSA-2012:076 ffmpeg 2012-05-15
Mandriva MDVSA-2012:075 ffmpeg 2012-05-15
Mandriva MDVSA-2012:074 ffmpeg 2012-05-14
Debian DSA-2471-1 ffmpeg 2012-05-13
Gentoo 201111-05 chromium 2011-11-19

Comments (none posted)

drupal6-views: SQL injection

Package(s):drupal6-views CVE #(s):
Created:November 21, 2011 Updated:November 23, 2011
Description: From the Drupal advisory:

The Views module enables you to list content in your site in various ways. The module doesn't sufficiently escape database parameters for certain filters/arguments on certain types of views with specific configurations of arguments.

Alerts:
Fedora FEDORA-2011-15399 drupal-views 2011-11-04
Fedora FEDORA-2011-15385 drupal6-views 2011-11-04
Fedora FEDORA-2011-15352 drupal6-views 2011-11-03

Comments (none posted)

freetype: code execution

Package(s):freetype CVE #(s):CVE-2011-3439
Created:November 17, 2011 Updated:April 19, 2012
Description:

From the Red Hat advisory:

Multiple input validation flaws were found in the way FreeType processed CID-keyed fonts. If a specially-crafted font file was loaded by an application linked against FreeType, it could cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. (CVE-2011-3439)

Alerts:
SUSE SUSE-SU-2012:0553-1 freetype2 2012-04-23
Fedora FEDORA-2012-4946 freetype 2012-04-18
Oracle ELSA-2012-0467 freetype 2012-04-12
Red Hat RHSA-2012:0094-01 freetype 2012-02-02
Gentoo 201201-09 freetype 2012-01-23
openSUSE openSUSE-SU-2012:0015-1 freetype2 2012-01-05
SUSE SUSE-SU-2011:1307-1 freetype2 2011-12-08
SUSE SUSE-SU-2011:1306-1 freetype2 2011-12-08
Fedora FEDORA-2011-15964 freetype 2011-12-04
Fedora FEDORA-2011-15956 freetype 2011-11-15
Fedora FEDORA-2011-15927 freetype 2011-11-15
CentOS CESA-2011:1455 freetype 2011-11-18
Ubuntu USN-1267-1 freetype 2011-11-18
Oracle ELSA-2011-1455 freetype 2011-11-17
Oracle ELSA-2011-1455 freetype 2011-11-17
Oracle ELSA-2011-1455 freetype 2011-11-17
Red Hat RHSA-2011:1455-01 freetype 2011-11-16
Mandriva MDVSA-2011:177 freetype2 2011-11-21
Debian DSA-2350-1 freetype 2011-11-20
CentOS CESA-2011:1455 freetype 2011-11-18
Scientific Linux SL-free-20111116 freetype 2011-11-16

Comments (none posted)

kdeutils: directory traversal

Package(s):kdeutils CVE #(s):CVE-2011-2725
Created:November 22, 2011 Updated:March 7, 2012
Description: From the Ubuntu advisory:

Tim Brown discovered that Ark did not properly perform input validation when previewing archive files. If a user were tricked into opening a crafted archive file, an attacker could remove files via directory traversal.

Alerts:
openSUSE openSUSE-SU-2012:0322-1 Ark 2012-03-06
Ubuntu USN-1276-1 kdeutils 2011-11-21

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2011-4131 CVE-2011-4132
Created:November 21, 2011 Updated:July 10, 2012
Description: From the Red Hat bugzilla:

nfs4_getfacl decoding causes a kernel Oops when a server returns more than 2 GETATTR bitmap words in response to the FATTR4_ACL attribute request.

While the NFS client only asks for one attribute (FATTR4_ACL) in the first bitmap word, the NFSv4 protocol allows for the server to return unbounded bitmaps.

From the Red Hat bugzilla:

A flaw was found in the way Linux kernel's Journaling Block Device (JBD) handled invalid log first block value. An attacker able to mount malicious ext3 or ext4 image could use this flaw to crash the system.

Alerts:
SUSE SUSE-SU-2015:0812-1 kernel 2015-04-30
openSUSE openSUSE-SU-2013:0925-1 kernel 2013-06-10
SUSE SUSE-SU-2013:0786-1 Linux kernel 2013-05-14
openSUSE openSUSE-SU-2013:0927-1 kernel 2013-06-10
Red Hat RHSA-2013:0566-01 kernel-rt 2013-03-06
Red Hat RHSA-2012:1541-01 kernel 2012-12-04
Ubuntu USN-1530-1 linux-ti-omap4 2012-08-10
CentOS CESA-2012:0862 kernel 2012-07-10
Oracle ELSA-2012-0862 kernel 2012-07-02
Oracle ELSA-2012-2022 kernel 2012-07-02
Oracle ELSA-2012-2022 kernel 2012-07-02
SUSE SUSE-SU-2012:0789-1 Linux kernel 2012-06-26
Ubuntu USN-1471-1 linux-lts-backport-oneiric 2012-06-12
Fedora FEDORA-2012-8824 kernel 2012-06-07
Ubuntu USN-1470-1 linux-lts-backport-natty 2012-06-12
Red Hat RHSA-2012:0862-04 kernel 2012-06-20
Ubuntu USN-1457-1 linux 2012-05-31
SUSE SUSE-SU-2012:0554-2 kernel 2012-04-26
Oracle ELSA-2012-0481 kernel 2012-04-23
SUSE SUSE-SU-2012:0554-1 Linux kernel 2012-04-23
Oracle ELSA-2012-0350 kernel 2012-03-12
Oracle ELSA-2012-2003 kernel-uek 2012-03-12
Oracle ELSA-2012-2003 kernel-uek 2012-03-12
Scientific Linux SL-kern-20120308 kernel 2012-03-08
CentOS CESA-2012:0350 kernel 2012-03-07
Red Hat RHSA-2012:0350-01 kernel 2012-03-06
Red Hat RHSA-2012:0333-01 kernel-rt 2012-02-23
Ubuntu USN-1476-1 linux-ti-omap4 2012-06-15
Ubuntu USN-1472-1 linux 2012-06-12
SUSE SUSE-SU-2012:0153-2 Linux kernel 2012-02-06
SUSE SUSE-SU-2012:0153-1 kernel 2012-02-06
Ubuntu USN-1340-1 linux-lts-backport-oneiric 2012-01-23
Ubuntu USN-1330-1 linux-ti-omap4 2012-01-13
Oracle ELSA-2012-0007 kernel 2012-01-12
Scientific Linux SL-kern-20120112 kernel 2012-01-12
CentOS CESA-2012:0007 kernel 2012-01-11
Red Hat RHSA-2012:0010-01 kernel-rt 2012-01-10
Red Hat RHSA-2012:0007-01 kernel 2012-01-10
Ubuntu USN-1322-1 linux 2012-01-09
Ubuntu USN-1312-1 linux 2011-12-19
Ubuntu USN-1311-1 linux 2011-12-19
Ubuntu USN-1304-1 linux-ti-omap4 2011-12-13
Ubuntu USN-1303-1 linux-mvl-dove 2011-12-13
Ubuntu USN-1302-1 linux-ti-omap4 2011-12-13
Ubuntu USN-1301-1 linux-lts-backport-natty 2011-12-13
Ubuntu USN-1300-1 linux-fsl-imx51 2011-12-13
Ubuntu USN-1299-1 linux-ec2 2011-12-13
Fedora FEDORA-2011-16621 kernel 2011-11-30
Ubuntu USN-1293-1 linux 2011-12-08
Ubuntu USN-1292-1 linux-lts-backport-maverick 2011-12-08
Ubuntu USN-1291-1 linux 2011-12-08
Ubuntu USN-1286-1 linux 2011-12-03
Fedora FEDORA-2011-16346 kernel 2011-11-23
Fedora FEDORA-2011-15959 kernel 2011-11-15

Comments (none posted)

libcap: unauthorized directory access

Package(s):libcap CVE #(s):CVE-2011-4099
Created:November 18, 2011 Updated:December 12, 2011
Description: From the openSUSE advisory:

capsh did not chdir("/") after callling chroot(). Programs could therefore access the current directory outside of the chroot

Alerts:
Mandriva MDVSA-2011:185 libcap 2011-12-12
Scientific Linux SL-libc-20111206 libcap 2011-12-06
Red Hat RHSA-2011:1694-03 libcap 2011-12-06
openSUSE openSUSE-SU-2011:1259-1 libcap 2011-11-18

Comments (none posted)

moodle: multiple vulnerabilities

Package(s):moodle CVE #(s):
Created:November 21, 2011 Updated:November 23, 2011
Description: Moodle 2.1.2, 2.0.5, and 1.9.14 contain multiple security fixes.
Alerts:
Fedora FEDORA-2011-14732 moodle 2011-10-22
Fedora FEDORA-2011-14733 moodle 2011-10-22
Fedora FEDORA-2011-14715 moodle 2011-10-22

Comments (none posted)

NetworkManager: man in the middle attack

Package(s):NetworkManager CVE #(s):CVE-2006-7246
Created:November 22, 2011 Updated:January 19, 2012
Description: From the SUSE advisory:

When 802.11X authentication is used (ie WPA Enterprise) NetworkManager did not pin a certificate's subject to an ESSID. A rogue access point could therefore be used to conduct MITM attacks by using any other valid certificate issued by the same CA as used in the original network (CVE-2006-7246). If password based authentication is used (e.g. via PEAP or EAP-TTLS) this means an attacker could sniff and potentially crack the password hashes of the victims.

Alerts:
openSUSE openSUSE-SU-2012:0101-1 NetworkManager-gnome 2012-01-19
openSUSE openSUSE-SU-2011:1273-1 NetworkManager 2011-11-23
SUSE SUSE-SA:2011:045 NetworkManager, 2011-11-22

Comments (none posted)

openldap: denial of service

Package(s):openldap CVE #(s):CVE-2011-4079
Created:November 17, 2011 Updated:November 23, 2011
Description:

From the Ubuntu advisory:

An OpenLDAP server could potentially be made to crash if it received specially crafted network traffic from an authenticated user.

[...]

It was discovered that slapd contained an off-by-one error. An authenticated attacker could potentially exploit this by sending a crafted crafted LDIF entry containing an empty postalAddress.

Alerts:
Gentoo 201406-36 openldap 2014-06-30
Ubuntu USN-1266-1 openldap 2011-11-17

Comments (none posted)

phpMyAdmin: arbitrary file reading

Package(s):phpMyAdmin CVE #(s):CVE-2011-4107
Created:November 23, 2011 Updated:January 2, 2012
Description:

From the CVE entry:

The simplexml_load_string function in the XML import plug-in (libraries/import/xml.php) in phpMyAdmin 3.4.x before 3.4.7.1 and 3.3.x before 3.3.10.5 allows remote authenticated users to read arbitrary files via XML data containing external entity references, aka an XML external entity (XXE) injection attack.

Alerts:
Debian DSA-2391-1 phpmyadmin 2012-01-22
Gentoo 201201-01 phpmyadmin 2012-01-04
Mandriva MDVSA-2011:198 phpmyadmin 2011-12-31
Fedora FEDORA-2011-15841 phpMyAdmin 2011-11-13
Fedora FEDORA-2011-15846 phpMyAdmin 2011-11-13
Fedora FEDORA-2011-15831 phpMyAdmin 2011-11-13

Comments (none posted)

software-center: man-in-the-middle attack/information disclosure

Package(s):software-center CVE #(s):CVE-2011-3150
Created:November 21, 2011 Updated:November 23, 2011
Description: From the Ubuntu advisory:

David B. discovered that Software Center incorrectly validated server certificates when performing secure connections. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to view sensitive information or install altered packages and repositories.

Alerts:
Ubuntu USN-1270-1 software-center 2011-11-21

Comments (none posted)

spip: privilege escalation/cross-site scripting

Package(s):spip CVE #(s):
Created:November 21, 2011 Updated:November 23, 2011
Description: From the Debian advisory:

Two vulnerabilities have been found in SPIP, a website engine for publishing, which allow privilege escalation to site administrator privileges and cross-site scripting.

Alerts:
Debian DSA-2349-1 spip 2011-11-19

Comments (none posted)

squid: denial of service

Package(s):squid CVE #(s):CVE-2011-4096
Created:November 18, 2011 Updated:January 6, 2012
Description: From the Red Hat bugzilla:

An invalid free flaw was found in the way Squid proxy caching server processed DNS requests, where one CNAME record pointed to another CNAME record pointing to an empty A-record. A remote attacker could issue a specially-crafted DNS request, leading to denial of service (squid daemon abort).

Alerts:
Gentoo 201309-22 squid 2013-09-27
openSUSE openSUSE-SU-2012:0213-1 squid3 2012-02-09
Debian DSA-2381-1 squid3 2012-01-06
CentOS CESA-2011:1791 squid 2011-12-22
Oracle ELSA-2011-1791 squid 2011-12-17
Mandriva MDVSA-2011:193 squid 2011-12-27
Scientific Linux SL-squi-20111206 squid 2011-12-06
Red Hat RHSA-2011:1791-01 squid 2011-12-06
Fedora FEDORA-2011-15233 squid 2011-11-02
Fedora FEDORA-2011-15256 squid 2011-11-02
SUSE SUSE-SU-2016:1996-1 squid3 2016-08-09
SUSE SUSE-SU-2016:2089-1 squid3 2016-08-16

Comments (none posted)

system-config-printer: man-in-the-middle package installation

Package(s):system-config-printer CVE #(s):CVE-2011-4405
Created:November 17, 2011 Updated:November 23, 2011
Description:

From the Ubuntu advisory:

Marc Deslauriers discovered that system-config-printer's cupshelpers scripts used by the Ubuntu automatic printer driver download service queried the OpenPrinting database using an insecure connection. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to install altered packages and repositories.

Alerts:
openSUSE openSUSE-SU-2011:1331-2 system-config-printer 2012-01-16
openSUSE openSUSE-SU-2011:1331-1 system-config-printer 2011-12-16
Ubuntu USN-1265-1 system-config-printer 2011-11-17

Comments (none posted)

tintin: multiple vulnerabilities

Package(s):tintin CVE #(s):CVE-2008-0671 CVE-2008-0672 CVE-2008-0673
Created:November 21, 2011 Updated:November 23, 2011
Description: From the Gentoo advisory:

Multiple vulnerabilities have been discovered in TinTin++. Remote unauthenticated attackers may be able to execute arbitrary code with the privileges of the TinTin++ process, cause a Denial of Service, or truncate arbitrary files in the top level of the home directory belonging to the user running the TinTin++ process.

Alerts:
Gentoo 201111-07 tintin 2011-11-20

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds