Thoughts about persistent exploit in AppVM

[hopef...@tuta.io]

Hello,

Currently any AppVM has persistent storage, it is referenced by default at least as /home, /rw/config, /usr/local. And software is executed from this persistent storage from read-only system.

This allows an adversary to install persistent AppVM exploit e.g. via ~/.bashrc or /rw/config/rc.local. Advanced exploit can then hide its own invocation script, so it won't be possible to detect it from running VM itself (at least aafter /rw/config/rc.local is executed; so better check when VM is turned off).

I suppose that it is by design and that won't harm other, trusted VMs (with an exception of unclear consequences of mounting this rw partition in another dom). But there is a threat model when persistent exploit of untrusted vm matters - the one when user wants to maintain anonymity.

For example, a persistent exploit in network vm can be used to defeat MAC randomization and track user location; it can even help mount attack against Tor for an adversary that isn't user's ISP - exploit can monitor outgoing Tor traffic and check correlations with incoming traffic of investigated sites (that are within adversary's ISP).

If the same is applicable to Whonix VMs, then it is even worse to anonymity: persistent exploit in Gateway completely defeats Tor while persistent exploit in Workstation can be used to deanonymise user via correlation analysis if attacker is controlling user's ISP (in this case attacker can send a controlled data stream to its own server over Tor and monitor incoming Tor traffic at ISP level).

Basically, as a user with threat model that involves maintaining anonymity, I cannot rely on stock Qubes now - at least untrusted VMs should be created from templates each time I need them - and that is inconvenient and may have other consequences.

I haven't found any public discussion of this persistent storage exploits - could you please point me to it if it is already covered? Any ideas how to address this issue properly?


Thanks,
Hopeful Fork

[Andrew Clausen]

Hi Hopeful Fork,

At the moment, Qubes has a half-solution for this problem: Disposable
VMs. In principle you could use the Whonix workstation template VM
for your disposable VMs, which have no persistent state.

However, Qubes only lets you use one template for all of your
disposable VMs. So that means all of your disposable VMs would be
using Tor, which is dangerous from an anonymity point of view (not to
mention inconvenient). For example, it would be dangerous to open
Gmail in a disposable VM on Tor because that would link your exit node
to your Gmail account.

It seems to me the best solution would be for Qubes to accommodate
multiple disposable VM templates.

Kind regards,
Andrew

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Actually this isn't true, because of stream isolation. See here:
https://www.whonix.org/wiki/Stream_Isolation

But the inconvenience argument still holds.

> It seems to me the best solution would be for Qubes to accommodate
> multiple disposable VM templates.

Multiple different Disposable VMs are already implemented in (upcoming)
Qubes 4.0.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYQBPeAAoJENuP0xzK19csLKkH/jZ8docgplCZBoMatF0R9RvQ
Uv2zibCCQhIhjUA3bG+uil4PsKfnISzh4SXQcTBmpxW1FGrBPL3bSXmuYOghdlPH
LjncAInL2pQKTD2tSitmqF7jaEJhRg3/DQArKYGlZmxdl1uHgTg4aci38rJiYQ3J
ov4RN0FWhn8/R+IAmx0aSHUXZG9rxQwWIDC1e1bFU4NieW79p2ilYMuwpv8oQ4WU
czOTkCv6gB1UpD0g+tFQGRijtS07F/ddOP4CYmEK1niriLaKWd9uZbZw3npJ2pLM
veKAivyjDefZzQsa4ORbt5QV2M9PJQEWkft6t7ocbJWv5DPzugn2Z/SwQN8uhFA=
=QAHj
-----END PGP SIGNATURE-----

[entr0py]

hopef...@tuta.io:

> Hello,
>
> Currently any AppVM has persistent storage, it is referenced by
> default at least as /home, /rw/config, /usr/local. And software is
> executed from this persistent storage from read-only system.
>

There may be additional persistent storage enabled as well[1].

> This allows an adversary to install persistent AppVM exploit e.g. via
> ~/.bashrc or /rw/config/rc.local. Advanced exploit can then hide its
> own invocation script, so it won't be possible to detect it from
> running VM itself (at least aafter /rw/config/rc.local is executed;
> so better check when VM is turned off).
>

Hence, all untrusted activity should be performed in a disposableVM or untrustedVMs with nothing of value.

> I suppose that it is by design and that won't harm other, trusted VMs
> (with an exception of unclear consequences of mounting this rw
> partition in another dom). But there is a threat model when
> persistent exploit of untrusted vm matters - the one when user wants
> to maintain anonymity.
>
> For example, a persistent exploit in network vm can be used to defeat
> MAC randomization and track user location; it can even help mount
> attack against Tor for an adversary that isn't user's ISP - exploit
> can monitor outgoing Tor traffic and check correlations with incoming
> traffic of investigated sites (that are within adversary's ISP).
>

I believe there is a ticket for disposable serviceVM (sys-net, sys-usb) functionality. Can't find at the moment.

Unfortunately, there are some scenarios that Tor was never designed to defend against. A global passive adversary that can listen on both endpoints presents a vulnerability for any low-latency anonymity system[2]. Also, being a specific target opens up many additional non-technical avenues for deanonymization that may be trivially simpler than attacking Tor. In your example, it's not obvious that an adversary who can compromise and monitor your sys-net as well as the connections of all of the other compromised network connections can't simply compromise / coerce / subpoena ISPs to perform the same function at lower cost (legal / reputational / computational).

> If the same is applicable to Whonix VMs, then it is even worse to
> anonymity: persistent exploit in Gateway completely defeats Tor while
> persistent exploit in Workstation can be used to deanonymise user via
> correlation analysis if attacker is controlling user's ISP (in this
> case attacker can send a controlled data stream to its own server
> over Tor and monitor incoming Tor traffic at ISP level).
>
> Basically, as a user with threat model that involves maintaining
> anonymity, I cannot rely on stock Qubes now - at least untrusted VMs
> should be created from templates each time I need them - and that is
> inconvenient and may have other consequences.
>
> I haven't found any public discussion of this persistent storage
> exploits - could you please point me to it if it is already covered?
> Any ideas how to address this issue properly?
>
>
> Thanks, Hopeful Fork
>

Your best bet to defend against persistent malware is to use Whonix-Workstation as your disposableVM template as previously suggested. Documentation is in-progress[3]. There is no additional threat to anonymity by using Tor all the time. Although stream isolation can effectively isolate your traffic across multiple Tor circuits, it is still advisable to use multiple VMs to separate your identities and never to use clearnet and Tor in the same VM[4]. You may find in certain cases, such as accessing your bank online, that you prefer to use a trusted banking VM connected directly to sys-net.

Persistent storage in Whonix-Gateway is not only a matter of convenience - for storing files/settings - but can also be considered a security feature. Tor implemented persistent entry guards to reduce the likelihood of user traffic being intercepted by malicious entry guards[5] and this requires persistent storage. On the other hand, if you are a mobile user, you may worry about your entry guard footprint being used to track you[6]. In that case, you may prefer to follow the Tails model, recreate your Whonix-Gateway VM on a more frequent schedule, or use multiple Whonix-Gateways.

The reason for isolating the Tor gateway from the user workstation in the first place is to be able to designate Whonix-Gateway as a trusted VM. Qubes VM isolation is relied on to maintain the integrity of Whonix-Gateway despite its connections to untrusted VMs. Whonix attempts to limit Gateway-Workstation interaction as much as possible to minimize attack surface - for example, via control port filters.

Workstation compromise, persistent or not, is certainly a concern that is hopefully mitigated by layered hardening measures, such as Tor Browser and Apparmor. Again, in your example, you seem to assume the adversary is a global passive attacker with resources significant enough to monitor all the ISPs in a region / countr(ies). In such a situation, the attacker doesn't necessarily need persistent compromise to de-anonymize the user. Once they locate and compromise a Workstation of interest, they can simply send out signals in a pattern while monitoring the ISPs. You can mitigate this situation by using dispVMs, which contain no identifying information (documents, logins) and being judicious with the amount of browsing done per VM. Simply deanonymizing random Tor circuits to their server only reveals that the target is a Tor user. Ultimately, low-latency networks are not safe against this type of adversary regardless of countermeasures. Something like a high-latency mailer would be preferred.


[1] https://www.qubes-os.org/doc/bind-dirs
[2] https://svn.torproject.org/svn/projects/design-paper/tor-design.html #Section3.1
[3] https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461
[4] https://www.whonix.org/wiki/DoNot
[5] https://blog.torproject.org/category/tags/entry-guards
[6] https://www.whonix.org/blog/persistent-tor-entry-guards

[Chris Laprise]

On 12/01/2016 03:03 PM, entr0py wrote:
> hopef...@tuta.io:
>> Hello,
>>
>> Currently any AppVM has persistent storage, it is referenced by
>> default at least as /home, /rw/config, /usr/local. And software is
>> executed from this persistent storage from read-only system.
>>
> There may be additional persistent storage enabled as well[1].
>
>
>> This allows an adversary to install persistent AppVM exploit e.g. via
>> ~/.bashrc or /rw/config/rc.local. Advanced exploit can then hide its
>> own invocation script, so it won't be possible to detect it from
>> running VM itself (at least aafter /rw/config/rc.local is executed;
>> so better check when VM is turned off).
>>
> Hence, all untrusted activity should be performed in a disposableVM or untrustedVMs with nothing of value.

There are more threats from persistent malware than what has been
discussed so far. As one example, the lax security within appVMs makes
them an ideal target for launching attacks against other computers on a
network. Another example is when long-term profiling of a victim's
system is required before launching an attack.

If normal permission-based security is enabled in an appVM/domU, then
there is a chance that system updates can render malware installations
defunct. Actually, the chance of this working is much better on Qubes
because no private.img-based rootkit can attempt to corrupt the update
process. So one of Qubes' best features is partially negated by default;
Malware that got into the VM via an application vulnerability can easily
persist as a kind of rootkit by simply adding a 'sudo ...' command to a
user script.

The first step in addressing the issue is to follow the 'vm sudo' doc
(disregarding the outdated explanatory part)...

https://www.qubes-os.org/doc/vm-sudo/

I think given recent developments in computer security, re-enabling
guest OS security will improve overall security on Qubes.

Chris

[hopef...@tuta.io]

Hi entr0py,

Thanks for your detailed and thorough answer.

1. Dec 2016 20:03 by 3n7r...@gmail.com:

hopef...@tuta.io:

Hello,

Currently any AppVM has persistent storage, it is referenced by
default at least as /home, /rw/config, /usr/local. And software is
executed from this persistent storage from read-only system.

There may be additional persistent storage enabled as well[1].

This allows an adversary to install persistent AppVM exploit e.g. via
~/.bashrc or /rw/config/rc.local. Advanced exploit can then hide its
own invocation script, so it won't be possible to detect it from
running VM itself (at least aafter /rw/config/rc.local is executed;
so better check when VM is turned off).

Hence, all untrusted activity should be performed in a disposableVM or untrustedVMs with nothing of value.

I suppose that it is by design and that won't harm other, trusted VMs
(with an exception of unclear consequences of mounting this rw
partition in another dom). But there is a threat model when
persistent exploit of untrusted vm matters - the one when user wants
to maintain anonymity.

For example, a persistent exploit in network vm can be used to defeat
MAC randomization and track user location; it can even help mount
attack against Tor for an adversary that isn't user's ISP - exploit
can monitor outgoing Tor traffic and check correlations with incoming
traffic of investigated sites (that are within adversary's ISP).

I believe there is a ticket for disposable serviceVM (sys-net, sys-usb) functionality. Can't find at the moment.

Looks like this is what I sought for. Couldn't find the ticket either - probably it isn't in any near scope, unfortunately.

 

Unfortunately, there are some scenarios that Tor was never designed to defend against. A global passive adversary that can listen on both endpoints presents a vulnerability for any low-latency anonymity system[2]. Also, being a specific target opens up many additional non-technical avenues for deanonymization that may be trivially simpler than attacking Tor. In your example, it's not obvious that an adversary who can compromise and monitor your sys-net as well as the connections of all of the other compromised network connections can't simply compromise / coerce / subpoena ISPs to perform the same function at lower cost (legal / reputational / computational).

I'm aware of this global adversary problem. We can imagine an adversary that is partially powerful - like a secret service of some state - which power is limited to a set of ISPs within the state. The service may want to know who are the foreigners accessing some web resource. It cannot launch a passive attack as the connections enter Tor from ISPs that are not under their control (this also includes VPN out of the state into Tor, not so rare use case actually). In this case, taking control of the sys-net of a suspect gives the opportunity for this passive attack on Tor connection of that particular user. And it isn't obvious that getting access to foreign ISPs is cheaper. We can imagine quite a lot of possible attack vectors at sys-net too - from local (e.g. during compromised or public hactivist meeting) to remote (like packet in packet attack, [7*]).

If the same is applicable to Whonix VMs, then it is even worse to

anonymity: persistent exploit in Gateway completely defeats Tor while
persistent exploit in Workstation can be used to deanonymise user via
correlation analysis if attacker is controlling user's ISP (in this
case attacker can send a controlled data stream to its own server
over Tor and monitor incoming Tor traffic at ISP level).

Basically, as a user with threat model that involves maintaining
anonymity, I cannot rely on stock Qubes now - at least untrusted VMs
should be created from templates each time I need them - and that is
inconvenient and may have other consequences.

I haven't found any public discussion of this persistent storage
exploits - could you please point me to it if it is already covered?
Any ideas how to address this issue properly?


Thanks, Hopeful Fork

Your best bet to defend against persistent malware is to use Whonix-Workstation as your disposableVM template as previously suggested. Documentation is in-progress[3].

Great! This feature is much anticipated.

 

There is no additional threat to anonymity by using Tor all the time. Although stream isolation can effectively isolate your traffic across multiple Tor circuits, it is still advisable to use multiple VMs to separate your identities and never to use clearnet and Tor in the same VM[4]. You may find in certain cases, such as accessing your bank online, that you prefer to use a trusted banking VM connected directly to sys-net.

Persistent storage in Whonix-Gateway is not only a matter of convenience - for storing files/settings - but can also be considered a security feature. Tor implemented persistent entry guards to reduce the likelihood of user traffic being intercepted by malicious entry guards[5] and this requires persistent storage. On the other hand, if you are a mobile user, you may worry about your entry guard footprint being used to track you[6]. In that case, you may prefer to follow the Tails model, recreate your Whonix-Gateway VM on a more frequent schedule, or use multiple Whonix-Gateways.

Yes, that is a well-known issue with entry guards. IMHO, a config option of some sort could help here - at least for those computers which are home-only or mobile only.

The reason for isolating the Tor gateway from the user workstation in the first place is to be able to designate Whonix-Gateway as a trusted VM. Qubes VM isolation is relied on to maintain the integrity of Whonix-Gateway despite its connections to untrusted VMs. Whonix attempts to limit Gateway-Workstation interaction as much as possible to minimize attack surface - for example, via control port filters.

Personally I don't think that Whonix-Gateway can be considered as trusted. It connects to a large set of entry guards / bridges and many of them can be malicious. Connections are done using C-written component - i.e. exposed to memory corruption issues which may lead to code execution. And even worse, its template is exposed to the same risky conditions. I.e. its activity is always under this constant risk that cannot be lowered, unlike other cases when we can estimate the risks and say whether we're in a low or high-risk condition.

And, just to be clear, compromise of the tor process is the instant "Game Over" for the anonymity (if user is relying solely on Tor). Someone may be lured into thinking that it is hard for an adversary to identify its targets at tor level and arbitrary exploitation of a 0-day in tor will be noticed quite fast, so it is safe overall. But ISP-level adversary can actually target any prominent person (like most of us - who are doing much of the stuff publicly - that is inevitable) - in case it gets connected to a compromised entry guard.

Workstation compromise, persistent or not, is certainly a concern that is hopefully mitigated by layered hardening measures, such as Tor Browser and Apparmor. Again, in your example, you seem to assume the adversary is a global passive attacker with resources significant enough to monitor all the ISPs in a region / countr(ies). In such a situation, the attacker doesn't necessarily need persistent compromise to de-anonymize the user. Once they locate and compromise a Workstation of interest, they can simply send out signals in a pattern while monitoring the ISPs.

I was saying exactly the same. Unfortunately, no hardening measures can prevent this from happening - except hardening the Tor Browser process itself (and, of course, the system context it runs within - like ASLR, NX etc - but not things like AppArmor/SELinux or even kernel hardening). Because implementing this attack doesn't require any more privilege than the browser already has. Hope in future we'll have Servo (which is written in memory-safe Rust). And I'm dreaming about some limited browser written in Go/Rust, that has the same fingerprint as Tor Browser with high security level.

You can mitigate this situation by using dispVMs, which contain no identifying information (documents, logins) and being judicious with the amount of browsing done per VM. Simply deanonymizing random Tor circuits to their server only reveals that the target is a Tor user. Ultimately, low-latency networks are not safe against this type of adversary regardless of countermeasures. Something like a high-latency mailer would be preferred.


[1] https://www.qubes-os.org/doc/bind-dirs
[2] https://svn.torproject.org/svn/projects/design-paper/tor-design.html #Section3.1
[3] https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461
[4] https://www.whonix.org/wiki/DoNot
[5] https://blog.torproject.org/category/tags/entry-guards
[6] https://www.whonix.org/blog/persistent-tor-entry-guards

[7*] https://www.usenix.org/legacy/event/woot11/tech/final_files/Goodspeed.pdf

[hopef...@tuta.io]

Hi Chris,

I agree with you. It is strange to me that Qubes doesn't follow defense in depth principle when thinking like "this vm is untrusted so we won't even try securing it". Sure, the vault vm won't be compromised - but that isn't the only asset to defend.

1. Dec 2016 21:03 by tas...@openmailbox.org:

On 12/01/2016 03:03 PM, entr0py wrote:

hopef...@tuta.io:

Hello,

Currently any AppVM has persistent storage, it is referenced by
default at least as /home, /rw/config, /usr/local. And software is
executed from this persistent storage from read-only system.

There may be additional persistent storage enabled as well[1].

This allows an adversary to install persistent AppVM exploit e.g. via
~/.bashrc or /rw/config/rc.local. Advanced exploit can then hide its
own invocation script, so it won't be possible to detect it from
running VM itself (at least aafter /rw/config/rc.local is executed;
so better check when VM is turned off).

Hence, all untrusted activity should be performed in a disposableVM or untrustedVMs with nothing of value.

There are more threats from persistent malware than what has been discussed so far. As one example, the lax security within appVMs makes them an ideal target for launching attacks against other computers on a network. Another example is when long-term profiling of a victim's system is required before launching an attack.

Good threats to consider!

If normal permission-based security is enabled in an appVM/domU, then there is a chance that system updates can render malware installations defunct. Actually, the chance of this working is much better on Qubes because no private.img-based rootkit can attempt to corrupt the update process. So one of Qubes' best features is partially negated by default; Malware that got into the VM via an application vulnerability can easily persist as a kind of rootkit by simply adding a 'sudo ...' command to a user script.

The first step in addressing the issue is to follow the 'vm sudo' doc (disregarding the outdated explanatory part)...

https://www.qubes-os.org/doc/vm-sudo

I think given recent developments in computer security, re-enabling guest OS security will improve overall security on Qubes.

Chris

IMO, restoring user and root users in the VMs won't help with preventing persistent exploits - only removing the persistent storage will (and taking measures to prevent code execution from it, be it preserved in some VMs like Whonix-Gateway).

Hopeful Fork

[Chris Laprise]

On 12/01/2016 06:00 PM, hopef...@tuta.io wrote:
> Hi Chris,
>
> I agree with you. It is strange to me that Qubes doesn't follow
> defense in depth principle when thinking like "this vm is untrusted so
> we won't even try securing it". Sure, the vault vm won't be
> compromised - but that isn't the only asset to defend.

I would like to clarify on this point:

"Defense in depth" per se is a philosophy that is outside the scope of
Qubes and could even threaten the Qubes philosophy and reason for
existing. Much of DiD strikes me as wild-goose chasing (and posturing)
when it is pursued by users and admins. Qubes Project should not spend
any significant time or resources on DiD even while not preventing it in
domUs.

However, traditional guest OSes like Linux and Windows do have their own
internal *default* security schemes (which form the basis for DiD) and
they often do impede various types of malware at least on a case-by-case
basis. Qubes should allow regular guest security to play their role in
(hopefully) impeding malware and making Qubes VMs less desirable targets.

Even though reports of in-the-wild exploits against Qubes are
exceedingly rare, Xen security did not turn out as good in practice as
it was hoped. So there is a short-term remedy and a long-term one as I
see it: First, re-enable guest security by default, then stimulate
interest either in finding a better hypervisor/microkernel (unlikely) or
in putting Xen and its development process under a stronger microscope
(more realistic). (Another long-term goal to enhance security would be
to get Qubes off of x86 and onto a hardware platform specified by the
project.)

Chris

[Chris Laprise]

On 12/01/2016 06:00 PM, hopef...@tuta.io wrote:

> IMO, restoring user and root users in the VMs won't help with
> preventing persistent exploits - only removing the persistent storage
> will (and taking measures to prevent code execution from it, be it
> preserved in some VMs like Whonix-Gateway).
>
> Hopeful Fork
>

A persistent exploit can't survive as a *rootkit* or command full use of
the appVM if, A) it's method of entry has been patched; and B) user
permissions are enforced. It would need additional exploits granting
privilege escalation in order to continue running after patch+reboot....
and those additional vulns may get patched also.

