On 05/16/2018 11:20 PM, Ilpo Järvinen wrote: > On Wed, 16 May 2018, [email protected] wrote: > >> On 05/15/2018 01:22 AM, john wrote: >> >>> On 05/14/18 14:58, Ángel wrote: >>>> This paper is most interesting for the discovery of multiple ways email >>>> client leak information on visualization. >>>> (not clearly stated in the paper: some of them are already fixed, while >>>> in other cases the developers are still working on providing them) >>>> >>>> Luckily, with Qubes it is easy to set a firewall rule so that your email >>>> AppVM can only contact with your email server. >>>> NB that some of these leaks are dns-based, so ideally you would not >>>> allow it to perform any dns query, either. >>>> >>>> Best regards >>>> >>> can you give an example to the steps to make such a fw rule, if >>> it's that simple please ? >> I would suggest simply only allowing the ports you need for your email >> client. > > It's much less secure approach than blocking all but the email server > address. With a port filter, the attacker only needs to use that same > port for the attack to succeed.
That's true, except HTML engines like the ones used by this attack should disallow eg. loading an image from port 25. For instance, firefox blocks at least ports 993 and 587, the only two that should be used by a reasonably recent and secure email setup. So that's not a solution against an arbitrary attacker, but that's a solution against the currently-spoken-about attack. BTW, if you really want to protect yourself from an arbitrary attacker, you'll want to protect against an attacker that has root on your email VM. And that means 1/ setting firewall rules in the FirewallVM, not in the email VM, as the latter could just be removed by the attacker 2/ all kinds of hardening against side-channels for compromised VM communication, that are currently not possible with Xen (and possibly not even with any widely-spread hypervisor, as that would likely entail a huge performance cost) Another solution for 2/ could be to never run the email VM at the same time as another potentially-compromised VM, but that very much restricts what you can do. And that can maybe (now that's all hypothetical) still be by-passed with side-channels through eg. LVM's thin pool allocator, as IIRC Qubes4 uses LVM thin pools as storage backend. (still haven't migrated…) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/436c6811-9ca0-bd0b-0c21-f2097248d43c%40leo.gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
