Paul Wouters gave a presentation on DNSSEC (Domain Name System Security
Extensions) on the first day of the 2012
Linux Security Summit (LSS). It was a "pretty generic" look at DNSSEC,
giving an overview of what it is and does. He also talked about some of
the problems that can occur when using DNSSEC, particularly with
hotspots or VPNs, along with some interesting applications that a secure
data distribution mechanism will allow.
As the subtitle to Wouters's talk described, DNSSEC is a "cryptographically
secured globally distributed database". But, not many people are actually
running DNSSEC, at least yet. He would like to see that change, because
DNSSEC has uses beyond just securing DNS. It can be used to safely distribute
content that can't be modified.
Digging for DNSSEC information
Wouters stepped through some examples of using the dig program to
query for DNSSEC information. The first thing to note when doing DNSSEC
queries is the Authenticated Data (ad) flag that is reported in the
results. It indicates that the results were validated by the recursive
name server. So, an A (address) record returned from the name
server with
the ad flag is simply a claim by that server that it did the
necessary verification. In order to be sure of the authenticity, though,
the local name server needs to do its own verification.
One can retrieve the signature that corresponds to a
given A record, using a command like:
$ dig +dnssec fedoraproject.org
To verify the mapping from name to IP address, DNSSEC resolvers use the signatures returned in the RRSIG (DNSSEC signature)
record. In order to reduce the processing burden, DNSSEC servers
typically do not do any cryptographic operations on the fly, and rely,
instead, on pre-generated signatures. The signatures for each host in
the domain are generated elsewhere, then installed on the DNSSEC
server. Signatures have a duration
associated with them, to stop replay
attacks, but that means the signatures need to be periodically
regenerated.
But, the name servers cannot know in advance the queries that might be
made. For example, querying doesnotexist.fedoraproject.org is a
perfectly valid request, but a server can't have canned, signed responses
for each invalid host. So, instead, it returns signed responses for the host
names alphabetically on either side of the requested name as
NSEC (next secure) records. Those essentially describe a range of names that do
not exist for the domain. Multiple queries could be used to map the full
namespace of the domain, which is one of the criticisms of DNSSEC. One
could avoid that by having the signing key on
the server to sign the "does not exist" response, but that is generally
considered to
be insecure.
In order to verify the signature on query results, the public key
corresponding to the
private key that
signed the entry must be retrieved. That is available as DNSKEY
record type for the domain. There will often be more than one key defined
for a domain to make it easier to roll over to a new key, Wouters said.
A chain of trust needs to be established in order to verify that the keys
being used are actually those used by the domain. In order to do that, the
parent domain (i.e. org for fedoraproject.org) will have
a hash of the valid keys in use by the child. That information is reported in
DS (delegation signer) records from the parent. That trust chain
can be followed all
the way back to the root zone, whose keys are widely available and are
typically statically stored on the system. These trust chains can be
examined using the drill utility.
When using straight DNS, all answers are considered to be insecure. But,
with DNSSEC, there are several different states that a query answer could be
in. The answer could be verified from a known trust anchor (such as a
root zone key), and thus be "secure". Or it could be proven that there is no
trust anchor that can be used to verify the answer, so it is "insecure" (as
with straight DNS).
But, there are two other states that an answer can be in, Wouters said. The
first is the "bogus" state, which means that the cryptographic verification
failed. That typically results in a SERVFAIL error from the
resolver. There is also the "indeterminate" state, which
indicates that the answers needed to verify the result were missing or
incomplete. The indeterminate state causes lots of problems, he said. It
could be mapped to the bogus state, but that makes it harder for browsers
and other applications to handle "soft failures".
DNSSEC and Linux
Linux distributions have a variety of DNSSEC tools available. For
resolvers, BIND or Unbound are available, with the latter being
preferred for on-the-fly changes. For DNS servers, one should use BIND, NSD, or PowerDNS,
any of which are modern DNS servers that should work fine, he said. To
sign zones, OpenDNSSEC is the most
widely used tool, but there are others, including dnssec-signzone
which is part of BIND. Lastly, there are a number of utilities for
querying and
debugging DNSSEC installations (e.g. dig and drill) that can be found by
doing a package manager search for "dnssec".
Using DNSSEC for name resolution on Fedora or RHEL is very simple, Wouters
said. Installing BIND or Unbound using yum, then doing:
echo "nameserver 127.0.0.1" >/etc/resolv.conf
is all that's needed. DNSSEC has been in the default configuration since
Fedora 15. But, he cautioned, you probably shouldn't do that, at least on a
laptop, because you depend on spoofed DNS all the time.
In some ways, DNSSEC is too good because it blocks operations like hotspot
authentication. The system needs to "know when to accept lies" in DNS
answers, he said. There are also problems with VPNs when there are two
different views of the DNS namespace (i.e. a VPN-internal view and the
external view). Additionally, problems occur because so many different
applications "mess with resolv.conf". Those problems all need to
be addressed at once.
Some recent changes to NetworkManager have been made to help with the
hotspot problem. The new dnssec-triggerd daemon can be used to detect
hotspots and inform NetworkManager, which will ask the user if they are
logging into a hotspot. If so, NetworkManager will change
resolv.conf to temporarily bypass the local DNSSEC-enabled
resolver, allow the user to log in, then re-enable DNSSEC resolution.
Unfortunately, many hotspots also hijack the traffic they carry. That
means that the DNSSEC resolver may not get clean responses even after the
authentication dance. For example, some will filter out signatures, while
others block the DNS port (53) to force users to their (generally
non-DNSSEC) name servers. There are workarounds that dnssec-triggerd
will try (e.g. running DNS over port 80 to suitably configured servers), but
there will be situations where getting DNSSEC responses is not possible.
In that case, NetworkManager asks the user if they want to disable DNS or
run in insecure mode. Dan Walsh pointed out that some organizations may
want to remove that choice, so that users cannot run with regular
DNS. Wouters said that can be configured for those who need it.
VPNs are another problem because there is a need to use internal IP
addresses. To handle that, VPN clients often rewrite the
resolv.conf file, but Fedora has removed that ability from the
Openswan client. Instead, Openswan informs the resolver, which adds entries for
the internal DNS server. Once the VPN link is shut down, the resolver
removes that information.
For signing your own DNSSEC zones, he recommends the OpenDNSSEC package.
It has tools to automatically re-sign zones when they are about to expire
and there are systemd unit files available to control the signing daemon.
Overall, OpenDNSSEC is "working pretty well" for handling all of the
signing chores, he said.
Converting applications
The standard gethostbyname() call that is used to look up host
names from programs does not return DNSSEC information (e.g. whether the
answer was secure or not), so programs that are going to use DNSSEC need to
be changed. Wouters did that conversion for Openswan using libunbound.
The changes are fairly straightforward, and he shows much of the code in
his slides
[PDF]. A DNSSEC cache context is established at program start, and
populated with information from /etc/hosts and
/etc/resolv.conf, as well as with keys for the root zone. It then
makes synchronous calls to ub_resolve() whenever a host name
lookup is needed, returning an error if the reply is not secure.
The conversion was "not rocket science", he said. There are other
alternatives, but he liked the libunbound interface. It supports both callbacks
and threads for asynchronous resolution. In addition, it has good tutorials.
There are several RFCs and draft RFCs for publishing data using the
DNSSEC infrastructure. For example, HTTPS certificates, SSH known_hosts
keys, IPsec public keys, PGP email keys, and others are all possibilities
for being distributed via DNSSEC. He had some other thoughts, including
file hashes (for file integrity checking), SELinux policies, and even a
secure Twitter-like text publishing scheme. There are many different
options, Wouters said, and once DNSSEC becomes pervasive, there is lots
of fun to be had.
Comments (4 posted)
Brief items
Now that we’ve learned that, historically, 8068 is (was?) the least commonly used password 4-digit PIN, please don’t go out and change yours to this! Hackers can read too! They will also be promoting 8068 up their attempt trees in order to catch people who read this (or similar) articles.
--
DataGenetics
looks at 4-digit passwords
Comments (4 posted)
Threatpost is
reporting on a browser vulnerability that affects secure cookies when TLS or SPDY compression is supported. Researchers Juliano Rizzo and Thai Duong, who also discovered the
BEAST flaw, have called the new vulnerability "Compression Ratio Info-leak Made Easy" or CRIME. "
Rizzo said that browsers that implement either TLS or SPDY compression are known to be vulnerable. That includes Google Chrome and Mozilla Firefox, as well as Amazon Silk. But the attack also works against several popular Web services, such as Gmail, Twitter, Dropbox and Yahoo Mail. SPDY is an open standard developed by Google to speed up Web-page load times and often uses TLS encryption.
[...]
Google and Mozilla have developed patches to defend against the CRIME attack, Rizzo said, and the latest versions of Chrome and Firefox are protected. The researchers will present their results at Ekoparty next week." Some speculation on the details can be found at
Stack Exchange.
Comments (23 posted)
New vulnerabilities
asterisk: remote command execution
| Package(s): | asterisk |
CVE #(s): | CVE-2012-2186
|
| Created: | September 18, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the CVE entry:
Incomplete blacklist vulnerability in main/manager.c in Asterisk Open Source 1.8.x before 1.8.15.1 and 10.x before 10.7.1, Certified Asterisk 1.8.11 before 1.8.11-cert6, Asterisk Digiumphones 10.x.x-digiumphones before 10.7.1-digiumphones, and Asterisk Business Edition C.3.x before C.3.7.6 allows remote authenticated users to execute arbitrary commands by leveraging originate privileges and providing an ExternalIVR value in an AMI Originate action. |
| Alerts: |
|
Comments (none posted)
asterisk: ignores ACL rules
| Package(s): | asterisk |
CVE #(s): | CVE-2012-4737
|
| Created: | September 18, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the Asterisk advisory:
When an IAX2 call is made using the credentials of a peer defined in a dynamic Asterisk Realtime Architecture (ARA) backend, the ACL rules for that peer are not applied to the call attempt. This allows for a remote attacker who is aware of a peer's credentials to bypass the ACL rules set for that peer. |
| Alerts: |
|
Comments (none posted)
bind9: denial of service
| Package(s): | bind9 |
CVE #(s): | CVE-2012-4244
|
| Created: | September 13, 2012 |
Updated: | October 15, 2012 |
| Description: |
From the Debian advisory:
It was discovered that BIND, a DNS server, does not handle DNS records
properly which approach size limits inherent to the DNS protocol. An
attacker could use crafted DNS records to crash the BIND server
process, leading to a denial of service. |
| Alerts: |
|
Comments (none posted)
blender: insecure temporary files
| Package(s): | blender |
CVE #(s): | CVE-2012-4410
|
| Created: | September 18, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the Red Hat bugzilla:
An insecure temporary file use flaw was found in the way 'undo save quit' routine of Blender kernel of Blender, a 3D modeling, animation, rendering and post-production software solution, performed management of 'quit.blend' temporary file, used for session recovery purposes. A local attacker could use this flaw to conduct symbolic link attacks, leading to ability to overwrite arbitrary system file, accessible with the privileges of the user running the blender executable. |
| Alerts: |
|
Comments (none posted)
chromium: multiple vulnerabilities
| Package(s): | chromium |
CVE #(s): | CVE-2012-2865
CVE-2012-2866
CVE-2012-2867
CVE-2012-2868
CVE-2012-2869
CVE-2012-2872
|
| Created: | September 19, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the CVE entries:
Google Chrome before 21.0.1180.89 does not properly perform line breaking, which allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted document. (CVE-2012-2865)
Google Chrome before 21.0.1180.89 does not properly perform a cast of an unspecified variable during handling of run-in elements, which allows remote attackers to cause a denial of service or possibly have unknown other impact via a crafted document. (CVE-2012-2866)
The SPDY implementation in Google Chrome before 21.0.1180.89 allows remote attackers to cause a denial of service (application crash) via unspecified vectors. (CVE-2012-2867)
Race condition in Google Chrome before 21.0.1180.89 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors involving improper interaction between worker processes and an XMLHttpRequest (aka XHR) object. (CVE-2012-2868)
Google Chrome before 21.0.1180.89 does not properly load URLs, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors that trigger a "stale buffer." (CVE-2012-2869)
Cross-site scripting (XSS) vulnerability in an SSL interstitial page in Google Chrome before 21.0.1180.89 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. (CVE-2012-2872) |
| Alerts: |
|
Comments (none posted)
dbus: root code execution
| Package(s): | dbus-1 |
CVE #(s): | CVE-2012-3524
|
| Created: | September 13, 2012 |
Updated: | April 9, 2013 |
| Description: |
From the SUSE advisory:
This update fixes a vulnerability in the DBUS
auto-launching feature that allowed local users to execute
arbitrary programs as root. |
| Alerts: |
|
Comments (none posted)
devscripts: multiple vulnerabilities
| Package(s): | devscripts |
CVE #(s): | CVE-2012-2240
CVE-2012-2241
CVE-2012-2242
|
| Created: | September 17, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the Debian advisory:
CVE-2012-2240:
Raphael Geissert discovered that dscverify does not perform
sufficient validation and does not properly escape arguments to
external commands, allowing a remote attacker (as when dscverify is
used by dget) to execute arbitrary code.
CVE-2012-2241:
Raphael Geissert discovered that dget allows an attacker to delete
arbitrary files when processing a specially-crafted .dsc or
.changes file, due to insuficient input validation.
CVE-2012-2242:
Raphael Geissert discovered that dget does not properly escape
arguments to external commands when processing .dsc and .changes
files, allowing an attacker to execute arbitrary code.
This issue is limited with the fix for CVE-2012-2241, and had
already been fixed in version 2.10.73 due to changes to the code,
without considering its security implications. |
| Alerts: |
|
Comments (none posted)
dhcp: denial of service
| Package(s): | dhcp |
CVE #(s): | CVE-2012-3955
|
| Created: | September 14, 2012 |
Updated: | March 11, 2013 |
| Description: |
From the Mageia advisory:
In the ISC DHCP server, prior to 4.2.4-P2, reducing the expiration time
for an active IPv6 lease may cause the server to crash (CVE-2012-3955). |
| Alerts: |
|
Comments (none posted)
gnupg: key spoofing
| Package(s): | gnupg, gnupg2 |
CVE #(s): | |
| Created: | September 17, 2012 |
Updated: | September 21, 2012 |
| Description: |
From the Ubuntu advisory:
It was discovered that GnuPG used a short ID when downloading keys from a
keyserver, even if a long ID was requested. An attacker could possibly use
this to return a different key with a duplicate short key id. |
| Alerts: |
|
Comments (1 posted)
horizon: cross-site scripting
| Package(s): | horizon |
CVE #(s): | CVE-2012-3540
|
| Created: | September 13, 2012 |
Updated: | October 24, 2012 |
| Description: |
From the Ubuntu advisory:
Thomas Biege discovered that the Horizon authentication mechanism
did not validate the next parameter. An attacker could use this to
construct a link to legitimate OpenStack web dashboard that redirected
the user to a malicious website after authentication.
|
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | linux |
CVE #(s): | CVE-2012-3412
CVE-2012-3511
|
| Created: | September 17, 2012 |
Updated: | November 7, 2012 |
| Description: |
From the Ubuntu advisory:
Ben Hutchings reported a flaw in the Linux kernel with some network drivers
that support TSO (TCP segment offload). A local or peer user could exploit
this flaw to to cause a denial of service. (CVE-2012-3412)
A flaw was discovered in the madvise feature of the Linux kernel's memory
subsystem. An unprivileged local user could exploit the flaw to cause a
denial of service (crash the system). (CVE-2012-3511) |
| Alerts: |
|
Comments (none posted)
keystone: privilege escalation
| Package(s): | keystone |
CVE #(s): | CVE-2012-4413
|
| Created: | September 13, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the Ubuntu advisory:
Dolph Mathews discovered that when roles are granted and revoked to
users in Keystone, pre-existing tokens were not updated or invalidated
to take the new roles into account. An attacker could use this to
continue to access resources that have been revoked.
|
| Alerts: |
|
Comments (none posted)
libxslt: denial of service
| Package(s): | libxslt |
CVE #(s): | CVE-2012-2870
CVE-2012-2871
|
| Created: | September 14, 2012 |
Updated: | October 4, 2012 |
| Description: |
From the Red Hat advisory:
libxslt 1.1.26 and earlier, as used in Google Chrome before 21.0.1180.89, does not properly manage memory, which might allow remote attackers to cause a denial of service (application crash) via a crafted XSLT expression that is not properly identified during XPath navigation, related to (1) the xsltCompileLocationPathPattern function in libxslt/pattern.c and (2) the xsltGenerateIdFunction function in libxslt/functions.c. (CVE-2012-2870)
libxml2 2.9.0-rc1 and earlier, as used in Google Chrome before 21.0.1180.89, does not properly support a cast of an unspecified variable during handling of XSL transforms, which allows remote attackers to cause a denial of service or possibly have unknown other impact via a crafted document, related to the _xmlNs data structure in include/libxml/tree.h. (CVE-2012-2871) |
| Alerts: |
|
Comments (none posted)
mcrypt: code execution
| Package(s): | mcrypt |
CVE #(s): | CVE-2012-4409
|
| Created: | September 19, 2012 |
Updated: | October 17, 2012 |
| Description: |
From the Red Hat bugzilla:
A buffer overflow was reported in mcrypt version 2.6.8 and earlier due to a boundary error in the processing of an encrypted file (via the check_file_head() function in src/extra.c). If a user were tricked into attempting to decrypt a specially-crafted .nc encrypted flie, this flaw would cause a stack-based buffer overflow that could potentially lead to arbitrary code execution. |
| Alerts: |
|
Comments (none posted)
openjpeg: code execution
| Package(s): | openjpeg |
CVE #(s): | CVE-2012-3535
|
| Created: | September 17, 2012 |
Updated: | November 2, 2012 |
| Description: |
From the Red Hat advisory:
It was found that OpenJPEG failed to sanity-check an image header field
before using it. A remote attacker could provide a specially-crafted image
file that could cause an application linked against OpenJPEG to crash or,
possibly, execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
otrs: cross-site scripting
| Package(s): | otrs |
CVE #(s): | CVE-2012-4600
|
| Created: | September 19, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the CVE entry:
Cross-site scripting (XSS) vulnerability in Open Ticket Request System (OTRS) Help Desk 2.4.x before 2.4.14, 3.0.x before 3.0.16, and 3.1.x before 3.1.10, when Firefox or Opera is used, allows remote attackers to inject arbitrary web script or HTML via an e-mail message body with nested HTML tags. |
| Alerts: |
|
Comments (none posted)
php: header injection
| Package(s): | PHP5 |
CVE #(s): | CVE-2011-1398
CVE-2011-4388
|
| Created: | September 13, 2012 |
Updated: | February 28, 2013 |
| Description: |
From the Ubuntu advisory:
It was discovered that PHP incorrectly handled certain character sequences
when applying HTTP response-splitting protection. A remote attacker could
create a specially-crafted URL and inject arbitrary headers.
(CVE-2011-1398, CVE-2012-4388) |
| Alerts: |
|
Comments (none posted)
php5: header injection
| Package(s): | php5 |
CVE #(s): | CVE-2012-4388
|
| Created: | September 17, 2012 |
Updated: | September 19, 2012 |
| Description: |
From the CVE entry:
The sapi_header_op function in main/SAPI.c in PHP 5.4.0RC2 through 5.4.0 does not properly determine a pointer during checks for %0D sequences (aka carriage return characters), which allows remote attackers to bypass an HTTP response-splitting protection mechanism via a crafted URL, related to improper interaction between the PHP header function and certain browsers, as demonstrated by Internet Explorer and Google Chrome. NOTE: this vulnerability exists because of an incorrect fix for CVE-2011-1398.
|
| Alerts: |
|
Comments (none posted)
spice-gtk: privilege escalation
| Package(s): | spice-gtk |
CVE #(s): | CVE-2012-4425
|
| Created: | September 18, 2012 |
Updated: | October 4, 2012 |
| Description: |
From the Red Hat advisory:
It was discovered that the spice-gtk setuid helper application,
spice-client-glib-usb-acl-helper, did not clear the environment variables
read by the libraries it uses. A local attacker could possibly use this
flaw to escalate their privileges by setting specific environment variables
before running the helper application. |
| Alerts: |
|
Comments (none posted)
tor: denial of service
| Package(s): | tor |
CVE #(s): | CVE-2012-4419
|
| Created: | September 14, 2012 |
Updated: | February 4, 2013 |
| Description: |
From the Debian advisory:
By providing specially crafted date strings to a victim tor instance,
an attacker can cause it to run into an assertion and shut down |
| Alerts: |
|
Comments (none posted)
wordpress: largely unspecified
| Package(s): | wordpress |
CVE #(s): | |
| Created: | September 13, 2012 |
Updated: | April 11, 2013 |
| Description: |
From the WordPress release announcement:
Version 3.4.2 also fixes a few security issues and contains some security hardening. The vulnerabilities included potential privilege escalation and a bug that affects multisite installs with untrusted users. These issues were discovered and fixed by the WordPress security team. |
| Alerts: |
|
Comments (none posted)
ypserv: memory leaks
| Package(s): | ypserv |
CVE #(s): | |
| Created: | September 19, 2012 |
Updated: | September 19, 2012 |
| Description: |
ypserv 2.29 fixes some memory leaks. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>
