App qube of course. Try to run this command in your whonix qube. I still did not get if you ran it there or not. I do not talk about timedatectl or something else. Just this command.
Well, the only special thing I performed before is completely disabling time sync operation in Qubes. I disabled timesync service in sys-net and set clock sync qube to “none” in Global Config. Your command shown my local time zone in dom0 terminal but in Whonix app qubes command: timedatectl returned only UTC time.
We are not talking about timezone actually used by Whonix but about your dom0 timezone leaked to Whonix qubes using this command in Whonix qube:
qubesdb-read /qubes-timezone
2 Likes
Ok. If to enter this command then it shows my local time. All this time I was talking about command of that guy that shown those outputs. His command returned UTC time.
Fine, now we are on the same page. Any app in whonix can make this request, of course without showing terminal or anything else, and know your timezone in other qubes.
Re-read his message, he provided more than one command there, including qubesdb-read, and showed that even DispVM is not helping with timezone privacy.
And no one still fixed this since then? Well…
P. S. Replying on your comment with link.
F***, I missed that line in his comment. My bad. Sorry…
But if to talk about that part I think I don’t see any leaks except processor info? Am I right? And seems all tests that I did didn’t show any real info except processor.
Please see `/etc/machine-id` should not be inherited from templates · Issue #8833 · QubesOS/qubes-issues · GitHub for more information.
(Highly recommended to read the whole issue)
1 Like
Thanks for the link, very informative!
In R4.1, the /usr/share/qubes/marker-vm file has a grammar mistake, for added authenticity 
(a VM HAS tools, it doesn’t HAVE tools). So if a linguistically sharp hacker tries to impersonate Qubes, it will be easily detected!
[user@personal ~]$ cat /usr/share/qubes/marker-vm
# This is just a marker file for Qubes OS VM.
# This VM have tools for Qubes version:
4.1
[user@personal ~]$
1 Like
If you’re interested in this topic, I highly recommend reading the following link:
(Already posted here earlier: How to hide the fact that I'm Qubes OS from Telegram - #59 by adrelanos)
I see no point in duplicating that information here.
Documented, in detail, here:
Also search Qubes forums for CPUID to avoid duplicates.
Also related:
Quite a lot is hidden but not all. Documented here:
- This forum discussion is about hiding information from locally running applications.
- Hiding thing from ISP is a different topic, which I wouldn’t recommend mixing in here to keep it nicely organized.
Some information (not CPU type as far as I am aware) can leak over the network. See here for references:
Also good search term for search engines:
TCP/IP fingerprinting
But to discuss this further, I recommend to search the forums first and if needed created separate forum thread. Please lets use this one only for the issues caused by information that can be obtained by locally running applications. Not issues that happen by using the network as these things are suffiently different.
6 Likes
I watched and as I understand only KVM among other VMs doesn’t leak real processor info? At least its model name and specifics but leaks its manufacturer.
And as total we have: VMs leak real processor info (KVM maybe is exception), real screen resolution, info that it actually is VM, in case of Qubes - that it is Qubes OS, in case of Qubes - probably real time zone. And all this in case if user runs app inside VM and not in case if user uses only Tor browser. Did I list all? Did I miss something?
To use web version you need to have telegram account that is registered on a simcard that you physically have and you should have device that will be working with that simcard (to every time enter account in web version). This is two things that some anonimous users try to avoid of having this because it can be dangarous and can deanonimize them even faster than Telegram app. Even if simcard and device will be anonimous there still left triengulation of cell towers.
This example is all about Linuxes but what’s about Windows?
The difference of Tor Browser versus Telegram is only that Tor Browser abstains (hopefully) from reading and using that information. Tor Browser developers are pro-privacy. Telegram, well, let me just carefully phrase this as “to lesser degree”. It’s application unspecific. This information is available and cannot be hidden due to technical challenges. What technical challenges? Refer to the links already provided.
I doubt KVM is an exception nowadays. Maybe CPU model masking maybe was a thing in the past but probably not a good idea nowadays due to CPU bugs (spectre, meltdown, …). → Also Technical Challenges.
1 Like
In this reply you mean only processor info, yes? Because in your quote is also my question about whether I did list it all or not. So it’s not clear if you’re just talking about processor or about all hardware info at all.
And in general about the topic: Telegram threat. Everything that was told here yet, on this topic, was in the field of theoretical assumptions. But let’s talk about this in terms of real, not theoretical possibilities. Does Telegram installed from repositories have not open source code? So it probably should contain no malicious code, yes? So from where will come threat in this case? In theory open-source app should not do those hardware requests that reveal your hardware info, right? Or it needs that information for proper work? If not then all threat in this case may come from the closed source code Telegram servers? Or these servers can’t/won’t do such hardware requests? As I know even official Telegram app from official site is open-source.
UPD: And forgot to say. All this we’re talking about must be a targeted attack, right? Adversary should to take appropriate, deliberate action to make an attack exactly on Qubes OS, to try to retrieve hardware data of its host machine. App itself can’t do this by default, otherwise it would be detected in its open-source code. So how this attack would be performed? Through interaction with Telegram servers and they would insert a malicious code in Telegram app or make malicious requests straight to the OS? Why am I asking all this? I’m just trying to steer the conversation in the direction of determining how much it’s possible, basically, in real life, in the percentage. Not just fantasizing about some theoretical threats and attacks.
Malware exists. Malware is realistic. So discussing this in context of Telegram I view as rather symptomatic as “but what if Malware running gathers this information”.
Telegram, while not known to be the worst collector of hardware information, while not considered malware by most, while there being valid criticisms may be considered by some as fine. But Telegram, as any software, could be vulnerability to security issues. Any legitimate software can be attacked. If vulnerable, can lead to malware getting locally installed. And that malware could then gather hardware information and leak it somewhere.
- Are attackers doing super complex attacks, using gigantic effort? Yes. Example, watch this: https://www.youtube.com/watch?v=1f6YyH62jFE
- Did any Linux malware ever read /proc/cpuinfo. Yes. References:
- Dota3 Malware Again and Again | CounterCraft
- IoTroop Botnet: The Full Investigation - Check Point Research
-
GET /shell?echo+jaws+123456;cat+/proc/cpuinfo HTTP/1.1
-
- Compromising devices: a step by step analysis - Avira Blog
-
Another way to find out more about the target platform is to use the command “cat /proc/cpuinfo” as shown below:
-
For a list of information available to locally running code that should ideally not be available, please refer to the links that I shared. If you read them, you see the label cannot be hidden due to technical challenges applies to all of them.
Since it’s Debian main we can safely assume it being Open Source but also Open Source can contain malicious functionality depending one one’s viewpoint what malicious means.
The Telegram client determining “login from this and that OS”, sending that message to some login notification prompt direct message could be considered malicious or at least unnecessary by some people as probability evidenced by this forum thread. This notification that telegram is sending is sent by the Telegram server. So the Telegram server knows it. Could be considered an unwanted information leak.
In theory. In practice, I wouldn’t be surprised if popular Open Source browsers during their phone home activity such as crash reporting are sending that information to browser vendors. Related: Browser Radio Silence After Start - Zero Background Connections - Development - Whonix Forum
4 Likes
I checked all links and there was no phrase “cannot be hidden due to technical challenges”. The only link where was something similar is this link where is the list of hardware info that can be revealed if local installed app makes request.
Should all Qubes-Whonix users install these packages or this is pre-installed in Qubes-Whonix? Or they don’t need them anyway because of Qubes/Whonix hardened security?