On 2020-04-08 at 12:15:22, Daiki Ueno wrote: > "brian m. carlson" <sand...@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. > > 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. Even if you do not wish to protect against active attacks where an attacker tampers with the data, reasonable users will expect cryptographic tools to do so. Moreover, it is in fact part of the threat model of other password managers, such as 1Password. 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]; Now x is zero if the values matched, and nonzero if they didn't, and the operation is constant time. There's no reason not to fix this, even if you don't consider it a vulnerability. You have also not mentioned the other attack which I mentioned in which there is information disclosure of metadata. This is in fact trivial to reproduce and is in my opinion the most damning of the vulnerabilities because it is entirely passive and can be done completely offline. An attacker should not be able to determine from my keyring how many GnuPG keys I have stored passphrases for, which wireless network passwords I've saved, or if I have a password for a given username on a given Git hosting site. Right now, all of those are trivial from my login keyring. The fix to issue 1 is a simple, well-known technique which is standard practice among cryptographic tools. The fix to the other issues is to encrypt all the data using a secure AEAD or EtM construction. Since the former is easy to do and the latter is required to fix the most severe of the issues, I'm not sure why we're arguing about the particulars. 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. I would not perform coordinated disclosure with the GNOME Project again. I stand by my bug report that these issues represent security-related defects in the gnome-keyring package and that they need to be fixed. Unless you are specifically disputing that they constitute defects needing fixing, or are reporting on your intention to productively fix them, I ask you not to further respond to this report. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
