Thanks! Without your research, this almost certainly would not have had a chance to make it into Whonix 14. Can you commit your changes to git please? (And/or create a github pull request?)

After much research this is the best way to hide the CPU using VirtualBox:

https://github.com/Whonix/Whonix/commit/6db3c345c80ee9841fcae57621cafbfcdd000a0f

This was done by @TNTBOMBOM:

Another LAN/Public wifi fingerprinting attack that Ethan's code can defeat:

Done. Added io limit commits to open pull requests. Each vm can only use a maximum of 25% of the host io resources.

Yes.

Should limits be enforced for GW too?

HulaHoop (HulaHoop):

HulaHoop added a comment.

Though I agree with anonym's argument that resource exhaustion goes
against the purpose of advanced malware that wants to hide

Though I agree with anonym's argument that resource exhaustion goes against the purpose of advanced malware that wants to hide - I still looked at io limits in case you still think its valuable to set.

HulaHoop (HulaHoop):

HulaHoop added a comment.

There's a problem with setting this. SSD vs HDD io throughput is very different. What is reasonable for one will be excessive or too low for the other.

There's a problem with setting this. SSD vs HDD io throughput is very different. What is reasonable for one will be excessive or too low for the other.

In T567#10647, @HulaHoop wrote:

blkiotune and iotune can restrict io (KVM only)

https://libvirt.org/formatdomain.html#elementsBlockTuning

Looks like I overlooked python3-netfilterqueue-packager.

Also with 64bit compatibility this means the repo paths have changed.

Yes it can stay as it is.

That's great! So https://github.com/Whonix/whonix-gw-network-conf/blob/master/etc/network/interfaces.d/30_non-qubes-whonix can stay as is?

Great news! This config works without hacks. You can keep 10.0.2.15 unchanged too. Turns out the gateway ip address was just called "ip address"...

No idea. But we should probably stay on the subnet we have.

OK I will try route but I need some help with commands.

Seems like an awful hack. Last resort. If it somehow by some update (by ifupdown) is run after ifupdown, it breaks connectivity.

We're using ConditionVirtualization=kvm elsewhere already.(shared-folder-help systemd unit file) Should be doable to reuse it for the route command also.

We're using ConditionVirtualization=kvm elsewhere already.
(shared-folder-help systemd unit file) Should be doable to reuse it for
the route command also.

Can you redirect these packages using route? (Try in a Debian VM first to exclude Whonix firewall from interfering.)

Can you redirect these packages using route? (Try in a Debian VM first to exclude Whonix firewall from interfering.)

A very ugly hack:

Then we have reached an impasse because nothing I can put in the network configuration can change the gateway IP. Its not KVM's fault as its the norm to have gateway IPs of x.x.x.1 for a given subnet. Because some idiot on the VBox team chose .2 compatibility is impossible.

In T559#10500, @HulaHoop wrote:

address 10.0.2.128
netmask 255.255.255.0

Looks like libvirt supports a gateway= keyword. Does that work?

Looks like libvirt supports a gateway= keyword. Does that work?

In T559#10494, @HulaHoop wrote:

address 10.0.2.15
netmask 255.255.252.0

Various documentation changes:

These steps were not needed at all. Once I selected non-conflicting settings everything worked. Some changes to the netmask and gateway will need to be made to interfaces.d

I doubt it is possible to successfully use a dhcp client with raw sockets disabled. It may be possible to develop such a thing in theory, but I don't think it exists.

What I meant was subnet range using the CIDR calculator:

Same as VirtualBox.

My mistake I was not clear. By network configuration I mean yet another XML to create a new separate network as an alternative to "default" (like how I do it now with whonix internal network for KVM). It has nothing to do with GW files at all. No changes have to be made there.

192... will be a huge generator of FUD "conflicts with my router". Long time ago we moved away from that exactly for that reason.

So can we move to something static in the 192.168.122.2 - 192.168.122.254 range (depends on VBox choking or not) or should I include another network file with the whonix-libvirt package?

By working you mean in multi-GW usecase too?

Can you emulate these changes, use that static IP?

Can you emulate these changes, use that static IP? What will need changes? KVM documentation?

With libvirt a user can create another NAT network besides the default - with the same IP range. So another GW would have its own dedicated NAT without conflicts.

Switched to static network configuration.

I've now added Debian packaging support to the actual filter. Both packages install correctly and work well.

In T530#10231, @ethanwhite wrote:

