Well, since the issue was finally closed I will reply here.
I don't understand this example - if the destination is compromised, then
why would there be a need to modify the clipboard? They just capture the
data as is and exfiltrate it - you are hosed, and the Qubes clipboard is
the least of your problems.
At destination there is nothing useful to steal (at least not bitcoins)
the bitcoin address is not useful for the attacker, it is a public
address and private keys are in other uncompromised offline vm.
What the attacker tries to do is replace your address in the clipboard
to other address (controlled by him), in the hope that you paste it to
someone who wants to send funds for you.
I'm agree that the attacker could do a lot of additional things but many
of them are more difficult, prone to fail, prone to cause detection. So
I don't think it is a justification for not having a more secure
clipboard and also easier to use which was the main objective.
Again, I don't understand your example. You say, "At destination there is
nothing useful to steal", and then you exactly indicate what is useful
to steal, i.e the bitcoin address.
In any case, this is where we disagree.
Most of those "additional things" seem to me to be far easier to
implement, and have far wider application, than an attack on the Qubes
clipboard.
I haven't seen anything in the discussion on GitHub which would provide
"a more secure clipboard", and which would be "easier to use". I think
what is needed are some concrete proposals, and perhaps poc -then
we'd actually have something to consider. Until I see that I'm bowing
out.
Again, I don't understand your example. You say, "At destination there is
nothing useful to steal", and then you exactly indicate what is useful
to steal, i.e the bitcoin address.
Well, the bitcoin address is not there until the user pastes it from
other qube and it is not something useful for the attacker itself. I
have attached two diagrams (with my limited dia skills) to represent the
threat model that I am trying to describe, and the alternative model
that could protect the user in this scenario.
In any case, this is where we disagree.
Most of those "additional things" seem to me to be far easier to
implement, and have far wider application, than an attack on the Qubes
clipboard.
I haven't seen anything in the discussion on GitHub which would provide
"a more secure clipboard", and which would be "easier to use". I think
what is needed are some concrete proposals, and perhaps poc -then
we'd actually have something to consider. Until I see that I'm bowing
out.
I am not security expert so probably I can consider difficult attacks
that are happening everyday. But please, consider my threat model a
little. It is not "an attack on the Qubes clipboard". It is an attack to
any OS clipboard using some exploit on a browser (or other program) as
Firefox that could only gain access to the clipboard. It could be a code
loaded on a webpage, a plugin error exploited or even directly a plugin
that the user installed.
It would be "easier to use" because all copy/pastes would require only
two steps (sometimes with explicit authorization). And for users who
come from other desktop they will have only one clipboard as they are
more used to.