If observing normal guest OS security stopped only 5% of malware, it
would be more than worth the effort to change. It should at least be a
minimal hassle to infect a Qubes VM, though currently it isn't.

Chris

[entr0py]

Thanks for your reply. Your points are well-noted!

hopef...@tuta.io:

> 1. Dec 2016 20:03 by 3n7r...@gmail.com:
>

>> I believe there is a ticket for disposable serviceVM (sys-net,
>> sys-usb) functionality. Can't find at the moment.
>
> Looks like this is what I sought for. Couldn't find the ticket either
> - probably it isn't in any near scope, unfortunately.
>

Here are the missing links: https://groups.google.com/d/msg/qubes-users/zAPyWpBHyDM/4KocUGvEPQAJ
(may be possible with Qubes 4.0)

[hopef...@tuta.io]

Thanks for digging out the link! From the discussion there it isn't clear whether sys-net will be disposable in Qubes 4.0 by default - or will it require just minor configuration change? Preserving known wifi credentials is still nice to have (though not needed in case of increased security requirements - then they should be stored in vault and provided when needed).

Found a bug in my previous reasoning:
> And even worse, its[Whonix-Gateway] template is exposed to the same risky conditions.
That's obviously not true: template is connected through active gateway instance; template's tor isn't connected.

2. Dec 2016 20:41 by 3n7r...@gmail.com:

