Whonix running as Qubes DispVM uses saved clock

[phabricator-migrator]

Information

ID: 695
PHID: PHID-TASK-4mgoyiickjv37iyydpvg
Author: anon5577
Status at Migration Time: wontfix
Priority at Migration Time: High

Description

Description:

When running as Qubes DispVM, whonix-ws sometimes (often) does not set the clock correctly, but instead seems to restore the date/time from when the DispVM savefile was created.

I have seen this often, over a very long period, but always assumed it had to do with my DispVM customisation. This time, I set up a clean Qubes R3.2, updated whonix-gw template and created a DispVM without customisation. The problem still occurs.

I usually don’t find out until I start getting OCSP errors due signatures being in the future. But this means that most likely a lot of earlier browsing has been correlateable since it all had the same wrong clock, therefore I set the priority of this ticket to high since it is a possible anonymity leak.

Recreating the DispVM savefile gets a more up-to-date clock in DispVMs launched afterwards.

Steps to reproduce:

• Install Whonix templateVM on Qubes
• Update the template (through qubes manager GUI action) and shut it down
• qvm-create-default-dvm whonix-ws
• Wait a couple of days
• Launch DispVM, start getting OCSP time errors on browsing. Note that system time is wrong.

Comments

---

Patrick

2017-06-29 16:56:06 UTC

@marmarek this is probably due to Qubes current DispVM savefile implementation? It should fix itself in Qubes R4.0 since DispVM implementation changed there?

---

anon5577

2017-07-07 14:28:34 UTC

This does not seem to happen every time, strangely enough. It seems sdwdate should call qubes.GetRandomizedTime as a post-suspend action if I read this correctly. So I guess under some circumstances that step does not run.

I am currently investigating this issue further, running a loop on dom0 that creates DVMs, checks time and leaves it running if the time is outside acceptable range.

I’ll comment here if something comes of it.

---

marmarek

2017-07-07 18:13:56 UTC

Yes to both of you:

• should just work on Qubes 4.0 (savefiles are not used there anymore)
• calling qubes.GetRandomizedTime as post-suspend action would fix that too

---

Patrick

2017-07-23 16:06:13 UTC

Unless someone else will be taking this one…

Time wise only possible solution currently: wait for Qubes 4.0.

---

awokd

2017-10-31 17:05:19 UTC

I didn’t notice this bug earlier but caught a reference in one of the Qubes mailing list discussions. For what it’s worth, I got this to function under Qubes 3.2 by deleting the sdwdate systemd unit files. It has been a while but I think I did that in the whonix-ws template. The dispvm appears to call bootclockrandomization on every start so time correlation is avoided and I no longer encounter times off by 2+ weeks.

Would it be helpful if I started from a fresh whonix-ws template and documented the exact steps I followed for 3.2? It’s possible there’s some attack I haven’t thought of.

---

Patrick

2017-10-31 20:29:57 UTC

Qubes-Whonix DispVMs won’t get any more development attention in Qubes
R3.2 because so much has changed. Please look into Qubes R4.