Bug#956045: gnome-keyring: several cryptographic vulnerabilities

[Daiki Ueno]

"brian m. carlson" <sandals at crustytoothpaste.net> writes:

> On 2020-04-07 at 13:45:20, Daiki Ueno wrote:
>> "brian m. carlson" <sandals at crustytoothpaste.net> writes:
>> 
>> > First, the code to verify the integrity hash is done with memcmp.  This
>> > is not safe against timing attacks, so an attacker can tamper with the
>> > data and determine how much of the hash matches based on the amount of
>> > time it takes[0].  This comparison should be done in a constant-time
>> > way.
>> >
>> > [0] This can be a problem with an untrusted container with the user's
>> > home directory mounted in it.  There's documentation for VS Code that
>> > tells people how to do exactly this, so it's clearly a common situation.
>> 
>> Could you elaborate which document you are referring to?  I'm wondering
>> how it can be a problem provided that VS Code and gnome-keyring-daemon
>> are running as a separate process.  I believe that both snap and flatpak
>> provide a process isolation mechanism.
>
> The document at [0] provides documentation on how to mount your home
> directory into containers.  It is well known that people download
> containers using Docker that are not audited and may contain malware[1].

How could that be relevant?  Note that, to leverage the weakness you
reported, you would need to monitor either the activity of
gnome-keyring-daemon running on the host, or potentially, any
communication between other (trusted) applications and
gnome-keyring-daemon.  I don't think this container use-case could help.

> [2] is an example of a cross-VM cryptographic timing attack, which can
> also be applied across processes.  Other timing attacks are known even
> across networks.

I am not sure why you suddenly mention cross-VM attacks while VMs are a
different beast from containers.

> It is, in general, not safe to assume that any timing attack is
> unexploitable.

I would also be concerned with that, if this was reported against crypto
components.  However, this was reported against desktop, where
protecting active attacks is not a goal for various reasons:
https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy#Active_Attacks

Fortunately, the situation is improving thanks to the emerging
sandboxing technologies (snap, flatpak) and the Wayland security model,
though we can't be perfect as long as the user can always choose
insecure options to install untrusted applications.

>> It's a bit disappointing that you didn't quote the full response with
>> the additional context.  Here it goes, for reference:
>
> I believe my report substantially mentioned the relevant points, which
> are that
>
> * you are aware of the issues;
> * you don't see the issues as warranting an immediate fix; and
> * you are working on a plan to address them in gnome-keyring, but the
>   point at which they will be fixed is not presently specified.

By omitting the text, your report didn't convey the following important
points:
* we have a different analysis, stance, and ongoing efforts on the
  issues as mentioned in the linked article
* that article indicates that running untrusted applications with
  unnecessary previleges IS the problem

> It was my intention to fairly and accurately present the substance of
> your comments as relevant to the bug report without quoting the full
> email.

I am afraid this didn't work apparently.

Regards,