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

Security

TACK: TLS key pinning for everyone

By Nathan Willis
May 31, 2012

Moxie Marlinspike and Trevor Perrin have created a TLS enhancement called Trust Assertions for Certificate Keys (TACK) that is designed to protect users against SSL certificate fraud with minimal overhead or infrastructure. The TACK proposal has been submitted to the IETF, as has a competing key-pinning mechanism created by Google's Chrome team. Although the two systems share broad similarities, their implementations are quite different.

The trouble

TACK is designed to combat flaws with the certificate authority (CA) trust chain model used by applications to check the validity of a remote site's TLS public key. The entire CA chain can be undermined by one bad CA, but there are other difficulties, too. First, any given hostname (e.g., www.example.net) can map to several different servers, with several certificate and thus several different CA chains deployed at once (e.g., in different jurisdictions) — which makes it harder to verify a connection. Second, the CA chain itself may change at any time, due to CA actions that are outside the control of the www.example.net site administrators.

There have been plenty of previous approaches to circumventing CA problems (including Marlinspike's own Convergence). "Certificate pinning" is a client-side technique in which the browser remembers (or "pins") a known-good SSL certificate across multiple browser sessions, and alerts the user if the certificate suddenly seems to change. The TACK proposal argues that certificate pinning is flawed because it binds the trust not to the server's TLS key but to the certificate, which includes the key plus the CA's signature and various other metadata. Thus, by extension, pinning the entire certificate ties trust of the server's TLS key to trust of the CA.

Google Chrome added a key-pinning feature (which tracks known-good TLS keys, even though it is often erroneously referred to as "certificate pinning") with Chrome 13 in mid-2011. But the TACK project says that this, too, has its flaws. First, Chrome's key-pinning uses a whitelist approach, with the browser designating specific CAs as trustworthy. But as long as the CA chain includes a whitelisted CA anywhere in the chain, the whole chain is trusted. Second, if a server issues a new TLS key, it does not roll out to users until a new version of Chrome is released.

TACK

In TACK, the identity-verification mechanism is also key-pinning, but rather than pinning a CA key, the browser pins a special "TACK" data structure created and controlled independently by the web site's administrators. The TACK includes a cryptographic signature of the site's TLS key, plus a public encryption key that the browser can use to verify the signature. Obviously the TACK public key and the TLS public key need to be different. In addition to this basic identity information, the TACK also includes an expiration date and a "generation" counter that gets incremented every time the site administrator creates a new TACK (so that old TACKs can be revoked if necessary). The final piece of the puzzle is that TACK is an extension to TLS itself, rather than an extension to HTTP as in Google's pinning proposal.

In practice, when the client application initiates a TLS connection, it requests a TACK from the server as part of the handshake step. When the server sends a TACK back in return, the client checks the generation information against its current cache for the site (if it has one), checks the expiration date, and validates the signature. If everything checks out, the TACK is "pinned" locally for future reference. The client can still choose to verify the CA chain or use other means to cross-check the identity of the server.

When the client pins a TACK, it is supposed to assign a cache lifespan to it equal to the amount of time between when it first saw the TACK and the present — up to a maximum of 30 days. In other words, a TACK that was first encountered seven days ago gets pinned for another seven days, while a TACK from one year ago gets the 30-day maximum. In the maximum-lifespan case, however, the TACK will only remain in the local cache if the user has returned to the site at least once every 30 days; otherwise it will have expired on the 31st day and a new pin will be created.

The big drawback of the TACK mechanism is that, like other client-side key-pinning methods, it does not protect the user against a man-in-the-middle (MITM) attack during the very first connection attempt to the remote server. It relies on the client having known-good information pinned locally. On the other hand, the TACK generation, cache lifespan, and expiration date features are intended to mitigate the damage that a MITM attack can inflict.

The worst-case scenario is a bad pin that lingers for 30 days, which is half the time the rogue google.com certificate issued by DigiNotar lingered in 2011 — and it could have lasted much longer had it not been discovered. Another advantage of TACK's design is that in the worst-case scenario, the server administrator can single-handedly push out an update, rather waiting on the CA or another party.

But TACK's developers also note that there is no reason that TACKs must only be retrieved "live" by the browser. Search engines could index well-known TACKs and browser-makers could pre-load lists of them into their applications. The TACK team has posted example TACK code for Apache and OpenSSL, plus a Python tool for making TACK requests.

Google, pins, and the future

Google submitted its own key-pinning proposal to the IETF, based on an evolution of its original feature in Chrome. The Google proposal is similar in many ways to TACK. For starters, unlike the built-in pinning currently found in Chrome, it allows each client application to check and cache its own pins rather than depend on a vendor-supplied list. It also pins individual site keys rather than CA keys, so it is independent of the CA chain-of-trust.

Google's pin format includes a max-age field, which takes the place both of TACK's expiration date and its maximum cache-lifespan criteria. Google's proposal does not track generations, however. To recover from a lost or stolen pin-signing key, it instead mandates that server administrators keep a "Backup Pin" — a second, un-deployed signing key that the administrators must store offline. The key fingerprint of the Backup Pin is published by the server, though, so that clients will recognize it if it needs to be deployed. Presumably when the Backup Pin is deployed, the administrators will then need to create a new, backup backup Pin.

There are other details that differ between the proposals (such as what signature algorithms are required), but the most fundamental difference is that Google's pinning proposal is an extension to HTTP: servers send their pinnable key signatures in a new HTTP header, rather than as part of the TLS handshake. TACK's proponents argue that because the CA weakness is fundamentally a TLS problem, it should be fixed in TLS itself, and that building an HTTP-based solution leaves other important protocols (e.g., IMAP and POP3) unprotected. HTTP proponents argue that an HTTP solution is easier to deploy due to the difficulty of setting up a TLS stack, and that HTTP protects the most attack targets.

As of today, TACK is being discussed by the IETF's TLS Working Group. It is a new enough proposal that it is likely to see revisions before it advances any further in the IETF standards process. Google's key pinning proposal was accepted as an Internet-Draft by the Web Security Working Group in December. Whichever makes it to broad browser and server acceptance first, it is fair to say that users will start hearing more about "pinning" in one form or another — but they still should not expect the CA system to disappear any time soon.

Comments (2 posted)

Brief items

Security quotes of the week

This has been a public service announcement made necessary by some damn' fool European Commission directive that confused a goal (securing web users' privacy) with a technology (cookies). Film at eleven.
-- Charlie Stross

