new wiki pages:
moved to its own wiki page:
new wiki pages:
moved to its own wiki page:
new wiki page:
new wiki page:
I don’t think we properly referenced Rowhammer attacks anywhere? Where should this go?
It turns out DDR4 ain’t so protected after all.
Rowhammer exploits that allow unprivileged attackers to change or corrupt data stored in vulnerable memory chips are now possible on virtually all DDR4 modules due to a new approach that neuters defenses chip manufacturers added to make their wares more resistant to such attacks.
Rowhammer attacks work by accessing—or hammering—physical rows inside vulnerable chips millions of times per second in ways that cause bits in neighboring rows to flip, meaning 1s turn to 0s and vice versa. Researchers have shown the attacks can be used to give untrusted applications nearly unfettered system privileges, bypass security sandboxes designed to keep malicious code from accessing sensitive operating system resources, and root or infect Android devices, among other things.
Research published on Monday presented a new Rowhammer technique. It uses non-uniform patterns that access two or more aggressor rows with different frequencies. The result: all 40 of the randomly selected DIMMs in a test pool experienced bitflips, up from 13 out of 42 chips tested in previous work from the same researchers.
“We found that by creating special memory access patterns we can bypass all mitigations that are deployed inside DRAM,” Kaveh Razavi and Patrick Jattke, two of the research authors, wrote in an email. “This increases the number of devices that can potentially be hacked with known attacks to 80 percent, according to our analysis. These issues cannot be patched due to their hardware nature and will remain with us for many years to come.”
Considering network-based attacks are feasible, this is a major issue to put it mildly i.e. they don’t need local access to your machine or to fool you into running dodgy code on websites or via apps.
This is a hacker’s delight for advanced adversaries since it blows apart any sandboxing, VM separation etc.
Existing DisposableVMs risk leaking various information (a known problem) → https://github.com/QubesOS/qubes-issues/issues/4972
Some Whonix users will probably want a “paranoid mode” or similar for launching of disposable Whonix-WS using this method? →
In normal use qubes are created on, and changes written to, the disk. There is also extensive logging and signs of the qube are scattered in a number of places. Sometimes, you want to create a qube which does not leave these traces.
You can do this relatively simply, by creating a RAM based storage area and using it for a new storage pool. The qube will persist until the RAM disk is deleted, or the machine is shut down.
A script like this in dom0, will create tmpfs RAM disk, create a new storage pool, and create a new qube using that pool.
You can remove the qube, and some of the associated artifacts by script in dom0.
None of this is forensically reliable, although it is better than using a standard pool. (Refer to this issue, particularly if you are using Xfce, and check the associated issues.) Also, the scripts themselves will be on the disk, which may require some explanation.
Given it is scripts in dom0, users would have to do that manually, but it’s probably worth referencing this procedure here for advanced users (although I haven’t yet tested it for Whonix 16):
Could you please e-mail me? @torjunkie
I installed a messaging app in whonix-ws-16 to message over Tor. Typically I use a Debian template for the messenger app but decided to use the whonix ws template for a more robust Tor connection.
The messaging app uses the default system font to display emojis. The current default whonix font is extremely limited. Even a simple displays as a white box.
Is the default whonix workstation font customized from within the VM template or is there a setting in dom0?
Is there a relatively secure way to install a custom font or should it be avoided?
I presume we should warn somewhere to not install custom fonts i.e. might be a fingerprinting vector? But I’m not sure - I gather it is a legitimate risk i.e. detectable by external sites etc?
Indeed. It may or may not be remotely fingerprintable but consider the user is prefering this font in non-anonymous and anonymous VMs then reduces anonymity set by posting screenshots with support requests for both. In either case, for an abundance of caution it is best avoided to even avoid the question.
Kicksecure homepage, wiki and forums is now online.
Sorting out Whonix vs Kicksecure wiki contents will be a major effort. Design:
Difference between revisions of "Chat" - Whonix - could you please clarify what “Message content limited.” means?
I want to fix
Xfce proper case-sensitive but I need to change/correct the files names spelling in Whonix source code in a future build. Hence, it’s not fixed everywhere yet.
Now that kicksecure.com is online, there are two recommended host operating systems for Whonix:
While migrating Disable TCP and ICMP Timestamps - Whonix to Kicksecure wiki I was wondering what to do with instructions on how to disable TCP and ICMP timestamps on other Linux such as Debian, MacOS and Windows. I think keeping this documentation is too much and should be rejected. If someone wants better security like an operating system that disabled TCP and ICMP timestamps by default, use either Kicksecure or Qubes OS as a host operaging system.
Documenting the same for Debian, MacOS, Windows and even OpenBSD is stretching the project focus too thin. It’s a bit similar like the Debian wiki explaining how to do something on Windows or the MacOS website explaining how to do something on Debian.
The only documentation on Windows, MacOS will be how to install VirtualBox and import Whonix. That is useful to first time Linux users to try out Whonix but for better security these host operating systems are a lost cause. Instructions how to disable TCP and ICMP timestamps would be incomplete in the bigger picture since there would be a lot more host security settings (such as disabling telemetry) that should’t be part of Whonix wiki. Becuase the other way around, we’d also have to host full instructions on how to harden a Windows or MacOS host operating system which would be huge.
There’s now a much more beautiful download button.
Some mediawiki CSS fixes have been implemented. Primarily, many places with previously too much white spaces have been fixes. More fixes are upcoming.
CodeSelect widget has also been improved.
Can be seen here:
Testpage8 - Whonix
And the many other wiki pages using the
There are still some bugs (wrong box size if text inside
CodeSelect is too long). Please test and leave feedback.
Other planned websites enhancements that I scheduled which are planned for the next 4 weeks are listed here: