Security
DeadDrop and Strongbox
In mid-May, US news magazine The New Yorker unveiled Strongbox, a service that lets whistleblowers and other potential news sources contact its reporters securely and anonymously. The security model is ambitious; it is reachable only on Tor, hides source identities (while preserving continuity across repeat visits), encrypts messages and uploaded files, and allows a monitoring station to watch for possible security breaches. It is also open source, and is the work of the late programmer and activist Aaron Swartz.
Wired's Kevin Poulsen wrote
about the system's origin in a blog post timed to coincide with the
debut of the service. The goal, he explained, was to
create a modern system through which journalists could safely communicate
with anonymous sources, since the old methods had not kept up with
the pace of technology—including both legal access methods and
"outright hacking
". Poulsen had met Swartz in 2006 when
Condé Nast (parent company to both Wired and The
New Yorker) purchased news site Reddit (where Swartz worked). Poulsen asked
Swartz to build the secure communications gateway in 2011, after
seeing Swartz's work on Tor2Web.
The security model designed by the two incorporated several stringent requirements, such as ensuring that it was impossible for the news organization to know the origin of files or messages (thus it could not be compelled to disclose that origin), but it should also be able to run on servers at the news organization's offices (to reduce the likelihood of tampering). Swartz insisted that the project should be released as open source software, and they settled on the name DeadDrop. Outside security researchers audited the architecture of the system as well as the code. By December 2012, DeadDrop was reasonably stable and a launch was planned. But those plans came to a sudden halt with Swartz's suicide in January 2013.
Strongbox debuts
In the subsequent months, Poulsen consulted with Swartz's friends and family before eventually deciding to proceed with the launch, which finally happened on May 15. The public front-end of the service runs as a "hidden service" on Tor, accessible only through a .onion pseudo-domain. The front end itself is almost deceptively simple; when a user (the would-be whistleblower or source) logs in for the first time, the system creates a unique code name composed of four English words. In the future, the same user can visit the service from any location and log on again using the four-word code (hopefully without writing it down). When logged in, the user can type a message into a web form and optionally attach files to upload. Journalists can leave secure messages for the user in reply, which the user is encouraged to delete after reading.
Obviously the system cannot provide absolute security; among other things, if the user discloses personally identifiable information in his or her messages, the anonymity is gone. If the user writes down the unique code word identifier, someone else could copy it and spoof the user's identity. But if the instructions are followed correctly, the framework does offer a fairly strong guarantee of anonymity and protection against eavesdropping—certainly a far better offer than PGP encryption or a TLS-protected web form do alone. Instructions and a privacy pledge are posted on the Strongbox home page; hopefully anyone concerned enough about security and anonymity to use the system will take the time needed to learn how to use it correctly.
Drop it
The Strongbox site does not go into much detail about how the system works, but there is a good deal more to examine on the DeadDrop project site at GitHub. The threat model document provides an overview of the system from the outside source's perspective as well as the journalist and administrator's. The same application server provides the front end seen by sources over Tor (which we have already described) and the front end seen by journalists inside the news organization on its internal network. The other two pieces of the puzzle are the "secure viewing station" (SVS) where journalists decrypt and read messages and the auditing system.
But security starts on the application server. The four-word code name generated randomly for the source is never stored in the clear, but it is used. The SHA256 hash of the code name is stored on the server as the directory name for the user. Every message sent by the source includes the code name in the POST request, and the application checks its hash against the stored hash to authorize the request. The application also creates a GPG v2 key pair for each new user, and uses the code name as the secret key passphrase (which, again, is not stored in the clear). Replies from the journalist are encrypted with the public key from this pair, so that only the intended source can decrypt them, but the decryption happens automatically using the code name in the HTTP request, so the source is not required to store or memorize a separate passphrase.
Every message or file uploaded by a source is also encrypted, but with a different key pair, for which the application server only stores the public key. The journalist interface to the application is only available through a VPN requiring two-factor authentication. The application uses private SSL certificates distributed to the journalists' computers, with the certificates and revocation lists generated offline. When a journalist logs in to the system, he or she is presented with a list of new messages, and must download them in encrypted form and take them to a separate machine (the SVS) to read. The SVS is intended to be a diskless workstation booted from a live CD and not attached to the network. The private key for the application is stored on the SVS live CD, so the journalist can read messages and files. As an additional measure of security, the application presents a different set of code names in the journalist interface, so that the source's code name and hash are not known.
Finally, the application server and the SVS are kept on the news organization's premises, under lock and key and monitored for unauthorized access. The application server has a hardware entropy source attached to generate strong cryptographic keys, and journalists are instructed to re-encrypt any files they take from the SVS to their personal workstations (using yet another GPG key pair). There is a separate machine running the OSSEC intrusion detection system and logging events from Tor, AppArmor, the firewall, and grsecurity. Just as the system provides guidance to sources using the service (including potentially unfamiliar pieces like Tor hidden services), there is a set of guidelines for security on the journalists' side of the system: GPG key type and key length, VPN settings, and browser certificates. There is an installation guide that walks the reader through the entire process, starting with installing the operating system with full-disk encryption.
Follow the money code
How much will Strongbox or any other DeadDrop installation ever get used? Those of us on the outside may never know for sure. Despite the best efforts of the designers to make DeadDrop easy-to-use, it should be clear to anyone who reads the threat model that balancing high security and ease-of-use remains a tall order. There are some very nice features in DeadDrop. The code name feature is quite clever; it allows both source and journalist to reliably feel confident that the same person is accessing any particular user account, but by using separate code names for the source and journalist front-ends, anonymity is preserved. Using the source's code name as both the POST authentication method and the GPG passphrase is a compromise, but it also reduces the burden of complexity placed on the source—who, in the real world, may already be taking on an enormous risk by talking to a reporter.
The downside is that some of DeadDrop's security stems from parameters that are hard or impossible for small organizations to implement, such as the constantly-guarded SVS and on-premises application server. Those features mandate dedicating a facility in a brick-and-mortar location (and ideally one that is distinct from the rest of the organization's network infrastructure). But physical security is a vital part of maintaining the overall integrity of the system; without it, someone could copy information from the server, install a keylogging device, or attempt any number of other attacks.
It is interesting to compare the design of DeadDrop to similar whistleblowing applications, like GlobaLeaks (which is arguably the best known). GlobaLeaks also allows sources to submit information to a news organization (or to any other entity running the service, of course), including a Tor hidden service front end. But GlobaLeaks does not implement the persistent identity across repeat visits feature (although it does allow a whistleblower to return to a specific "tip" by saving or remembering a ten-digit "receipt" string). GlobaLeaks also does not offer end-to-end encryption of uploaded messages and files, nor does it utilize DeadDrop's rather complex offline SVS scheme to ensure that communications are not monitored or intercepted.
Of course, to some budding journalists and whistleblowers, GlobaLeaks' lack of complexity may well be a plus. DeadDrop's architecture is set up to protect against a wider assortment of attacks, but along with the usual administrative overhead, a more complex system brings with it the increased chances of human error. That is almost always the case with security; the better password is harder to remember, the safer authentication method is easier to mess up—and in either case, the temptation to write down a secret for fear of forgetting it is an obstacle to which there is no technological solution. Then again, Whistleblowing fundamentally requires some leaps of faith; a source must trust the news organization to begin with or DeadDrop would not make them do so. But DeadDrop remains a valuable object for those interested in developing secure communication systems, regardless of whether or not their plans involve contacting The New Yorker.
Brief items
Security quotes of the week
Strongbox and Aaron Swartz (The New Yorker)
The New Yorker magazine has started a service called Strongbox that allows anonymous information to be sent to magazine. It is based on the DeadDrop free software project that was created by the late Aaron Swartz, which uses the Tor network to preserve anonymity. The magazine also has an article by Kevin Poulsen, who organized the project, about its history. "In New York, a computer-security expert named James Dolan persuaded a trio of his industry colleagues to meet with Aaron to review the architecture and, later, the code. We wanted to be reasonably confident that the system wouldn't be compromised, and that sources would be able to submit documents anonymously—so that even the media outlets receiving the materials wouldn't be able to tell the government where they came from."
New vulnerabilities
gallery3: cross-site scripting
| Package(s): | gallery3 | CVE #(s): | CVE-2013-2087 | ||||||||
| Created: | May 22, 2013 | Updated: | May 22, 2013 | ||||||||
| Description: | From the Gallery advisories [1, 2]:
Gallery contains a flaw that allows a remote cross-site scripting (XSS) attack. This flaw exists because the application does not validate input passed via movie titles before returning it to the user. This may allow an attacker to create a specially crafted request that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server. Gallery contains a flaw that allows a reflected cross-site scripting (XSS) attack. This flaw exists because the application does not validate input passed via the Error page before returning it to the user. This may allow an attacker to create a specially crafted request that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server. | ||||||||||
| Alerts: |
| ||||||||||
kernel: multiple vulnerabilities
| Package(s): | linux | CVE #(s): | CVE-2013-3227 CVE-2013-3301 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 16, 2013 | Updated: | July 18, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory: CVE-2013-3227: Mathias Krauss discovered an issue in the Communication CPU to Application CPU Interface (CAIF). Local users can gain access to sensitive kernel memory. CVE-2013-3301: Namhyung Kim reported an issue in the tracing subsystem. A privileged local user could cause a denial of service (system crash). This vulnerabililty is not applicable to Debian systems by default. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: privilege escalation
| Package(s): | linux | CVE #(s): | CVE-2013-2094 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 16, 2013 | Updated: | June 14, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory: CVE-2013-2094: Tommie Rantala discovered an issue in the perf subsystem. An out-of-bounds access vulnerability allows local users to gain elevated privileges. More information available here. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: information disclosure
| Package(s): | kernel | CVE #(s): | CVE-2013-2636 | ||||||||||||||||||||
| Created: | May 20, 2013 | Updated: | May 22, 2013 | ||||||||||||||||||||
| Description: | From the CVE entry:
net/bridge/br_mdb.c in the Linux kernel before 3.8.4 does not initialize certain structures, which allows local users to obtain sensitive information from kernel memory via a crafted application. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
krb5: UDP ping-pong flaw in kpasswd
| Package(s): | krb5 | CVE #(s): | CVE-2002-2443 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 21, 2013 | Updated: | July 2, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
A flaw in certain programs that handle UDP traffic was discovered and assigned the name CVE-1999-0103 (that CVE specifically mentions echo and chargen as vulnerable). In 2002, a Nessus plugin was included [1] that reference this CVE name, but was for the kpasswd service. Until recently, this issue had not been reported upstream. This issue has since been reported upstream [2] and is now fixed [3]. If a malicious remote user were to spoof their IP address to that of another server running kadmind with the password change port (kpasswd, port 464), or to the target server's IP address itself), kpasswd will pass UDP packets to the spoofed address and reply each time. This can be used to consume bandwidth and CPU on the affected servers running kadmind. This should be fixed in the krb5-1.11.3 release.
[1] http://marc.info/?l=nessus&m=102418951803893&w=2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libvirt: denial of service
| Package(s): | libvirt | CVE #(s): | CVE-2013-1962 | ||||||||||||||||||||||||||||||||||||
| Created: | May 17, 2013 | Updated: | July 3, 2013 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory: It was found that libvirtd leaked file descriptors when listing all volumes for a particular pool. A remote attacker able to establish a read-only connection to libvirtd could use this flaw to cause libvirtd to consume all available file descriptors, preventing other users from using libvirtd services (such as starting a new guest) until libvirtd is restarted. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
mediawiki: multiple vulnerabilities
| Package(s): | mediawiki | CVE #(s): | CVE-2013-2031 CVE-2013-2032 | ||||||||||||||||||||||||
| Created: | May 20, 2013 | Updated: | May 22, 2013 | ||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
Two flaws were corrected in the recently-released MediaWiki 1.20.5 and 1.19.6 releases: * Jan Schejbal / Hatforce.com reported that SVG script filtering could be bypassed for Chrome and Firefox clients by using an encoding that MediaWiki understood, but these browsers interpreted as UTF-8. [1] * Internal review discovered that extensions were not given the opportunity to disable a password reset, which could lead to circumvention of two-factor authentication. [2]
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=47304 | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
openstack-keystone: delayed token invalidation
| Package(s): | keystone | CVE #(s): | CVE-2013-2059 | ||||||||||||
| Created: | May 17, 2013 | Updated: | June 11, 2013 | ||||||||||||
| Description: | From the Ubuntu advisory: Sam Stoelinga discovered that Keystone would not immediately invalidate tokens when deleting users via the v2 API. A deleted user would be able to continue to use resources until the token lifetime expired. | ||||||||||||||
| Alerts: |
| ||||||||||||||
openstack-keystone: insecure signing directory
| Package(s): | openstack-keystone | CVE #(s): | CVE-2013-2030 | ||||||||
| Created: | May 22, 2013 | Updated: | June 27, 2013 | ||||||||
| Description: | From the Openwall advisory:
Grant Murphy from Red Hat and Anton Lundin both independently reported a vulnerability in Nova's default location for the Keystone middleware signing directory (signing_dir). By previously setting up a malicious directory structure, an attacker with local shell access on the Nova node could potentially issue forged tokens that would be accepted by the middleware. Only setups that use the default value for signing_dir are affected. Note that future versions of the Keystone middleware will issue a warning if an insecure signing directory is used. | ||||||||||
| Alerts: |
| ||||||||||
openstack-nova: denial of service
| Package(s): | nova | CVE #(s): | CVE-2013-2096 | ||||||||||||||||||||
| Created: | May 17, 2013 | Updated: | July 29, 2013 | ||||||||||||||||||||
| Description: | From the Ubuntu advisory: Loganathan Parthipan discovered that Nova did not verify the size of QCOW2 instance storage. An authenticated attacker could exploit this to cause a denial of service by creating an image with a large virtual size with little data, then filling the virtual disk. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
openswan: code execution
| Package(s): | openswan | CVE #(s): | CVE-2013-2053 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 16, 2013 | Updated: | January 20, 2014 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory: A buffer overflow flaw was found in Openswan. If Opportunistic Encryption were enabled ("oe=yes" in "/etc/ipsec.conf") and an RSA key configured, an attacker able to cause a system to perform a DNS lookup for an attacker-controlled domain containing malicious records (such as by sending an email that triggers a DKIM or SPF DNS record lookup) could cause Openswan's pluto IKE daemon to crash or, potentially, execute arbitrary code with root privileges. With "oe=yes" but no RSA key configured, the issue can only be triggered by attackers on the local network who can control the reverse DNS entry of the target system. Opportunistic Encryption is disabled by default. (CVE-2013-2053) | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
openvpn: possible plaintext recovery
| Package(s): | openvpn | CVE #(s): | CVE-2013-2061 | ||||||||||||||||||||||||||||||||
| Created: | May 16, 2013 | Updated: | October 3, 2014 | ||||||||||||||||||||||||||||||||
| Description: | From the OpenVPN advisory: OpenVPN 2.3.0 and earlier running in UDP mode are subject to chosen ciphertext injection due to a non-constant-time HMAC comparison function. Plaintext recovery may be possible using a padding oracle attack on the CBC mode cipher implementation of the crypto library, optimistically at a rate of about one character per 3 hours. PolarSSL seems vulnerable to such an attack; the vulnerability of OpenSSL has not been verified or tested. OpenVPN servers are typically configured to silently drop packets with the wrong HMAC. For this reason measuring the processing time of the packets is not trivial without a MITM position. In practice, the attack likely needs some target-specific information to be effective. The severity of this vulnerability can be considered low. Only if OpenVPN is configured to use a null-cipher, arbitrary plain-text can be injected which can completely open up this attack vector. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
ruby: object taint bypassing
| Package(s): | ruby | CVE #(s): | CVE-2013-2065 | ||||||||||||||||||||||||||||
| Created: | May 17, 2013 | Updated: | May 30, 2013 | ||||||||||||||||||||||||||||
| Description: | From the Ruby advisory: There is a vulnerability in DL and Fiddle in Ruby where tainted strings can be used by system calls regardless of the $SAFE level set in Ruby. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
thunderbird: multiple vulnerabilities
| Package(s): | thunderbird | CVE #(s): | CVE-2013-0801 CVE-2013-1670 CVE-2013-1672 CVE-2013-1674 CVE-2013-1675 CVE-2013-1676 CVE-2013-1677 CVE-2013-1678 CVE-2013-1679 CVE-2013-1680 CVE-2013-1681 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 17, 2013 | Updated: | June 28, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mozilla release notes: Security researcher Abhishek Arya (Inferno) of the Google Chrome Security Team used the Address Sanitizer tool to discover a series of use-after-free, out of bounds read, and invalid write problems rated as moderate to critical as security issues in shipped software. Some of these issues are potentially exploitable, allowing for remote code execution. We would also like to thank Abhishek for reporting additional use-after-free flaws in dir=auto code introduced during Firefox development. These were fixed before general release. (CVE-2013-1676, CVE-2013-1677, CVE-2013-1678, CVE-2013-1679, CVE-2013-1680, CVE-2013-1681) Mozilla community member Ms2ger discovered that some DOMSVGZoomEvent functions are used without being properly initialized, causing uninitialized memory to be used when they are called by web content. This could lead to a information leakage to sites depending on the contents of this uninitialized memory. (CVE-2013-1675) Security researcher Nils reported a use-after-free when resizing video while playing. This could allow for arbitrary code execution. (CVE-2013-1674) Security researcher Seb Patane reported an issue with the Mozilla Maintenance Service on Windows. This issue allows unprivileged users to local privilege escalation through the system privileges used by the service when interacting with local malicious software. This allows the user to bypass integrity checks leading to local privilege escalation. Local file system access is necessary in order for this issue to be exploitable and it cannot be triggered through web content. (CVE-2013-1672) Security researcher Cody Crews reported a method to call a content level constructor that allows for this constructor to have chrome privileged accesss. This affects chrome object wrappers (COW) and allows for write actions on objects when only read actions should be allowed. This can lead to cross-site scripting (XSS) attacks. (CVE-2013-1670) Mozilla developers identified and fixed several memory safety bugs in the browser engine used in Firefox and other Mozilla-based products. Some of these bugs showed evidence of memory corruption under certain circumstances, and we presume that with enough effort at least some of these could be exploited to run arbitrary code. (CVE-2013-0801) | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
tomcat: information disclosure
| Package(s): | tomcat | CVE #(s): | CVE-2013-2071 | ||||||||||||||||||||||||||||
| Created: | May 21, 2013 | Updated: | July 2, 2013 | ||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
An information disclosure flaw was found in the way asynchronous context implementation of Apache Tomcat, an Apache Servlet/JSP Engine, performed request information management in certain circumstances (formerly certain elements of a previous request might have been exposed to the current request). If an application used AsyncListeners that threw RuntimeExceptions, a remote attacker could use this flaw to possibly obtain sensitive information. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>