Bug 1652194 (CVE-2018-19358) - CVE-2018-19358 gnome-keyring: login credentials retrieval via a Secret Service API call
Summary: CVE-2018-19358 gnome-keyring: login credentials retrieval via a Secret Servic...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2018-19358
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1652195
Blocks: 1652200
TreeView+ depends on / blocked
 
Reported: 2018-11-21 16:30 UTC by Laura Pardo
Modified: 2020-02-11 00:31 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-10 13:54:22 UTC


Attachments (Terms of Use)

Description Laura Pardo 2018-11-21 16:30:37 UTC
GNOME Keyring through 3.28.2 allows local users to retrieve login credentials via a Secret Service API call and the D-Bus interface if the keyring is unlocked, a similar issue to CVE-2008-7320. One perspective is that this occurs because available D-Bus protection mechanisms (involving the busconfig and policy XML elements) are not used. 


References:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1780365

Comment 1 Laura Pardo 2018-11-21 16:31:05 UTC
Created gnome-keyring tracking bugs for this issue:

Affects: fedora-all [bug 1652195]

Comment 2 Debarshi Ray 2018-11-22 15:02:56 UTC
Sorry, this is an invalid bug. There's no difference between this and a scp command that uploads your GPG and SSH private keys or any private file from the disk somewhere across the Internet.

Issues like this are mitigated by encapsulating untrusted applications in Flatpaks.

Comment 3 Riccardo Schirone 2018-12-06 10:41:21 UTC
Except that SSH/GPG keys should be passphrase-protected so even if you upload the files somewhere, your secrets are still safe.

Comment 4 Debarshi Ray 2018-12-06 13:28:02 UTC
Except "should be" isn't the same as "are always", and there's no reason why my personal photo collection or my bank statements aren't as senstive as my SSH/GPG keys or random passwords on random websites.

And don't even get me started about the possibility that any process can hold me hostage by threatening to 'rm -rf' my whole $HOME directory.

And no, this gnome-keyring libsecret issue isn't the only example of such a thing.

This CVE is a joke. It's not like somebody has found something hitherto unknown. Far from it. These issues have been known and understood for years. You are very unlikely to get a single patch that fixes it.

The solution, as I said so before, is to migrate applications to Flatpaks with portals acting as well-defined user-controlled gateways to accessing hardware peripherals, files, etc..

Comment 5 Ray Strode [halfline] 2018-12-06 13:42:53 UTC
agreed this is not a security problem.  see my analysis on https://gitlab.gnome.org/GNOME/gnome-keyring/issues/5

Comment 6 Riccardo Schirone 2018-12-10 13:54:04 UTC
I think this is still a security issue. Not an easy one, nor one where there's a single patch that can fix everything, but it's a design issue and somehow it should be solved in the future.

However, we can dispute this particular CVE for the reasons mentioned by both of you, debarshir and rstrode. Mainly because a malicious app can already do all sorts of things.

Comment 7 Riccardo Schirone 2018-12-10 14:02:46 UTC
Marking this flaw as NOTABUG because that is not an issue in gnome-keyring itself, but a design problem in the Linux desktop. There is no current way (except using Flatpak, sandbox, containers, etc.) to separate user applications from each other, so a malicious application could look at all your files, remove them, attach to other user processes to inspect their memory, etc. D-Bus protection mechanisms are not an option because applications could identify themselves as different applications with various mechanisms.

More references:
https://bugzilla.redhat.com/show_bug.cgi?id=1652194#c4
https://gitlab.gnome.org/GNOME/gnome-keyring/issues/5

Comment 8 Doran Moppert 2020-02-11 00:31:28 UTC
Statement:

Red Hat Product Security determined that this flaw was not a security vulnerability. See the Bugzilla link for more details.


Note You need to log in before you can comment on or make changes to this bug.