Thanks for your reply. Your points are well-noted!

hopef...@tuta.io:

1. Dec 2016 20:03 by 3n7r...@gmail.com:

I believe there is a ticket for disposable serviceVM (sys-net,

sys-usb) functionality. Can't find at the moment.

Looks like this is what I sought for. Couldn't find the ticket either
- probably it isn't in any near scope, unfortunately.

Here are the missing links: https://groups.google.com/d/msg/qubes-users/zAPyWpBHyDM/4KocUGvEPQAJ
(may be possible with Qubes 4.0)

--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/b934e48c-eb2b-9d95-abe9-bf7ed8f016ae%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[hopef...@tuta.io]

2. Dec 2016 00:17 by tas...@openmailbox.org:

On 12/01/2016 06:00 PM, hopef...@tuta.io wrote:

Hi Chris,

I agree with you. It is strange to me that Qubes doesn't follow defense in depth principle when thinking like "this vm is untrusted so we won't even try securing it". Sure, the vault vm won't be compromised - but that isn't the only asset to defend.

I would like to clarify on this point:

"Defense in depth" per se is a philosophy that is outside the scope of Qubes and could even threaten the Qubes philosophy and reason for existing. Much of DiD strikes me as wild-goose chasing (and posturing) when it is pursued by users and admins. Qubes Project should not spend any significant time or resources on DiD even while not preventing it in domUs.

