[snap] Doesn't store encrypted passwords unless interface is connected

[Erlenmayr]

In the Snap package of Chromium, Chromium is not protecting passwords with gnome-keyring (or KWallet).

As a result, copying the Chromium profile directory from the snap directory gives access to all stored passwords. This is a HIGH security risk. Regular users who are used to storing their passwords in browsers are probably unaware of this.

Note that Chromium is started with the command line option “--password-store=basic”. This hack should never have been released to the public.

The Chromium documentation states:
> --password-store=basic (to use the plain text store)

https://chromium.googlesource.com/chromium/src/+/master/docs/linux/password_storage.md

[Nathan Teodosio (nteodosio)]

Hello Erlenmayr, thanks for your report.

 > In the Snap package of Chromium, Chromium is not protecting passwords
 > with gnome-keyring (or KWallet).

You can connect the corresponding interface for that:

   snap connect chromium:password-manager-service

 > As a result, copying the Chromium profile directory from the snap
 > directory gives access to all stored passwords.

Please note those passwords are not stored in the clear, though they can
be discovered by going into Chromium's Settings > Passwords.

[A333 (agrrr3)]

> > As a result, copying the Chromium profile directory from the snap
> > directory gives access to all stored passwords.
>
> Please note those passwords are not stored in the clear, though they can
> be discovered by going into Chromium's Settings > Passwords.

According to the chromium documented cited, this is wrong.
According to the docs, the credentials are actually stored as plain text in the chrome profile if one is not using an external password manager.
And this is still true today.

You can also see that when using chromium - no one has to give a secret at any time to decrypt the passwords.

For many people an autoconnect for the password-manager-service would probably solve this

[Nathan Teodosio (nteodosio)]

> According to the chromium documented cited, this is wrong.

Maybe it's a different way of interpreting the terminology.

