joanna, is this a concern for qubes users?

[David Timber]

When reading the Tor wiki isolating proxy section, I read this line:

This is important. Crash reporting software sometimes sends contents of RAM over unencrypted connections.


Should qubes users be concerned by this? Seems like it could completely destroy torvm usage among other things.

Thank you.

[temp4081]

Surely this is outside the scope of Qubes?

If you choose to run software which "phones home" and makes stupid
decisions such as sending sensitive information in cleartext, Qubes
cannot help with this.

Qubes protects you in two ways:

1) software running in an appVM phoning home cannot leak info from other
security domains

2) firewall rules allow you to control the hosts, ports, and protocols
an appVM and its software may use to talk to the outside world

Now if you use a torVM, the anonVM (appvm with torvm as netvm) will leak
the unencrypted data out over Tor. This means that while the data will
be encrypted for some of the hops, the Exit Node and anything between
the Exit Node and the phoning home server can read the contents of the
RAM which have been dumped. Which may include de-anonymising information.

Certainly I'm aware that software bundled with Ubuntu phones home, does
crash reports, there was a scandal about user search terms being given
to Canonical under automatic opt in, etc.

Need to be aware which software phones home, which is theoretically
possible when the software is open source.

[Micah Lee]

On 04/30/14 11:54, temp4081 wrote:
> Surely this is outside the scope of Qubes?
>
> If you choose to run software which "phones home" and makes stupid
> decisions such as sending sensitive information in cleartext, Qubes
> cannot help with this.
>
> Qubes protects you in two ways:
>
> 1) software running in an appVM phoning home cannot leak info from other
> security domains
>
> 2) firewall rules allow you to control the hosts, ports, and protocols
> an appVM and its software may use to talk to the outside world

I think firewall rules are the way to go. If you need to use software
that phones home, you can use it in very restrictive AppVMs so that the
requests never leave the computer.

(BTW, Firefox and Thunderbird both phone home, but they do a decent job
of letting you know and letting you opt-out or opt-in even more -- and I
believe they communicate over https, and I'm actually kind of fine with
it, since usage statistics and crash reports seem to be very helpful in
making their software better.)

> Now if you use a torVM, the anonVM (appvm with torvm as netvm) will leak
> the unencrypted data out over Tor. This means that while the data will
> be encrypted for some of the hops, the Exit Node and anything between
> the Exit Node and the phoning home server can read the contents of the
> RAM which have been dumped. Which may include de-anonymising information.
>
> Certainly I'm aware that software bundled with Ubuntu phones home, does
> crash reports, there was a scandal about user search terms being given
> to Canonical under automatic opt in, etc.
>
> Need to be aware which software phones home, which is theoretically
> possible when the software is open source.

It's possible, and probably about as easy to discover, with proprietary
software too. Just use wireshark and see if it phones home.

--
Micah Lee

[Vincent Penquerc'h]

On 30/04/14 17:55, Micah Lee wrote:
> (BTW, Firefox and Thunderbird both phone home, but they do a decent
> job of letting you know and letting you opt-out or opt-in even more
> -- and I

I found out that Thunderbird was sending my mail server domain name to
Mozilla after I firewalled out everything except my mailserver in a
VM. I did miss the "can I do this ?" question if there was one.
Subsequent searching said it was "because mozilla might already know
how to set up Thunderbird for that mailserver". Which would be a good
reason if it had *asked* first.

[David Timber]

My point was that the contents of ram could include encryption keys. So if the contents of ram get sent back, it could be a problem right?

Should we be concerned about this?

[Axon]

Micah Lee:

> On 04/30/14 11:54, temp4081 wrote:
>> Surely this is outside the scope of Qubes?
>>
>> If you choose to run software which "phones home" and makes stupid
>> decisions such as sending sensitive information in cleartext, Qubes
>> cannot help with this.
>>
>> Qubes protects you in two ways:
>>
>> 1) software running in an appVM phoning home cannot leak info from other
>> security domains
>>
>> 2) firewall rules allow you to control the hosts, ports, and protocols
>> an appVM and its software may use to talk to the outside world
>
> I think firewall rules are the way to go. If you need to use software
> that phones home, you can use it in very restrictive AppVMs so that the
> requests never leave the computer.
>

The Qubes firewall is not a leak-prevention mechanism.

Joanna:
> Now, what does the firewalling in Qubes is *not* supposed to provide?
> Well it is not supposed to be a *leak-prevention* mechanism! So, if my
> 'work' domain has got compromised somehow (e.g. somebody sent me
> GPG-encrypted message that exploited a hypothetical bug in gnupg
> process), then the firewall will *not* prevent the (smart) attacker from
> leaking data out of this compromised domain, especially if the attacker
> has compromised at least one other domain in my system, e.g. 'red' or
> 'netvm' -- both of which are normally assumed to be untrusted.

https://groups.google.com/d/msg/qubes-devel/niMbDhS_nWI/M545pB7JBWYJ

However, a completely network-disconnected AppVM (i.e., it has no NetVM)
should be leak-proof (I hope).

[Axon]

temp4081:

> Surely this is outside the scope of Qubes?
>
> If you choose to run software which "phones home" and makes stupid
> decisions such as sending sensitive information in cleartext, Qubes
> cannot help with this.
>
> Qubes protects you in two ways:
>
> 1) software running in an appVM phoning home cannot leak info from other
> security domains
>
> 2) firewall rules allow you to control the hosts, ports, and protocols
> an appVM and its software may use to talk to the outside world
>
> Now if you use a torVM, the anonVM (appvm with torvm as netvm) will leak
> the unencrypted data out over Tor. This means that while the data will
> be encrypted for some of the hops, the Exit Node and anything between
> the Exit Node and the phoning home server can read the contents of the
> RAM which have been dumped. Which may include de-anonymising information.
>