Could you please elaborate a bit more on your view of DiD? The metaphor isn't very clear for me. And why DiD threatens Qubes philosophy etc - fairly strong statement that needs clarification and proofs.

My understanding of DiD isn't very original - as one of a set of design principles that need to be applied together, not isolated - more or less in accordance with e.g. [1]. At least three properties can be achieved with DiD:

(i) avoid single point of failure

(ii) increase costs of exploiting (obviously, as need to subvert more security mechanisms)

(iii) defend more assets (as different security mechanisms usually defend different things)

Single point of failure in Qubes is Xen (only from user vault PoV). And I think that Joanna's point in vm-sudo doc [2] still holds - if adversary has Xen exploit, most probably it has Linux kernel exploit (elevation of privilege user->root) as well. BTW, how has this changed in recent 5-6 years?

But other points in [2] are not true:

- No direct benefit to attacker if he escalates to root in the VM: that's true only if attacker wants user data; if he wants to use the VM for its own, like distributing malware further (or many other use cases), root will be required.

- Persistent rootkits are still possible in non-disposable VMs (strictly speaking, it is possible in any case when there is some persistent storage, even very limited - combined with a bug in a software that accesses it).

This reasoning shows that at least (ii) and (iii) still hold, even if (i) is questionable.

So in my understanding, Qubes can benefit from DiD just like any other system.

