By Nathan Willis
June 19, 2013
The Tor project has now posted the first alpha builds of
the soon-to-be-released Tor Browser Bundle 3.0, which provides a newer
and faster anonymous-browsing experience from previous editions, but revamps
a number of interface settings for simplicity. Tor's architecture can
be on the confusing side for many people, so (in theory) improved
ease-of-use translates into fewer accidentally-insecure browsing
sessions. The project is also taking the first steps into other
important features, like a means for verifying binary builds.
The browser at the heart of the Tor
Browser Bundle is a derivative of Firefox; the 3.0 release will be
based on Firefox 17 Extended Support Release (ESR). It incorporates
several changes from the upstream Firefox, including settings and
extensions that guard the user's anonymity and a pre-configured
pipeline to the anonymizing Tor network. In addition to piping all
browser traffic
through Tor, the bundle includes the HTTPS Everywhere extension to
force TLS/SSL connections to a wide variety of sites, NoScript to
selectively disable JavaScript and other executable content, and
Torbutton for one-click toggling of Tor transport.
The new bundles are available
on the Tor site. There are packages for OS X and Windows as well
as both 32-bit and 64-bit Linux systems, all in a variety of
localizations. The Linux builds are compressed tar archives; they can
be uncompressed to virtually any location and run with standard user
permissions.
Previous releases of the bundle included Vidalia, a standalone Tor
controller which allowed the user to start and stop the Tor network
connection, as well as tweak its settings. In the 3.0 browser series,
Vidalia has been replaced with a Tor Launcher browser extension, which
performs the same basic function. Users who require more
customization can still run Vidalia separately. As such, there is a
tad less "bundle" to the new Tor Browser Bundle, but there is also less
complexity to fret over.
This streamlining of the user experience is evidently a conscious
decision on the project's part; it is mentioned first in the blog
announcement of the alpha. But there is more. The new release also
includes a new default home page, a local about:tor URI.
![[Tor Browser about:tor]](/images/2013/06-torbrowser-about-sm.png)
This page provides Tor status information, a "secure search" bar
utilizing the Startpage search
engine, and links to some informational resources about both privacy
and how to get more involved in the Tor project. Perhaps the biggest
difference, though, is that this page reports whether or not Tor
has been successfully started.
This has the potential to be an important change for users in the
field; the old version of the browser was set to visit
https://check.torproject.org/ as the default homepage. While
it, too, checks that Tor is running, it has the drawback of doing so
by immediately requesting a remote page, and that could be a security
risk for those users who run the Tor browser to evade surveillance.
After all, if Tor is not running for some reason when the
browser launches, that information could be intercepted via the HTTPS
request. In addition, although Tor has greatly improved its bandwidth
in recent years, connecting to a remote site could be slow. The about:tor page performs a local test to ensure
that Tor is in fact functioning, and check.torproject.org is
still accessible as a link.
The Tor Launch extension also fires up a "first run" wizard the
first time it is run (obviously) that asks whether the user's
Internet connection is "clear of obstacles" or is
"censored, filtered, or proxied." Choosing the first
option launches Tor in normal mode without any special settings;
choosing the second provides a set of settings windows into which one
can enter proxy addresses, open firewall ports that Tor should use,
and bridge relay
addresses to which Tor should connect. Manually entering bridge
relay addresses is an added security layer; the addresses are not
published, so they are much harder for censors to monitor or block in
advance. On the other hand, one must obtain the addresses "out of
band" so to speak—usually by emailing the Tor project.
![[Tor Browser launcher]](/images/2013/06-torbrowser-launcher-sm.png)
The first-run wizard is a nice feature, although it is puzzling why
it is configured to only run one time. After all, surely it is fairly
common for Tor Browser users to run the software from a laptop. The
user can get to the wizard again by punching the "Options" button on
the "Tor is starting up" window that appears when the browser is launched,
but speed is required on anything resembling modern hardware. On my
machine, the startup window only appeared for 1.5 seconds at most.
Alternatively, resetting the
extensions.torlauncher.prompt_at_startup preference to "true"
in about:config brings it back as well; it is simply odd not
to have a setting available.
There are other changes to the 3.0 alpha builds, including a
"guided" extraction for Windows users, which assists the user to
install the browser in a convenient and hopefully difficult-to-forget
location on the system, and overall reductions in the sizes of the
downloaded packages. All builds are now less than 25MB in size, a
size chosen because it makes it possible to send the package as an
attachment in GMail.
The announcement also highlights a change in the project's build
infrastructure. The Tor Browser Bundle is now built with Gitian trusted-build tool, which is
designed to allow independent developers to compile bit-identical
binaries, thus providing a means for verifying the integrity of a
binary package. The Tor Browser is not yet "quite at the point
where you always get a matching build," the announcement says,
but it is getting closer. Gitian is already in use by a handful of
other projects like Bitcoin.
As a browser, naturally, the Tor Browser is quite solid. The
update to Firefox 17 ESR brings with it a host of improved web
features—although one notable addition, Firefox's built-in PDF
viewer, was not introduced until Firefox 19, so its functionality in
Tor Browser comes via the official
add-on instead. The PDF reader extension is (like more and more
Mozilla projects) implemented in JavaScript. But users will
inevitably find using Tor Browser a somewhat frustrating affair simply
because of how many sites these days rely on JavaScript and
other potentially-privacy-harming techniques. There is no silver bullet for
that problem; the best one can do is delve into NoScript exception
rules to restore functionality for specific, trusted sites.
There does not appear to be a full list of the preferences that Tor
Browser changes from the upstream Firefox release, although there are
several (e.g., it is set to never record browsing history or save
passwords). It is also a bit strange that the bundled extensions do
not include a cookie-management tool, but perhaps this is in the
interest of simplicity for the user. Finally, it is also surprising
that the builds offer no tools for finding Tor hidden
services. Hidden services are not directly related to anonymous
access to the Internet, but the project does use the browser bundle to
promote other efforts, like SSL Observatory, which is
included in the HTTPS Everywhere Extension. Still, perhaps providing
any sort of hidden service index would simply be crossing into
services best left to others.
So far there are few known issues to report, but there will
certainly be some during the alpha and beta testing cycle. The only
real caveat for power users is that the increased simplicity of the
bundle means less flexibility. The absence of Vidalia has already
been mentioned; one can also run the browser with an existing
transparent Tor router (a feature that in previous releases was
explicitly presented to the user) by jumping through some hoops.
Using the browser with a transparent router now requires setting the
TOR_SKIP_LAUNCH environment variable to 1. Of course, with a
Tor router already running, adding the Tor Browser to the mix
essentially just gives the user Firefox with fewer extensions and
plugins, but perhaps that is desirable from time to time. Then again,
where anonymity is concerned, maybe you can't be too careful.
Comments (7 posted)
Brief items
For the past several years, we've been seeing a steady increase in the
weaponization, stockpiling, and the use of exploits by multiple
governments, and by multiple *areas* of multiple governments. This
includes weaponized exploits specifically designed to "bridge the air
gap", by attacking software/hardware USB stacks, disconnected Bluetooth
interfaces, disconnected Wifi interfaces, etc. Even if these exploits
themselves don't leak (ha!), the fact that they are known to exist means
that other parties can begin looking for them.
In this brave new world, without the benefit of anonymity to protect
oneself from such targeted attacks, I don't believe it is possible to
keep a software-based GPG key secure anymore, nor do I believe it is
possible to keep even an offline build machine secure from malware
injection anymore, especially against the types of adversaries that Tor
has to contend with.
—
Mike
Perry
For instance, did you know that it is a
federal crime to be in possession of a lobster under a certain size? It doesn't matter if you bought it at a grocery store, if someone else gave it to you, if it's dead or alive, if you found it after it died of natural causes, or even if you killed it while acting in self defense. You can go to jail because of a lobster.
If the federal government had access to every email you've ever written and every phone call you've ever made, it's almost certain that they could find something you've done which violates a provision in the 27,000 pages of federal statues or 10,000 administrative regulations. You probably do have something to hide, you just don't know it yet.
—
Moxie
Marlinspike (Thanks to Paul Wise.)
Many of you have seen my
talk about medical
devices and general software safety [YouTube]. In fact, I'm up in the
Boston area, having given a similar talk yesterday at the
Women's
Leadership Community Luncheon alongside the Red Hat Summit. Well, I
seem to have gotten through, at least a little! While I was giving the talk
yesterday, the FDA finally admitted that there is a big problem. In their
Safety
Communication, the FDA says that medical devices can be vulnerable to
attack. They recommend that manufacturers assure that appropriate
safeguards are in place to prevent security attacks on devices, though they
do not recommend how this should be accomplished.
—
Karen
Sandler (ICS-CERT
alert.)
Comments (11 posted)
New vulnerabilities
autotrace: denial of service
| Package(s): | autotrace |
CVE #(s): | CVE-2013-1953
|
| Created: | June 19, 2013 |
Updated: | July 9, 2013 |
| Description: |
From the Red Hat bugzilla:
A buffer overflow flaw was reported in autotrace's input_bmp_reader() function. When autotrace is compiled with FORTIFY_SOURCE, this is caught and turned into a simple denial of service. |
| Alerts: |
|
Comments (none posted)
dbus: denial of service
| Package(s): | dbus |
CVE #(s): | CVE-2013-2168
|
| Created: | June 13, 2013 |
Updated: | August 23, 2013 |
| Description: |
From the Debian announcement:
Alexandru Cornea discovered a vulnerability in libdbus caused by an
implementation bug in _dbus_printf_string_upper_bound(). This
vulnerability can be exploited by a local user to crash system services
that use libdbus, causing denial of service. Depending on the dbus
services running, it could lead to complete system crash. |
| Alerts: |
|
Comments (none posted)
fail2ban: denial of service
| Package(s): | fail2ban |
CVE #(s): | CVE-2013-2178
|
| Created: | June 17, 2013 |
Updated: | July 2, 2013 |
| Description: |
From the Debian advisory:
Krzysztof Katowicz-Kowalewski discovered a vulnerability in fail2ban, a
log monitoring and system which can act on attack by preventing hosts to
connect to specified services using the local firewall.
When using fail2ban to monitor Apache logs, improper input validation in
log parsing could enable a remote attacker to trigger an IP ban on
arbitrary addresses, thus causing a denial of service.
|
| Alerts: |
|
Comments (none posted)
gallery3: insecure URL handling
| Package(s): | gallery3 |
CVE #(s): | CVE-2013-2138
|
| Created: | June 14, 2013 |
Updated: | June 19, 2013 |
| Description: |
From the Fedora bug:
A security flaw was found in the way uploadify and flowplayer SWF files handling functionality of Gallery version 3, an open source project with the goal to develop and support leading photo sharing web application solutions, processed certain URL fragments passed to these files (certain URL fragments were not stripped properly when these files were called via direct URL request(s)). A remote attacker could use this flaw to conduct replay attacks. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
Comments (none posted)
kernel: denial of service
| Package(s): | linux |
CVE #(s): | CVE-2013-2146
|
| Created: | June 14, 2013 |
Updated: | June 19, 2013 |
| Description: |
From the Ubuntu advisory:
A flaw was discovered in the Linux kernel's perf events subsystem for Intel
Sandy Bridge and Ivy Bridge processors. A local user could exploit this
flaw to cause a denial of service (system crash). |
| Alerts: |
|
Comments (none posted)
kernel: information disclosure
| Package(s): | linux-lts-quantal |
CVE #(s): | CVE-2013-2141
|
| Created: | June 14, 2013 |
Updated: | June 19, 2013 |
| Description: |
From the Ubuntu advisory:
An information leak was discovered in the Linux kernel's tkill and tgkill
system calls when used from compat processes. A local user could exploit
this flaw to examine potentially sensitive kernel memory. |
| Alerts: |
|
Comments (none posted)
nfs-utils: information disclosure
| Package(s): | nfs-utils |
CVE #(s): | CVE-2013-1923
|
| Created: | June 14, 2013 |
Updated: | June 25, 2013 |
| Description: |
From the Novell bug report:
It was reported [1],[2] that rpc.gssd in nfs-utils is vulnerable to DNS
spoofing due to it depending on PTR resolution for GSSAPI
authentication. Because of this, if a user where able to poison DNS to
a victim's computer, they would be able to trick rpc.gssd into talking
to another server (perhaps with less security) than the intended server
(with stricter security). If the victim has write access to the second
(less secure) server, and the attacker has read access (when they
normally might not on the secure server), the victim could write files
to that server, which the attacker could obtain (when normally they
would not be able to). To the victim this is transparent because the
victim's computer asks the KDC for a ticket to the second server due to
reverse DNS resolution; in this case Krb5 authentication does not fail
because the victim is talking to the "correct" server. |
| Alerts: |
|
Comments (none posted)
owncloud: cross-site scripting
| Package(s): | owncloud |
CVE #(s): | CVE-2013-2150
CVE-2013-2149
|
| Created: | June 17, 2013 |
Updated: | June 24, 2013 |
| Description: |
From the Mandriva advisory:
Cross-site scripting (XSS) vulnerabilities in js/viewer.js inside
the files_videoviewer application via multiple unspecified vectors in
all ownCloud versions prior to 5.0.7 and 4.5.12 allows authenticated
remote attackers to inject arbitrary web script or HTML via shared
files (CVE-2013-2150).
Cross-site scripting (XSS) vulnerabilities in core/js/oc-dialogs.js
via multiple unspecified vectors in all ownCloud versions prior to
5.0.7 and other versions before 4.0.16 allows authenticated remote
attackers to inject arbitrary web script or HTML via shared files
(CVE-2013-2149). |
| Alerts: |
|
Comments (none posted)
perl-Dancer: header injection
| Package(s): | perl-Dancer |
CVE #(s): | CVE-2012-5572
|
| Created: | June 13, 2013 |
Updated: | June 28, 2013 |
| Description: |
From the Red Hat Bugzilla entry:
A security flaw was found in the way Dancer.pm, lightweight yet powerful web application framework / Perl language module, performed sanitization of values to be used for cookie() and cookies() methods. A remote attacker could use this flaw to inject arbitrary headers into responses from (Perl) applications, that use Dancer.pm. |
| Alerts: |
|
Comments (none posted)
perl-Module-Signature: code execution
| Package(s): | perl-Module-Signature |
CVE #(s): | CVE-2013-2145
|
| Created: | June 18, 2013 |
Updated: | October 4, 2013 |
| Description: |
From the Red Hat bugzilla:
The perl Module::Signature module adds signing capabilities to CPAN modules. The 'cpansign verify' command will automatically download keys and use them to check the signature of CPAN packages via the SIGNATURE file.
The format of the SIGNATURE file includes the cipher to use to match the provided hash; for instance:
SHA1 955ba924e9cd1bafccb4d6d7bd3be25c3ce8bf75 README
If an attacker were to replace this (SHA1) with a special unknown cipher (e.g. 'Special') and were to include in the distribution a 'Digest/Special.pm', the code in this perl module would be executed when 'cpansign -verify' is run. This will execute arbitrary code with the privileges of the user running cpansign.
Because cpansign will download public keys from a public key repository, the GPG key used to sign the SIGNATURE file may also be suspect; an attacker able to modify a CPAN module distribution file and sign the SIGNATURE file with their own key only has to make their key public. cpansign will download the attacker's key, validate the SIGNATURE file as being correctly signed, but will then execute code as noted above, if the SIGNATURE file is crafted in this way. |
| Alerts: |
|
Comments (none posted)
puppet: code execution
| Package(s): | puppet |
CVE #(s): | CVE-2013-3567
|
| Created: | June 19, 2013 |
Updated: | August 22, 2013 |
| Description: |
From the Ubuntu advisory:
It was discovered that Puppet incorrectly handled YAML payloads. An
attacker on an untrusted client could use this issue to execute arbitrary
code on the master. |
| Alerts: |
|
Comments (none posted)
rrdtool: denial of service
| Package(s): | rrdtool |
CVE #(s): | CVE-2013-2131
|
| Created: | June 18, 2013 |
Updated: | June 19, 2013 |
| Description: |
From the Fedora advisory:
This is an update that adds explicit check to the imginfo format. It may prevent crash/exploit of
user space applications which pass user supplied format to the library call without checking. |
| Alerts: |
|
Comments (none posted)
subversion: code execution
| Package(s): | subversion |
CVE #(s): | CVE-2013-2088
|
| Created: | June 14, 2013 |
Updated: | June 19, 2013 |
| Description: |
From the Novell bug report:
Subversion releases up to 1.6.22 (inclusive), and 1.7.x tags up to 1.7.10
(inclusive, but excepting 1.7.x releases made from those tags), include a
contrib/ script prone to shell injection by authenticated users, which could
result in arbitrary code execution. |
| Alerts: |
|
Comments (none posted)
wireshark: multiple vulnerabilities
| Package(s): | wireshark |
CVE #(s): | CVE-2013-4075
CVE-2013-4076
CVE-2013-4077
CVE-2013-4078
CVE-2013-4082
|
| Created: | June 18, 2013 |
Updated: | September 30, 2013 |
| Description: |
From the CVE entries:
epan/dissectors/packet-gmr1_bcch.c in the GMR-1 BCCH dissector in Wireshark 1.8.x before 1.8.8 does not properly initialize memory, which allows remote attackers to cause a denial of service (application crash) via a crafted packet. (CVE-2013-4075)
Buffer overflow in the dissect_iphc_crtp_fh function in epan/dissectors/packet-ppp.c in the PPP dissector in Wireshark 1.8.x before 1.8.8 allows remote attackers to cause a denial of service (application crash) via a crafted packet. (CVE-2013-4076)
Array index error in the NBAP dissector in Wireshark 1.8.x before 1.8.8 allows remote attackers to cause a denial of service (application crash) via a crafted packet, related to nbap.cnf and packet-nbap.c. (CVE-2013-4077)
epan/dissectors/packet-rdp.c in the RDP dissector in Wireshark 1.8.x before 1.8.8 does not validate return values during checks for data availability, which allows remote attackers to cause a denial of service (application crash) via a crafted packet. (CVE-2013-4078)
The vwr_read function in wiretap/vwr.c in the Ixia IxVeriWave file parser in Wireshark 1.8.x before 1.8.8 does not validate the relationship between a record length and a trailer length, which allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) via a crafted packet. (CVE-2013-4082)
|
| Alerts: |
|
Comments (none posted)
xen: multiple vulnerabilities
| Package(s): | xen |
CVE #(s): | CVE-2013-2076
CVE-2013-2077
CVE-2013-2078
|
| Created: | June 14, 2013 |
Updated: | June 19, 2013 |
| Description: |
From the Fedora bugzilla:
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an exception is pending, these instructions save/restore only the FOP, FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain to determine portions of the state of floating point instructions of other domains.
A malicious domain may be able to leverage this to obtain sensitive information such as cryptographic keys from another domain. (CVE-2013-2076)
Processors do certain validity checks on the data passed to XRSTOR. While the hypervisor controls the placement of that memory block, it doesn't restrict the contents in any way. Thus the hypervisor exposes itself to a fault occurring on XRSTOR. Other than for FXRSTOR, which behaves similarly, there was no exception recovery code attached to XRSTOR.
Malicious or buggy unprivileged user space can cause the entire host to crash. (CVE-2013-2077)
Processors do certain validity checks on the register values passed to XSETBV. For the PV emulation path for that instruction the hypervisor code didn't check for certain invalid bit combinations, thus exposing itself to a fault occurring when invoking that instruction on behalf of the guest.
Malicious or buggy unprivileged user space can cause the entire host to crash. (CVE-2013-2078) |
| Alerts: |
|
Comments (none posted)
xml-security-c: multiple vulnerabilities
| Package(s): | xml-security-c |
CVE #(s): | CVE-2013-2153
CVE-2013-2154
CVE-2013-2155
CVE-2013-2156
|
| Created: | June 19, 2013 |
Updated: | June 28, 2013 |
| Description: |
From the Debian advisory:
CVE-2013-2153:
The implementation of XML digital signatures in the Santuario-C++
library is vulnerable to a spoofing issue allowing an attacker to
reuse existing signatures with arbitrary content.
CVE-2013-2154:
A stack overflow, possibly leading to arbitrary code execution,
exists in the processing of malformed XPointer expressions in the
XML Signature Reference processing code.
CVE-2013-2155:
A bug in the processing of the output length of an HMAC-based XML
Signature would cause a denial of service when processing specially
chosen input.
CVE-2013-2156:
A heap overflow exists in the processing of the PrefixList attribute
optionally used in conjunction with Exclusive Canonicalization,
potentially allowing arbitrary code execution. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>
