Receive-only email VM

[reddi...@vfemail.net]

In Qubes, is it possible to set up a VM that can receive email, but not send information out, via email or otherwise?

The motivation is: Many online accounts rely on an email address to reset passwords. However, the VM that handles inbound emails, processes a lot of untrusted input. If the VM gets compromised by an attacker, the attacker can then send password reset emails and read them. So to defend against this, I want to prevent the compromised VM from communicating out the contents of these password reset emails.

Specifically:
1. Assume the VM is compromised (can't rely on in-VM enforcement mechanisms).
2. Assume the email provider is not compromised

To further illustrate the problem, here are example setups and why they don't work:

Setup 1: Use qubes firewall to restrict to the email provider's server and IMAP port. Block UDP requests using qvm-firewall.
Why it doesn't work: Attacker can create an account on the same email provider and connect to their account (the firewall rules will not prevent this). They can then sync emails containing any data, to their account.

Setup 2: Like Setup 1, but use POP3.
Why it doesn't work: Attacker creates account at provider, transmits data via POP3 delete operations.

Does anyone have a email setup with this inbound-only property, ideally that does not require running their own email server?

Thank you.

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net
 
ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas!   15GB disk space!
Commercial and Bulk Mail Options!

[awokd]

reddi...@vfemail.net:

> In Qubes, is it possible to set up a VM that can receive email, but not
> send information out, via email or otherwise?

>

> Does anyone have a email setup with this inbound-only property, ideally
> that does not require running their own email server?

Running your own email server is what first came to mind. You could
maybe get some layer 4-7 application firewall in the mix that could
restrict email logins to only your account, but I haven't investigated
those too much.

[alex.b...@gmail.com]

Some time ago there was a post on reddit (https://www.reddit.com/r/Qubes/comments/9q76f2/splitmail_setup/) that described setting up an offline mail vm. Just kill the "send" part there and you'll get a mail black hole that receivs but never sends. Seems like this is more or less what you want.

[V C]

Couldn't you just use a dedicated VM and thunderbird, don't set up outbound in thunderbird?

[Steve Coleman]

On 8/2/19 1:24 PM, reddi...@vfemail.net wrote:
> In Qubes, is it possible to set up a VM that can receive email, but not
> send information out, via email or otherwise?
>
> The motivation is: Many online accounts rely on an email address to
> reset passwords. However, the VM that handles inbound emails, processes
> a lot of untrusted input. If the VM gets compromised by an attacker, the
> attacker can then send password reset emails and read them. So to defend
> against this, I want to prevent the compromised VM from communicating
> out the contents of these password reset emails.
>
> Specifically:
> 1. Assume the VM is compromised (can't rely on in-VM enforcement
> mechanisms).
> 2. Assume the email provider is not compromised
>
> To further illustrate the problem, here are example setups and why they
> don't work:
>
> Setup 1: Use qubes firewall to restrict to the email provider's server
> and IMAP port. Block UDP requests using qvm-firewall.
> Why it doesn't work: Attacker can create an account on the same email
> provider and connect to their account (the firewall rules will not
> prevent this). They can then sync emails containing any data, to their
> account.
>
> Setup 2: Like Setup 1, but use POP3.
> Why it doesn't work: Attacker creates account at provider, transmits
> data via POP3 delete operations.

How about setup the firewall to black hole the entire IP range of the
email service company, then set up a proxy on the firewall which you
then control, and you set their email program to use the proxy. If need
be you can black hole all the pop/smtp/imap ports for all Internet
traffic forcing them to use the proxy for any email no matter what email
program or provider they use. When they try to send any email the proxy
simply closes that connection.

Controlling HTTP/s traffic might be more difficult, but if necessary you
can proxy all that as well. If its just one service provider you care
about then the black hole IP trick should do the job.

You put any custom logic for your specific requirements into the proxy
which then controls their access accordingly. Basically its a default
deny gateway which needs to match on the permitted rules before they are
ever granted access. The downside is you will likely need to write your
own proxy for this.

[Alex Barinov]

As long as your dedicated Thunderbird VM has internet connection (which it needs to receive email) an attacker can get any data out of it using Thunderbird exploits, whether you set up outgoing mail server or not.

Kind regards,
Alex