However, traditional guest OSes like Linux and Windows do have their own internal *default* security schemes (which form the basis for DiD) and they often do impede various types of malware at least on a case-by-case basis. Qubes should allow regular guest security to play their role in (hopefully) impeding malware and making Qubes VMs less desirable targets.

 

There is no such OS like Linux; and different distributions have quite different default security schemes. Moreover,  distributions are trying to balance usability and security - usually resulting in insecure defaults (because the need to provide software that is insecure by design), that can be hardened quite easily.

IMO, you're suggesting a step in DiD (or whatever we call it) - hardening systems in VMs, but to the default level only. I support this direction - but do not see why Qubes should stop at default level - and not go further, when it is possible. There are quite a lot of "low fruits" in hardening - and they're really reachable, compared to "better hypervisor", "securing Xen & its dev process" or even different hardware platform (for a general purpose desktop OS - are you kidding?)

One reason why Qubes cannot spend time on hardening VMs is that they have other things to do, i.e. prioritization issue - but that can be viewed only as a comparison, i.e. case-by-case basis. Sure, disposable VMs are more important than hardening them. But e.g. writing a better UI for something vs slight hardening is questionable IMHO.

Even though reports of in-the-wild exploits against Qubes are exceedingly rare, Xen security did not turn out as good in practice as it was hoped. So there is a short-term remedy and a long-term one as I see it: First, re-enable guest security by default, then stimulate interest either in finding a better hypervisor/microkernel (unlikely) or in putting Xen and its development process under a stronger microscope (more realistic). (Another long-term goal to enhance security would be to get Qubes off of x86 and onto a hardware platform specified by the project.)

