Re: [qubes-devel] apt RCE
On Tue, 22 Jan 2019, Chris Laprise wrote: > On 01/22/2019 08:49 PM, unman wrote: > > On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote: > > > On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA256 > > > > > > > > On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: > > > > Can you explain this? As far as I can see, the temporary update > > instruction *do* work in a template. > > What makes you think they don't? > > > With normal update proxy settings (no cache), this happens: > > > user@d9:~$ sudo apt -o Acquire::http::AllowRedirect=false update > > Ign:1 http://security.debian.org stretch/updates InRelease Hit:2 > > http://deb.qubes-os.org/r4.0/vm stretch InRelease Ign:3 > > http://deb.debian.org/debian stretch InRelease > > Err:4 http://deb.debian.org/debian stretch Release > > 302 Found > > Err:5 http://security.debian.org stretch/updates Release > > 302 Found > > Reading package lists... Done > > E: The repository 'http://deb.debian.org/debian stretch Release' does no > > longer have a Release file. > > N: Updating from such a repository can't be done securely, and is therefore > > disabled by default. > > N: See apt-secure(8) manpage for repository creation and user configuration > > details. > > E: The repository 'http://security.debian.org stretch/updates Release' does > > no longer have a Release file. > > N: Updating from such a repository can't be done securely, and is therefore > > disabled by default. > > N: See apt-secure(8) manpage for repository creation and user configuration > > details. > > Did I miss something? Isn't there a cure given to this problem in it? "This is known to break some proxies when used against security.debian.org. If that happens, people can switch their security APT source to use: deb http://cdn-fastly.deb.debian.org/debian-security stable/updates main" ...that is, disable (comment out) other repos in souces.list and update with this repo once? -- i. -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/alpine.DEB.2.20.1901230445510.6055%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jan 24, 2019 at 03:13:54PM -0500, Chris Laprise wrote: > On 01/23/2019 09:03 AM, unman wrote: > > On Tue, Jan 22, 2019 at 10:06:01PM -0500, Chris Laprise wrote: > > > I didn't realize, as Ilpo suggested, that I should comment-out the other > > > sources temporarily. That did the trick. > > > > > > > deb.debian.org, which you are using, isnt a repository. It's a > > placeholder with SRV records pointing to repositories. > > If the SRV doesn't work, then it provides a redirect function, which you > > are obviously blocking, (as instructed). > > The instructions aren't all that clear, since the problem will occur with > > any use of deb.debian.org, not just for security repos. > > The new debian-9 template appears to have an extraneous line for > 'jesse-backports' in sources.list. Oh, indeed, fixed: https://github.com/QubesOS/qubes-builder-debian/commit/07c4621d992da8de2780e07098e9dcab6680e673 Will be in the next template build. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxKISIACgkQ24/THMrX 1yxuywgAhCZ9en/IEIuqKzf0WQH7PF2FBFJpUG6SRb5SQ+4D1J3uLbq2chH0FanG YvGCEMJZ0DJtEDlPJ6vZ35hbKAwSh68NZ+UAa9wX+ZQINrARoATT+O/yeiaLzyGV A2SQ5lu8GKSTP8lAjPn77QOWC4EvIlWwtEeh5driyv+ThRRjt5WfeZGyU6ifxafe 63sTVRxKd3g+ds2/BbARH4ATnLN8MT6n2dIzvpX+yfOBzMe+awNrEw75OhmoUb5U LCilB9VqhdzSrE2uGhFx5RaPBcCNtjjd+iycpZEe+1VsGKaRBynx017jAU1iqQJ0 JU9wMeNOlfFwPlDa0GPRH0rRaN1lVA== =1QSY -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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190124203338.GA1429%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On 01/23/2019 09:03 AM, unman wrote: On Tue, Jan 22, 2019 at 10:06:01PM -0500, Chris Laprise wrote: I didn't realize, as Ilpo suggested, that I should comment-out the other sources temporarily. That did the trick. deb.debian.org, which you are using, isnt a repository. It's a placeholder with SRV records pointing to repositories. If the SRV doesn't work, then it provides a redirect function, which you are obviously blocking, (as instructed). The instructions aren't all that clear, since the problem will occur with any use of deb.debian.org, not just for security repos. The new debian-9 template appears to have an extraneous line for 'jesse-backports' in sources.list. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/cb397610-c006-1e7f-507b-93b68e18f2d1%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 23/01/2019 11.16 AM, Simon Gaiser wrote: > Patrick Schleizer: >> Many users already upgraded APT in a vulnerable way without ever knowing >> about this issue. > > That's probably true. OTOH if you count since the public announcement > from Debian it's only about 29 h. So I think there's also a significant > portion of users who didn't installed new packages in that time (While > apt-get update is also affected, AFAIU, unless you find another bug in > APT this does not enable code execution.). > > For those affected we at least offer fresh templates. Of course > depending on the usage of those templates recovering might still require > significant work (sanitizing/recreating affected VMs). > > And then there is of course always the possibility that somebody > discovered this bug much earlier. > >> What about introducing a security on/off switch that a subset of Qubes >> developers can trigger? > >> Before apt-get (or other package manager) does actually anything, a >> simple script could fetch a file from Qubes clearnet domain (and/or >> onion) and ask "is it currently secure to update"? > >> In most cases, the server would provide a cryptographically signed file >> by a Qubes developer which says "ok". Otherwise in situations such as >> now with APT security vulnerability DSA 4371-1 a Qubes developer could >> put a cryptographically signed file saying "not safe" there. In such >> cases, updates would be blocked until a new file is provided. > >> Things to keep in mind related to such a file: man-in-the-middle attack >> - infinite freeze atttacks; rollback attacks; perhaps more. Can think >> about this more if this sounds interesting. > >> Of course there should be options to: > >> - disable this mechanism entirely >> - manually override by user > >> These override option is useful for: > >> - to stay flexible in case of bugs of this mechanism itself and, >> - to not give Qubes developers too much power. No advanced adversary >> should be able to ask Qubes developers to remotely brick all Qubes >> installations (mostly theoretic at this point and not important for now >> but still easy to implement and good to have), >> - other unforeseeable things. > > I think blocking updates automatically is probably more problematic > than useful. But ... > >> This idea could be seen as a subset of the emergency project news >> mechanism that is currently missing in all distributions. In short: >> distributions have no mechanism to communicate with their users >> effectively in situations such as this one. More info: > >> https://www.whonix.org/wiki/Dev/project-news > > I think having something like qubes-announce directly integrated into > Qubes is a very interesting idea. (Of course implementing it safely is > tricky). > > Simon > Related issue: "Mechanism to notify users when critical action is required" https://github.com/QubesOS/qubes-issues/issues/3430 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxJJeMACgkQ203TvDlQ MDD3bBAAm/VlNvXQTmA/apCk3ZwWzNWqKCdawiBzjebJTjg/UDabUaZDnvihdfdf 7VGRlJIUONq0k4ddpImxv89OiklRC/VWzK7d/2t1TW+ZerN24WqRQRfSfWg/uCIz VqHj3WDJ3vPBAuBA9NqBjweisnsvi+nzvLeob/6xaYGk/Ch5Cluy2SKiNDDJip7n OkLlDcT5jB32HTzT0fHSdh+VrLGIx2Ey5sQOke2xvbF22M6wyrgcbvNcNdI5SR3I pfLP+XGrbwrhMDSZdhtGiWwaSYp77FYlcUqY2GC9IoyrjGg0pAyBDwpJSQqzVAFG Zti+2sHaVqt9rVhc0JigcC96I4Z16xH7cmjQto9mtfTqCxUX0W0+zds0xiPOvuA3 342ZxHfbTIVfWWORbq9LYAdLCqHUyXRBKH7rqke8M0XMlRAMoUJ0OOsN5dLyR6JJ ChiYCNlGpPQDOsHCKANR2fhEks1BxQJq7G3T4yHWd8cCITHhArty6A270aOO1H2v O51jWRCd7WKPJXm4Z+EpDr+bqqRvzMv9RBQ/3i51sk0HocSBb6jJ3N9RzxlmVmOk t5XTtY4X+aKrXScz4Z3v0AhgJDulqYhtelZ995B5WOh9F3+BwRQHgqwnHGx3C0dI IqlpWxmKbJ4wAMbFWQDTJvDduupDqV/XL5eT5hYBKkZNFQGcZwM= =J40i -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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/5951eeb2-0afe-2e3a-c329-6c817852e7a1%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 unman: > On Wed, Jan 23, 2019 at 10:02:00AM +, Patrick Schleizer wrote: >> Many users already upgraded APT in a vulnerable way without ever knowing >> about this issue. >> > > Yes, and many will have installed the update before Qubes is able to > push out a resolution. So, not meaning to put down efforts, it seems to > me that working on a scripted solution is not the best way to go. One of the main motivation for the scripted solution was to cover users who don't read the announcements (Also it's reused for template builds). > I dont know what is the readership of qubes-users, but should > announcements not be sent there for widest coverage? Particularly where > the fix is already available and could be installed by anyone capable of > copying commands. (Please, no adverse comments about our users.) What do you propose exactly. Pre-announce the QSB? Notify about the Debian announcement? Something else? We should consider some quicker reactions than a full QSB. But then you also need to consider that creating such announcements in a hurry is tricky, especially if you try to provide copyable command. I'm sure Debian has put some thoughts into their message and still it wasn't that clear to some users. >> What about introducing a security on/off switch that a subset of Qubes >> developers can trigger? >> >> Before apt-get (or other package manager) does actually anything, a >> simple script could fetch a file from Qubes clearnet domain (and/or >> onion) and ask "is it currently secure to update"? >> >> In most cases, the server would provide a cryptographically signed file >> by a Qubes developer which says "ok". Otherwise in situations such as >> now with APT security vulnerability DSA 4371-1 a Qubes developer could >> put a cryptographically signed file saying "not safe" there. In such >> cases, updates would be blocked until a new file is provided. >> >> Things to keep in mind related to such a file: man-in-the-middle attack >> - infinite freeze atttacks; rollback attacks; perhaps more. Can think >> about this more if this sounds interesting. > > I think that you have already identified many of the reasons why I > wouldnt favour such a process. > Another major issue is that it relies on users responding to the > inability to update, and once the resolution is posted, updating as > instructed. As opposed to simply doing nothing and then updating as > normal. (Whatever the Qubes scripted solution may be it must rely on > users updating and installing it before using apt again.) The note about installing with apt is true. But if "updating as normal" is through the Qubes Manager they are covered. > I'm generally not in favour of mechanisms that push to users. I have > seen these implemented in various networks and they sometimes work well. > I'm not convinced that they work any better than passing information by > posting messages on mail or website. Users who dont follow those are > likely also to ignore pushed messages - classic click through without > reading. I think having some way to notify users directly in Qubes (a widget or something) would reach a lot more users than any MLs. >> Of course there should be options to: >> >> - disable this mechanism entirely >> - manually override by user >> >> These override option is useful for: >> >> - to stay flexible in case of bugs of this mechanism itself and, >> - to not give Qubes developers too much power. No advanced adversary >> should be able to ask Qubes developers to remotely brick all Qubes >> installations (mostly theoretic at this point and not important for now >> but still easy to implement and good to have), >> - other unforeseeable things. >> >> This idea could be seen as a subset of the emergency project news >> mechanism that is currently missing in all distributions. In short: >> distributions have no mechanism to communicate with their users >> effectively in situations such as this one. More info: >> >> https://www.whonix.org/wiki/Dev/project-news >> >> Cheers, >> Patrick > > Almost every project has such mechanisms, but they rely on user opt in > and response. I've had a quick look at the proposal and I cant see how > it will overcome the obstacles that bedevil existing schemes. > > I have seen this sort of mechanism implemented on private networks, > where users HAD to perform certain actions before being able to access > company resources. Sometimes it worked; sometimes not. Only the threat > of the policy handbook would make some users do the right thing, and even > then there was considerable kick back. More effort went in to > circumventing controls than in to compliance - some people are like > that. > (I recognise that you mention an opt-out/override option.) I think Qubes OS users has much more users who not ignore such instructions than in a classic cooperate environment. And if users intentionally ignore our advice, that's fine, I think. It's their decision.
Re: [qubes-devel] apt RCE
On 01/23/2019 09:43 AM, unman wrote: On Wed, Jan 23, 2019 at 10:02:00AM +, Patrick Schleizer wrote: Many users already upgraded APT in a vulnerable way without ever knowing about this issue. Yes, and many will have installed the update before Qubes is able to push out a resolution. So, not meaning to put down efforts, it seems to me that working on a scripted solution is not the best way to go. One more wrinkle to all this: People installing the debian-9 template fresh (or reinstall): How should they update securely? There is the install iso and also the repo package to consider. I suppose the latter is relatively easy to update, but the iso not so much. I wouldn't object to a dom0 solution that - at template install time - tests a watchlist of package versions for that OS. This could be touted as a form of VM hardening offered by Qubes. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1ffc2521-a647-40a1-c40f-661cd4dd8605%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrick Schleizer: > Many users already upgraded APT in a vulnerable way without ever knowing > about this issue. That's probably true. OTOH if you count since the public announcement from Debian it's only about 29 h. So I think there's also a significant portion of users who didn't installed new packages in that time (While apt-get update is also affected, AFAIU, unless you find another bug in APT this does not enable code execution.). For those affected we at least offer fresh templates. Of course depending on the usage of those templates recovering might still require significant work (sanitizing/recreating affected VMs). And then there is of course always the possibility that somebody discovered this bug much earlier. > What about introducing a security on/off switch that a subset of Qubes > developers can trigger? > > Before apt-get (or other package manager) does actually anything, a > simple script could fetch a file from Qubes clearnet domain (and/or > onion) and ask "is it currently secure to update"? > > In most cases, the server would provide a cryptographically signed file > by a Qubes developer which says "ok". Otherwise in situations such as > now with APT security vulnerability DSA 4371-1 a Qubes developer could > put a cryptographically signed file saying "not safe" there. In such > cases, updates would be blocked until a new file is provided. > > Things to keep in mind related to such a file: man-in-the-middle attack > - infinite freeze atttacks; rollback attacks; perhaps more. Can think > about this more if this sounds interesting. > > Of course there should be options to: > > - disable this mechanism entirely > - manually override by user > > These override option is useful for: > > - to stay flexible in case of bugs of this mechanism itself and, > - to not give Qubes developers too much power. No advanced adversary > should be able to ask Qubes developers to remotely brick all Qubes > installations (mostly theoretic at this point and not important for now > but still easy to implement and good to have), > - other unforeseeable things. I think blocking updates automatically is probably more problematic than useful. But ... > This idea could be seen as a subset of the emergency project news > mechanism that is currently missing in all distributions. In short: > distributions have no mechanism to communicate with their users > effectively in situations such as this one. More info: > > https://www.whonix.org/wiki/Dev/project-news I think having something like qubes-announce directly integrated into Qubes is a very interesting idea. (Of course implementing it safely is tricky). Simon -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlxIoXUACgkQkO9xfO/x ly9Avw/7BqFwvZ/1N9WrWQGx3HTzg83ltMNdxq6/pnPCpYK9SgBzGl6b0jsdnTZH sa7q4SXkDCSO9wyBkXMdgV89FS4ACc41gTocybUBpu7yXiTBSfFnWBNZku6WlfqC v/th0zr2MNEQP2naV2lV1D4MXTHX5zUvX8hMvyAY6nDe6CxjEL+D3sqqlFE6YfKW YsyRwGsynCFOsnYhMRHqLX/Y4Cp+baIMW0J1h1Ns1gtrlju8Kc7hI7kyNA3e8hzo KW/gTJlj8Ug4jS6J/JMf0q2Xut+WWsnp6NkxMY/WD1y6IoxT9+u28pld8shHCsyu m4/GsNe94F7uZlgHIgHto6hTRq619+0A3RoP36zrKFhUqLTVUVDN3wvY4HqZBUnF b2IvslfDTy2bfHFPsNArWB3iVQoZlQq97fLg/q+SJ7bOkea0EvD9Ajy14V03cG1K H7vrztcDDQmuar5Yzr1donXwRU1D57MFT/fHrJUZb5AzestfkCiQoe0iBdYzIBPq FqY1hcoksKKyaym09GYZTQYZTPXe4CcM+Urz6Yjr1Q/Dm7YtiaBofxcjRfORJ2q9 atlc2Oz1SrVTogGWgHU7spnkZb42CErc1hh2dI0cH4A4nHiGKpNQstsCGEbYMOEE sa/EnNRcZUfHbxOLSwwNSrqg+MSFAKuLeH+zxJBLqRDDfjo9Agw= =jAwT -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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/af02a09a-3760-4bbe-824c-f2df8548a4bd%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On Wed, Jan 23, 2019 at 10:02:00AM +, Patrick Schleizer wrote: > Many users already upgraded APT in a vulnerable way without ever knowing > about this issue. > Yes, and many will have installed the update before Qubes is able to push out a resolution. So, not meaning to put down efforts, it seems to me that working on a scripted solution is not the best way to go. I dont know what is the readership of qubes-users, but should announcements not be sent there for widest coverage? Particularly where the fix is already available and could be installed by anyone capable of copying commands. (Please, no adverse comments about our users.) > What about introducing a security on/off switch that a subset of Qubes > developers can trigger? > > Before apt-get (or other package manager) does actually anything, a > simple script could fetch a file from Qubes clearnet domain (and/or > onion) and ask "is it currently secure to update"? > > In most cases, the server would provide a cryptographically signed file > by a Qubes developer which says "ok". Otherwise in situations such as > now with APT security vulnerability DSA 4371-1 a Qubes developer could > put a cryptographically signed file saying "not safe" there. In such > cases, updates would be blocked until a new file is provided. > > Things to keep in mind related to such a file: man-in-the-middle attack > - infinite freeze atttacks; rollback attacks; perhaps more. Can think > about this more if this sounds interesting. I think that you have already identified many of the reasons why I wouldnt favour such a process. Another major issue is that it relies on users responding to the inability to update, and once the resolution is posted, updating as instructed. As opposed to simply doing nothing and then updating as normal. (Whatever the Qubes scripted solution may be it must rely on users updating and installing it before using apt again.) I'm generally not in favour of mechanisms that push to users. I have seen these implemented in various networks and they sometimes work well. I'm not convinced that they work any better than passing information by posting messages on mail or website. Users who dont follow those are likely also to ignore pushed messages - classic click through without reading. > > Of course there should be options to: > > - disable this mechanism entirely > - manually override by user > > These override option is useful for: > > - to stay flexible in case of bugs of this mechanism itself and, > - to not give Qubes developers too much power. No advanced adversary > should be able to ask Qubes developers to remotely brick all Qubes > installations (mostly theoretic at this point and not important for now > but still easy to implement and good to have), > - other unforeseeable things. > > This idea could be seen as a subset of the emergency project news > mechanism that is currently missing in all distributions. In short: > distributions have no mechanism to communicate with their users > effectively in situations such as this one. More info: > > https://www.whonix.org/wiki/Dev/project-news > > Cheers, > Patrick Almost every project has such mechanisms, but they rely on user opt in and response. I've had a quick look at the proposal and I cant see how it will overcome the obstacles that bedevil existing schemes. I have seen this sort of mechanism implemented on private networks, where users HAD to perform certain actions before being able to access company resources. Sometimes it worked; sometimes not. Only the threat of the policy handbook would make some users do the right thing, and even then there was considerable kick back. More effort went in to circumventing controls than in to compliance - some people are like that. (I recognise that you mention an opt-out/override option.) -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190123144300.icw6y572g7sv4pd6%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Jan 23, 2019 at 10:02:00AM +, Patrick Schleizer wrote: > Many users already upgraded APT in a vulnerable way without ever knowing > about this issue. > > What about introducing a security on/off switch that a subset of Qubes > developers can trigger? > > Before apt-get (or other package manager) does actually anything, a > simple script could fetch a file from Qubes clearnet domain (and/or > onion) and ask "is it currently secure to update"? > > In most cases, the server would provide a cryptographically signed file > by a Qubes developer which says "ok". Otherwise in situations such as > now with APT security vulnerability DSA 4371-1 a Qubes developer could > put a cryptographically signed file saying "not safe" there. In such > cases, updates would be blocked until a new file is provided. > > Things to keep in mind related to such a file: man-in-the-middle attack > - infinite freeze atttacks; rollback attacks; perhaps more. Can think > about this more if this sounds interesting. > > Of course there should be options to: > > - disable this mechanism entirely > - manually override by user > > These override option is useful for: > > - to stay flexible in case of bugs of this mechanism itself and, > - to not give Qubes developers too much power. No advanced adversary > should be able to ask Qubes developers to remotely brick all Qubes > installations (mostly theoretic at this point and not important for now > but still easy to implement and good to have), > - other unforeseeable things. While such mechanism in this particular case could be useful, generally I think it makes more harm than good. Potential of breaking updates completely is too big, either by a bug in such mechanism, or someone attacking this mechanism itself. Having a single point of failure blocking (potentially) all updates for all templates (and maybe even dom0) doesn't sound good. > This idea could be seen as a subset of the emergency project news > mechanism that is currently missing in all distributions. In short: > distributions have no mechanism to communicate with their users > effectively in situations such as this one. More info: > > https://www.whonix.org/wiki/Dev/project-news > > Cheers, > Patrick > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxIemAACgkQ24/THMrX 1yz4HQf/QEzPlS+WkX1kjF3xT7FRx273Aj8sJWBwncTNO6QTPk2dLO5Qyomfo4vi 7106DJa4iRcEBrRFU+rCsAoXYWAL/eFRCIVr6XxYLez3y4aX3qaF9aOfRV7PBKEg FUZcTHvAsY980sYA1ZM7OEYwDXgxU4Jqo1HkVqFE5FjjmXUy7QEWBvDJWIbcOTBz deEflNglvbsMvYsTe/TAEfJ4p34n7NsxzMZJWxZeOPATdZcr6zZYweBpp6heBqtS LElp7/dtO0ac6p4PqSkfDbyXxPAe8Ucf14TSXY/2XnO/D8PJ1cqhG6LC0e6J+4ey a03uzaxddh3Iv9DPrg+RpoQXpZkS/w== =pPkF -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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190123142952.GE2528%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On Tue, Jan 22, 2019 at 10:06:01PM -0500, Chris Laprise wrote: > On 01/22/2019 09:51 PM, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Tue, Jan 22, 2019 at 09:44:31PM -0500, Chris Laprise wrote: > > > On 01/22/2019 08:49 PM, unman wrote: > > > > On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote: > > > > > On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > > Hash: SHA256 > > > > > > > > > > > > On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: > > > > > > > https://justi.cz/security/2019/01/22/apt-rce.html > > > > > > > > > > > > > > A patch is out to cover this vulnerability, but I'm of the > > > > > > > opinion that it may be best to move the qubes-update-proxy worker > > > > > > > VMs to a disposable VM model after reading up on this one. > > > > > > > > > > > > > > Granted, at first glance it appears that the use of the > > > > > > > qubes-update-proxy certainly helps, but using disposable VMs > > > > > > > might provide an extra layer of protection. > > > > > > > > > > > > Updates proxy unfortunately does not help with this issue, but also > > > > > > is > > > > > > not affected by it (at least not directly). It is only a http > > > > > > proxy, which > > > > > > does not interpret content it receive, only pass it down to the VM > > > > > > that > > > > > > requested it. Specifically, if remote server would send malicious > > > > > > Location: header, it will be forwarded back to apt. While in theory > > > > > > that > > > > > > proxy could perform some extra filtering on the response, it isn't > > > > > > used > > > > > > for that right now. I don't think tinyproxy supports anything like > > > > > > this > > > > > > (but we could change it to a different http proxy implementation). > > > > > > > > > > The proxy appears to be 'affected' in the sense that Debian's > > > > > temporary > > > > > update instructions from their security bulletin do not work in the > > > > > Qubes > > > > > template. > > > > > > > > > > So we are missing a straightforward resolution that Qubes users can > > > > > follow. > > > > > > > > > > > > > Can you explain this? As far as I can see, the temporary update > > > > instruction *do* work in a template. > > > > What makes you think they don't? > > > > > > > > > With normal update proxy settings (no cache), this happens: > > > > > > > user@d9:~$ sudo apt -o Acquire::http::AllowRedirect=false update > > > > Ign:1 http://security.debian.org stretch/updates InRelease > > > > Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease > > > > Ign:3 http://deb.debian.org/debian stretch InRelease > > > > Err:4 http://deb.debian.org/debian stretch Release > > > > 302 Found > > > > Err:5 http://security.debian.org stretch/updates Release > > > >302 Found > > > > Reading package lists... Done > > > > E: The repository 'http://deb.debian.org/debian stretch Release' does > > > > no longer have a Release file. > > > > N: Updating from such a repository can't be done securely, and is > > > > therefore disabled by default. > > > > N: See apt-secure(8) manpage for repository creation and user > > > > configuration details. > > > > E: The repository 'http://security.debian.org stretch/updates Release' > > > > does no longer have a Release file. > > > > N: Updating from such a repository can't be done securely, and is > > > > therefore disabled by default. > > > > N: See apt-secure(8) manpage for repository creation and user > > > > configuration details. > > > > > > Did I miss something? > > > > The second part of the instruction in the DSA: > > > > This is known to break some proxies when used against > > security.debian.org. If that happens, people can switch their security > > APT source to use: > > > > deb http://cdn-fastly.deb.debian.org/debian-security stable/updates > > main > > Hmmm. I didn't have security.debian.org enabled in the first place (IIRC > disabled is the default) so at first I dismissed that advice. Then I tried > adding their source line anyway and got the same warnings. > > I didn't realize, as Ilpo suggested, that I should comment-out the other > sources temporarily. That did the trick. > deb.debian.org, which you are using, isnt a repository. It's a placeholder with SRV records pointing to repositories. If the SRV doesn't work, then it provides a redirect function, which you are obviously blocking, (as instructed). The instructions aren't all that clear, since the problem will occur with any use of deb.debian.org, not just for security repos. -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web
Re: [qubes-devel] apt RCE
Many users already upgraded APT in a vulnerable way without ever knowing about this issue. What about introducing a security on/off switch that a subset of Qubes developers can trigger? Before apt-get (or other package manager) does actually anything, a simple script could fetch a file from Qubes clearnet domain (and/or onion) and ask "is it currently secure to update"? In most cases, the server would provide a cryptographically signed file by a Qubes developer which says "ok". Otherwise in situations such as now with APT security vulnerability DSA 4371-1 a Qubes developer could put a cryptographically signed file saying "not safe" there. In such cases, updates would be blocked until a new file is provided. Things to keep in mind related to such a file: man-in-the-middle attack - infinite freeze atttacks; rollback attacks; perhaps more. Can think about this more if this sounds interesting. Of course there should be options to: - disable this mechanism entirely - manually override by user These override option is useful for: - to stay flexible in case of bugs of this mechanism itself and, - to not give Qubes developers too much power. No advanced adversary should be able to ask Qubes developers to remotely brick all Qubes installations (mostly theoretic at this point and not important for now but still easy to implement and good to have), - other unforeseeable things. This idea could be seen as a subset of the emergency project news mechanism that is currently missing in all distributions. In short: distributions have no mechanism to communicate with their users effectively in situations such as this one. More info: https://www.whonix.org/wiki/Dev/project-news Cheers, Patrick -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f5db4a75-6793-0da8-4186-6ae771af16c4%40whonix.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On 01/22/2019 09:51 PM, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jan 22, 2019 at 09:44:31PM -0500, Chris Laprise wrote: On 01/22/2019 08:49 PM, unman wrote: On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote: On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: https://justi.cz/security/2019/01/22/apt-rce.html A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one. Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection. Updates proxy unfortunately does not help with this issue, but also is not affected by it (at least not directly). It is only a http proxy, which does not interpret content it receive, only pass it down to the VM that requested it. Specifically, if remote server would send malicious Location: header, it will be forwarded back to apt. While in theory that proxy could perform some extra filtering on the response, it isn't used for that right now. I don't think tinyproxy supports anything like this (but we could change it to a different http proxy implementation). The proxy appears to be 'affected' in the sense that Debian's temporary update instructions from their security bulletin do not work in the Qubes template. So we are missing a straightforward resolution that Qubes users can follow. Can you explain this? As far as I can see, the temporary update instruction *do* work in a template. What makes you think they don't? With normal update proxy settings (no cache), this happens: user@d9:~$ sudo apt -o Acquire::http::AllowRedirect=false update Ign:1 http://security.debian.org stretch/updates InRelease Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease Ign:3 http://deb.debian.org/debian stretch InRelease Err:4 http://deb.debian.org/debian stretch Release 302 Found Err:5 http://security.debian.org stretch/updates Release 302 Found Reading package lists... Done E: The repository 'http://deb.debian.org/debian stretch Release' does no longer have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. E: The repository 'http://security.debian.org stretch/updates Release' does no longer have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Did I miss something? The second part of the instruction in the DSA: This is known to break some proxies when used against security.debian.org. If that happens, people can switch their security APT source to use: deb http://cdn-fastly.deb.debian.org/debian-security stable/updates main Hmmm. I didn't have security.debian.org enabled in the first place (IIRC disabled is the default) so at first I dismissed that advice. Then I tried adding their source line anyway and got the same warnings. I didn't realize, as Ilpo suggested, that I should comment-out the other sources temporarily. That did the trick. Anyway, a progress on automated fix: https://github.com/QubesOS/qubes-issues/issues/4752 -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/46d6c7df-2529-f62f-5b9f-7d1a2f93c686%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jan 22, 2019 at 09:44:31PM -0500, Chris Laprise wrote: > On 01/22/2019 08:49 PM, unman wrote: > > On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote: > > > On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA256 > > > > > > > > On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: > > > > > https://justi.cz/security/2019/01/22/apt-rce.html > > > > > > > > > > A patch is out to cover this vulnerability, but I'm of the opinion > > > > > that it may be best to move the qubes-update-proxy worker VMs to a > > > > > disposable VM model after reading up on this one. > > > > > > > > > > Granted, at first glance it appears that the use of the > > > > > qubes-update-proxy certainly helps, but using disposable VMs might > > > > > provide an extra layer of protection. > > > > > > > > Updates proxy unfortunately does not help with this issue, but also is > > > > not affected by it (at least not directly). It is only a http proxy, > > > > which > > > > does not interpret content it receive, only pass it down to the VM that > > > > requested it. Specifically, if remote server would send malicious > > > > Location: header, it will be forwarded back to apt. While in theory that > > > > proxy could perform some extra filtering on the response, it isn't used > > > > for that right now. I don't think tinyproxy supports anything like this > > > > (but we could change it to a different http proxy implementation). > > > > > > The proxy appears to be 'affected' in the sense that Debian's temporary > > > update instructions from their security bulletin do not work in the Qubes > > > template. > > > > > > So we are missing a straightforward resolution that Qubes users can > > > follow. > > > > > > > Can you explain this? As far as I can see, the temporary update > > instruction *do* work in a template. > > What makes you think they don't? > > > With normal update proxy settings (no cache), this happens: > > > user@d9:~$ sudo apt -o Acquire::http::AllowRedirect=false update > > Ign:1 http://security.debian.org stretch/updates InRelease > > Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease > > Ign:3 http://deb.debian.org/debian stretch InRelease > > Err:4 http://deb.debian.org/debian stretch Release > > 302 Found > > Err:5 http://security.debian.org stretch/updates Release > > 302 Found > > Reading package lists... Done > > E: The repository 'http://deb.debian.org/debian stretch Release' does no > > longer have a Release file. > > N: Updating from such a repository can't be done securely, and is therefore > > disabled by default. > > N: See apt-secure(8) manpage for repository creation and user configuration > > details. > > E: The repository 'http://security.debian.org stretch/updates Release' does > > no longer have a Release file. > > N: Updating from such a repository can't be done securely, and is therefore > > disabled by default. > > N: See apt-secure(8) manpage for repository creation and user configuration > > details. > > Did I miss something? The second part of the instruction in the DSA: This is known to break some proxies when used against security.debian.org. If that happens, people can switch their security APT source to use: deb http://cdn-fastly.deb.debian.org/debian-security stable/updates main Anyway, a progress on automated fix: https://github.com/QubesOS/qubes-issues/issues/4752 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEyBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxH1q8ACgkQ24/THMrX 1yyVFwf2OE5iwaUd5m0wKU7IKaB/PhmiOw6paUuHHU/u4gbpz1LjA46/HgJf+3i0 I2FcJuxSdHhpCEd9TX7hJq4DuS7MSR+OWPhKkZdRsCZoK7KrweRLqnty5/C+5FaQ tu9wvqw1sZE82rAiDkxbAv6n0PS/HxkeKS/hNHFRRyXZNx+Degu4P8+Dvr++m10s N4PB5luaw+3GPCJdp+hf3xhWqhnAR1s8/BBy4bLvIsd0PS9qjYPlSZx0bExTpHcI WTuAg0FRImLhL7bELAxyPKbx0KhjAVs9ToJhRJDC8uTm4++ctAwUJDbwHSeEtSSk zK44/+tc9RQnqt2rxCymE+P+EO+w =7uDy -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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190123025127.GL1429%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On 01/22/2019 08:49 PM, unman wrote: On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote: On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: https://justi.cz/security/2019/01/22/apt-rce.html A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one. Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection. Updates proxy unfortunately does not help with this issue, but also is not affected by it (at least not directly). It is only a http proxy, which does not interpret content it receive, only pass it down to the VM that requested it. Specifically, if remote server would send malicious Location: header, it will be forwarded back to apt. While in theory that proxy could perform some extra filtering on the response, it isn't used for that right now. I don't think tinyproxy supports anything like this (but we could change it to a different http proxy implementation). The proxy appears to be 'affected' in the sense that Debian's temporary update instructions from their security bulletin do not work in the Qubes template. So we are missing a straightforward resolution that Qubes users can follow. Can you explain this? As far as I can see, the temporary update instruction *do* work in a template. What makes you think they don't? With normal update proxy settings (no cache), this happens: user@d9:~$ sudo apt -o Acquire::http::AllowRedirect=false update Ign:1 http://security.debian.org stretch/updates InRelease Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease Ign:3 http://deb.debian.org/debian stretch InRelease Err:4 http://deb.debian.org/debian stretch Release 302 Found Err:5 http://security.debian.org stretch/updates Release 302 Found Reading package lists... Done E: The repository 'http://deb.debian.org/debian stretch Release' does no longer have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. E: The repository 'http://security.debian.org stretch/updates Release' does no longer have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Did I miss something? At this moment, I could try to gpg verify the DSA bulletin, then use the hash from the bulletin to verify a manually-downloaded apt deb before installing it. Or, since I have Whonix installed, maybe look at the docs for enabling .onion updates. I use apt-cacher-ng with the templates configured with http://HTTPS/// scheme, which allows for caching *and* HTTPS to repos. I'm checking to see how apt-cacher-ng is affected, but wont be able to finish until this evening. This sounds like a good setup; I'll await feedback from you and rusty about your vuln review. However, I'm not sure how many other users will want to setup a cache. And if it requires installing any packages, then that leaves me in a catch-22. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/92ca5d5a-7ff8-9113-4f05-bb4d56831ba1%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote: > On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: > > > https://justi.cz/security/2019/01/22/apt-rce.html > > > > > > A patch is out to cover this vulnerability, but I'm of the opinion that > > > it may be best to move the qubes-update-proxy worker VMs to a disposable > > > VM model after reading up on this one. > > > > > > Granted, at first glance it appears that the use of the > > > qubes-update-proxy certainly helps, but using disposable VMs might > > > provide an extra layer of protection. > > > > Updates proxy unfortunately does not help with this issue, but also is > > not affected by it (at least not directly). It is only a http proxy, which > > does not interpret content it receive, only pass it down to the VM that > > requested it. Specifically, if remote server would send malicious > > Location: header, it will be forwarded back to apt. While in theory that > > proxy could perform some extra filtering on the response, it isn't used > > for that right now. I don't think tinyproxy supports anything like this > > (but we could change it to a different http proxy implementation). > > The proxy appears to be 'affected' in the sense that Debian's temporary > update instructions from their security bulletin do not work in the Qubes > template. > > So we are missing a straightforward resolution that Qubes users can follow. > Can you explain this? As far as I can see, the temporary update instruction *do* work in a template. What makes you think they don't? I use apt-cacher-ng with the templates configured with http://HTTPS/// scheme, which allows for caching *and* HTTPS to repos. I'm checking to see how apt-cacher-ng is affected, but wont be able to finish until this evening. -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190123014915.zt2ucotraph7rp2o%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jan 22, 2019 at 02:17:35PM -0800, Brendan Hoar wrote: > On Tuesday, January 22, 2019 at 12:57:45 PM UTC-5, Chris Laprise wrote: > > On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: > ... > > The proxy appears to be 'affected' in the sense that Debian's temporary > > update instructions from their security bulletin do not work in the > > Qubes template. > > Reminder to self: anytime I post a security statement to qubes-* mailing > lists, I should prepare to be schooled by those who are actually on top of > this stuff. :) > > > So we are missing a straightforward resolution that Qubes users can follow. > > Yeah...assuming this type of issue (bulk or targeted MITM software-update > exploits) is in-scope for the Qubes security model, sounds like the project > has a bit of a tough one to deal with. We're working on scripted resolution for this. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxHsAUACgkQ24/THMrX 1yzndQf/Z/htHtj8iNOBYD6A9yAvzSNd2ZGSAi8aMsu6xFT76NnRuAhVcTQXQCnh RmXkms9D0pSrNfmo8l8KCciX6h+27YTBpXhyhE6FqjfvjTVyWk2+j/DmvpyqkN0e yO1OvsnMj0e5YVJVn5KMAptXqOO13qIzm/y3AUD81bTiu1RXDJQOXMGTKKDg5ylK q8zDv0D1QtfLx7LtzQ5GrI52hctrGjzHzCJBofCciCzHGazobmg3EbnuHQ0AN9zo Fk+rhBgJ60QE0NU6xkb0I6y+fzymZtZmE4iCdq1QoZa0IKCyP583uJ18n7y5vw9A 7QQrOD62vMP8grq5XF6kWI807/FkKg== =G/1E -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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190123000630.GG1429%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On Tuesday, January 22, 2019 at 12:57:45 PM UTC-5, Chris Laprise wrote: > On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: ... > The proxy appears to be 'affected' in the sense that Debian's temporary > update instructions from their security bulletin do not work in the > Qubes template. Reminder to self: anytime I post a security statement to qubes-* mailing lists, I should prepare to be schooled by those who are actually on top of this stuff. :) > So we are missing a straightforward resolution that Qubes users can follow. Yeah...assuming this type of issue (bulk or targeted MITM software-update exploits) is in-scope for the Qubes security model, sounds like the project has a bit of a tough one to deal with. Brendan -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/fce1c5d8-c302-4263-938f-bdf864734c9a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: https://justi.cz/security/2019/01/22/apt-rce.html A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one. Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection. Updates proxy unfortunately does not help with this issue, but also is not affected by it (at least not directly). It is only a http proxy, which does not interpret content it receive, only pass it down to the VM that requested it. Specifically, if remote server would send malicious Location: header, it will be forwarded back to apt. While in theory that proxy could perform some extra filtering on the response, it isn't used for that right now. I don't think tinyproxy supports anything like this (but we could change it to a different http proxy implementation). The proxy appears to be 'affected' in the sense that Debian's temporary update instructions from their security bulletin do not work in the Qubes template. So we are missing a straightforward resolution that Qubes users can follow. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f750330b-7fc8-e6c9-3c3e-1ae9f828520a%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote: > https://justi.cz/security/2019/01/22/apt-rce.html > > A patch is out to cover this vulnerability, but I'm of the opinion that it > may be best to move the qubes-update-proxy worker VMs to a disposable VM > model after reading up on this one. > > Granted, at first glance it appears that the use of the qubes-update-proxy > certainly helps, but using disposable VMs might provide an extra layer of > protection. Updates proxy unfortunately does not help with this issue, but also is not affected by it (at least not directly). It is only a http proxy, which does not interpret content it receive, only pass it down to the VM that requested it. Specifically, if remote server would send malicious Location: header, it will be forwarded back to apt. While in theory that proxy could perform some extra filtering on the response, it isn't used for that right now. I don't think tinyproxy supports anything like this (but we could change it to a different http proxy implementation). When using https, updates proxy does even have a chance to do anything about it, as it sees only encrypted traffic. Using DisposableVM as updates proxy does not help here, because even if someone would perform the attack, updates proxy itself would remain unaffected (unless it's based on the attacked template, but then being disposable also doesn't help). The only thing that would change is if someone would successfully take over updates proxy using different method, then could attack apt from there - and when updates proxy is in DisposableVM, then it's easier to return such proxy to a clean state. > Also a good reason to ensure all of the URLs used for repositories are HTTPS, > of course. Yes, that's right, at least when connecting outside. As mentioned in the linked post, it's far easier to attack any intermediate network machine or mirror server, than being limited only to mirror server. On the other hand, handling HTTPS also bring its own complexity (all the OpenSSL stuff and more). Something that could _in theory_ be a good idea, is plain http connection to updates proxy, then https connection to download actual updates. This still allows compromised updates proxy to attack the template, but on the other hand, we could perform more filtering/caching on the updates proxy level. BTW it's worth checking if apt-cacher-ng a) is vulnerable itself to the attack b) prevents it spreading further (i.e. resolve redirects locally). But keeping more complex updates proxy have also its own downsides. First, it enlarges its attack surface (you trade some apt/dnf bugs for updates proxy bugs). But also it's harder to maintain, as you need to track various repository layout changes for multiple distributions. Related: https://github.com/QubesOS/qubes-issues/issues/4415 "Egypt and UAE HTTP Repository Manipulation/Poison" https://github.com/QubesOS/qubes-core-agent-linux/pull/150 "Switch to HTTPS" https://github.com/QubesOS/qubes-issues/issues/1957 "Cache updates" https://github.com/rustybird/qubes-updates-cache - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxHTNAACgkQ24/THMrX 1yzVxAf/Q/wwsoJaqy92zY3oc6u78toh+JPHFc+ouMumhNLrymsJI3MyMVozRMPF ac5Hc/PPU35y/P7TuZSQ27Uy/+GVcha6H4xZW0KZRJzxjsjHJNjlIgbDfaV1JLhL 8Ta83bTUtfJOgJ1AsD+3y6J3SLLXTEHBYhuZNmMqfzWq9SZcvsHahfhfySysskLr N4ozVbI5wkOaFkSsC505pzcsxsGvuRH2in1CGN8zBgH08K50UrePxA1Aackn1/5p jbApw7JJ8qn9RJYePZLyMLKNwNjL+JF9IN9ZC6yHc9Uk468He8ydpMTbSf3g3INV fp61FHnsgdv15pG7fO3JIJLl6gFC3A== =t6eI -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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190122170314.GD1429%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] apt RCE
On Tue, Jan 22, 2019 at 5:03 PM Brendan Hoar wrote: > > https://justi.cz/security/2019/01/22/apt-rce.html > > A patch is out to cover this vulnerability, but I'm of the opinion that it > may be best to move the qubes-update-proxy worker VMs to a disposable VM > model after reading up on this one. > > Granted, at first glance it appears that the use of the qubes-update-proxy > certainly helps, but using disposable VMs might provide an extra layer of > protection. > > Also a good reason to ensure all of the URLs used for repositories are HTTPS, > of course. > > Brendan (Sorry, sent the first one direct instead of to all.) No it isn't. libcurl itself has had multiple CVEs related to its HTTP(S) implementation as well, that's not even mentioning OpenSSL. Have fun reading: https://curl.haxx.se/docs/security.html https://www.openssl.org/news/vulnerabilities.html Compare to apt, where most of it would still affect it even if you use HTTPS: (plus this new one) https://www.cvedetails.com/vulnerability-list/vendor_id-23/product_id-17236/Debian-APT.html apt + https is bigger attack surface than apt itself... Most importantly, Qubes has an update proxy which should scrub this silliness anyway with the tinyproxy. https://www.qubes-os.org/doc/software-update-vm/#updates-proxy This cannot work with https target at all. -- Radosław Szkodziński -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAAmECqQXOtVNeD44C%3D0Tx5diS_dK%3DGZNgvxmrWLg8tBDhstbXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