Why would there be any de-anonymizing information in your AnonVM in the
first place?

[Joanna Rutkowska]

Unfortunately no thanks to potential cooperative covert channels between
VMs -- see e.g. the discussions in the middle of the thread linked from
this ticket:

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

Cooperative covert channels could also be possible between two airgapped
machines -- e.g. via mic and speaker.

Finally, a poor mans solution to this problem on Qubes OS, I think, is
to stop or pause all other domains while you're using the "isolated"
AppVM. I do this (sometimes :) for my sensitive VMs when do some
key-related operations there (key gen, signing, etc).

joanna.

[Axon]

Joanna Rutkowska:

Yes, I remember that thread, but I took myself to be saying something
possibly consistent with it. I guess I shouldn't have said "leak-proof"
without qualification. Let us then distinguish between leaks caused by
malicious software and leaks caused by non-malicious software (such as
error reporting, as originally mentioned). I assume that my "vault"
AppVM is not compromised by malicious software since it has never had a
NetVM and no files have ever been copied to it from anywhere. (In fact,
everything in it either "came with Qubes" or was input from the keyboard
by me.) So, I assume that there is no malicious software in this AppVM
which might attempt to establish a cooperative covert channel with a
different (compromised) AppVM. Nonetheless, there might be (and probably
is) some non-malicious "leaky" Fedora software running in this AppVM.
But I'm not worried about it since this AppVM has no NetVM. In this
latter, more restricted sense, can we say that the AppVM is
"leak-proof"? In other words, can we say that a network-disconnected
AppVM is leak-proof as long as it's not compromised?

This is, of course, directly relevant to the OP's question, which is
about non-malicious software which phones home. (Presumably, the OP is
not concerned that this software will attempt to establish a cooperative
covert channel with another AppVM; only that it will leak sensitive data
directly from the AppVM in which it runs.)

[Joanna Rutkowska]

Ah, I see. So, generally yes, but for completeness I think we should
distinguish between 3 scenarios:

1) Intentional leaks: so, malicious software trying to actively leak out
info, perhaps via cooperative covert channels established with another
malicious software on another VM (or on some server via networking, if
networking, even limited, is allowed for the VM).

2) Intentional sniffing, so a malicious software trying to use side
channels to e.g. actively guess some key material used in another VM by
some non-malicious software there (e.g. non-leak-proof GPG accidentally
leaking out bits of the private key by generating some timing patterns
when using this key for some crypto operation). Such attacks have been
described in the academic literature, although I personally _feel_ they
won't work in practice in a moderately busy general purpose system like
Qubes OS (where the attacker also has normally no way to trigger the
target crypto operation explicitly, as normally it is required for the
attacker to trigger lots of such operations).

3) Unintentional leaks made by non-malicious software (but one that
doesn't treat privacy too seriously, or is just buggy)

Qubes firewall (as well as networking-not-having of course) can prevent
#3 easily. Qubes firewall (neither networking-not-having) _cannot_
probably protect against #1 and #2. What, I think, can protect against
#1 and #2 is the user shutting down or pausing other VMs while
performing sensitive operations in the target VMs.

Ideally we could put this summary somewhere in the Wiki :)

joanna.

[Axon]

Joanna Rutkowska:

So, just to be clear: With respect to data "leakability," is there any
practical difference between

[A] NetVM: firewallvm (clearnet)
Qubes firewall:
Deny network access except... (No exceptions).
[Unchecked] Allow ICMP traffic
[Unchecked] Allow DNS queries
[Unchecked] Allow connections to Updates Proxy
and

[B] NetVM: none

?

[Marek Marczykowski-Górecki]

When using standard firewallvm - no, both will drop all packets. The only
difference is VM with [A] have network interface which drops all traffic, but
[B] have no network interface at all.
The difference is when using some non-standard netvm setting - like torvm.
When such ProxyVM(like torvm)/NetVM do not have qubes-firewall service, the
settings in firewall tab are not applied at all, so everything is up to other
scripts for firewall setting in that VM.
Above paragraph do not apply to DispVMs started from there, which do not
inherit netvm settings, only firewall settings (which most likely will be used
then).

BTW [B] implicitly set [A]

So to clarify: when you have
a) torvm (which have qubes-firewall service disabled), and
b) DispVM template with standard firewallvm as its uplink,
there is a difference:
- when VM have settings as in [A] and is using standard firewallvm, all
traffic will be blocked
- when VM have settings as in [A] and is using torvm, traffic will be
*allowed* (and routed via tor)
- when VM have set netvm to none, all traffic will be blocked (obviously)
- in all cases traffic from DispVM (started from above VM) will be blocked

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

[Axon]

Joanna Rutkowska:

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

> joanna.
>

[Gorka Alonso]

Small typo in http://qubes-os.org/trac/wiki/DataLeaks

"but it doubtful that they would succeed in practice"

should be

"but it is doubtful"

[Axon]

Gorka Alonso:

> Small typo in http://qubes-os.org/trac/wiki/DataLeaks
>
> "but it doubtful that they would succeed in practice"
>
> should be
>
> "but it is doubtful"
>

Corrected. Thanks.