Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Very small attack surface, I have been using qubes for years, never had to copy a file from dom0 to a vm.
    by throwawayffffas
  • its kind of fascinating that all this paranoia falls to a shell escaping issue with system().
    by bawolff
  • Most security bugs are due to improper string validation and use.
    by _pdp_
  • (Obviously a take that does not get very far in lower level programming, but from the comfort of some abstractions away:) I like to think of buffer overruns, command injections and path traversal as all the same category of bug: type confusion. Nothing special. An no excuse to risk any of them, if the logic implementing them is expected to be called just O(1) times anyway.
    by edelbitter
  • Another example for why system() is so dangerous to use.

    I also don't understand why it needs to show the dialog in dom0. If you have the option to handle attacker controlled input on the unprivileged side, you should do that instead of putting a lot of logic on the privileged side.

    by charcircuit
  • > why it needs to show the dialog in dom0

    I think it's the "secure screen" that cannot be manipulated by the malware in a VM. I'd expect a password entry dialog to also be handled like that.

    by HackerThemAll
  • The code is sloppy. They check existance of kdialog binary using full path; next step they rely on PATH search by shell. If would've been much safer to just do execve directly.
    by delamon
  • Mini tangent: Could someone explain to me why Qubes is used for security, when (from what I understand) Jails on BSD is significantly more robust/safe/has a much smaller exposed area? Is it just "everyone's using linux already; here's a safer linux"?
    by user_7832
  • Qubes uses VMs, Jails use a shared kernel. So I wouldn’t say Jails are safer nor that they have a smaller exposed area with regard to host isolation than VMs.
    by amarshall
  • Qubes can be viewed as a Xen distribution, rather than a Linux distribution [1]. You may find the Qubes FAQ a good starting point (I'm reading it now because of your question, so thanks).

    [1] https://doc.qubes-os.org/en/latest/introduction/faq.html#is-...

    by zvmaz
  • I'm still very impressed by qubes, and glad I'm not such a target that I feel I need the level of opsec it affords (on all my laptops).

    Maybe someday AI-assisted killchains will be so widespread that Qubes is the minimal level for the (few?) still-local users of compute.

    I would not have copied anything from dom0 to any another qube, the impact is low.

    by polotics
  • > I would not have copied anything from dom0 to any another qube, the impact is low.

    You'd typically copy logs, to open issue tickets etc.

    by negura
  • The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system() That is C security 101: never pass untrusted input through a shell. This should have been caught in review!
    by Allwinkt
  • I do really like the following in the bulletin:

    > Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.

    It looks like Qubes is ran by people who take security seriously, which is refreshing.

    by TacticalCoder
  • I own a Qubes T-shirt which I bought in person at FOSDEM. The design on the T-shirt consists of many copies of the QMSK in hexadecimal. All of their merch is like this.
    by inigyou
  • How well is QMSK protected from a serious attacker?
    by leonidasrup
  • I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop.

    IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?

    by zby
  • Problem is not that nobody wants to do it, it is that GPU stack is exactly the kind of enormous driver surface Qubes exists to keep away from dom0. Second monitor does not really change that, somebody still has to trust the driver.
    by artyomsv
  • Hardware graphics acceleration can work, it just needs a bit of fiddling and opens a few attack vectors. I don't legitimately know if there has ever been a viable attack through a shared pci device though.
    by throwawayffffas
  • This is sort of a solved problem with virtio native context. You can just run mesa driver in the virtual machine and proxy it's ioctl calls to host kernel gpu driver.

    I'm pretty sure all the major GPU drivers in mesa now supports this feature.

    Wonder why QubesOS hasn't adopted this yet.

    by madushan1000
  • I dropped QubesOS once exactly for that reason in the past but now I’m running it again on a separate computer.

    Even with all its drawbacks, there is something really nice about being able to run different applications over Tor, VPN or plain internet simultaneously, the ability to isolate non-safe binaries and being able to backup your VMs easily.

    I wish a similar distro would be made based on KVM so that the standard kernel could be used. It would be great for compatibility.

    by jwrallie
  • The founder Joanna Rutkowska left QubesOS in 2018. All the code involved in this bug was committed by her successor Marek Marczykowski-Górecki.

    Joanna seems to be a genuine good guy, she once wrote a paper titled "Intel x86 considered harmful". That's why Huawei and the Chinese government aren't even trying any more to make western CPU architectures secure, it's a hopeless cause.

    by grommz
  • Is there some evidence that x86 is uniquely prone to exploitable memory corruption? I haven't seen it, if so.

    > That's why Huawei and the Chinese government aren't even trying any more to make western CPU architectures secure, it's a hopeless cause.

    I suspect there are much more boring reasons for this, ranging from licensing to geopolitics (i.e., it being useful/valuable to have a domestic base of engineers who can design an ISA).

    by woodruffw
  • Reminds me of Theo DeRaadt again: https://marc.info/?l=openbsd-misc&m=119318909016582
    by sdcfgy
  • Brutal

    I hope when people read this though they understand this is a communication style; they're clearly trying to strongly discourage people from thinking they are suddenly protected. Effective? Maybe at one time, where "macho dev energy" was a thing. Today, not so much. You can tell they mean well because the intro sentence is actually pretty cheeky!

    by fallat
  • This is less of a virt/x86 bug and more of a "don't call system() on arbitrary user input" bug.

    .. incidentally, OpenBSD also provides one of the clearest examples of how the excuse "calling system() is fine in my case, its totally not arbitrary user input" is deluded just the same, see CVE-2020-8794.

    by edelbitter
  • Theo is a very insightful guy, but also very opinionated. I think the truth is somewhere in between.

    Especially as more and more virtualization functions move into hardware, not using them as a second security barrier seems foolish.

    by throwa356262
  • All I see is rudeness, insults, and arrogance sparkled with inklings of technical arguments. Worthless.
    by zvmaz
  • Looks like this has nothing to do with the hypervisor, it's not a traditional VM escape
    by XMPPwocky
  • The bug here is not related to virtualization, but a footgun as old as C stdlib: system() that doesn't take arguments separately, and instead relies on shell escaping by the application.
    by pornel