Chris

As an example, consider sys-net VM. We can see two attack surfaces in it:

1. kernel network subsystem & device drivers; kernel is exposed directly; only Grsecurity can help here

2. network manager, dhcp client etc; this can be hardened putting this software in a container (starting from a separate UID)

I.e. in this particular case separating user-root doesn't help at all; only hardening beyond defaults makes sense.

[1] https://www.owasp.org/index.php/Security_by_Design_Principles

[2] https://www.qubes-os.org/doc/vm-sudo

[hopef...@tuta.io]

2. Dec 2016 00:28 by tas...@openmailbox.org:

On 12/01/2016 06:00 PM, hopef...@tuta.io wrote:

IMO, restoring user and root users in the VMs won't help with preventing persistent exploits - only removing the persistent storage will (and taking measures to prevent code execution from it, be it preserved in some VMs like Whonix-Gateway).

Hopeful Fork

A persistent exploit can't survive as a *rootkit* or command full use of the appVM if, A) it's method of entry has been patched; and B) user permissions are enforced.

You're absolutely right about rootkit, but even persistent user-level exploit may be harmful - e.g. a malware invoked from .bashrc and not having root access - but still having network access - so connecting to C&C server. This malware won't be able to do some advanced stuff like sending raw packets or binding to well-known ports etc but otherwise, as changing non-persistent root filesystem is pointless, it will be equal to a rootkit actually. Am I missing something here?