Let's say you chose NOT to accept any cookies from bbc.com (most people are going to tend toward a binary decision -- all or none -- not try to micromanage their cookies). The result of blocking all BBC cookies will be that (apparently) you'll be forced to see this banner over and over and over ... and over again. How do you stop it? By accepting BBC cookies of course!
-- Lauren Weinstein

When I helped to develop the open standards that computers use to communicate with one another across the Net, I hoped for but could not predict how it would blossom and how much human ingenuity it would unleash. What secret sauce powered its success? The Net prospered precisely because governments — for the most part — allowed the Internet to grow organically, with civil society, academia, private sector and voluntary standards bodies collaborating on development, operation and governance.
-- Vint Cerf worries about the future of the internet

Even though humans produce distributions with pitifully few bits of security, I think passwords will always be with us. As one component in a system with many layers, passwords can be valuable as a low-cost authentication mechanism which nearly all people can do with no special equipment. The important thing is to stop considering them the first and last step in authentication.
-- Joseph Bonneau

These days I'd argue that multi-user is such a corner case that it's not worth optimizing for it as far as defaults are concerned. If you're trying to run a secure multi-user system, you need to be an expert system administrator, keep up with all security patches, and even then, good luck to you. (The reality is that these days, no matter what OS you're talking about, shell == root. And that's probably even true on the most unusably locked down SELinux system.)
-- Ted Ts'o