If it applied a rot13 to your password (of course that would be very stupid but it's just for the sake of the argument) and stored that in a file, I could say that it is stored in plain text and that however they aren't stored in the clear, i.e. they are not stored exactly as they are, there is some sort of transformation*, trivial or not, applied to them.

Otherwise, you could prove me wrong by pointing to the file where you see Chromium password stored in the clear.

> For many people an autoconnect for the password-manager-service would probably solve this

Then you're welcome to follow up in [1], in which the automatic connection of the interface has been declined. I cannot override the policy reviewers' decision.

*I think the transformation is the one Evan Carroll describes in LP:2038875.

[1] https://forum.snapcraft.io/t/auto-connecting-the-cups-control-and-password-manager-service-interfaces-for-the-chromium-snap/4592/6

[Erlenmayr (erlenmayr)]

What is there to prove? The documentation *literally* says it is plain text.

Also: Any attacker can just copy the entire browser profile to another machine and then access the passwords. So he does not have to care about the implementation details of the password storage at all.

On the other side, normal Chrome/Chromium (without Snap and this command line argument) is using Gnome Keyring to protect the passwords. In that case, the attacker would need the login password or a equivalent secret from PAM and friends.

[Nathan Teodosio (nteodosio)]

> What is there to prove? The documentation *literally* says it is plain
> text.

The documentation isn't the code that is executed. The only source of
truth is code and the proof is in the pudding, namely execution. However
that was not my point at all, you didn't read what I said carefully enough.

You can prove me wrong easily, grep the Chromium state files (or the
whole filesystem if you want) for your password and see if it returns
something. Or else show me the plain text file where it is stored.
Answer: It is

Now I've already investigated the issue and the file where your
credentials are stored is:

--->
% less "$HOME/snap/chromium/common/chromium/Default/Login Data"
".../Login Data" may be a binary file. See it anyway?
% file "$HOME/snap/chromium/common/chromium/Default/Login Data"
.../Login Data: SQLite 3.x database
<---

So much for plain text[1]. You could even go ahead and SQL dump it and
see if you could find the password in the clear. I didn't. Which of
course does not mean it is not easy to retrieve it.

> Also: Any attacker can just copy the entire browser profile to another
> machine and then access the passwords. So he does not have to care about
> the implementation details of the password storage at all.
 >
> On the other side, normal Chrome/Chromium (without Snap and this command
> line argument) is using Gnome Keyring to protect the passwords. In that
> case, the attacker would need the login password or a equivalent secret
> from PAM and friends.

Right. But as I said this was declined by policy reviewers and you are
welcome to follow up in that link.

[1] https://en.wikipedia.org/wiki/Plain_text

[A333 (agrrr3)]

> > According to the chromium documented cited, this is wrong.
>
> If it applied a rot13 to your password

...it would be the same security level against anyone who has ever read anything about security as storing it plaintext. That is just obfuscation.

The point was not that it is plain text. The point was that it is unsafe. And your cited discussion thread jdstrand also refers to the situation as
> with it not connected the passwords are stored in effectively plaintext on disk

If there is no (secure) secret, there is no added security level.

> > For many people an autoconnect for the password-manager-service would probably solve this
>
> Then you're welcome to follow up in [1], in which the automatic connection of the interface has been
> declined. I cannot override the policy reviewers' decision.

referring to that thread is a sensible answer;

probably there should be a feature request for an auto-connection to some kind of restricted password manager (where a snap can only write and read its own passwords), which may be manually connected to one of the usual password managers if the users decide so.

if what jdstrand writes is true..

> Other snaps that plugs password-manager-service also have access to chromium’s passwords.

.. i think the current password manager situation (all connected snaps sharing passwords) is kind of broken. Probably the same kind of broken like on a normal desktop, but snaps are supposed to sandboxed.

[Evan Carroll (evancarroll)]

I don't see how this debate is apropos. Whether or not the passwords are stored in the clear, or obscured with symmetric encryption using hard coded parameters in chrome is irrelevant. Both of these scenarios are entirely unacceptable.

That said, the answer here afaik is they're stored with a key generated with pbkdf2 using a password of "peantus" and a salt of "saltysalt" and 1 iteration. I think that because I know 100% this is how the Cookies work having examined the source in OSCrypt which is in os_crypt_linux.cc which I assume handles passwords too.

Ubuntu is the most popular Linux desktop. It's use is not unique from either OSX or Windows (which uses DPAPI). Both of which have entirely superior solutions to this problem and do not store passwords in clear text, or with hard-coded symmetric encryption. That's not the default anyway.

That all said, I will extend https://github.com/EvanCarroll/xbrowser/ to support decoding passwords soon.

So you'll have a tool you can run.. The command will be simple,

    xbrowser export chrome passwords

And you'll be able to dump all the passwords.

[Evan Carroll (evancarroll)]

> .. i think the current password manager situation (all connected snaps sharing passwords) is kind of broken. Probably the same kind of broken like on a normal desktop, but snaps are supposed to sandboxed.

In theory, sure. That doesn't mean it's defensible to not use it.

There is a theory solution here, you can use the XDG Desktop Protal spec https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Secret which supplies org.freedesktop.portal.Secrets and have containerized secret handling too. However, you'd still have to patch Chrome and it still sends the wrong signal to users that Snap refuses to use the systems keyring by default and so you're all vulnerable until the applications adopts the theoretical best practice available.

[Nathan Teodosio (nteodosio)]

> I don't see how this debate is apropos. Whether or not the passwords are stored in the clear, or obscured with symmetric encryption using hard coded parameters in chrome is irrelevant. Both of these scenarios are entirely unacceptable.

You are right, but if a statement presented as a certainty and is however inaccurate, I think it there is no harm in having a discussion to settle it, because the thread can serve a purpose for other people, and one different from ours.

If it became unclear, the fact that the current behavior is undesired is undisputed.

> So you'll have a tool you can run.. The command will be simple,
>
> xbrowser export chrome passwords
>
> And you'll be able to dump all the passwords.

I've already nudged folks internally and there will be a new review of the auto-connection request, that will be a great proof-of-concept and I thank you in advance.