[Chris Laprise]

On 12/04/2016 08:23 AM, hopef...@tuta.io wrote:
> 2. Dec 2016 00:28 by tas...@openmailbox.org

> <mailto:tas...@openmailbox.org>:

>
> On 12/01/2016 06:00 PM, hopef...@tuta.io

> <mailto:hopef...@tuta.io> wrote:
>
> IMO, restoring user and root users in the VMs won't help with
> preventing persistent exploits - only removing the persistent
> storage will (and taking measures to prevent code execution
> from it, be it preserved in some VMs like Whonix-Gateway).
>
> Hopeful Fork
>
>
> A persistent exploit can't survive as a *rootkit* or command full
> use of the appVM if, A) it's method of entry has been patched; and
> B) user permissions are enforced.
>
>
> You're absolutely right about rootkit, but even persistent user-level
> exploit may be harmful - e.g. a malware invoked from .bashrc and not
> having root access - but still having network access - so connecting
> to C&C server. This malware won't be able to do some advanced stuff
> like sending raw packets or binding to well-known ports etc but
> otherwise, as changing non-persistent root filesystem is pointless, it
> will be equal to a rootkit actually. Am I missing something here?
>

I won't get into details about why root access is more desirable to an
attacker in a Linux VM. Its a matter of degree that comes with no cost
and shouldn't be discarded under the present circumstances.

Note that Qubes is designed to indicate availability of template updates
within minutes of their posting. This is normal. But who is going to
believe the urgency placed on guest updates is primarily to correct
functional non-security bugs (in fact, on *any* hypervisor-based system,
not just Qubes)?

There appears to be an unstated assumption that we are updating guests
to help prevent exploits at the app level. But if that's the case (and I
think it is... Whonix with Torbrowser is a prime example!) would we
patch only the apps? If app security is important, then we shouldn't
pull a basic assumption about an app's runtime environment out from
under it.

The current practice is cultivating a worrisome inconsistency: We're
supposed to abide by "Security is not a boolean", yet leave malware in
the guest to roam free with but one ultimate hurdle... Can it perform VM
breakout or not?

I think the way to correct this inconsistency is to distinguish between
traditional (Linux, BSD, Windows) guests and the newer, pared-down kind.
Trying to make the former 'simple' like the latter by turning off user
security does nothing of the sort and just invites rampant pwnage,
creating a viable platform for less-skilled attackers who otherwise
might give up.

Chris

[Chris Laprise]

On 12/04/2016 06:18 AM, hopef...@tuta.io wrote:
>
> 2. Dec 2016 00:17 by tas...@openmailbox.org

> <mailto:tas...@openmailbox.org>:

>
> On 12/01/2016 06:00 PM, hopef...@tuta.io

As practiced over the years, I see it as a gigantic, rambling, expensive
business culture that is full of empty (even 'macho') posturing and bad
advice. There is a certain type of mindset operating within IT that
revels in hyping every little, outdated "security cookbook" homily...
the selling of myopia.

>
> Single point of failure in Qubes is Xen (only from user vault PoV).
> And I think that Joanna's point in vm-sudo doc [2] still holds - if
> adversary has Xen exploit, most probably it has Linux kernel exploit
> (elevation of privilege user->root) as well. BTW, how has this changed
> in recent 5-6 years?
>

I don't think this can be assumed. Some attackers may have what is
needed to escalate to root at a given date/time. It is highly likely
that some installations will be saved in a *minority* of cases,
especially if the target VM may sit unpowered while its template has one
or more update sessions. Even moreso, considering that resourceful
attackers dislike exposing their best zero-days... more mundane attacks
will be tried first. Here and there, those mundane attack vectors are
more likely to be patched.