Comments (53 posted)

SSL fix flags forged certificates before they're accepted by browsers (Ars Technica)

Over at Ars Technica, Dan Goodin writes about Trust Assertions for Certificate Keys (TACK), a proposed extension to SSL/TLS designed to discover fake certificates before they are accepted. "The opt-in system works by allowing SSL sites to sign valid SSL certificates, the domain name, and an expiration date with a TACK key. Once an end user has visited the site a few times using a TACK-compatible browser, a 'pin' for that site is activated on the user's computer. If the end user later encounters a forged certificate for that same site—as was the case when DigiNotar was breached—the browser will reject the session and return a warning to the user." One of TACK's co-creators is Moxie Marlinspike, who proposed the Convergence alternative certificate-management framework in 2011.

Comments (21 posted)

Android Malware Genome Project launched (The H)

The H covers the debut of the Android Malware Genome Project by researchers from North Carolina State University. The team "has already collected more than 1,200 samples of Android malware, including GingerMaster and DroidKungFu, and has organised them into various malware families. [Xuxian] Jiang told Dark Reading that 'the purpose is to engage the research community to better our understanding of mobile threats and develop effective solutions against them.'" Access to the data set, however, is restricted.

Comments (2 posted)

Implementing UEFI Secure Boot in Fedora

On his blog, Matthew Garrett writes about plans for supporting UEFI secure boot in Fedora 18. In it he covers signing the first-stage bootloader with a Microsoft key, while signing GRUB 2, the kernel, modules, etc. with a Fedora key. It is a compromise to try to avoid problems for users who want to boot Linux on Windows 8 hardware. "The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key."

Comments (107 posted)

New vulnerabilities

chromium: multiple vulnerabilities

Package(s):chromium CVE #(s):CVE-2011-3103 CVE-2011-3104 CVE-2011-3105 CVE-2011-3106 CVE-2011-3107 CVE-2011-3108 CVE-2011-3109 CVE-2011-3111 CVE-2011-3115
Created:May 29, 2012 Updated:May 31, 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.

Alerts:
Gentoo 201205-04 chromium 2012-05-27

Comments (none posted)

cobbler: remote code execution

Package(s):cobbler CVE #(s):CVE-2012-2395
Created:May 29, 2012 Updated:July 3, 2012
Description: From the Novell bugzilla:

David Black has recently reported a remote code execution flaw in cobbler.

Alerts:
SUSE SUSE-SU-2012:0814-1 cobbler 2012-07-03
openSUSE openSUSE-SU-2012:0655-1 cobbler 2012-05-29

Comments (none posted)

dokuwiki: cross-site scripting/request forgery

Package(s):dokuwiki CVE #(s):CVE-2012-2129 CVE-2012-2128
Created:May 29, 2012 Updated:August 13, 2012
Description: From the Red Hat bugzilla:

A cross-site scripting (XSS) and cross-site request forgery (CSRF) flaws were found in the way DokuWiki, a standards compliant, simple to use Wiki, performed sanitization of the 'target' parameter when preprocessing edit form data. A remote attacker could provide a specially-crafted URL, which once visited by a valid DokuWiki user would lead to arbitrary HTML or web script execution in the context of logged in DokuWiki user.

Alerts:
Mageia MGASA-2012-0207 dokuwiki 2012-08-12
Fedora FEDORA-2012-6630 dokuwiki 2012-06-12
Fedora FEDORA-2012-6628 dokuwiki 2012-05-27

Comments (none posted)

kernel: denial of service

Package(s):kernel CVE #(s):CVE-2012-2375
Created:May 29, 2012 Updated:December 19, 2012
Description: From the Red Hat bugzilla:

The fix for CVE-2011-4131 was not complete. Malicious NFS server could still crash the clients when returns more than 2 GETATTR bitmap words in response to the FATTR4_ACL attribute request.

