FYI: Obligatory Heartbleed post

[Jens Alfke]

tl;dr: The “Heartbleed” security vulnerability doesn’t directly affect Couchbase’s mobile products. It’s possible the Android platform might have a vulnerability, but if so it would be shared by all Android apps and would have to be fixed by Google.

Keep in mind that Heartbleed is an OpenSSL bug, and while OpenSSL is the most common SSL implementation it’s not the only one.

• The Sync Gateway uses the Go language’s SSL implementation.
• Couchbase Server uses Erlang’s SSL implementation.
• Couchbase Lite on iOS/Mac uses Apple’s SecureTransport library for SSL, which has had its own problems (remember ‘goto fail’?) but is not based on OpenSSL.
• I don’t know what Android’s SSL implementation is based on, but I would guess OpenSSL. But Couchbase Lite is of course acting as a client, not a server (unless you’re doing P2P stuff), and while I think it may theoretically be possible for Heartbleed to be used by a server to attack a client, I haven’t heard anything about that and it seems pretty unlikely. In any case, the SSL implementation is part of the Android OS, not our code, so it would have to be patched in an Android update if it’s vulnerable.

A bit off-topic, but Heartbleed underscores two interesting points about security:

1. Using high-level languages or frameworks is good for security because they provide safety features like array bound checking. Heartbleed is a particularly catastrophic array bounds check bug. It would almost certainly not have occurred if OpenSSL were written in Go or Erlang or Java, and probably not in Objective-C either. There are obvious performance trade-offs, but IMHO people don’t weight security highly enough when making these sorts of implementation decisions.
2. The most secure way to handle passwords and private keys is to avoid keeping them in the process’s address space, in case there are vulnerabilities that give an attacker the ability to read memory. One of the less-appreciated features of Apple’s Keychain is that it keeps sensitive data in a separate system process that’s very well-protected against snooping. On iOS or Mac OS, if you put a password into the NSURLCredentialStore, it’ll be safer than if you keep it in an instance variable or a global — the app might briefly have the password in memory while constructing a message to a server, but it’ll probably get overwritten quickly since it’s not stored in a long-lived heap block. (There may be an Android/Java equivalent of this?)

—Jens