So, when instating default Linux security (and other 'low hanging
fruit')... can we make less-than-perfect attack opportunities even less
perfect? Yes! Will it cover everyone most of the time? Probably not
(though Linux team is reaching for some pretty interesting improvements,
so probabilities may improve soon).

Can this approach theoretically save someone's hide? I believe yes, even
if a failed attack is re-tried with a new vector... time has been
bought, and Qubes VMs seldom stay running and open-to-attack the way
servers do since its PC-type platform and threat models.

>
> But other points in [2] are not true:
>
> - No direct benefit to attacker if he escalates to root in the VM:
> that's true only if attacker wants user data; if he wants to use the
> VM for its own, like distributing malware further (or many other use
> cases), root will be required.
>
> - Persistent rootkits are still possible in non-disposable VMs
> (strictly speaking, it is possible in any case when there is some
> persistent storage, even very limited - combined with a bug in a
> software that accesses it).
>

I think you're still assuming that a priv escalation is persistent as
well. Without that, rootkit becomes defunct and discovery/recovery of a
bad situation becomes more straightforward.

>
> This reasoning shows that at least (ii) and (iii) still hold, even if
> (i) is questionable.
>
> So in my understanding, Qubes can benefit from DiD just like any other
> system.
>

The DiD investment already made for a guest OS is welcome. DiD process
and mentality in Qubes community, not so much.

Advances that Qubes users want to see in a guest OS could probably be
addressed upstream. Even GRsecurity is finding its way into the Linux
kernel bit by bit, so special efforts toward Xen compatibility may
become not so special.

Meanwhile, advances are made with unikernels and microkernels.

>
>
> However, traditional guest OSes like Linux and Windows do have
> their own internal *default* security schemes (which form the
> basis for DiD) and they often do impede various types of malware
> at least on a case-by-case basis. Qubes should allow regular guest
> security to play their role in (hopefully) impeding malware and
> making Qubes VMs less desirable targets.
>
> There is no such OS like Linux; and different distributions have quite
> different default security schemes. Moreover, distributions are trying
> to balance usability and security - usually resulting in insecure
> defaults (because the need to provide software that is insecure by
> design), that can be hardened quite easily.
>

Well, there is and there isn't 'Linux'. But the Qubes critique of it
usually begins with "monolithic kernel". I think either kernel or
'distro X' works here, though.

> IMO, you're suggesting a step in DiD (or whatever we call it) -
> hardening systems in VMs, but to the default level only. I support
> this direction - but do not see why Qubes should stop at default level
> - and not go further, when it is possible. There are quite a lot of
> "low fruits" in hardening - and they're really reachable, compared to
> "better hypervisor", "securing Xen & its dev process" or even
> different hardware platform (for a general purpose desktop OS - are
> you kidding?)
>

Yeah, I'm suggesting using the default level of security provided by a
(traditional) guest OS---as the Qubes default. Maybe even limit that to
Windows, 'Linux', Android. More hardening steps than that would be up to
the community, however I think it will become easier due to upstream
development.

Chris

>
> One reason why Qubes cannot spend time on hardening VMs is that they
> have other things to do, i.e. prioritization issue - but that can be
> viewed only as a comparison, i.e. case-by-case basis. Sure, disposable
> VMs are more important than hardening them. But e.g. writing a better
> UI for something vs slight hardening is questionable IMHO.
>
>
> Even though reports of in-the-wild exploits against Qubes are
> exceedingly rare, Xen security did not turn out as good in
> practice as it was hoped. So there is a short-term remedy and a
> long-term one as I see it: First, re-enable guest security by
> default, then stimulate interest either in finding a better
> hypervisor/microkernel (unlikely) or in putting Xen and its
> development process under a stronger microscope (more realistic).
> (Another long-term goal to enhance security would be to get Qubes
> off of x86 and onto a hardware platform specified by the project.)
>
> Chris
>
>
> As an example, consider sys-net VM. We can see two attack surfaces in it:
>
> 1. kernel network subsystem & device drivers; kernel is exposed
> directly; only Grsecurity can help here
>
> 2. network manager, dhcp client etc; this can be hardened putting this
> software in a container (starting from a separate UID)
>
> I.e. in this particular case separating user-root doesn't help at all;
> only hardening beyond defaults makes sense.
>
>
> [1] https://www.owasp.org/index.php/Security_by_Design_Principles
>
> [2] https://www.qubes-os.org/doc/vm-sudo

> <https://www.qubes-os.org/doc/vm-sudo/>
>