Alerts:
Red Hat RHSA-2014:0284-01 kernel 2014-03-11
Scientific Linux SLSA-2013:1645-2 kernel 2013-12-16
Oracle ELSA-2013-1645 kernel 2013-11-26
Red Hat RHSA-2013:1645-02 kernel 2013-11-21
Red Hat RHSA-2013:0566-01 kernel-rt 2013-03-06
Oracle ELSA-2013-2507 kernel 2013-02-28
Oracle ELSA-2012-2047 kernel 2012-12-20
Oracle ELSA-2012-2047 kernel 2012-12-20
Oracle ELSA-2012-1580 kernel 2012-12-19
Scientific Linux SL-kern-20121219 kernel 2012-12-19
CentOS CESA-2012:1580 kernel 2012-12-19
Red Hat RHSA-2012:1580-01 kernel 2012-12-18
Ubuntu USN-1530-1 linux-ti-omap4 2012-08-10
Ubuntu USN-1499-1 linux-ti-omap4 2012-07-08
Ubuntu USN-1494-1 linux-ti-omap4 2012-07-02
Ubuntu USN-1490-1 linux-lts-backport-natty 2012-06-29
Ubuntu USN-1489-1 linux-lts-backport-oneiric 2012-06-29
Ubuntu USN-1488-1 linux 2012-06-29
Ubuntu USN-1487-1 linux 2012-06-29
Ubuntu USN-1486-1 linux 2012-06-29
SUSE SUSE-SU-2012:0789-1 Linux kernel 2012-06-26
Fedora FEDORA-2012-8359 kernel 2012-05-27

Comments (none posted)

kernel: privilege escalation

Package(s):kernel CVE #(s):CVE-2012-2136
Created:May 30, 2012 Updated:November 5, 2012
Description: From the Red Hat advisory:

It was found that the data_len parameter of the sock_alloc_send_pskb() function in the Linux kernel's networking implementation was not validated before use. A local user with access to a TUN/TAP virtual interface could use this flaw to crash the system or, potentially, escalate their privileges. Note that unprivileged users cannot access TUN/TAP devices until the root user grants them access.

Alerts:
Oracle ELSA-2013-1645 kernel 2013-11-26
SUSE SUSE-SU-2012:1391-1 Linux kernel 2012-10-24
Ubuntu USN-1598-1 linux 2012-10-09
openSUSE openSUSE-SU-2012:1439-1 kernel 2012-11-05
Ubuntu USN-1529-1 linux 2012-08-10
Ubuntu USN-1539-1 linux-lts-backport-oneiric 2012-08-14
Ubuntu USN-1538-1 linux-lts-backport-natty 2012-08-14
Ubuntu USN-1535-1 linux 2012-08-10
Ubuntu USN-1533-1 linux 2012-08-10
Ubuntu USN-1531-1 linux 2012-08-10
Ubuntu USN-1530-1 linux-ti-omap4 2012-08-10
Ubuntu USN-1514-1 linux-ti-omap4 2012-08-10
Ubuntu USN-1534-1 linux-ec2 2012-08-10
Ubuntu USN-1532-1 linux-ti-omap4 2012-08-10
Red Hat RHSA-2012:1087-01 kernel 2012-07-17
openSUSE openSUSE-SU-2012:0812-1 kernel 2012-07-03
Oracle ELSA-2012-0862 kernel 2012-07-02
Oracle ELSA-2012-2022 kernel 2012-07-02
Oracle ELSA-2012-2022 kernel 2012-07-02
openSUSE openSUSE-SU-2012:0799-1 kernel 2012-06-28
SUSE SUSE-SU-2012:0789-1 Linux kernel 2012-06-26
Oracle ELSA-2012-2021 kernel 2012-06-23
Oracle ELSA-2012-2021 kernel 2012-06-23
openSUSE openSUSE-SU-2012:0781-1 kernel 2012-06-22
Oracle ELSA-2012-0743 kernel 2012-06-21
Oracle ELSA-2012-2020 kernel 2012-06-21
Oracle ELSA-2012-0690 kernel 2012-05-31
Red Hat RHSA-2012:0690-01 kernel 2012-05-29
Scientific Linux SL-kern-20120619 kernel 2012-06-19
CentOS CESA-2012:0743 kernel 2012-06-19
Red Hat RHSA-2012:0743-01 kernel 2012-06-18
Scientific Linux SL-kern-20120531 kernel 2012-05-31
CentOS CESA-2012:0690 kernel 2012-05-29

