Ask / Submit

[urgent bugfix] SERIOUS VULNERABILITY - Jolla please update OpenSSL lib (heartbleed) [released]

asked 2014-04-08 10:41:27 +0200

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.

updated 2014-04-10 16:19:12 +0200

penpen gravatar image

Due to the very critical heartbleed bug in the OpenSSL library, please update OpenSSL to version 1.0.1g in the next system update.

edit retag flag offensive reopen delete

The question has been closed for the following reason "released in a software update" by
close date 2014-04-11 13:23:00.856615



Preferably sooner than that! My desktop got the update this morning.

Fuzzillogic ( 2014-04-08 10:42:54 +0200 )edit

Canonical seems to be slower, Ubuntu got an update to 1.0.1e this morning. But that version still implies the bug, hopefully they will react soon.

scharelc ( 2014-04-08 10:46:31 +0200 )edit

With only 6 votes it will be fixed around May 2015.

cropas ( 2014-04-08 11:40:22 +0200 )edit

If someone knows a better title for the post, that could attract more votes, feel free to edit

scharelc ( 2014-04-08 11:56:19 +0200 )edit

I changed title a bit, hope it helps ( 2014-04-08 12:43:49 +0200 )edit

4 Answers

Sort by » oldest newest most voted

answered 2014-04-08 16:04:52 +0200

tigeli gravatar image

updated 2014-04-11 11:22:47 +0200

We are aware of the issue and currently working on it.

Update: Issue has now been fixed with the (

edit flag offensive delete publish link more



you are so awsome <3

scharelc ( 2014-04-11 11:37:44 +0200 )edit

I closed as released :)

trying to keep it clean ;) ( 2014-04-11 13:23:21 +0200 )edit

answered 2014-04-08 13:26:55 +0200

Larswad gravatar image

updated 2014-04-08 13:33:27 +0200

Actually, the heartbleed bug isn't very likely to leak much of value. The attacker need quite a bit of luck with a LOT of analysis in the raw 64KiB blocks returned.

Besides, how many of us are running https or say bitcoin servers on our jolla?

Don't cause panic from paranoia, its not constructive.

For the moment, I'm actually voting down on this just because I doubt the high priority stated. Even so, it wouldn't hurt if jolla upgrade as soon as they have the proper time to do so.

edit flag offensive delete publish link more



Even if this vulnerability is not critical, it is a good test on the reactivity of sailfish updates infrastructure.

It should not take them more than one day to deploy an upstream vulnerability fix.

Sailfish is also about security. The fact that it is based on gnu/linux, which means fast vulnerability correction, with a lot of manpower to do these fix, is a sales argument for Jolla.

Let’s see their reactivity.

vbregier ( 2014-04-08 15:41:29 +0200 )edit

I agree that a secure platform is indeed very important if it proves to have flaws that jeopardize the integrity and privacy of its users. But the title indicates that it is serious and urgent and personally I don't agree with that since the nature of this weakness doesn't apply to the usecases of mobile phones, if at all. I patched my own linux server in a hurry, because to that kind of machine it is sure relevant. I think jolla will get the chance to patch serious stuff later on anyway.

Larswad ( 2014-04-08 16:04:51 +0200 )edit

Actually patching the client is as important as patching the server as malicious server can retrieve parts of clients memory too.

tigeli ( 2014-04-08 16:09:14 +0200 )edit

Not really in this case, correct me if I'm wrong but for that to happen: 1. The phone itself need to connect to a server that performs a man in the middle attack AND is exploiting the heartbleed bug. 2. The phone and server must have the heartbeat extension active/enabled.

Larswad ( 2014-04-08 16:38:34 +0200 )edit

Connecting to a malicious server is not such a far-fetched and unlikely scenario, I would say. Similarly, typical scenarios for using internet on a cellphone, such as wifis in restaurants make MITM attacks significantly easier. Therefore this sounds like a serious issue even if one doesn't run any services on the phone.

dschoepe ( 2014-04-08 19:40:17 +0200 )edit

answered 2014-04-10 12:02:11 +0200

Larswad gravatar image

updated 2014-04-10 12:09:47 +0200

Noticed today that Jolla seems to have updated the repos now to the 'g' version, (if anyone really has panic in updating :-) ).

Use zypper or pkcon to update, i used zypper myself.

(enter password)
zypper ref
zypper up openssl-libs

I have no idea if the heartbeat extension even was compiled in at all into the ssl libs. But when i installed the openssl package and ran 'openssl version -a' I could see that there was no specific compile flag for disabling the extension, so an educated guess is that it was there. Even so, it is pretty far fetched that it would have been any threat to our devices, there is a lot of fud going on here.

edit flag offensive delete publish link more

answered 2014-04-09 13:26:18 +0200

ray-ven gravatar image

please change thread title. this is not a security issue on client-only device. no panicing please.


edit flag offensive delete publish link more



Can the problem simply be solved by installing the 1.0.1g version available on Openrepos?

jsoubiran ( 2014-04-09 14:12:18 +0200 )edit

From what I've read, clients using affected openssl are vulnerable too. Firefox (and thus sailfish browser?) uses Mozilla's own library. Normal browsing on Jolla should be safe. But what about Qt and/or webkit, which are used by many apps?

Fuzzillogic ( 2014-04-10 01:05:37 +0200 )edit

Well, actually it is. If you connect via SSL connection to a malicious server it can dump 64K blobs from your Jolla and maybe get credentials for your Jolla account, your online banking session, password aso. With every hearthbeat they dump memory from your heap and this can not be ignored. Jolla should ASAP fix this like they did with the fastload bootloader thing last December and not wait until April, 14th.

Nekron ( 2014-04-10 12:04:50 +0200 )edit

This is a very serious issue on the client side also. It's possible to get previously used login details, session cookies etc. for example from the Webcat browser. I tested the concept by logging in to my webmail with Webcat and after that navigating to an example malicious server ( ) running on my machine. The malicious server dumped the contents of previous HTTPS responses, in this case the mail headers, to the console:

Jonni ( 2014-04-10 13:31:05 +0200 )edit

While I see the point Jonni and Nekron are trying to make with client-side attack with malicious server, I wasn't able to reproduce the issue with Jolla browser, when using pace maker on server side I get:

Listening on :4433 for tls clients Connection from: Client returned 7 (0x7) bytes 0000: 15 03 03 00 02 02 2f ....../

And browser gives an "SSL received malformed Server Hello handshake message"

TopStreamsNet ( 2014-04-10 14:15:25 +0200 )edit

Question tools



Asked: 2014-04-08 10:41:27 +0200

Seen: 2,490 times

Last updated: Apr 11 '14