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

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

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.

@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

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.

Could use something like http://www.sqlite.org/see with using the lock code as the encryption pw.

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.

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).

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

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.

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

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.

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.

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?

@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).

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

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.

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.

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.

@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).

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)

@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.

@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.

@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.