Comments (none posted)

mailman: information disclosure

Package(s):mailman CVE #(s):CVE-2002-0389
Created:May 29, 2012 Updated:May 31, 2012
Description: From the CVE entry:

Pipermail in Mailman stores private mail messages with predictable filenames in a world-executable directory, which allows local users to read private mailing list archives.

Alerts:
Scientific Linux SLSA-2015:1417-1 mailman 2015-08-03
Oracle ELSA-2015-1417 mailman 2015-07-29
Red Hat RHSA-2015:1417-01 mailman 2015-07-22
openSUSE openSUSE-SU-2012:0660-1 mailman 2012-05-29

Comments (none posted)

net-snmp: denial of service

Package(s):net-snmp CVE #(s):CVE-2012-2141
Created:May 24, 2012 Updated:April 8, 2013
Description: From the Ubuntu advisory:

It was discovered that Net-SNMP incorrectly performed entry lookups in the extension table. A remote attacker could send a specially crafted request and cause the SNMP server to crash, leading to a denial of service.

Alerts:
Gentoo 201409-02 net-snmp 2014-09-01
Mandriva MDVSA-2013:049 net-snmp 2013-04-05
CentOS CESA-2013:0124 net-snmp 2013-01-09
Oracle ELSA-2013-0124 net-snmp 2013-01-12
Fedora FEDORA-2012-16659 net-snmp 2012-10-31
Fedora FEDORA-2012-16662 net-snmp 2012-10-31
Scientific Linux SL-net--20130116 net-snmp 2013-01-16
CentOS CESA-2012:0876 net-snmp 2012-07-10
Scientific Linux SL-net--20120709 net-snmp 2012-07-09
Oracle ELSA-2012-0876 net-snmp 2012-07-02
Mageia MGASA-2012-0128 net-snmp 2012-06-27
Mandriva MDVSA-2012:099 net-snmp 2012-06-21
openSUSE openSUSE-SU-2012:0659-1 net-snmp 2012-05-29
Red Hat RHSA-2012:0876-04 net-snmp 2012-06-20
Ubuntu USN-1450-1 net-snmp 2012-05-23

Comments (none posted)

pidgin: multiple vulnerabilities

Package(s):pidgin CVE #(s):CVE-2012-2214 CVE-2012-2318
Created:May 29, 2012 Updated:March 15, 2013
Description: From the Mandriva advisory:

Multiple vulnerabilities have been discovered and corrected in pidgin:

A series of specially crafted file transfer requests can cause clients to reference invalid memory. The user must have accepted one of the file transfer requests (CVE-2012-2214).

Incoming messages with certain characters or character encodings can cause clients to crash (CVE-2012-2318).

Alerts:
Oracle ELSA-2013-0646 pidgin 2013-03-14
Scientific Linux SL-pidg-20120719 pidgin 2012-07-19
Oracle ELSA-2012-1102 pidgin 2012-07-20
CentOS CESA-2012:1102 pidgin 2012-07-19
CentOS CESA-2012:1102 pidgin 2012-07-19
Red Hat RHSA-2012:1102-01 pidgin 2012-07-19
openSUSE openSUSE-SU-2012:0866-1 pidgin 2012-07-11
Ubuntu USN-1500-1 pidgin 2012-07-09
SUSE SUSE-SU-2012:0782-1 finch, libpurple and pidgin 2012-06-22
Fedora FEDORA-2012-8669 pidgin 2012-06-10
Fedora FEDORA-2012-8686 pidgin 2012-06-10
Mandriva MDVSA-2012:082 pidgin 2012-05-28
Fedora FEDORA-2012-8687 pidgin 2012-06-03

