Ask / Submit
142

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

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

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 +0300

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 c.la
close date 2014-04-11 13:23:00.856615

Comments

7

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

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

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 +0300 )edit
3

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

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

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 +0300 )edit
5

I changed title a bit, hope it helps

c.la ( 2014-04-08 12:43:49 +0300 )edit

4 Answers

Sort by » oldest newest most voted
51

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

tigeli gravatar image

updated 2014-04-11 11:22:47 +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/)

edit flag offensive delete publish link more

Comments

1

you are so awsome <3

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

I closed as released :)

trying to keep it clean ;)

c.la ( 2014-04-11 13:23:21 +0300 )edit
20

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

Larswad gravatar image

updated 2014-04-08 13:33:27 +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.

edit flag offensive delete publish link more

Comments

17

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 )edit
2

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 +0300 )edit
9

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 +0300 )edit
1

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 +0300 )edit
4

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 +0300 )edit
4

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

Larswad gravatar image

updated 2014-04-10 12:09:47 +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.

edit flag offensive delete publish link more
3

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

ray-ven gravatar image

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

ray

edit flag offensive delete publish link more

Comments

1

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

jsoubiran ( 2014-04-09 14:12:18 +0300 )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 +0300 )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 +0300 )edit
4

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 ( 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 )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: 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 )edit

Question tools

Follow
5 followers

Stats

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

Seen: 2,503 times

Last updated: Apr 11 '14