Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On 8/19/20 6:45 AM, 54th Parallel wrote: On Wednesday, 19 August 2020 at 00:15:08 UTC+8 Robert Spigler wrote: This is the real solution for the Intel problem :) https://github.com/QubesOS/qubes-issues/issues/4318 I believe IBM stated they also have protections against the Rowhammer attacks I'm all for having Qubes on ppc64 but I think the problem is how rare the hardware seems to be. With ARM, at least they're common; ppc laptops aren't even a thing. My view is that you can get ppc-PCs from places like Raptor Computing, but A) they almost always have to be shipped (opening it up to targeted interdiction) Is this really a problem? EVERYTHING gets shipped. Unless you always go and collect your laptop/PC/server/WiFi router/keyboard/mouse/you-name-it right off the production line., there is no way else of mitigating such risk. And do you then trust the staff on the production floor to not compromise the specific device they are building for you. And and and... and B) there are so few places with them available that the risk of vendor/retailer compromise is massive. This doesn't seem likely to change anytime soon (or ever). But I'm probably missing something, since someone who is almost certainly more knowledgeable than I am (I'm not technical) found it worth paying a 2btc bounty for -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/31029915-03c2-6053-cc8e-b4b4fef0157c%40ak47.co.za.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On Wednesday, 19 August 2020 at 00:15:08 UTC+8 Robert Spigler wrote: > This is the real solution for the Intel problem :) > > https://github.com/QubesOS/qubes-issues/issues/4318 > > I believe IBM stated they also have protections against the Rowhammer > attacks > I'm all for having Qubes on ppc64 but I think the problem is how rare the hardware seems to be. With ARM, at least they're common; ppc laptops aren't even a thing. My view is that you can get ppc-PCs from places like Raptor Computing, but A) they almost always have to be shipped (opening it up to targeted interdiction) and B) there are so few places with them available that the risk of vendor/retailer compromise is massive. This doesn't seem likely to change anytime soon (or ever). But I'm probably missing something, since someone who is almost certainly more knowledgeable than I am (I'm not technical) found it worth paying a 2btc bounty for -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c219bb0d-389d-4468-9f97-02c595230692n%40googlegroups.com.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
This is the real solution for the Intel problem :) https://github.com/QubesOS/qubes-issues/issues/4318 I believe IBM stated they also have protections against the Rowhammer attacks -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/dce1bbe4-8be2-4ff1-a461-c844e573a230n%40googlegroups.com.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On Sunday, 16 August 2020 at 01:14:08 UTC+8 Chris Laprise wrote: > I'm not going to get into details now, but the short story is Intel > haven't addressed all the sidechannel vulnerabilities, and the long and > varied trend of Intel vulns points to a fundamentally flawed > implementation... too many cheap shortcuts were taken. > > Even worse is that Intel are now retiring their patch process for some > CPUs that are still popular with Qubes users, for example Ivy Bridge (I > expect Haswell to not be far behind if it hasn't already been ghosted). > To do this with a CPU that is 7 years old (when they announced it) is > very disappointing. > > IIRC for a relatively recent generation (I think it was Skylake!) they > said the expected mitigation was for You + Me to replace their junk with > newer hardware. No refund, no exchange program... just "We're the Big > Gorilla and you give us more of your money now". There's a lot of schadenfreude out there as Intel flounders with its delayed transistor nodes, frequent security failings, the very public dumping by Apple, and personnel issues. I think it's a good thing, since the company has basically become the Boeing of the processor industry (even before Boeing, since Spectre and Meltdown pre-dated the 737-MAX)--they're both venerable industry pioneers that have been consumed by corruption borne from complacency and needed good kicks in the pants. Whether the kicks will actually lead to substantial change remains to be seen, since they're too big to fail. AMD may be winning the PR race, but Intel is still very much virtually the sole supplier of laptop CPUs where I live--you'd have to actively dig around to find AMD laptops, and those you find are usually old and/or underpowered. I'd love an ARM Qubes. My dream PC would be a top-end ARM Macbook Pro with Qubes running on it (since this is a fantasy, it'd have all the MBP's security features, like the T2 chip, functioning). > Yes, rowhammer and its offshoots. Unfortunately, the changes in DDR4 > that were supposed to increase resistance were eventually discovered to > be cheap shortcuts themselves and have actually made the situation worse. > Ever get the feeling that the goal of truly secure computing is a sisyphean task? There's probably a mathematical formula out there proving that things above a certain degree of complexity cannot be guaranteed to be absolutely secure. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/61a11cb0-3148-4bbd-8810-316103b53d8cn%40googlegroups.com.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On Saturday, 15 August 2020 at 14:39:32 UTC+8 a...@qubes-os.org wrote: > > Then don't use it! :) > With the new look that makes it so much harder to use (top posting is default now) and replying to multiple people in a single post is a pain, so I just might give Thunderbird or Mutt a try. I'd say I'm de-Googling, but I'm typing this from ChromeOS, so there's that. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a345e2a7-ff09-4692-ab76-dd35352d47e9n%40googlegroups.com.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On 8/13/20 10:32 PM, 54th Parallel wrote: > Since the lions' share of Qubes installs are Intel based, I think a > side-channel attack would be the most likely way to breach a Qubes > system. I thought Spectre and Meltdown have been dealt with by shutting off hyperthreading and updating microcode? Also, the latest CPUs have Spectre mitigation built-in, though this only deals with the earlier variants of the attacks if I remember correctly. I'm not going to get into details now, but the short story is Intel haven't addressed all the sidechannel vulnerabilities, and the long and varied trend of Intel vulns points to a fundamentally flawed implementation... too many cheap shortcuts were taken. Even worse is that Intel are now retiring their patch process for some CPUs that are still popular with Qubes users, for example Ivy Bridge (I expect Haswell to not be far behind if it hasn't already been ghosted). To do this with a CPU that is 7 years old (when they announced it) is very disappointing. IIRC for a relatively recent generation (I think it was Skylake!) they said the expected mitigation was for You + Me to replace their junk with newer hardware. No refund, no exchange program... just "We're the Big Gorilla and you give us more of your money now". FTS! > DDR4 memory offers a big attack surface as well Does this refer to the RowHammer (HammerRow?) attack? Yes, rowhammer and its offshoots. Unfortunately, the changes in DDR4 that were supposed to increase resistance were eventually discovered to be cheap shortcuts themselves and have actually made the situation worse. > OTOH, a state actor wishing to attack a Qubes system might have better luck with the RPM MITM against Fedora that we discussed in another thread. Pretty much my biggest concern right now, though I'm procrastinating on writing the damn script Relevant to the thread: https://arstechnica.com/information-technology/2020/08/nsa-and-fbi-warn-that-new-linux-malware-threatens-national-security/ P.S. I'm not liking this new Google Groups look On Friday, 14 August 2020 at 00:06:42 UTC+8 Chris Laprise wrote: -- 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-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2006256d-543b-8e24-d3e4-3502d8ca1ce6%40posteo.net.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2020-08-13 9:32 PM, 54th Parallel wrote: > P.S. I'm not liking this new Google Groups look Then don't use it! :) "While the mailing lists are implemented as Google Group web forums, a Google account is in no way required, expected, or encouraged. Many discussants (including most members of the Qubes team) treat these lists as conventional mailing lists, interacting with them solely through plain text email with MUAs like Thunderbird and Mutt. The Google Groups service is just free infrastructure, and we distrust the infrastructure. This is why, for example, we encourage discussants to use Split GPG to sign all of their messages to the lists, but we do not endorse the use of these Google Groups as web forums. Some users prefer to interact with the mailing lists through their optional web interfaces. This has the advantage that it allows you to search and reply to messages which were sent prior to your subscription to the list. However, a Google account is required in order to post through the web interfaces. (Note: There have been many discussions about why the Qubes OS Project does not maintain an official forum. The curious can find these by searching the list archives.)" https://www.qubes-os.org/support/#mailing-lists-vs-forums - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl83gwoACgkQ203TvDlQ MDBoDQ//fRXbNMyGgvY2JjUX/qxzKqditI/w6YAwTf4BCwY9SJ6PL3z7XDSP9USY uZG70EN9wTGHtQpjl6e1BewE7kSfR/V3wFmzPMWT+9paQ2pfG9mX38OYFAhKRJ5l /nAEH19pSc692KuQWEZDfizT6P5TX2lPbaeFgUvGS3AGnrHXOZvtk8C73WauFx9/ JGU14KjDvoKRRrGkHSC5vmXG3ih8aBdzxQ3pnRCpCJ7ukPuwdhmJ9flU9cOoWEoM m5mPNmA884J1VTYNJUmqSeAqzU1eRH/y/llZBDrJvj9w4vZaM8dsxfgBlAYH/rsO 65t5Z70N4cM1m8TELk6khICEhc3tHyDbsooeGpq7M9P6ts/O11OLkCqu+koppfyM H/SzwyYqMIHzdTdDVx5AAEaVahErm6rc0eTmLNWNYzgh+u1++0KusvY8d15BWujO Wb1ZpAVuQ4DHSBMLxACKlx342XiHBe04wKJ22BbRzzJ2HvFU4hO0fh/x9LY1K0Pw d43dedUYw0SGh1jXrKRxaOrH7f3Hknx+ZzFwDFgy8SfcCdAcQcYAKz8cvs6ysqEl GoTTWIPl+Evzt+bLt6HrBZeWfoAt2SOVVm5RxACqEVRpxU4SoTxEp+0sMmiT1/oP RzixkvJ5CUv0E0StpRJJ5s3KDjWw+82KbDCI+TBxNw5H0IuCgvg= =7DwR -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2a17b80b-7b9e-199e-787f-2aedf0129681%40qubes-os.org.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
> Since the lions' share of Qubes installs are Intel based, I think a > side-channel attack would be the most likely way to breach a Qubes > system. I thought Spectre and Meltdown have been dealt with by shutting off hyperthreading and updating microcode? Also, the latest CPUs have Spectre mitigation built-in, though this only deals with the earlier variants of the attacks if I remember correctly. > DDR4 memory offers a big attack surface as well Does this refer to the RowHammer (HammerRow?) attack? > OTOH, a state actor wishing to attack a Qubes system might have better luck with the RPM MITM against Fedora that we discussed in another thread. Pretty much my biggest concern right now, though I'm procrastinating on writing the damn script Relevant to the thread: https://arstechnica.com/information-technology/2020/08/nsa-and-fbi-warn-that-new-linux-malware-threatens-national-security/ P.S. I'm not liking this new Google Groups look On Friday, 14 August 2020 at 00:06:42 UTC+8 Chris Laprise wrote: > On 8/13/20 10:59 AM, fiftyfour...@gmail.com wrote: > > If you were tasked with remotely hacking into a default but updated > > Qubes OS system (installation configuration of 4.0.3, but with updated > > templates and dom0), how would you do it? What would you attack? The > > precise objective (e.g. retrieve a PGP key from a vault, read a text > > document, achieve persistence, modify the system) is open--I just want > > to see how people might generally approach this question so I might > > better plug potential holes. > > > > Sorry for the extremely broad question--please think of this as > > something like a 'red team' exercise. > > Since the lions' share of Qubes installs are Intel based, I think a > side-channel attack would be the most likely way to breach a Qubes > system. But also its not just Intel CPUs that are weak here; DDR4 memory > offers a big attack surface as well. Such attacks can be carried out > with javascript from websites. > > OTOH, a state actor wishing to attack a Qubes system might have better > luck with the RPM MITM against Fedora that we discussed in another thread. > > -- > 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-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/495b0cac-fbee-4a45-93a6-2e56c4ef44a4n%40googlegroups.com.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On 8/13/20 10:59 AM, fiftyfourthparal...@gmail.com wrote: If you were tasked with remotely hacking into a default but updated Qubes OS system (installation configuration of 4.0.3, but with updated templates and dom0), how would you do it? What would you attack? The precise objective (e.g. retrieve a PGP key from a vault, read a text document, achieve persistence, modify the system) is open--I just want to see how people might generally approach this question so I might better plug potential holes. Sorry for the extremely broad question--please think of this as something like a 'red team' exercise. Since the lions' share of Qubes installs are Intel based, I think a side-channel attack would be the most likely way to breach a Qubes system. But also its not just Intel CPUs that are weak here; DDR4 memory offers a big attack surface as well. Such attacks can be carried out with javascript from websites. OTOH, a state actor wishing to attack a Qubes system might have better luck with the RPM MITM against Fedora that we discussed in another thread. -- 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-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2dff0958-e186-e1bf-ade9-2d519597fe7c%40posteo.net.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On Thursday, 13 August 2020 23:09:04 UTC+8, disrupt_the_flow wrote: > > On August 13, 2020 2:59:37 PM UTC, "fiftyfour...@gmail.com " > > wrote: >> >> If you were tasked with remotely hacking into a default but updated Qubes >> OS system (installation configuration of 4.0.3, but with updated templates >> and dom0), how would you do it? What would you attack? The precise >> objective (e.g. retrieve a PGP key from a vault, read a text document, >> achieve persistence, modify the system) is open--I just want to see how >> people might generally approach this question so I might better plug >> potential holes. >> >> Sorry for the extremely broad question--please think of this as something >> like a 'red team' exercise. >> >> > Or maybe you want to actually hack a computer with Qubesos but you don't > know how. I highly doubt you can write patches. > That strikes me as an unnecessarily paranoid way of thinking. White hat hackers are an important part of security. Also, I don't understand what you mean about me being unable to write patches. It should be clear from my recent posting history that I can't write patches--or any code beyond the most basic Python. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/906024f7-1942-4d34-a344-b526025193ado%40googlegroups.com.
Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?
On August 13, 2020 2:59:37 PM UTC, "fiftyfourthparal...@gmail.com" wrote: >If you were tasked with remotely hacking into a default but updated >Qubes >OS system (installation configuration of 4.0.3, but with updated >templates >and dom0), how would you do it? What would you attack? The precise >objective (e.g. retrieve a PGP key from a vault, read a text document, >achieve persistence, modify the system) is open--I just want to see how > >people might generally approach this question so I might better plug >potential holes. > >Sorry for the extremely broad question--please think of this as >something >like a 'red team' exercise. > >-- >You received this message because you are subscribed to the Google >Groups "qubes-users" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to qubes-users+unsubscr...@googlegroups.com. >To view this discussion on the web visit >https://groups.google.com/d/msgid/qubes-users/7bb49647-afea-4471-b6f1-c9e0b7cdda7ao%40googlegroups.com. Or maybe you want to actually hack a computer with Qubesos but you don't know how. I highly doubt you can write patches. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1576572C-B1F5-4597-A170-74E31A6D5D16%40pretty.Easy.privacy. pEpkey.asc Description: application/pgp-keys