Comments (none posted)

python: insecure file creation

Package(s):python CVE #(s):CVE-2011-4944
Created:May 30, 2012 Updated:October 18, 2012
Description: From the Novell bugzilla:

python distutils first creates ~/.pypirc and then calls chmod() to restrict permissions. This allows for a time window where the file is readable by others.

Alerts:
Mandriva MDVSA-2013:117 python 2013-04-10
Ubuntu USN-1615-1 python3.2 2012-10-23
Ubuntu USN-1616-1 python3.1 2012-10-24
Ubuntu USN-1613-1 python2.5 2012-10-17
Ubuntu USN-1613-2 python2.4 2012-10-17
Ubuntu USN-1596-1 python2.6 2012-10-04
Ubuntu USN-1592-1 python2.7 2012-10-02
Mageia MGASA-2012-0170 python 2012-07-19
Mageia MGASA-2012-0169 python 2012-07-19
Mandriva MDVSA-2012:096-1 python 2012-07-02
Mandriva MDVSA-2012:096 python 2012-06-20
Mandriva MDVSA-2012:097 python 2012-06-20
openSUSE openSUSE-SU-2012:0667-1 python 2012-05-30
CentOS CESA-2012:0744 python 2012-06-18
Scientific Linux SL-pyth-20120618 python 2012-06-18
CentOS CESA-2012:0745 python 2012-06-18
Red Hat RHSA-2012:0745-01 python 2012-06-18
Red Hat RHSA-2012:0744-01 python 2012-06-18
Oracle ELSA-2012-0745 python 2012-06-19
Oracle ELSA-2012-0744 python 2012-06-19
Scientific Linux SL-pyth-20120618 python 2012-06-18

Comments (none posted)

python-tornado: HTTP header injection

Package(s):python-tornado CVE #(s):CVE-2012-2374
Created:May 29, 2012 Updated:June 18, 2012
Description: From the CVE entry:

CRLF injection vulnerability in the tornado.web.RequestHandler.set_header function in Tornado before 2.2.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via crafted input.

Alerts:
Fedora FEDORA-2012-8194 python-tornado 2012-05-29
openSUSE openSUSE-SU-2012:0755-1 python-tornado 2012-06-18
Fedora FEDORA-2012-8205 python-tornado 2012-05-29
Fedora FEDORA-2012-8217 python-tornado 2012-05-29

Comments (none posted)

request-tracker3.8: multiple vulnerabilities

Package(s):request-tracker3.8 CVE #(s):CVE-2011-2082 CVE-2011-2083 CVE-2011-2084 CVE-2011-2085 CVE-2011-4458 CVE-2011-4459 CVE-2011-4460
Created:May 25, 2012 Updated:September 17, 2012
Description:

From the Debian advisory:

CVE-2011-2082: The vulnerable-passwords scripts introduced for CVE-2011-0009 failed to correct the password hashes of disabled users.

CVE-2011-2083: Several cross-site scripting issues have been discovered.

CVE-2011-2084: Password hashes could be disclosed by privileged users.

CVE-2011-2085: Several cross-site request forgery vulnerabilities have been found. If this update breaks your setup, you can restore the old behaviour by setting $RestrictReferrer to 0.

CVE-2011-4458: The code to support variable envelope return paths allowed the execution of arbitrary code.

CVE-2011-4459: Disabled groups were not fully accounted as disabled.

CVE-2011-4460: SQL injection vulnerability, only exploitable by privileged users.

