Apple totally screwed up SSL with a fundamental bug in their certificate checking implementation in both MacOS 10.9 and iOS 7. Every consumer iPhone, iPad, and Macintosh running recent versions of their OS is vulnerable. My understanding is SSL certificate checking basically does not work and any secure site can be spoofed with a man-in-the-middle attack. It’s about as deep a flaw as it goes. There’s a patch for iOS out but not yet for MacOS. You can test if a browser is vulnerable here.
The bug boils down to a simple typo in the code, the good ol’ C gotcha that indentation doesn’t match control flow. Bugs like that happen in C. What’s alarming is Apple didn’t catch the bug; not with a lint tool, not in code review, not in unit testing, not in integration testing. No aspect of Apple’s software development process caught this bug before releasing it to millions of users. That’s terrible engineering practice; in a critical security library it’s outright negligence.
At the moment MacOS users are entirely vulnerable and there’s no fix. In the past Apple has taken many weeks to fix critical bugs in things like Java, hopefully they’ll be faster here. Using Chrome instead of Safari will insulate you from malicious web servers, Chrome wisely has its own SSL implementation. But a whole lot of other Mac software is relying on the broken certificate library, presumably including Apple’s own software update system.
Nice of Apple to publish the exploit before the fix.
RSA Security (part of EMC) was one of America’s most respected security companies. Thanks to Edward Snowden, we now know the price of their reputation: $10 million. For that tiny sum RSA sold out their customers, deliberately installing a compromised random number generator in their core security library BSafe at NSA’s request. For $10M, a company’s reputation destroyed.
The nature of NSA’s sabotage is worth looking at in detail. We knew back in 2006 that Dual_EC_DRBG, a NIST standard crypto random number generator, was fishy. That algorithm has baked into it an arbitrary constant; two Microsoft researchers figured out that if an adversary had chosen that constant, then the numbers were predictable and any system built on it was insecure. Snowden’s leaks confirmed in Sep 2013 that this backdoor had been placed. And now in Dec 2013 we know the price: $10M. (Interestingly, one old-school cypherpunk knew the price back in September).
It’s worth noting that RSA’s complicity with NSA is not their only enormous security black eye. Back in 2010 their flagship SecurID two factor login system was also widely compromised, it’s assumed by the Chinese government trying to get military and commercial access to US and European interests.
Open source ends up looking good in all this mess. NSA has probably attacked other random number implementations. There was a weird push from Intel to get Linux to completely trust their undocumented hardware generator, something resisted by the Linux team (thankfully). And OpenSSL, the open alternative to RSA’s library, doesn’t use the compromised algorithm (although their code has had its problems).
I remain indignant that NSA is willfully going around deliberately sabotaging the security of core Internet components. Even if you believe it’s good for NSA themselves to be able to break all encryption, it is so dangerous to have back doors like this hiding in systems. NSA is actively undermining everyone’s security.
Here’s something ugly, the whois response for pirate book site readanybooks.net. Below is an extract of the interesting parts that both MacOS and Debian’s whois display.
$ whois readanybooks.net Domain Name: READANYBOOKS.NET Registrar: XIN NET TECHNOLOGY CORPORATION Whois Server: whois.paycenter.com.cn Name Server: RICK.NS.CLOUDFLARE.COM Billing Contact: Name : li xiaoing Email : email@example.com <script src= "http://img2.xinnet.com/d/js/acmsd/thea178.js"> </script>
Huh? What’s an HTML tag doing in this whois response? And under what circumstances might that script tag be executed? I can imagine a naïve Web interface just injecting that script wholesale into my browser. Every way I load the referenced script it seems benign (right now), but that’s an attack vector waiting to happen.
Another reason to end passwords as a method of authentication is the poor usability of strong passwords on mobile devices.
Sorry if this is stating the obvious, but the lack of usability of strong passwords on my iPhone and iPad is a big part of why I don’t log into sites on mobile devices.
Google has reduced itself to outright spamming users to promote its products. Here’s a screenshot of an email I got today about Google’s failing payments product, Google Wallet. Note the footer, the email is marked “You have received this mandatory email service announcement to update you about important changes to your Google Wallet account”. What are those important changes?
In summary: four ads for Google products, one ad for random other companies that happen to use Google Wallet, and zero important changes. I guess I should block firstname.lastname@example.org?
It’s cliché now to point out how disappointing Google, Inc. has become. But this seems bad even for the trend. All that’s missing is the “+1 on Google+” button.
One of the great failures of the Internet era has been giving up on end-to-end encryption. PGP dates back to 1991, 22 years ago. It gave us the technical means to have truly secure email between two people. But it was very difficult to use. And in 22 years no one has ever meaningfully made email encryption really usable.
A big part of the problem is the architecture of Internet services. Most of us host our email on a third party server like Gmail or Lavabit or whatever. That makes true end-to-end encryption very difficult. Instead we have to trust our hosting service with access to our email, and as we find the government can compel them to rat you out (or simply break in).
We do have SSL/HTTPS, the only real end-to-end encryption most of us use daily. But the key distribution is hopelessly centralized, authority rooted in 40+ certificates. At least 4 of those certs have been compromised by blackhat hackers in the past few years. How many more have been subverted by government agencies? I believe the SSL Observatory is the only way we’d know.
The cypherpunks movement foresaw all of this surveillance risk. It outlined principles and technologies to protect individuals from both evil hackers and overreaching governments. It failed to actually implement it.
originally a Metafilter comment
I no longer really use passwords to log into websites. Instead I use an authentication agent that lives in my browser and proves my identity to websites. Sadly, the authentication protocols of the Web require sending my secret token rather than doing some safer public key protocol. And the details of figuring out how to transmit the token to each website are needlessly complex.
To put it another way, passwords are completely broken; even strong passwords like “qeadzcwrsfxv1331” are crackable. With LastPass in my browser I literally do not know what my password is on pretty much every one of the 479 websites I log in to. I already run a complex authentication protocol. The stupid thing is that it’s a very bad protocol, involving stuffing secrets into random form elements on the web page.
Mozilla Persona is a strong proposal for how to end passwords in a better way, at least for desktop computers. And Tim Bray has lots of good notes on the authentication and identity. I still think OpenID is sufficient, or maybe the newer OpenID Connect system. Hell, at this point I’ll accept log in with Facebook or Google+ Sign-In. But whatever it is needs to be universal. And it really should be vendor neutral.
I had a bit of email drama this week; Gmail started classifying half of my incoming legitimate email as spam. I got some great help from Gmail support who explained the problem and taught me how to properly forward email.
In detail, what happened… I get all my email to email@example.com, which I forward via procmail and SMTP to my gmail account. For some reason monkey.org recently got branded a possibly spammy domain. Because of my forwarding Gmail was under the impression that all my email was coming from monkey.org, so a bunch of it started getting marked as spam. The Gmail UI is a bit buggy in this circumstance; it was misidentifying which domain was the problem, telling me “we’ve found that lots of messages from gmail.com are spam” and the like when the real problem was monkey.org.
I fixed the problem by forwarding my mail properly. Gmail doesn’t just use the From: email header to identify the sender, it also uses the (normally invisible) From⎵ SMTP envelope. And because I misconfigured procmail, that header was always being set to firstname.lastname@example.org (since I was sending the mail). You can spoof the envelope too via -f, you just have to set it up that way. (Which makes me wonder why the spam filter pays any attention to it.)
It's a subtle problem; I only noticed it after several years. If you use procmail to forward to Gmail, you may want to look into your configuration. I believe most more ordinary forwarding mechanisms don’t have the envelope problem. Procmail is weird in that it’s generating new emails, not forwarding existing ones.
Check out this amazing popup Citibank gives you when you’re creating an account:
According to Citibank, a person’s name:
In other words, your name at Citibank can’t be anything like a person’s real name. Really it needs to be more like a password. But not too much like a password.
Welcome to our website. Your designation is THX_1138.
Yesterday’s leap second killed half the Internet, including Pirate Bay, Reddit, LinkedIn, Gawker Media and a host of other sites. Even an airline. Any Linux user processes that depends on kernel threads had a high chance of failing. That includes MySQL and many Java servers like webapps, Hadoop, Cassandra, etc. The symptom was the user process spinning at 100% CPU even after being restarted. A quick fix seems to be setting the system clock which apparently resets the bad state in the kernel (we hope).
The underlying cause is something about how the kernel handled the extra second broke the futex locks used by threaded processes. Here’s a very detailed analysis on the failing code but I’m not sure it’s correct. According to this analysis the bug was introduced in 2008, then fixed in March 2012. But it may be the March fix is part of the problem. OTOH most of the systems that failed will be running kernels older than March so the problem must go further back. There's a kernel fix and also a detailed analysis. Time is hard, let’s go shopping.
It’s frustrating that these bugs keep popping up; the theory is not so difficult. The NTP daemon tells the kernel a leap second is coming via adjtime(), the kernel should handle it by slewing or holding the clock, all is well. But it didn’t work in 2012. Didn’t work in 2009 either; a logging bug caused kernels to crash on the leap second. 2005 was better. Google’s solution of giving up on the kernel entirely and having the NTP daemon lie about what time it is seems more clever now.
I got hit by this bug myself, the CrashPlan
backup daemon runs Java and got caught in a spin. And
none of my machines really kept time right because POSIX
does not account for leap
seconds. Both Ubuntu boxes just ran 23:59:59 twice, so time went
backwards on a subsecond basis. My Mac was even worse, it actually flipped
over to 00:00:00 before going backwards to 23:59:59 briefly.