Deprecated
VirtualBox Generic Bug Reproduction using virtualbox-guest-additions-iso[edit]
This entry is based on Bug Report Recommendations, specifically Generic Bug Reproduction. The content is similar to the Try a non-Kicksecure™ VM chapter above.
A manual reproduction of the Kicksecure VirtualBox Integration.
- Use the recommended
(.onion
) Linux distribution -- Debian bookworm-- as the host operating system. (Debian Tips) - Install the recommended version of the VirtualBox host software.
- Installation of non-freedom software is not required, but the Debian "
nonfree" (free in price but non-freedom) repository must be temporarily enabled; the reason is documented below. virtualbox-guest-additions-iso (Freedom Software) from the Debian repository on the the Debian host operating system. Due to a Debian packaging bug the package is only available from Debian nonfreerepository, but the package is not non-freedom. That package provides file/usr/share/virtualbox/VBoxGuestAdditions.iso.- Install Debian
bookworminside a VirtualBox VM. - Mount the VirtualBox Guest Additions CD iso file
/usr/share/virtualbox/VBoxGuestAdditions.isoinside the Debian VM. - Install VirtualBox Guest Additions from the virtual CD-ROM drive inside the Debian VM. Change to the directory where the CD-ROM drive is mounted and run the following command as root:
sh ./VBoxLinuxAdditions.run - Attempt to reproduce the original issue.
NTP[edit]
Disabling NTP[edit]
If ISP tampering with NTP is ever confirmed, users are advised to disable NTP and manually update the host clock out-of-band. For example, a watch or atomic clock can be used for this purpose. If the tampering is targeted and not a widescale attack, then the user already has much bigger problems to worry about than NTP; see Confirmation Attacks.
If following the advice above -- disabling NTP on the host and adjusting the clock out-of-band -- be aware that clearnet traffic might be easier to fingerprint. [1] The reason is that it introduces a device issuing clearnet traffic (such as OS updates), but without the use of NTP. It is unknown how many people have NTP which is deactivated, broken, uninstalled, or never in fact installed in the first place. Also unknown is how many people are using alternative time synchronization methods such as authenticated NTP, tails_htp, tlsdate, sdwdate or similar. However, search engine research suggests that very few people fall into both these categories.
NTP Issues[edit]
The host system clock synchronization mechanism still uses unauthenticated NTP from a single source. This is not optimal, but there is no real solution to this problem. [2] A potential attack vector is created by this NTP behavior; the ISP and/or time server could either inadvertently or maliciously introduce a significant clock skew, or the host clock could simply malfunction.
If the host clock value is grossly inaccurate -- more than one hour in the past or more than 3 hours in future -- Tor cannot connect to the Tor network. [3] This is easily solved by manually fixing the clock on the host, then powering the Kicksecure™ off and on again.
Another side effect of a significantly inaccurate host clock concerns operating system (OS) updates and cryptographic verification on the host. Until the host clock is manually fixed, it may no longer be possible to download updates or verify SSL certificates correctly with the host browser.
Users should always check whether a host clock defect relates to an empty battery before assuming the ISP is tampering with NTP.
???[edit]
KVM[edit]
For KVM, click on Expand on the right.
Edit the VM xml before import or edit the VM xml after import and change the following setting. <clock offset='utc'> To.
<clock offset='variable' adjustment='123456' basis='utc'>
The adjustment attribute takes any arbitrary value for seconds. The user must pick a random value that is unknown to others, ranging between 0 and 900 (a 15 minute range).
Qubes[edit]
TODO
Unfortunately, it is not yet possible to set a random clock offset for Kicksecure™ for Qubes VM to prevent clock correlation attacks since it is unsupported by Xen. A related issue is denying Kicksecure™ for Qubes access to "clocksource=xen", which may not be possible without Linux kernel and/or Xen patches. For a detailed discussion of these issues, see here.
VirtualBox[edit]
For VirtualBox, click on Expand on the right.
VirtualBox has a feature to spoof the initial virtual hardware clock offset by setting the clock X milliseconds in the future or past. The syntax is outlined below.
VBoxManage modifyvm <name> --biossystemtimeoffset -<milliseconds> VBoxManage modifyvm <name> --biossystemtimeoffset +<milliseconds>
It is recommended to add a random delay within the following range.
VBoxManage modifyvm <name> --biossystemtimeoffset -60000 VBoxManage modifyvm <name> --biossystemtimeoffset +60000
A spoofing example is below. Users should select their own unique and random values for both the past (-) and future (+) within the specified range. Different values should be used for each distinct VM (on the host).
VBoxManage modifyvm "Kicksecure" --biossystemtimeoffset -35017 VBoxManage modifyvm "Kicksecure" --biossystemtimeoffset +27931 VBoxManage modifyvm "Kicksecure<sup>™</sup>" --biossystemtimeoffset -35017 VBoxManage modifyvm "Kicksecure" --biossystemtimeoffset +27931
Apart from this small biossystemtimeoffset, a clock skew always degrades privacy. [4] [5]
- ↑ See the Fingerprint page to discover what fingerprinting means in this case.
- ↑ See Design: Dev/TimeSync.
- ↑ In this case, Tor cannot verify the Tor consensus.
- ↑
biossystemtimeoffsetis used to unlink the virtualizer's initial clock synchronization of the VM from the host clock. - ↑ After powering on a VM, it initially synchronizes the VM clock with the host clock until Kicksecure Timesync adjusts it.