Alerts:
Debian DSA-2480-4 request-tracker3.8 2012-09-15
Debian DSA-2480-3 request-tracker3.8 2012-06-07
Fedora FEDORA-2012-8339 rt3 2012-06-02
Fedora FEDORA-2012-8363 rt3 2012-06-02
Fedora FEDORA-2012-8290 rt3 2012-06-01
Debian DSA-2480-1 request-tracker3.8 2012-05-24
Debian DSA-2480-2 request-tracker3.8 2012-05-29

Comments (none posted)

strongswan: authentication bypass

Package(s):strongswan CVE #(s):CVE-2012-2388
Created:May 31, 2012 Updated:April 30, 2013
Description:

From the Debian advisory:

An authentication bypass issue was discovered by the Codenomicon CROSS project in strongSwan, an IPsec-based VPN solution. When using RSA-based setups, a missing check in the gmp plugin could allow an attacker presenting a forged signature to successfully authenticate against a strongSwan responder.

Alerts:
Debian DSA-2483-1 strongswan 2012-05-31
Fedora FEDORA-2012-8821 strongswan 2012-06-10
Fedora FEDORA-2012-8815 strongswan 2012-06-10
openSUSE openSUSE-SU-2012:0691-1 strongswan 2012-06-04

Comments (none posted)

wireshark: denial of service

Package(s):wireshark CVE #(s):CVE-2012-2392 CVE-2012-2393 CVE-2012-2394
Created:May 29, 2012 Updated:July 11, 2012
Description: From the openSUSE advisory:

This update is a maintenance release of Wireshark. It fixes some vulnerabilities when dissecting certain protocols. As packages for these protocols may be received over the network, an attacker may trigger infinite or large loops or crashes of the dissector.

Alerts:
Scientific Linux SLSA-2013:1569-2 wireshark 2013-12-09
Oracle ELSA-2013-1569 wireshark 2013-11-26
Red Hat RHSA-2013:1569-02 wireshark 2013-11-21
Mandriva MDVSA-2013:055 wireshark 2013-04-05
Mageia MGASA-2012-0206 wireshark 2012-08-12
Fedora FEDORA-2012-10175 wireshark 2012-07-10
Mageia MGASA-2012-0134 wireshark 2012-06-27
openSUSE openSUSE-SU-2012:0657-1 wireshark 2012-05-29

Comments (none posted)

xinetd: service disclosure flaw

Package(s):xinetd CVE #(s):CVE-2012-0862
Created:May 29, 2012 Updated:October 9, 2013
Description: From the Red Hat bugzilla:

Thomas Swan reported a service disclosure flaw in xinetd. xinetd allows for services to be configured with the TCPMUX or TCPMUXPLUS service types, which makes those services available on port 1, as per RFC 1078 [1], if the tcpmux-server service is enabled. When the tcpmux-server service is enabled, xinetd would expose _all_ enabled services via the tcpmux port, instead of just the configured service(s). This could allow a remote attacker to bypass firewall restrictions and access services via the tcpmux port.

Alerts:
openSUSE openSUSE-SU-2014:0517-1 xinetd 2014-04-11
openSUSE openSUSE-SU-2014:0494-1 xinetd 2014-04-08
Scientific Linux SLSA-2013:1302-1 xinetd 2013-10-09
Oracle ELSA-2013-1302 xinetd 2013-10-02
Red Hat RHSA-2013:1302-01 xinetd 2013-09-30
CentOS CESA-2013:0499 xinetd 2013-03-09
Scientific Linux SL-xine-20130228 xinetd 2013-02-28
Mandriva MDVSA-2013:057 xinetd 2013-04-08
Oracle ELSA-2013-0499 xinetd 2013-02-25
Red Hat RHSA-2013:0499-02 xinetd 2013-02-21
Mandriva MDVSA-2012:155-1 xinetd 2012-10-02
Mandriva MDVSA-2012:155 xinetd 2012-09-28
Fedora FEDORA-2012-8041 xinetd 2012-05-29
Fedora FEDORA-2012-8061 xinetd 2012-05-29

Comments (none posted)

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


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