-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2016-12-31 09:30, 'Olivier Médoc' via qubes-devel wrote: > On 12/31/2016 05:25 PM, Andrew David Wong wrote: >> 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. >> > Ooops, I actually forgot. That's why I did not understood your arguments :D >
Understandable, given that it's been over three years. :) > In this case, it possible that openssl has been selected because it > supports HMAC (password verification instead of public key) ? > Because I still feel that the discussion about trust was related to > the usage (verification before any parsing) and that it did not > specifically outed the PGP tools because of that. > Re-read this thread if you don't believe me. :) > One good point however is that multiplying verification tools if they > have the same purpose increase the attack surface. If you use both PGP > and OpenSSL, you double the chances that a vulnerability is discovered > in one of those tools. > > >>> 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). > > I agree that this could be investigated. If there is security critical > code such as signature verification and that there are a lot of tools > available, selecting the most hardened one and stripping it to avoid bad > usage is probably a good idea. > >> >>>> >>>>> 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----- iQIcBAEBCgAGBQJYaDd7AAoJENtN07w5UDAwulwP/RWhz48K9uOPAVMOyX7Y1eJQ 0AcZuwK0x2vJU/vajGOEyGBvXLvFwXF55s5x+gxdfc5I08sJXkgO5eq8wdNNU1ul qU4m9WElPc9cTxVMTCsfk4gVA/ZtQQLtggW5AGAPk5PbKk0eHNuqBrEeD574ba06 c2SveUKy62Ck6XgabaBPH3Pm1tCvLS3oR/RL/EK+qEPycQxBKBb9M6YXSyXZTMh5 Zw6TDoeiJcGqwKxI+o2AgBHnZi2ANB9p7+XaCSZlH7wcY/1oQzH8UdBnao7biybI M3XtZ7BvoetvkK02NuCp2Pbf2nBcbyuFSlGMCHNGvJrpr9O8U7MJNeyFEym6qQK6 17rctpp/iCl66XUpC76dbmIerG12i+qNQ85HqSzLaLK0FCA1NzsxI4xrRHTOOXbl pe9EVL3B0DkMX6IkTbSuKGA9UU1Kl1maQdNEOkgeimKdPitqfyiLfcR2SQoQhRBO NkZyDL13vp8YdYrs0U7rgEC5jRT6ZrFwg79GCvVXpC9Y7QsMOTt1+FmJem7Y87CE izYm9HKbEfyXzoFfDmsOzUJkMkX+l9f5DssWoiOTRaU80sG4f0dlGh8EZWWjHCRX +Ae0eodJ7UR6BzX/3h5L3JV731MljZzO7KaxhPcKPI56dEl/oEEbp6xAZj9XOlt3 bCapE1UGt1BUZoVHNu5q =cLFO -----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/f700dfc7-87c7-e020-fac0-f81f70539077%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
