We have moved to a new Sailfish OS Forum. Please start new discussions there.

# Security risk with sqlite db in Jolla! Passwords in plain text in user space! [answered]

Dear Jolla Team, I found out today that a Jolla Phone which is connected via USB gives complete access to the folder Sailfish\Phone Memory.config\signond. Within this folder are lying 2 sqlite databases. Both can be opened with a stadard SQLite Manager like, for example, the Firefox Extension https://code.google.com/p/sqlite-manager/. In both cases the databases can be accessed without knowing any passwort. Inside I found my eMail-Passwort in clearcase-readable.

I think this is a security risk since connecting a phone to the wrong computer could give a script a chance to copy these dbs directly and giving my credentials for 3rd party accounts.

I know that this is not so likely to happen but the fact that one can simply access these files via windows explorer could give even other possibilities to read these files.

I think two steps should be performed, set a user password for the sqlite dbs and/or encrypt the password. Even if both methods can be broken by brute force it will at least raise the efforts needed to use the information.

Greetings

edit retag reopen delete

### The question has been closed for the following reason "the question is answered, an answer was accepted"by PatsJolla close date 2015-03-27 13:58:53.123604

5

The filesystem will not be exported by USB if the devicelock is on. So you can already avoid this by using that.

( 2014-04-15 12:04:37 +0300 )edit
2

Yes, but that doesn't solve the problem. If I connect an active phone, for example, because I just realised the batt is low, the data/file is still not save. Who would lock his phone right before connecting it (him/herself) for charging? And everytime I unlock the phone while it's still connected via usb I am exposing the files again and again.

( 2014-04-15 12:15:11 +0300 )edit
4

@PatsJolla: That's why there is charging only ;) That does not expose any data to a computer.

( 2014-04-15 12:37:14 +0300 )edit
1

@Phillippe I don't even get the question weather to switch to charging only or not. Please don't explain me now how to go to settings and change this. I know it's possible but it's nonsense I don't want to chage phone defaults to "reset-to-default" because there could be a security risk connecting the phone to usb for charging and exposing its content at the same time. How should I cover then possible bugs that still have not been found in default mode? - possible own PC infection not even told

( 2014-04-15 12:48:26 +0300 )edit
2

@PatsJolla: I was just telling you about a work-around for now. And personally having the phone ask makes sense to me as I don't want data exposed when I connect my phone to an unknown pc or charging point. So in one way it is weird you are less worried about exposing ALL your data that way, to any random PC, than some more complex attack vector like reading from a database though USB in a specific dir.

Anyhow it is a bug and it is reported. Passwords should never ever be stored in plain text.

( 2014-04-15 13:37:05 +0300 )edit

Sort by » oldest newest most voted

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

There is no work-around: This is a real thread now! If the file is within the user-space (what it seems to be the case), any app (native and [worst case:] Android) can access it, extract the password and call home.

@eric: Jolla should act immediately and provide an immediate update to close this security hole!

PS: Sailfish File Browser as well as CargoDock can read this folder and copy the files. Android OI File Manager showed only "This folder is empty" for .config.

PS Edit 2014-04-16. Android apps may not have access to the files due to the file attribute settings.

PS Edit 2014-04-16: It may not even need an app, to read out your passwords: Just a web page may be sufficient, see my answer below!

more

3

No, if unix access rights are set correctly any app can't access it. For example .config/signond is privileged/privileged so only jolla apps can access it.

( 2014-04-16 09:43:07 +0300 )edit
4

@jgr This is exactly same problem as your desktop computer has. Same-origin-policy protects local files same way as it does on your desktop. http://en.wikipedia.org/wiki/Same-origin_policy

( 2014-04-17 10:35:45 +0300 )edit
2

This is a fair bug report. This is an issue:

[nemo@Jolla ~]$cd .config/signond/ [nemo@Jolla signond]$ ll
total 36
-rw-r----- 1 nemo nemo 26624 2014-05-02 14:23 signon.db
-rw-r----- 1 nemo nemo  5120 2014-05-02 14:23 signon-secrets.db
[nemo@Jolla signond]$id uid=100000(nemo) gid=100000(nemo) groups=39(video),100(users),994(alien),995(ssu),996(timed),999(oneshot),1000(system),1002(bluetooth),1003(graphics),1004(input),1005(audio),1006(camera),1024(mtp),100000(nemo) [nemo@Jolla signond]$ pwd
/home/nemo/.config/signond
[nemo@Jolla signond]$ If it's accessible from a default shell in the nemo users directory, then it is accessible for at least nemo based applications. This is unacceptable and mandates a CVE security report. ( 2014-05-02 15:27:10 +0300 )edit 1 Could use something like http://www.sqlite.org/see with using the lock code as the encryption pw. ( 2014-07-04 10:44:16 +0300 )edit answered 2014-05-24 19:48:13 +0300 It turns out that on my Jolla at least these files are nemo:nemo owned. That can be easily fixed however: (you need to run under devel-su/root, otherwise you'll get access denied) chown privileged:privileged .config/signond/*.db chmod 0660 .config/signond/*.db  Additionally, you must edit /usr/share/dbus-1/services/com.google.code.AccountsSSO.SingleSignOn.service , replacing the line Exec=/usr/bin/signond  with Exec=/usr/bin/invoker --type=generic /usr/bin/signond  The last changed is required because otherwise signond itself will not have enough privileges to read the file! After this, most applications will no longer be able to read the file. I'm still testing whether anything breaks on my jolla while running with these changes. Calendar sync, mail, and IM seem to work, but you have been warned! more ## Comments 3 Thank you! Still one questions remains: why is there no action from Jolla in this? Maybe there will be, now that you have shown how it's done 8) ( 2014-05-25 14:06:10 +0300 )edit 1 @hardcodes.de, see the comment by Philippe De Swert: "Anyhow it is a bug and it is reported. Passwords should never ever be stored in plain text." I take it this will be fixed in the upcoming update. ( 2014-05-26 02:44:03 +0300 )edit 1 @nthn I can't see a Jolla tag on him, so I don't know if he has further insight. Nevertheless the plaintext part is debatable and I already had my debate with Javispedro. ( 2014-05-26 12:39:01 +0300 )edit 2 @hardcodes.de since most of the privileged account work was already done, I suspect that this will just happen on some update without much ado as it is a trivial thing. I remember it being privileged:privileged at some point so this may actually be a regression of a recent update. @nthn I don't think passwords being in plain text is a bug, as discussed. If you want more security than this "fix" provides the only solution is either being sensible with what you install or creating the "security framework" stuff. ( 2014-05-26 23:57:28 +0300 )edit answered 2014-04-15 16:38:32 +0300 One solution could be to only expose the Photos, Videos (Camera) and Music folders as separate folders via MTP, and not the complete home folder. The home folder could still be accessed using e.g. SSH via developer mode, and if need be, there could be a "Shared" folder inside$HOME that is also exposed via MTP, so users who want to copy files from/to the MTP device can do so using a file manager app and the "Shared" folder.

more

7

Hmm could be a good workaround and a fast solution, but I still would (also/additionally) prefer the passwords not to be plain text and/or the files to be encrypted

( 2014-04-15 16:49:46 +0300 )edit

Thread can be closed. The initial rights/permissions for this folder have been changed. It is now not accessible in the originally described way

more

Parts of my answer may not be popular but bear with me....

First of all my first knee-jerk response to the sketched situation is that just like you wouldn't login to your accounts using a computer you don't trust you shouldn't connect a device to such a machine.

Second as has been pointed out above it is possible to assure the connected computer has no access, using 2-factor auth will of course also mitigate a lot of the risks but not all.

sqlite as far as I know provides no user/password mechanism, it's not meant to be used that way and honestly I think most people want that data to be accessible so they can create scripts to backup, sync etc.

It is however possible to fix the problem, if the passwords are encrypted and then stored in the database, however this too has the problem that the key has to be stored somewhere unless you have to enter it on every reboot, if it is stored anywhere of the flash memory then scripts have a potential of reaching it. Jolla may already have a solution for that in the form of the reviled /drm partition which I am not 100% sure how it works. Another option would be to encrypt all the passwords with a passphrase that you are prompted for on boot or when you decide to bring the device online, this obviously has some convenience drawbacks and to a true paranoid person it would still mean a risk since the passphrase would exist in RAM.

Whatever the solution is the key has to be unique per device and not be based on something predictable like phone# or sim id etc since all these methods will eventually be figured out.

more

The encryption should be include the lock-screen password. Yes, this is not very strong (digits only, minimum length 6 digits), but combined with some other difficult to retrieve strings it would not be that easy to encrypt as it is currently. And: Your answer only takes the PC attack into account, not the app attack mentioned by me.

( 2014-04-16 01:01:58 +0300 )edit

Native and android apps can get to it, I didn't deal with it because I only skimmed most replies, but dealing with native/android apps is a lot more difficult since they have 'physical' access unlike the external machine

6 digit codes are as good as cleartext all possible combinations can be run by the jolla cpu in a matter of seconds (if it also needs to try the 'decrypted' password then more since the webservice will undoubtedly start blocking access if bombarded with too many auth requests).

( 2014-04-16 01:12:36 +0300 )edit

Most likely as I write above the solution lies in /drm much though I may despise DRM.

( 2014-04-16 01:13:55 +0300 )edit
1

The way to handle this is to have locked-down system daemon where only this daemon can access the credentials database. The information in the database can as well be encrypted. Apps which requires to grab credentials, uses an established API. That's basically how gnome-keyring and similar tools works already. And these tools can use the users login password as encryption key. A similar thing could be done with Sailfish as well, if you have the screen lock code set.

( 2014-05-02 15:31:25 +0300 )edit

There's no REAL solution for this. The closest you can get is:

2. Have some sort of daemon keep them decrypted in memory.
3. Have this daemon prompt the user every time a program requets access to a password (over a socket? dbus?).

There's the Secret Service API that covers all threee points, but it still requires a lot of work on all client applications.

Any other solution is just a false sense of security. I very much recomend reading that pidgin wiki article, since it applies in this scenario as well.

more

2

Actually the secret service API is practically deprecated by the signond stuff, which is an API that Meego invented and is being now used by Gnome3 and... Jolla. Yes, they already do this.

( 2014-05-06 13:35:49 +0300 )edit

I haven't managed to find the spec (after some quick searching). How does it deal with only giving password to authorized applications? It still needs to be unlocked upon every boot too.

( 2014-05-25 00:24:50 +0300 )edit

Both GNOME or KDE for instance have a password manager service that keeps this stuff encrypted and manage access. I'd like to see something like this.

( 2015-02-24 13:35:48 +0300 )edit

@Blizzz That's basically what I suggested. As mentioned above, that's the sigond API, and jolla already implements this. And again, an initial password prompt would be necesary (as is necesary with gnome/kde as well).

( 2015-03-24 04:05:15 +0300 )edit

What about SELinux to protect the file ? It even comes with a nice coloring book ! :)

more

2

SELinux can surely increase the security. But it's not the only thing which should be used in this case.

( 2014-05-02 15:32:38 +0300 )edit

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

[Edit: Sailfish 1.0.7: The file permissions have been changed (without devel-su and chmod they cannot be accessed) and the password is not written in clear text.]

Ok, to make it short: It may not even need an app, just a (Sailfish) browser only:

Try either:

(It seems, it does not work with Android browsers due to the file attributes.)

more

2

If that would be that easily exploitable Firefox would be in big trouble...

( 2014-04-16 23:06:21 +0300 )edit

Why? Does Firefox save passwords in plain text?

By the way: There are enough web sites (including this one, Jolla Together) that allow you to select a file from your file system and upload it to a web server. If you know the location of the file (path and name), you do not have to ask the user to upload. In case, a user interaction such as hitting a button should be required: You only have to label the bottom suitably and the user may click it.

( 2014-04-16 23:12:28 +0300 )edit
1

I'm afraid it doesn't work like that. Otherwise hackers would've been getting everyone to upload /etc/passwd (back when it still contained encrypted passwords). Yes, the plain texts passwords should not be there, but you can't make a user upload that file without them explicitly selecting it for upload.

( 2014-04-17 00:23:41 +0300 )edit

To upload a file, you place a simple form in your html code.

• Are you sure, that no JavaScript can interact with that form and pre-fill it with the "desired" file path/name?
• Are you sure, that there is no way for attackers to hide from you, what you really do but make you thinking you do something else? Presenting you for example with a fake layer under which the nasty things happen -- before you realize that you have been defrauded?

Alternatively to a file upload: Are you sure, that a web page script cannot read the local file (of which path and name and structure are known) and include the required parts in an URL? Or in a cookie to be read out thereafter?

( 2014-04-17 01:08:46 +0300 )edit
5

@jgr the short answer to your questions is: I'm as sure as I can be.

The long answer is there may be undiscovered security holes in browsers which could lead to the behaviour you suggest, but that would be a very serious security issue, Jolla or not, sqlite password databases or not. If you were to find some way a website could do that, it would be as notorious as the Heartbleed matter (and you would be world famous).

( 2014-04-17 01:31:38 +0300 )edit