On 12/30/2016 11:30 AM, Andrew David Wong wrote: > On 2016-12-29 23:54, 'Olivier Médoc' via qubes-devel wrote: > > On 12/30/2016 06:58 AM, Andrew David Wong wrote: > >> On 2013-08-18 10:18, Joanna Rutkowska wrote: > >>> On 08/17/13 16:48, Marek Marczykowski-Górecki wrote: > >>>>> IIRC, gpg did waaay to much parsing (related decyrpting) before > >>>>> veryfing > >>>>>> the signature, which we agreed was wrong. Openssl seemed > >>>>>> better in this respect. > >>>> [...] > >>>> > >>>> By "gpg did waaay to much parsing (related decyrpting) before > >>>> veryfing the signature" you basically mean that gpg isn't usable > >>>> to encrypt the backup in our case, right? IIUC ideal solution > >>>> would be to first verify all the data intergiry, then decrypt it > >>>> and pass to restore core. But the "verify all the data integrity" > >>>> part needs access to the whole backup blob (so store it > >>>> somewhere), which isn't doable as I said earlier... Perhaps some > >>>> block-based data integrity check (so can be done on the fly), > >>>> but I'm not aware of any existing solution like this. As said > >>>> earlier I'd prefer to keep our backup format as simple as > >>>> possible - IOW to be extractable also with simple tools (without > >>>> QubesOS). > >>>> > >>>> IMHO the best compromise here is to encrypt/decrypt the data with > >>>> gpg (symmetric) then use tar for archive and each file keep with > >>>> attached hmac (additional file right after). This means that > >>>> untrusted data is processed by gpg (decryption), then by tar and > >>>> then by openssl for hmac verification. Note that if you don't > >>>> trust gpg in regard of parsing untrusted data (decryption here), > >>>> probably much more components must be also reimplemented (like > >>>> dom0 updates - rpm signatures, installation ISO signatures, > >>>> enigmail for thunderbird etc). So IMO we don't have really the > >>>> choice about the trust in gpg. > >>>> > >> > >>> We ain't need no stinkin' gpg to trust! > >> > >>> [...] > >> > >> After meditating on this thread for a little over three years, I'd > >> like to revive it, because I think Marek made an important point here, > >> and I don't quite understand Joanna's response. > >> > >> If we don't trust GPG in our backup system because it does too much > >> parsing of untrusted data before verification (which I believe is > >> correct), then why do we trust it in our dom0 update system? > >> > >> As a reminder, take a look at what we say about the security of the > >> dom0 update system.[1] We tout the "separation of duties" between dom0 > >> and the UpdateVM as a security feature (which it certainly is), but we > >> also note that we're implicitly trusting GPG in dom0 not to be > >> exploitable by a malicious package when it attempts to verify that > >> package. > >> > >> The only asymmetry between the two cases that I can see is that in the > >> case of dom0 updates, the packages are not encrypted, only signed, > >> whereas we have to assume that the backup blob may be encrypted. > >> Therefore, our position (viz., distrusting GPG with respect to backups > >> while trusting it with respect to dom0 updates) is consistent only if > >> it is the case that too much pre-parsing is done when handling a > >> signed-and-encrypted blob, whereas an acceptable amount of pre-parsing > >> is done on an only-signed blob. > >> > >> This condition, in turn, is likely to hold only if GPG handles > >> signed-and-encrypted blobs by *first* attempting to decrypt the blob, > >> *then* attempting to verify the integrity of the plaintext.[2] > >> Otherwise, there should be no significant difference between the two > >> cases in the amount of pre-parsing performed when verifying a blob. If > >> the first step is always verification, then the amount of parsing done > >> before the first step should be basically the same whether the thing > >> being verified happens to be plaintext or ciphertext. > >> > >> > >> [1] > >> > https://www.qubes-os.org/doc/software-update-dom0/#how-is-software-updated-securely-in-dom0 > >> > >> By the way, the last sentence in this section sounds false to me: > >> "While we could, in theory, write a custom solution, it would only be > >> effective if Qubes repos included all of the regular TemplateVM > >> distro's updates, and this would be far too costly for us to > >> maintain." This doesn't follow, since TemplateVMs are less trusted > >> than dom0. A more secure custom solution for dom0 updates would not > >> have to be applied to TemplateVMs in order to make Qubes as a whole > >> more secure (by making dom0 less vulnerable to attacks via malicious > >> update packages). > >> > >> Perhaps we meant something slightly different here: All the normal > >> distro packages *for dom0* (e.g., Fedora 23 packages, in the case of > >> R3.2) would have to be included in the Qubes repos in order for such a > >> solution to be effective. Even this would be true only if the custom > >> solution were repo- or package-dependent, and only if we wanted to > >> guarantee secure updates using the new method for all of those > >> packages. (There's a lot to be said for making dom0 smaller, and > >> minimizing the number of packages installed there accords with that > >> notion.) > >> > >> [2] This would seem to be a significant design flaw (perhaps a flaw in > >> the OpenPGP spec).[3] It means that GPG does either mac-then-encrypt > >> or mac-and-encrypt rather than the superior encrypt-then-mac.[4] > >> > >> [3] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > >> > >> [4] http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html > >> > > > I think the assumption was that PGP makes too much parsing during > > decryption/decoding of an encrypted blob. In fact it can do > > decryption, decompression which means more string/data manipulation > > routines and more potential bugs or vulnerabilities. > > > But this only matters if decryption is performed *before* HMAC > verification. If it's not -- if, instead, HMAC verification is > performed first -- then there will be one of two results: Either the > verification will succeed, in which case the data is trustworthy, and > decryption is safe no matter how much parsing it involves; or > verification fails, in which case the data is untrustworthy, and there > is no reason to attempt decryption or any further parsing at all. > > > On this assumption, PGP has been used first to check the signature > > of encrypted blobs (using a HMAC algorithm based on a user > > provided passphrase), then and only then any program could be > > selected to decrypt/decompress the data. In this case this can also > > be PGP. > > > If that's true, then our design is inconsistent, for we trust GPG in > the case of verifying packages but not in the case of verifying > backups, even though the amount of pre-parsing should be the same in > both cases.
Sorry, there is something I do not understand: The restore mechanism is working like this: verify HMAC first, then cancel the operation if the data is untrustworthy. Most package managers are working like this: verify PGP signature first, then tell the user the package is invalid if the signature is wrong or untrustworthy and stop doing things. So it is consistent. You should interpret "GPG is no trusted to parse package data" as "we should not give untrusted data to GPG decryption/decompression routines". > > > In most linux distribution PGP is used to verify packages before > > reading package data or extracting packages, but the reason is > > essentially validating package integrity and chain of trust. Not > > protecting against parsing=bugs=vulnerabilities. > > > Nonetheless, protecting against parsing/bugs/vulnerabilities applies > just as much (indeed, more) to packages. An attacker may attempt to > craft a malformed package that, when parsed by GPG for verification, > exploits a bug that allows it to take over dom0. This attack vector is > more likely than a malformed backup blob, since a package can be > distributed concurrently to thousands of users through a single repo, > whereas the storage locations of user backups are highly individual, > and most backups are never restored. > > > The question may be whether one should choose PGP or another tool, > > but in fact the important thing is how Encryption / Signature / > > Trust mechanisms are used whatever the selected or combined tool, > > and PGP can sign then encrypt or encrypt then sign. > > > I disagree. If GPG, when used *only* for verification, pre-parses to > such a degree that we consider it insecure for backup verification, > then we ought, on pain of inconsistency, to regard it as insecure > for any comparably security-sensitive verification task, including > for package verification. That is true, however, if you verify that the data is from a trusted source first, you limit the risk of the data being forged to trigger a vulnerability in the rest of your code. The verification routine can still be vulnerable, but this reduce your risks of being compromized, and the amount of source code that you should review. > > > One interesting example is the history of package signature in > > Archlinux: > > > Archlinux only choose recently - considering its history - to sign > > packages and it was during years considered as unnecessary by > > Archlinux developpers. Now it verify packages (trust), and > > *optionnally* the package database that contains metadata of all > > packages (Actually, I think that there is no signature available > > for the core package database). This means that this database that > > involve a lot of parsing is not verified, but packages are. > > > I don't checked how fedora package update exactly works, > > especially package database files, however I remember that packages > > are downloaded in an AppVM (usually the default firewall vm). The > > package signatures could then be verified against PGP fedora PGP > > keys before being imported in dom0, and are definitively verified > > in dom0 before generating a package database file only for dom0 > > [1]. > > > [1] /usr/libexec/qubes/qubes-receive-updates > > > As Joanna argued previously in this thread, it does little good to > verify the signature of an untrusted file in an AppVM as an > intermediate step before transferring it to dom0, since if the > verification process allows for the compromise of that AppVM, we > cannot trust it to accurately report the verification result of the > file that may have compromised it. > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/92606850-7f99-2d22-6f0b-74ce178d48ee%40yahoo.fr. For more options, visit https://groups.google.com/d/optout.
