LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityHoles discovered in SSL certificate validationA stinging indictment of the state of SSL client applications was recently published as part of the Proceedings from the ACM Computer and Communications Security (CCS) conference. The six authors of the paper (three each from Stanford and The University of Texas) describe testing that certainly should have been done as part of the application development process, but clearly wasn't. The problem stems partly from the libraries that provide SSL certificate verification, because developers are not using them properly. By and large the low-level library cryptographic protocol implementations are fine, the authors found, but the APIs are designed so poorly that developers commonly misuse them. The paper [PDF] is entitled "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" and lives up to that label. It is truly an eye-opening read. The researchers simulated man-in-the-middle attacks using a combination of self-signed and invalid SSL certificates along with a valid certificate for the amusing AllYourSSLAreBelongTo.us domain to observe the effects on various applications. The observations led to the overall conclusion: "SSL certificate validation is completely broken in many critical software applications and libraries". The researchers used Windows and Ubuntu laptops, a Nexus One smartphone, and an iPad 2 as clients for their testing. A second Ubuntu system running custom Java and C proxies, as well as the Fiddler web debugging proxy, served as the man in the middle. As they noted, the kind of attack that can be launched from the proxies is precisely what SSL is meant to thwart—their testing did not go beyond what an active man in the middle could do:
This is exactly the attack that SSL is intended to protect against.
It does not involve compromised or malicious certificate authorities, nor forged certificates, nor compromised private keys of legitimate servers. The only class of vulnerabilities we exploit are logic
errors in client-side SSL certificate validation.
What they found was client applications that largely (or completely) accepted various kinds of invalid certificates and blindly sent private information (cookies, authentication information, credit card numbers) over an unsecured link. In many cases, the proxies could make the actual SSL connection to the remote server and funnel the data along—while surreptitiously storing the data away for (ab)use at a later time. The paper gives plenty of examples of where the applications go wrong. Much of it can be blamed on bad library APIs, they said, in essentially all of the low-level SSL libraries (OpenSSL, GnuTLS, JSSE, CryptoAPI, etc.):
The root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying SSL libraries. Instead of expressing high-level security properties of network tunnels such as
confidentiality and authentication, these APIs expose low-level details of the SSL protocol to application developers. As a consequence, developers often use SSL APIs incorrectly, misinterpreting
and misunderstanding their manifold parameters, options, side effects, and return values.
While that is certainly a problem, the application authors do bear some of the responsibility as well. It is not difficult to test an application against a few types of bad certificates. Because of the complexity of the APIs, developers should probably have been more wary that they might have made a mistake. Given that there is some kind of security requirement for the application (why use SSL otherwise?), it would seem prudent to verify proper functioning. Using a well-tested, industry-standard library is certainly an important piece of the puzzle, but there is more to it than just that. There is also the problem of higher-level libraries perched atop OpenSSL, et al. The researchers found that libraries like Apache HttpClient, cURL, and the PHP and Python SSL libraries all had flaws in certificate validation. In fact, Python's urllib, urllib2, and httplib documentation warns that no certificate checking is done by the libraries, which evidently doesn't stop "high security" applications from still using them. One of the examples shows how this can all go awry:
Amazon's Flexible Payments
Service PHP library attempts to enable hostname verification by
setting cURL's CURLOPT_SSL_VERIFYHOST parameter to true. Unfortunately, the correct, default value of this parameter is 2; setting
it to true silently changes it to 1 and disables certificate validation. PayPal Payments Standard PHP library introduced the same bug
when updating a previous, broken implementation.
These kinds of errors would almost be comical, if they weren't so serious. While it may sound difficult for attackers to position themselves "in the middle", the prevalence of wireless networking these days makes it easier. Taking over an access point (or just running a hostile one as "Free Airport WiFi", say) puts an attacker squarely in the middle. Users that are running the vulnerable applications over a link to a bad access point are susceptible to many kinds of attacks. Compromise of home routers is another possibility. Obviously, malware running upstream in the wired internet is equally dangerous (if harder to pull off). The researchers conclude the article with recommendations for both application and SSL library developers. For the most part, they are pretty common-sense suggestions (do test your application, don't have multiple inconsistent error reporting mechanisms, etc.) that could certainly apply more widely than just SSL applications and libraries. Obviously, they could not test each and every non-browser SSL-using client (or even all of the SSL client libraries) out there, but the list of vulnerable components from the abstract is rather astonishing:
Vulnerable
software includes Amazon's EC2 Java library and all cloud clients
based on it; Amazon's and PayPal's merchant SDKs responsible
for transmitting payment details from e-commerce sites to payment
gateways; integrated shopping carts such as osCommerce, ZenCart,
Ubercart, and PrestaShop; AdMob code used by mobile websites;
Chase mobile banking and several other Android apps and libraries;
Java Web-services middleware—including Apache Axis, Axis 2,
Codehaus XFire, and Pusher library for Android—and all applications
employing this middleware.
Perhaps the most distressing piece of this research is the appearance—at least—that developers are being pretty cavalier about checking the security baked into their supposedly "high security" applications. Beyond that, it is amazing that payment processors who are dealing with credit cards (and, importantly, credit card fraud) have seemingly not been very diligent about the code they distribute to their customers. All in all, this research shows that even "secure" applications and libraries often skimp on important verification testing—a seriously sad state of affairs.
Brief items Security quotes of the week
It checks to see if the /mnt/ubi_boot/mfg_test/enable file exists, and if
so, it fires up a telnet service (among other things). However, the
mfg_test directory doesn't exist at all on the production system [...] But
with the SSID command injection vulnerability, we can easily create it. The
commands to create the file are too long to fit into the restricted
32-character SSID input field, so we'll echo them piecemeal into a shell
script and then execute that script [...]
-- /dev/ttyS0
on jailbreaking the Netgear NTV300 "NeoTV"
Rooted with nothing but the remote control it came with.
The industry standard is most Social Security numbers are not encrypted. A
lot of banks don't encrypt. It's very complicated. It's very
cumbersome. There's a lot of numbers involved with it.
-- South Carolina governor Nikki Haley
If you're going to allow users to download all of their data with one command, you might want to double- and triple-check that command. Otherwise it's going to become an attack vector for identity theft and other malfeasance.
-- Bruce
Schneier on "data portability" risks
I have X'd out any information that you could use to change my reservation. But it's all there, PNR, seat assignment, flight number, name, [etc.] But what is interesting is the bolded three on the end. This is the TSA Pre-Check information. The number means the number of beeps. 1 beep no Pre-Check, 3 beeps yes Pre-Check. On this trip as you can see I am eligible for Pre-Check. Also this information is not encrypted in any way.
-- John
Butler shows how to change a boarding pass for less TSA screening
This iommu encrypts addresses on the device bus to avoid [divulging] information
to hackers equipped with bus analyzers. Following 3DES, addresses are encrypted
multiple times. A XOR cypher is employed for efficiency.
-- Avi Kivity (thanks to Michael S. Tsirkin.)
New vulnerabilities cgit: code execution
dokuwiki: path disclosure
drupal7: code execution
exim4: arbitrary code execution
java: multiple unspecified vulnerabilities
kdelibs: multiple vulnerabilities
kernel: information leak
libqt4: CRIME attack
mozilla: multiple vulnerabilities
optipng: use after free
python-django: information disclosure
request-tracker: multiple vulnerabilities
rtfm: privilege escalation
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||