Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[Chris Laprise]

On 12/04/2016 06:18 AM, hopefulf...@tuta.io wrote:


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


On 12/01/2016 06:00 PM, hopefulf...@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)




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 a

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[Chris Laprise]

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


On 12/01/2016 06:00 PM, hopefulf...@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




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



--
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/08f3a871-0af5-3852-73da-f9ec4e3dd887%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[hopefulfork]

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


> On 12/01/2016 06:00 PM, > hopefulf...@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?


 

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

-- 
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/KY9-BG5--3-0%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[hopefulfork]

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


> On 12/01/2016 06:00 PM, > hopefulf...@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

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[hopefulfork]

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 3n7r0...@gmail.com:


> Thanks for your reply. Your points are well-noted!
>
> hopefulf...@tuta.io> :
>> 1. Dec 2016 20:03 by >> 3n7r0...@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+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/b934e48c-eb2b-9d95-abe9-bf7ed8f016ae%40gmail.com>
>  .
> For more options, visit > https://groups.google.com/d/optout> .

-- 
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/KY31-Cj--3-0%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[entr0py]

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

hopefulf...@tuta.io:
> 1. Dec 2016 20:03 by 3n7r0...@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+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/b934e48c-eb2b-9d95-abe9-bf7ed8f016ae%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[Chris Laprise]

On 12/01/2016 06:00 PM, hopefulf...@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

--
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/f3ec1701-1b95-1fb1-412c-ef83ecec4ce4%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[Chris Laprise]

On 12/01/2016 06:00 PM, hopefulf...@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

--
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/42523b24-311a-a888-c984-41fa2d376f2b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[hopefulfork]

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:
>> hopefulf...@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


 

-- 
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/KXwbXhS--3-0%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[hopefulfork]

Hi entr0py,

Thanks for your detailed and thorough answer.

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


> hopefulf...@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 ma

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[Chris Laprise]

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

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

--
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/0a03ebdc-9230-8826-634a-3d5eb3d9248c%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[entr0py]

hopefulf...@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 
reg

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Dec 01, 2016 at 12:07:56PM +, Andrew Clausen wrote:
> Hi Hopeful Fork,
> 
> On 1 December 2016 at 08:59,   wrote:
> > 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).
> 
> 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.

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-

-- 
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/20161201121317.GH1145%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Thoughts about persistent exploit in AppVM

[Andrew Clausen]

Hi Hopeful Fork,

On 1 December 2016 at 08:59,   wrote:
> 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).

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

-- 
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/CAAXZBW%2B1%3D3GHowLm%3DPNZOeibpKX9JMaKEtxB8sCC3JijiY%3DGyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Thoughts about persistent exploit in AppVM

[hopefulfork]

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

-- 
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/KXtb6AX--3-0%40tuta.io.
For more options, visit https://groups.google.com/d/optout.