[Q] Heartbleed - Disable Heartbeats in OpenSSL on Android 4.1.1 Rooted

Search This thread

dosmac

Member
Jul 20, 2009
35
2
Apparently the ONLY version of Android that is vulnerable to Heartbleed is 4.1.1. I ran a check on my phone, and sure enough I'm running that version, and heartbeats are definitely enabled. I used the Lookout security app to verify this. Is there a way I can patch my system myself and somehow disable the heartbeats feature without having to wait another 3 years for Motorola to come out with a fix? My phone is rooted, but something tells me that OpenSSL probably needs to be essentially recompiled with a flag set to disable heartbeats?

I was hoping there would be a quick config file for OpenSSL that can be modified, but I'm not usually lucky. Based on everything I've seen thus far, a recompile with a flag set is the only way to fix this. Figured i'd give it a shot and ask on here.
 
Last edited:

stevep2007

Member
Jun 5, 2012
22
10
I've been thinking about the same thing.

If memory was encrypted that could solve all or part of the problem.

If the Chrome https browser cache were turned off, which I think requires an APK edit there would not be any clear text data in the browser cache.

What do you think?

Apparently the ONLY version of Android that is vulnerable to Heartbleed is 4.1.1. I ran a check on my phone, and sure enough I'm running that version, and heartbeats are definitely enabled. I used the Lookout security app to verify this. Is there a way I can patch my system myself and somehow disable the heartbeats feature without having to wait another 3 years for Motorola to come out with a fix? My phone is rooted, but something tells me that OpenSSL probably needs to be essentially recompiled with a flag set to disable heartbeats?

I was hoping there would be a quick config file for OpenSSL that can be modified, but I'm not usually lucky. Based on everything I've seen thus far, a recompile with a flag set is the only way to fix this. Figured i'd give it a shot and ask on here.
 

skeevydude

Inactive Recognized Contributor
Feb 10, 2012
3,072
3,042
39
Hot Springs
Yep, 4.1.1 is vulnerable to this. 4.1.2 has the no heartbeat fix added in and 4.1.1 took the update that was bugged. That said, we DO have TWO 4.1.2 Stock roms, Mexican Retail and Bell are both 4.1.2 and should have that fix -- needs confirmation. Our Stock ICS roms are all from before this bug was added in and are safe. In reality, only stock, locked AT&T Atrix HD's are vulnerable to this since all the other roms* have this fix.

Normally I'd say something around the lines of give me a few days and I'll look into this more, but I've been busy lately, and when I'm not busy I'm either tired or sore; did some heavy lifting a few weeks ago and my back is still sore from that day.

*Our 4.1.2 roms are untested, but 4.1.2 AOSP has the fix so our 4.1.2 stocks should too
 

stevep2007

Member
Jun 5, 2012
22
10
I was just thinking that ther eis no such thing as security. Security is achieved by being harder to exploit than the other computers. Even 3-DES can be cracked with enough computing power.

So encrypting memory and stopping https caching would close two big holes. I'm now wondering what holes would remain to be exploited by the heartbeat exploit on a 4.1.1 device if this were done?
 

skeevydude

Inactive Recognized Contributor
Feb 10, 2012
3,072
3,042
39
Hot Springs
I was just thinking that ther eis no such thing as security. Security is achieved by being harder to exploit than the other computers. Even 3-DES can be cracked with enough computing power.

So encrypting memory and stopping https caching would close two big holes. I'm now wondering what holes would remain to be exploited by the heartbeat exploit on a 4.1.1 device if this were done?

If I was on a stock phone running 4.1.1 and I was that worried about heartbleed, I'd unlock the bootloader and install Bell or Mex Retail because both are 4.1.2. I might even be possible to just swap the exploited binaries with the ones in our 4.1.2 roms, that's something someone else worried about this can do. Hell, it might even be possible to run the 4.1.2 roms with safestrap and the AT&T kernel...again, that's a someone else thing...I have no intention of dicking with SSR.

Think about Wifi being hacked....when it first came out a crappy password like 12345678 was good enough because computing power wasn't that good for consumers yet; nowadays, a basic gaming laptop can check 500,000 wpa2 passwords a second, a decent desktop with multiple GPU's can do over a million a second. All wpa2 hacking is sniffing out the verification md5*, then the tools generate passwords and their md5 and compare it against the sniffed out one, eventually you'll find one that matches, especially so if the password sucks. If you know how certain telecoms set up their wifi passwords, you can shorten the amount of time taken by limiting to the characters they use -- for example, AT&T U-Verse** uses 10 digit numeric passwords, so all you'd have to do is limit the tools to use numbers and start with 10 digits....hint: there are only 1 million codes if you use 10 numbers only....10 to the power of 10 and all....

That isn't a wifi hacking tutorial, just an example of how overtime good security unchanged becomes very bad security and how eventually an exploit will be found and security compromised, like how wpa2 for a split second sends out a the verification md5 unencrypted.

*not sure if WPA2 uses md5, but most of us know what md5's are
**last time I read about that service that's what I saw...and I read that a few months ago