> This is actually worse than not using a password manager at all, > because the window you are about to enter the password into has full > control over its title, and so this opens a race condition where the > site could change its title right before dom0 checks it (perhaps > triggered by "I am displaying a login form, and I just lost focus") to > turn the dom0 pw mgr into a confused deputy [1] which would be happy > to deliver the password for site A to the malicious site B which is > temporarily spoofing site A's expected title.
Counterarguments in order of decisiveness, starting with the least and going to most: 1. This is touching on a debate on real security vs. theoretical, and I happen to think these situations parallels the debate about cell phone cameras. Do you remember back when they first came out and quite a lot of people were constantly complaining about their picture quality (atrocious) and questioning why anyone would need a camera in a phone? Convenience. You can say "just bring a real camera" all you want but when you're talking about day to day life, 99% people will inevitably be caught with nothing but their camera phone on them. And without a usable Dom0 / Offline-VM password manager, 99% people will choose inferior passwords, have persistent logins and/or store their passwords on their online machine in some fashion. >From another angle: If theoretical security must trump real-world security or >convenience, then passwordless sudo needs to be removed, right? It's not even >all that "theoretical"; wasn't there a Xen jailbreak not that long ago? 2. I'm assuming the name of the VM being in the window titles prevents the password from ever going to the wrong VM. So if you are using multiple VMs of different trust levels, your bank password can't be targeted in this way unless it's by another highly trusted site. I'll take the chance that Gmail is pretending to be Amazon in order to steal my password. I mean, I sort of suspect they have stronger methods of identity theft at their disposal. 2a. Only sites you have an account with *and* are using this manager with could even attempt that attack. So mitigation vs. most realistic attacks is thus as simple as only using the password manager with important, "name-brand" websites and sticking with your browser's password storage for $ObscureUBB#7482. The target user here is a savvy power user who actually understands what's going on, not someone who needs training wheels. 3. How are on earth are they going to time that? How could an AppVM, a non-compromised AppVM[1], anticipate the Dom0 window poll? Like I said, this isn't a suggestion for a standard, robust, idiotproof scheme. It's also not telepath-proof. If not telepaths, How else are you going to know when to change the title? And before you answer, see #4. 4. I was actually already envisioning a few repeated polls over the course of a second or so for reliability, to guard against the user clicking around, but that would guard against this as well. All polls have to agree, otherwise the AppVM's clipboard is never filled. In the context of an attentive user, this should be a fatal blow to your described attack unless they can stack it with some other bugs. The deputy is being closely watched by the sheriff. >Not quite. The holy grail would be never having the VM see the passwords *ever*, and this is in theory actually achievable. Yes, you can split up the AppVM into multiple pieces but one of the pieces with internet access is going to need to see the password at some point. That's far, far ahead of what I'm talking about, though. I'm talking about a very simple project with lots of code reuse. If we're going to start talking about what Qubes should *ideally* do given lots of time or resources, I think some words like Alpine, unikernel and Genode should be thrown around. >This is better than using a password manager, I don't doubt it. I would never suggest a long term focus on window titles as a way of authenticating websites or communicating between Dom0 and DomUs. But I think it will be some years before they manage to get things properly separated and locked down like that. I hesitate to make claims about codebases I've never seen, but... this is a cookie cutter job, isn't it? Aren't the pieces all there? I wouldn't be surprised if someone could have something functional in less than a day's work. (Assuming that the person was sufficiently familiar with both the window manager and the hyperclipboard code bases.) Start by using the existing hyperclipboard code with a new hotkey combination, toss in an SQLite database or maybe just plain text, poll the window title for xxxx milliseconds[2] and if the polls all agree, send it to the clipboard. If they don't all agree, abort. I was merely thinking of this as a power user thing. Duct tape. I happen to think it's pretty strong duct tape, and that even a well-placed adversary would be find it difficult to pull off an attack against a user who was paying attention to what she or he was doing, but I want to underline that I would never consider this solution to be anywhere near ideal and I'd be aghast if anyone suggested standardizing on window titles as a permanent, long term solution. Shane 1. If it's been compromised, then they can just intercept your credentials directly. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9303059f-f1ce-430f-a48a-a1133e266096%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
