How would you remotely infiltrate a default Qubes OS?

[fiftyfour...@gmail.com]

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. 

[disrupt_the_flow]

On August 13, 2020 2:59:37 PM UTC, "fiftyfour...@gmail.com" <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.

[fiftyfour...@gmail.com]

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.

[Chris Laprise]

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

[54th Parallel]

> 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

[Andrew David Wong]

-----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-----

[Chris Laprise]

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.

[54th Parallel]

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.

[54th Parallel]

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. 

[Robert Spigler]

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

[54th Parallel]

 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

[Qubes]

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...