Snap uses hardcoded key and salt for password and cookie encryption
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
chromium-browser (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
A working Ubuntu install includes Gnome which includes the gnome-keyring. The snap version of Ubuntu does not make use of it. On an install of Debian with Gnome, the key ring is used. However, with Ubuntu everything is encrypted with the static key of peanuts and the salt of saltysalt, and openly accessible as sqlite databases in ~/snap/
This should probably be fixed. If a laptop is physically compromised it's trivial to decrypt this with a tool like xbrowser.
You can verify that gnome-libcrypt isn't chosen by default with --enable-
You can see /why/ gnome-libcrypt isn't chosen with chromium --password-
I don't think this is a vulnerability per se, Chrome ships in Debian with the ability to use a basic store too. But it's an undesirable configuration and a regression from Debian when it's run on a platform with gnome and libsecret, and only doesn't work because of snap.
summary: |
- Snap does not use v11 encryption for cookie store + Snap uses hardcoded key and salt for password and cookie encryption |
tags: | added: password-storage |
You know if you're using the insecure v10 cookies by looking at the first three bytes of encrypted data in the sqlite database. If it reads \x76\x31\x30 you've got v10.. literally. if the third byte is \x31 you've got v11 the desirable variant.