Bug#956045: gnome-keyring: several cryptographic vulnerabilities

[Daiki Ueno]

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

> On 2020-04-08 at 12:15:22, Daiki Ueno wrote:
>> "brian m. carlson" <sandals at crustytoothpaste.net> writes:
>> > [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.
>
> The attack I mentioned states that it is possible to simply run on the
> same processor as the affected process to conduct a side-channel attack.
> That applies to containers as well as other processes, in addition to
> VMs.

That attack assumes that the gnome-keyring-daemon process is running
inside the VM and the attacker on the host has full control.  That
certainly falls into the category of active attacks.

>> > 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
>
> gnome-keyring stores data in a cryptographic format and is therefore a
> cryptographic tool.  The standard cryptographic model assumes an active
> attacker, Mallory, who tampers with the data and monitors the actors.

We never say that that it is not worth fixing, but we consider it's not
our priority, because it's not vulnerable in our supported use-cases.

> Moreover, protecting against timing attacks like this is extremely
> simple.  It can be done with three lines of portable C:
>
>   int x = 0;
>   for (size_t i = 0; i < n; i++)
>       x |= a[i] ^ b[i];

And you thought that it's more effective to report it as a vulnerability
and just wait 45 days, rather than providing a trivial patch.

> You have also not mentioned the other attack which I mentioned in
> which there is information disclosure of metadata.

That's because it has already been disclosed 5 months before you
reported.  See the slides (from page 19) at my GUADEC presentation:
https://people.gnome.org/~dueno/libsecret-guadec.pdf

Although I admit I probably should have filed an issue on the upstream
tracker, I don't see any point re-evaluating the same issue and forcing
embargo.

> I should also point our that when someone reports a security issue to
> you with a disclosure deadline, the right time to discuss the matter or
> dispute the findings is during the coordination period.  If you don't
> bother to respond then, then the reporter can only assume that you don't
> care at all.  I received no such discussion or feedback about the
> reports during the 45 day disclosure window, only notification that some
> bug reports were filed.

Our security team lead immediately forwarded your report to us and
discussed the impact with the maintainers.  While we agreed that none of
those issues are considered to be serious enough, we also filed the
upstream issues to track those, which you've never got involved with.

If our agreement was not clear to you, there was probably a
communication problem.

> I would not perform coordinated disclosure with the GNOME Project again.