-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2016-12-30 04:43, 'Olivier Médoc' via qubes-devel wrote: > 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. >
I think you're forgetting that we decided not to use GPG in the backup system for precisely the reasons being discussed here (i.e., too much pre-parsing). Instead, we use OpenSSL for HMAC verification. Meanwhile, we continue to use GPG for package verification. > You should interpret "GPG is no trusted to parse package data" as > "we should not give untrusted data to GPG decryption/decompression > routines". > But that doesn't reflect our actual position. We distrust GPG for untrusted data *verification* in the backup system. If we didn't, then we would be using GPG in the backup system. >> >>> 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. > This point is not in dispute. We all agree that verification prior to any *further* parsing is superior to no verification at all. The question is whether the amount of parsing that GPG does *prior to verification* is acceptable for security-critical components. If it's not, then we shouldn't use it in any of them (including dom0 updates). If it is, then we should feel free to use it any of them (including the backup system). >> >>> 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. >> - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYZ9wEAAoJENtN07w5UDAwtxwP/0POqTWEH0rux6xI57ugk/5W KRkAhRhPJwegT3BnXklWAwyPgs5UYGJ0RaeqFO58FErnQFpVyMwN5CZmBmhwvYBt 8SpG6rL7eHFQfI7YV+uKW+8qNm9oFz8CuRgasIhpAj77yGMwYX28eTC+N2e1mzjN bU343lPFtqPIYUbWcviAoYiBRyXK/3keYUoBkgK0SbBCdeSSbmuV5fLqbKzW+gEB EMzT/Ye+Cv08BMoyTm3ddqx34XzNY5cn/8rnB1Geiz1ANdox27FcbFAtECp1lXVC wqQqb8Ey2NyyBgy74o9cPmyI71fPmj2nTQUsEBMEZE3xOaZrjs/4OKib0MoZ4L7v wYW6x5M+5w/7+tHNruGFJc+2UmiFU6KvcjVgX89jw3KXu2EEXjr2VLUVne17ahkU CwF6tWKFrxNkYdJIBWfMrb3zOfLx7txXJIrK1qYNZ0H8ELu9vBMDotyCrZN0vvn/ 2iiPEfBU73EI09h2n3iz9msWFvq3fNpsV3eRPY3HWoOxDw3gveu/DyhBMsORzaic OwYR6rC4p49Z00hjwmTrym5pfxPxgSIh9hGkxIu2q6byhkSPw2UkiQY7Kw6UlzHU T2TEwGKllxP023UouMZDKQBYuwLTpUKwybhJ6vL3npiy9sK/7oVS2KVEDvyJM8ik Nwxj7YjngeKzbpb2lhsT =ulSw -----END PGP SIGNATURE----- -- 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/535847fb-4c18-3ab7-7306-28cf79c73965%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
