I don’t know what’s there for @anon97031756, but I can tell for sure that he’s not even close to be a Russian or from anywhere close to that or simply speak Russian well.
I’m not saying he have bad intentions, even though it does seems like FUD.
During my involvement in discussions occurring in corners of the Internet where some unsavory people congregate, I have been made aware of existing exploits for XEN by formally respected security researchers, some of which played a role in the compromise of OpenBSD’s CVS server circa 2002.
Migrating to a memory safe hypervisor with less LoC needs to occur. Linux-reliant software should then run within gVisor containers inside of linux-hardened (consult with Spender, if possible - maybe with if we collectively donate, he will be willing to provide assistance) VMs using memory safe alternatives to the GNU coreutils. Google has recreated most of them in Go already. Some efforts to do this in Rust are under way by less trustworthy groups. Services not reliant upon Linux can use library operating systems like MirageOS. Mirage-firewall is almost ready for prime time.
The Qubes specific tooling needs to be rewritten in a memory safe language as well.
Once these things are done, we will be much better off.
1 Like
Как я уже озвучивал выше проблема Qubes в том что они полагаются только на гипервизор. Какая разница сколько LOC используется в гипервизоре, если он потенциально уязвим. Я поискал больше информации про Qubes Air, они вроде как они планировали начать внедрение в 4.3. https://www.youtube.com/watch?v=V4flhwEITr4 но сейчас это не готово
Интересно как вы это поняли
Qubes OS is open source
I have actually given some thought to these sort of things and came up with the conclusion that the best way to avoid backdoors (having the absolute lowest probability of having any backdoors) is to start a project to port TempleOS onto the RISC-V beagleboard.
1 Like
TempleOS works fine in Qubes, but I would sign up for that.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
I can proof that by provide PC with hardware or just SSD of actual active QubesOS installation that was hacked in last year for any investigation team that wish for.
Same attack was implemented against PC, non-certifated laptop and certified V56 with heads from Nitrokey.
A few preliminary points:
I consider QubesOS as best personal use OS, but not ideal solution and definitely backdoored as any another solution at market.
I’m activist, past investigative journalist with an unusually high threat model.
I figurate that attacker compromised mobile device used as hotspot by zero-click spyware, when I connected via whonix to that hotspot for updates i got templates of whonix gateway and workstation infected, and entire installation after that.
As option without investigation but with high alertness Lateral movement committed via file transfer function between qubes, from sys-net to templates without trigger UI approve need regrading dom0 default security settings.
Anyway, attacker reached full C&C over dom0 fully remote without any chance of physical contact with device - I’m carrying last compromised device V56, with heads for 24/7 with me, even in toilet.
Bottom line,
QubesOS isn’t honeypot, but it not enough secured by default.
Attacker: Israel.
1 Like
There are organizations providing help in such cases, for example, this one:
You should contact them.
Nice try.
If by Israel you mean the government, then they do the right thing.
Don’t try shady things for shady people.
Obviously.
Otherwise, how would you eat without watching or reading something while sitting on the toilet, so bizarre!
Thx you, I should consider that.
By Israel I mean government and shady companies as NSO and another false flag methods.
Please keep your political opinion out of discussion in cyber aspect, in cyber aspect it’s critical to identify offensive actor.
[“The design of Qubes is based on the belief that the hypervisor will not be compromised”, according to DeepL]
What are you talking about? Qubes’ security doesn’t solely rely on Xen. It relies more on the hardware-assisted virtualization (VT-d). Last time a VM escape in this, modern Qubes implementation was discovered in 2006 by the Qubes founder: Blue Pill (software) - Wikipedia.
Xen is used by many large organizations that are constantly verifying its security. Also, most vulnerabilities in Xen don’t even affect Qubes.
Dear @WhiteShadow ,
This would be very extraordinary.
You could make a new post in the “Help I think I’ve been hacked” category
In every case I saw, after enough information was given, there were other explanations (it was looking like normal but not-expected behaviour, it was misinterpreted log file/journal entries, hardware issues, or similar problems)
If any attacker has a method to break isolation from appvm to template or Dom0, then they are surely very sophisticated, and unlikely to leave any easily visible traces. If you have evidence, then it would be very interesting for others.
I’m not skilled enough for solo fully and deep investigate technical part, but my “technical” issues followed by real life results:
- Agents that talk to me in public and ask me not to share information with manipulations. For example, same as yevabe9977 comment, but in real life from people in train, bus, clients and etc.
- Same of technical issues, became a sequence of events with a purpose.
Case not limited to QubesOS, QubesOS is minor part of my entire life as target for silencing and intimidation.
I would be happy to share knowledge and evidence that I have. But not in that way.
How do you sleep? Physical compromise would still seem the most plausible to me.
Xen is even used in US government projects like AIS SecureView, needing to keep different information classification levels apart and using a system architecture quite similar to Qubes OS.
This is mainly achieved by running only the hypervisor in Ring 0 of Intel’s processor architecture. Compromising Xen’s security, therefore, requires an uncontrolled switch from one of the outer rings to Ring 0, which is not impossible but would necessitate either a serious bug in Xen itself or a hole in the processor architecture. While the existence of such holes is not impossible, it is doubtful that they would remain unnoticed for years. (By the way, this is just the cause of the Qubes documentation stating that its system security mainly depends not on Xen but on the use of Intel VT-d and so.)
6 Likes
I would like to follow up on this.
@WhiteShadow If you are willing to provide the hardware or SSD, as you say you will, I
can put you in touch with a number of investigators - PM me with you
location and I will provide you with address to send the SSD or PC.
Examples of successful attacks, particularly against Xen or Qubes, are
of great value.
Your anonymity will, of course, be fully respected.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
4 Likes
You should keep in mind that Qubes was not intended to withstand attacks by state-sponsored groups that can manipulate the hardware or get into the supply chain. This has already been stated by the Qubes team several times - as far as I remember, e.g., by @adw.
In order to get security sufficient to thwart such attacks, you have to get into the area of handling highly classified information, and then the rules for computer use change drastically: You won’t be allowed to use standard commercial hardware and software, and you won’t be allowed to have this hardware in an unprotected place and use unverified software like standard browsers or office software. Instead, you are confined to working in highly protected, radiation-controlled areas, possibly without any network access, and using a very limited software portfolio, which is quite unusable for “normal” work. Taking your PC with you to the toilet, as @WhiteShadow wrote, is quite out of question - maybe causing quite some other problems! 
Qubes OS targets quite another market: having better security for people needing a secure environment that is still suitable for normal work like browsing, document handling, etc. In order to satisfy such usability requirements, clearly some compromises have to be made, and Qubes does this admirably: You get a much higher level of security than available with standard monolithic systems, and still have most of the functionality available there.
It depends on your threat model and your possible attackers whether you can live with such a compromise. But you have to be realistic and consider whether your adversaries will think the costs and efforts for high-level attacks against you worthwhile. This is a question that no one else can answer for you.
9 Likes
I absolutely agree with what GWeck just said, but I think Qubes OS is definitely a honeypot too, just to be in topic with the thread. It is not about the Qubes devs made this honeypot to trap you. It is rather about how Qubes OS is being used as a honeypot. It is trivial to know what OS you are using, and if you are using Qubes OS, you just gained yourself an entry in soneone’s watchlist. And that is, I’m afraid, the definition of honeypot.
For those of you who think Qubes OS is not a honeypot, it’s good for you.
For those of you who think Qubes OS is a honeypot, why are you playing “their game” by “their rules” and wonder why you always lose? What stops you from creating your own world to live in, e.g. making new friends you can trust, building own hardware you can use, write own software you can run, etc?
What stops you from creating your own world to live in, e.g. making new friends you can trust, building own hardware you can use, write own software you can run, etc?
Funny, here I am under the impression that’s exactly what we are doing here within reasonable limits.
Over the past years I’ve come to trust Marek, Unman, Andrew and some others quite a bit by observing their actions and advice. I’ve built my own machines (granted Intel-based, but still). I’ve even inspected some of the Qubes OS code, without fooling myself into believing I’d be qualified to audit.
The longer I’m here the more I get what the team means when they put the “reasonable” qualifier before “security”. I’d estimate a good 50% of the discussions in this forum are attempts to work out what reasonable means in individual contexts and within the limits we all experience (time, ability, resources).
17 Likes
xz backdoor was detected before it could do any harm.
3 Likes