Page MenuHomePhabricator

feature request clock offset adjustment random value from KVM upstream
Closed, ResolvedPublic

Description

To stop clock correlation attacks it would be good, if we could automate the advice from advanced security guide, Spoof the Initial Virtual Hardware Clock Offset. Currently the offset can only be set to a fixed value, that's why we cannot deploy this setting by default.

TODO:
post a feature request upstream that allows setting a random value with a configurable minimum, maximum value

Details

Impact
High

Event Timeline

Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick added projects: KVM, security, upstream.
Patrick set Impact to High.
Patrick added subscribers: Patrick, HulaHoop.

Even if the feature exists there are some questions that need to be answered so we introduce something that has real security vs security theater.

How many bits of randomness does some range of seconds add? How coarse is the clock resolution before the information it provides is no longer useful to an attacker? Depending on the answers a known offset may be enough.

Note that from previous tests the clock always differed from the host's when I checked hwclock's numbers. hwclock in the VM was UTC by the way. Despite the best attempts to keep both clocks synced they always differed.

I am not optimistic about upstream feature requests. They never have an effect.

HulaHoop (HulaHoop):

Even if the feature exists there are some questions that need to be answered so we introduce something that has real security vs security theater.

Sure.

How many bits of randomness does some range of seconds add? How coarse is the clock resolution before the information it provides is no longer useful to an attacker?

Good question. Some speculative thoughts...

It depends on so many things. For one on adversary capabilities. And on
how many clocks are how much slow or fast.

If the host clock is off by two hours, then I think it's save to
conclude that adding or removing a 15 minutes offset would not help to
have company.

Let's say, there are,

  • x people who's clock is 10 second fast.
  • y people who's clock is 60 seconds fast.
  • z people who's clock is 1000 seconds fast.

And so forth.

Having an independent VM clock with a secret offset of plus 30 seconds.

x: measure host: 10
x: measure VM : 30

y: measure host: 60
y: measure VM : 90

z: measure host: 1000
z: measure VM : 1030

x would stand out least.
y would stand out more.
z would stand out most.

This speaks for huge random offsets, so those can obscure host clocks
that are off a lot.

On the gateway the offset may not be too big, otherwise Tor will no
longer be able to connect. So sdwdate cannot connect, cannot take over.
A drift host clock plus too big offset could introduce a Tor
connectivity issue where otherwise none would have been.

On the workstation the offset can be bigger. Not sure how big. One
condition is not being that big, so sdwdate would get confused. Requires
research. Another issue with too big offsets could be the system getting
confused by it. Messed up logs. Confused server software. Requires
research what else. Perhaps most of this could be prevented with some
clever systemd dependencies. On the workstation also the offset is more
important, because it is more likely to get compromised.

We can prevent strange web fingerprints with hugely offset clocks by
blocking all traffic except sdwdate until sdwdate finished after boot.
This was the plan anyhow.

My hope is explaining clock correlation attacks real well, and having an
independent VM clocks becoming the standard, so adversaries won't even
attempt clock correlation attacks anymore, because there hopefully will
be random offsets everywhere.

Depending on the answers a known offset may be enough.

I don't think a public known offset would work. Because then adversaries
would always do a calculation with public known offset removed.

Note that from previous tests the clock always differed from the host's when I checked hwclock's numbers. hwclock in the VM was UTC by the way. Despite the best attempts to keep both clocks synced they always differed.

Did you disable boot clock randomization? Not using it will surely mess
up this test.

Did you try test with non-Whonix, Debian VMs?

I will update this ticket when I try this. Can you post instructions for disabling biosoffset?

While I understand the rationale for offsets for the workstation (on regular hosts whose users don't care about security) I don't see why the gateway should have it too. The gateway doesn't run any leaky applications nor have anything that exposes its view of time. My goal is to have it auto sync clocks with the host upon resume so Tor can connect.

HulaHoop (HulaHoop):

I will update this ticket when I try this. Can you post instructions for disabling biosoffset?

Disable biosoffset? I don't think there is such as thing, since enabling
biosoffset is an optional change. Anyhow...

VirtualBox:

VBoxManage modifyvm <name> --biossystemtimeoffset 0

KVM:

Change

<clock offset='variable' adjustment='123456' basis='utc'>

back to

<clock offset='utc'>

But you probably meant how to disable other influences on the clock. You
can disable bootclockrandomization and sdwdate just like as any other
[systemd] service. To disable those:

sudo systemctl mask bootclockrandomization

sudo systemctl mask sdwdate

To re-enable those:

sudo systemctl unmask bootclockrandomization

sudo systemctl unmask sdwdate

While I understand the rationale for offsets for the workstation (on regular hosts whose users don't care about security) I don't see why the gateway should have it too. The gateway doesn't run any leaky applications nor have anything that exposes its view of time.

I can understand this, since reading the host clock from within the VM
(VM's wall clock) would require [root] compromise anyhow. And since a
compromised gateway exposes the real external IP anyhow.

However, this is useful as defense in depth. When combining
Whonix-Gateway with further tunnels/gateways behind it, it's best if
even a compromised Whonix-Gateway would not leak the host's time.

Another reason is, that on a system that happens to be successfully
configured to prevent any local clock leaks, a compromised
Whonix-Gateway ideally could not access the host's clock.

My goal is to have it auto sync clocks with the host upon resume so

Tor can connect.

That doesn't conflict with clock offsets as long those aren't too big.

The Libvirt developers said that such functionality should not be implemented into the stack itself but is already possible thru scripting.

The suggested virDomainSetTime API may need guest agent to be installed (which we can't do for security reasons).

Another idea is to implement a script in a hypothetical whonix-host package that appends some randomly chosen value for the offset in Whonix xml files.

Now that I've disabled rtc timer this is no longer possible. However no accurate timers exist for the guest. Another side effect was that you can't do graceful shutdowns (necessary to remove acpi_pm timer - acpi had to be disabled).

The original scope of this ticket (writing the feature request) is done.
Could you please close this ticket and open a follow up one should there
be anything left to do?

HulaHoop claimed this task.