asked 2014-04-08 10:41:27 +0300
This post is a wiki. Anyone with karma >75 is welcome to improve it.
Due to the very critical heartbleed bug in the OpenSSL library, please update OpenSSL to version 1.0.1g in the next system update.
answered 2014-04-08 16:04:52 +0300
We are aware of the issue and currently working on it.
Update: Issue has now been fixed with the 1.0.5.16/Paarlampi-update. (https://together.jolla.com/question/38508/release-notes-software-version-10516-paarlampi/)
answered 2014-04-08 13:26:55 +0300
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.
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 +0300 )editI 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 +0300 )editNot 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 +0300 )editConnecting 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 +0300 )editanswered 2014-04-10 12:02:11 +0300
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.
devel-su
(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.
answered 2014-04-09 13:26:18 +0300
please change thread title. this is not a security issue on client-only device. no panicing please.
ray
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 +0300 )editWell, 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 +0300 )editThis 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 ( https://github.com/Lekensteyn/pacemaker ) running on my machine. The malicious server dumped the contents of previous HTTPS responses, in this case the mail headers, to the console: http://pastebin.com/gXVafU5E
Jonni ( 2014-04-10 13:31:05 +0300 )editWhile 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: 192.168.1.1:12610 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 +0300 )editAsked: 2014-04-08 10:41:27 +0300
Seen: 2,621 times
Last updated: Apr 11 '14
Preferably sooner than that! My desktop got the update this morning.
Fuzzillogic ( 2014-04-08 10:42:54 +0300 )editCanonical 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 +0300 )editWith only 6 votes it will be fixed around May 2015.
cropas ( 2014-04-08 11:40:22 +0300 )editIf someone knows a better title for the post, that could attract more votes, feel free to edit
scharelc ( 2014-04-08 11:56:19 +0300 )editI changed title a bit, hope it helps
c.la ( 2014-04-08 12:43:49 +0300 )edit