I'm thinking that, from an architecture standpoint, we probably want to have one package for kti/python-netfilterqueue, and another one for my NetfilterQueue handler, rather than merge them both into the same package. This would be good if we end up with more than one NetfilterQueue handler (which seems likely; see, for example, T543). I'll also be creating a Debian package for my NetfilterQueue handler in the coming days.

I've created some bash scripts to create a Debian package for kti/python-netfilterqueue. They're available in this GitHub repository, and I've uploaded a version of the package created on my Debian Jessie system here. There are still a few issues I'll be resolving in the coming days, including the lack of a source package, but it's overall completely functional.

These KDE menus are disabled by Whonix. In plain Debian VMs these should

be visible.

HulaHoop (HulaHoop):

Tested enabling pm settings in KVM and I don't see suspend/hibernate in the VM power options in the menu.

Tested enabling pm settings in KVM and I don't see suspend/hibernate in the VM power options in the menu. VBox threads on SE agree that guest suspend isn't available.

You're right. My idea is needlessly complicated and I admit I learned a lot from your plan.

In T550#10191, @HulaHoop wrote:

Right, clock_jump_detector_monitor works also not in VirtualBox ws (or gw). Both system time (date) and hardware clock (hwclock) do not notice VirtualBox being paused.

Is that true on Linux too? I thought I saw a support thread about VBox 5+ using kvmclock device too: https://www.whonix.org/blog/virtualbox-acceleration-mode

Right, clock_jump_detector_monitor works also not in VirtualBox ws (or gw). Both system time (date) and hardware clock (hwclock) do not notice VirtualBox being paused.

Right, clock_jump_detector_monitor works also not in VirtualBox ws (or gw). Both system time (date) and hardware clock (hwclock) do not notice VirtualBox being paused.

For generating the knock packets (when clock jump detected) we can use scapy:
https://packages.debian.org/jessie/python-scapy

Test summary:

In T530#10102, @ethanwhite wrote:

The Debian package you mentioned is actually a completely different library serving the same purpose. I'll probably end up porting my code over to use that

As it turns out, that other library chokes whenever the packet handler releases the GIL (which is the only way to get the packet skewing we want). We can't use the Debian package python-nfqueue.

That really leaves us with two options:

• I could rewrite the handler entirely in C, in which case all we need is Debian's libnetfilter-queue package. However, I generally consider writing security-critical code in C to be a bad idea, especially when threads are involved like they are here.

First off, this would likely better be discussed directly on T543, as it's largely unrelated to ping latency covert channels.

The Debian package you mentioned is actually a completely different library serving the same purpose. I'll probably end up porting my code over to use that

If the attacker's goal is to judge clock skew (which can get to be tens of milliseconds), then it's completely practical

Could it be replaced with the Debian package python-nfqueue? Is it the same?

The following is an issue for us. (Since upgrades come outside of apt-get which makes it hard to keep it up to date for users as linux distribution maintainer. Package manager security and whatnot.)

Thanks for researching this and contributing a fix.

In T530#9956, @Patrick wrote:

Could you please post (and license Open Source) your fix to github? @ethanwhite

Could you please post (and license Open Source) your fix to github? @ethanwhite

Would it be correct to say that the fix developed also defends against the earlier attack described by Steven Murdoch?

Would it be correct to say that the fix developed also defends against the earlier attack described by Steven Murdoch? - Therefore closing up this entire class of threats.

We would like your feedback on the TCP ISN attack/mitigation info (or on the covert channel attack in general) on the wiki page.

In T530#9844, @ethanwhite wrote:

Can you please implement the same protections for IPv6/ICMP6 if its not too much work.

It's a matter of using ip6tables as well as iptables; I've added a shell script to configure them both automatically as well, for ease of use. However, none of the machines I have access to seem to have good IPv6 support, so I wasn't able to test it properly.

I'm not aware of any other issues. Performance seems to be decent as well; although this obviously increases the average latency, it can easily handle 10mbps of traffic.

Can you please implement the same protections for IPv6/ICMP6 if its not too much work.

Can you please implement the same protections for IPv6/ICMP6 if its not too much work. We plan to roll out the package for Whonix hosts (to end this attack for other VMs besides Whonix) where some users may have no choice but to connect with IPv6 because of their ISP.

Here I found an example of someone using libnetfilter_queue to manipulate ICMP packet timing. Though their goal is different - they embed covert patterns while we are preventing them. [1]

After looking at the netem documentation I'm pretty sure there is something here we can use.

Here is someone using tc (traffic control) [1] and netem [2] to delay packets in a queue. It can be applied to all traffic [3]
Another way to delay packets is using the libnetfilter_queue interface. [4]

it is definitely possible to disable c-states as a guest operating system

Not easy.