Does Qubes OS Has A Leak Hole ?
86 views
Skip to first unread message
donoban
Jul 10, 2016, 9:51:44 AM7/10/16
to qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Very fun read:
https://www.deepdotweb.com/2016/03/12/does-qube-os-has-a-leak-hole/
Some parts:
"According to technical documentation concerning Qubes structure,
domains are separated from each other via encryption . Like the Dom0,
the storage domain is literally protected from other domains via
encryption to prevent viruses in other domains [ such as Network Vm ]
from penetrating into each other."
"Seemingly, Qubes OS depends on a backup system to prevent huge mass
of data. In default, the backup system relies on weak key derivation
scheme . So it is recommended that users select a high-entropy
passphrase for use with Qubes backups ."
"Qubes allows users not to ‘send’ or ‘transport’ but to copy and paste
files and folders . Let’s assume users download a file or a program
from a ‘phished’ website ( designated as an https website )
unknowingly . Later, the file or program downloaded from the phished
website is copied from the App Vm to the Storage Vm.
The storage Vm is encrypted from the Network Vm to prevent replication
of malwares ( i.e virus ) . Can the encryption method employed to
prevent malicious software in the programs or folders on the App Vm
from attaching itself to the Storage Vm ?"
Has some Qubes dev contacted with this guys?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXglLrAAoJEBQTENjj7QilnhYQAL0IlUfBJITyzZawPx42k9v5
QiXEWuSgdu8FOaxY+L2+6EBYRrpR5dqD+rgcS6bexlmlmPxwFdSyfce54QlRDEEx
BrXu7+Z9LY2NqM3M6L69Vc4KcnHHJ4JXWg26ThCKa2NmO+Us5tF0i6FRiOuhz9vu
dQ2etpDg+AZFvriu+OCMnqYOTJO69/nnCZ1d8eecNZa77cImnJNWkMZu4F9MlpoD
6IllNPSRz12GjRSTuOdq5TUh6plGeTrN8K1o4xGfjjQIKSer9q/+0rvj4K/Cxo9i
BixuFSpZKyJgU2wnhXATPwWXEoPLMQyqC5hd9vvLk7uTPsd5f1FG8Xt06g2Jxjxa
g2wKLJHGkDILHrrj9Ox2Ofs+Nk6BiaaAcEs/6Zztb/SzfjmW8gOd4F3QloHcf6dA
T1n4eSsoaSbjlhb49EH+evDF0yATt/KvogO1C6aMcJtftPJv1cJYjbsQnx/b6peG
tqUGQ60yTvKe2ArLZzKaSyxsmoWmSsE3xVmmiZsgQLbzDVDV0ztj3haYi64RMSUm
bJDv+99plKzfeSTSHx9A4Z2EsJlZFblOJP7K2Oc9r0Hh5MLpXKUcqtB4aWxhXZUl
R5nj/jSHqmEeJNQlvIGVyyNhiIzr6nqbwLQ+rMAImkkg2BsxLsk7QUKsOBCePZ0Y
A42OyCaHOyeH7fq4C0C4
=ubt7
-----END PGP SIGNATURE-----
Hash: SHA256
Very fun read:
https://www.deepdotweb.com/2016/03/12/does-qube-os-has-a-leak-hole/
Some parts:
"According to technical documentation concerning Qubes structure,
domains are separated from each other via encryption . Like the Dom0,
the storage domain is literally protected from other domains via
encryption to prevent viruses in other domains [ such as Network Vm ]
from penetrating into each other."
"Seemingly, Qubes OS depends on a backup system to prevent huge mass
of data. In default, the backup system relies on weak key derivation
scheme . So it is recommended that users select a high-entropy
passphrase for use with Qubes backups ."
"Qubes allows users not to ‘send’ or ‘transport’ but to copy and paste
files and folders . Let’s assume users download a file or a program
from a ‘phished’ website ( designated as an https website )
unknowingly . Later, the file or program downloaded from the phished
website is copied from the App Vm to the Storage Vm.
The storage Vm is encrypted from the Network Vm to prevent replication
of malwares ( i.e virus ) . Can the encryption method employed to
prevent malicious software in the programs or folders on the App Vm
from attaching itself to the Storage Vm ?"
Has some Qubes dev contacted with this guys?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXglLrAAoJEBQTENjj7QilnhYQAL0IlUfBJITyzZawPx42k9v5
QiXEWuSgdu8FOaxY+L2+6EBYRrpR5dqD+rgcS6bexlmlmPxwFdSyfce54QlRDEEx
BrXu7+Z9LY2NqM3M6L69Vc4KcnHHJ4JXWg26ThCKa2NmO+Us5tF0i6FRiOuhz9vu
dQ2etpDg+AZFvriu+OCMnqYOTJO69/nnCZ1d8eecNZa77cImnJNWkMZu4F9MlpoD
6IllNPSRz12GjRSTuOdq5TUh6plGeTrN8K1o4xGfjjQIKSer9q/+0rvj4K/Cxo9i
BixuFSpZKyJgU2wnhXATPwWXEoPLMQyqC5hd9vvLk7uTPsd5f1FG8Xt06g2Jxjxa
g2wKLJHGkDILHrrj9Ox2Ofs+Nk6BiaaAcEs/6Zztb/SzfjmW8gOd4F3QloHcf6dA
T1n4eSsoaSbjlhb49EH+evDF0yATt/KvogO1C6aMcJtftPJv1cJYjbsQnx/b6peG
tqUGQ60yTvKe2ArLZzKaSyxsmoWmSsE3xVmmiZsgQLbzDVDV0ztj3haYi64RMSUm
bJDv+99plKzfeSTSHx9A4Z2EsJlZFblOJP7K2Oc9r0Hh5MLpXKUcqtB4aWxhXZUl
R5nj/jSHqmEeJNQlvIGVyyNhiIzr6nqbwLQ+rMAImkkg2BsxLsk7QUKsOBCePZ0Y
A42OyCaHOyeH7fq4C0C4
=ubt7
-----END PGP SIGNATURE-----
Andrew David Wong
Jul 10, 2016, 10:10:10 AM7/10/16
to donoban, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2016-07-10 06:51, donoban wrote:
> Very fun read:
> https://www.deepdotweb.com/2016/03/12/does-qube-os-has-a-leak-hole/
>
> Some parts:
>
> "According to technical documentation concerning Qubes structure,
> domains are separated from each other via encryption . Like the
> Dom0, the storage domain is literally protected from other domains
> via encryption to prevent viruses in other domains [ such as
> Network Vm ] from penetrating into each other."
>
No.
> "Seemingly, Qubes OS depends on a backup system to prevent huge
> mass of data. In default, the backup system relies on weak key
> derivation scheme . So it is recommended that users select a
> high-entropy passphrase for use with Qubes backups ."
>
This appears to be taken directly from what I wrote at the top of this
page:
https://www.qubes-os.org/doc/backup-restore/
>
> "Qubes allows users not to ‘send’ or ‘transport’ but to copy and
> paste files and folders . Let’s assume users download a file or a
> program from a ‘phished’ website ( designated as an https website
> ) unknowingly . Later, the file or program downloaded from the
> phished website is copied from the App Vm to the Storage Vm.
>
> The storage Vm is encrypted from the Network Vm to prevent
> replication of malwares ( i.e virus ) . Can the encryption method
> employed to prevent malicious software in the programs or folders
> on the App Vm from attaching itself to the Storage Vm ?"
>
Nonsense.
> Has some Qubes dev contacted with this guys?
>
I doubt it. It would be a supreme waste of our developers' time to
contact this author.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXglc8AAoJENtN07w5UDAwEPEQALX5hf+7RnTlH0P2aFK8S2Ue
4FaSfnvfCztO5sDWfr5/dRab7LfGSfaE3YhIEB8xi+7FLqC2BZPUvI9pvn76tfJZ
MnmHzxt9bVWB2nO7uMUJy3P93BMZlrZe7eWz4dr8GRMOrWvzZJd9zcy5Mi6PlQ8n
ahRLaCorMvQjIrAdGdbbnvD6k+YvaLKefQ1uuyCoLslX2fzvIXGfLTFr8tGQ9WvN
RUJobWk5dyF6EZ/QPw2zPZg14oWNqZZu1B99jJ+F1dYCVjZhO3EM7wkxPebYC2+6
Dd0pX6uTwlYmPzwarGq6b98QCk0c7lOVJfv30EnYavJQobELPV0pgp2GUV3T+Tb7
l3MJt7LKubXHD0Pbw5rAeOWyCgbx+UHa3G3mjcpP1DPo0Td8fJtF78N1z7fanMGU
JEr0z3tJzj8DCc46Cwj3GyRCEx/HjUpBKxxszeW+f8xNtFaVjm5gq0BdsaSibSea
oNjZdARTz5NnJBp6vZIQguWYHjbpcM+ny6LBwdZcle0WS3b1/LXRfh/wcITafB9s
LICDI1t0Atnx6JmWudmH7eMT+G5RQK7JzpjZf22fMLKZkk5o0V3XSTJbcQXNNNO5
jWIf9CMbBuMNYEinIBA4mJO1fPmUFyqxIFtUtvHn3jkoqKVincRvmTYZcOZF3GHc
uljM557dU2fVLwhsDNzB
=p+cj
-----END PGP SIGNATURE-----
Hash: SHA512
On 2016-07-10 06:51, donoban wrote:
> Very fun read:
> https://www.deepdotweb.com/2016/03/12/does-qube-os-has-a-leak-hole/
>
> Some parts:
>
> "According to technical documentation concerning Qubes structure,
> domains are separated from each other via encryption . Like the
> Dom0, the storage domain is literally protected from other domains
> via encryption to prevent viruses in other domains [ such as
> Network Vm ] from penetrating into each other."
>
> "Seemingly, Qubes OS depends on a backup system to prevent huge
> mass of data. In default, the backup system relies on weak key
> derivation scheme . So it is recommended that users select a
> high-entropy passphrase for use with Qubes backups ."
>
page:
https://www.qubes-os.org/doc/backup-restore/
>
> "Qubes allows users not to ‘send’ or ‘transport’ but to copy and
> paste files and folders . Let’s assume users download a file or a
> program from a ‘phished’ website ( designated as an https website
> ) unknowingly . Later, the file or program downloaded from the
> phished website is copied from the App Vm to the Storage Vm.
>
> The storage Vm is encrypted from the Network Vm to prevent
> replication of malwares ( i.e virus ) . Can the encryption method
> employed to prevent malicious software in the programs or folders
> on the App Vm from attaching itself to the Storage Vm ?"
>
> Has some Qubes dev contacted with this guys?
>
contact this author.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXglc8AAoJENtN07w5UDAwEPEQALX5hf+7RnTlH0P2aFK8S2Ue
4FaSfnvfCztO5sDWfr5/dRab7LfGSfaE3YhIEB8xi+7FLqC2BZPUvI9pvn76tfJZ
MnmHzxt9bVWB2nO7uMUJy3P93BMZlrZe7eWz4dr8GRMOrWvzZJd9zcy5Mi6PlQ8n
ahRLaCorMvQjIrAdGdbbnvD6k+YvaLKefQ1uuyCoLslX2fzvIXGfLTFr8tGQ9WvN
RUJobWk5dyF6EZ/QPw2zPZg14oWNqZZu1B99jJ+F1dYCVjZhO3EM7wkxPebYC2+6
Dd0pX6uTwlYmPzwarGq6b98QCk0c7lOVJfv30EnYavJQobELPV0pgp2GUV3T+Tb7
l3MJt7LKubXHD0Pbw5rAeOWyCgbx+UHa3G3mjcpP1DPo0Td8fJtF78N1z7fanMGU
JEr0z3tJzj8DCc46Cwj3GyRCEx/HjUpBKxxszeW+f8xNtFaVjm5gq0BdsaSibSea
oNjZdARTz5NnJBp6vZIQguWYHjbpcM+ny6LBwdZcle0WS3b1/LXRfh/wcITafB9s
LICDI1t0Atnx6JmWudmH7eMT+G5RQK7JzpjZf22fMLKZkk5o0V3XSTJbcQXNNNO5
jWIf9CMbBuMNYEinIBA4mJO1fPmUFyqxIFtUtvHn3jkoqKVincRvmTYZcOZF3GHc
uljM557dU2fVLwhsDNzB
=p+cj
-----END PGP SIGNATURE-----
Drew White
Jul 11, 2016, 3:24:06 AM7/11/16
to qubes-users, don...@riseup.net
On Monday, 11 July 2016 00:10:10 UTC+10, Andrew David Wong wrote:
> > https://www.deepdotweb.com/2016/03/12/does-qube-os-has-a-leak-hole/
> > Has some Qubes dev contacted with this guys?
> >
>
> I doubt it. It would be a supreme waste of our developers' time to
> contact this author.
> > https://www.deepdotweb.com/2016/03/12/does-qube-os-has-a-leak-hole/
> > Has some Qubes dev contacted with this guys?
> >
>
> I doubt it. It would be a supreme waste of our developers' time to
> contact this author.
If the author knew English, would it be worth 1 second to consider saying maybe and then say no?
Andrew David Wong
Jul 11, 2016, 7:07:46 PM7/11/16
to Drew White, qubes-users, don...@riseup.net
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 2016-07-11 00:24, Drew White wrote:
> On Monday, 11 July 2016 00:10:10 UTC+10, Andrew David Wong wrote:
>>> https://www.deepdotweb.com/2016/03/12/
>>> does-qube-os-has-a-leak-hole/ Has some Qubes dev contacted with
> On Monday, 11 July 2016 00:10:10 UTC+10, Andrew David Wong wrote:
>>> https://www.deepdotweb.com/2016/03/12/
>>> this guys?
>>>
>>>
>>
>> I doubt it. It would be a supreme waste of our developers' time
>> to contact this author.
>
> If the author knew English, would it be worth 1 second to consider
> saying maybe and then say no?
>
The main issue is not whether the author knows English (though that's
>>>
>>>
>>
>> I doubt it. It would be a supreme waste of our developers' time
>> to contact this author.
>
> If the author knew English, would it be worth 1 second to consider
> saying maybe and then say no?
>
important if you're going to publish articles in English for an
English-reading audience, IMHO). Rather, it's that the author
evidently hasn't done any due diligence to check whether the things he
or she is writing have any basis in fact (or even make any sense at
all). Instead, it looks like the author just skimmed our website and
the arch spec doc, made a bunch of unfounded assumptions, then wrote
the article. If the author isn't going to take the time and effort to
look into Qubes a bit more before writing about it, why should our
developers take time away from their work to contact him or her?
Also, remember that we have little (and, in some cases, no) control
over what other people publish about Qubes in independent publications
and on various websites. Responsible journalists typically contact us
before writing a story about us. I think it would be a fool's errand
for us to try to contact every author of every article about Qubes
that contains a factual error (even egregious ones) without carefully
considering the importance (based on things like the reputation of the
publication and the breadth of its readership) and the opportunity
cost of doing so.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
wyVGiygDvAsu0wWIA7AiWOCb7epuHR4BlavA39mLC5D9YV8eSRnXA5gZO3+XLy14
8dgX+Wb/JfTLpOpgrmfvSOtigqpJRuoiMV5NPGRXCpWNtjbsIzBJqUhodIXc2ArV
SuY6NiVjKJESK7BSaqEeyajo6DpbK5CCWwNgq39JBj1wCr+/aRbZpXcRoUsMaQ/8
KGOOFM8V+4fmU1AUA+1lqz7RpQyTK8uFVCyM3LZgt/RurbWuviwiorfb7zEBXTWb
q+XBW2gGQd8ZOaHalXPAT9mQ6kbjbssDauavZKdls30bKzLP0TNE0QYuvQ42mQgD
nIQvuYjyqshsEoaa237e2OiNW2wL40pBpjqiachg4LCmN7Q3oFUKpXcWIS3zSaip
gQ/mgKnFX8zamytSrMjkdsIyuHHILiZr/UsSNXeFdVr89ZBp3UFWqj7wn0/fM++J
E7qzTDdk2LFdkJ5aNE+RHVGr3KsPP/7EvYhsLnPciyHMUnDh/gSJfH/XqQJuMj0+
ABKtnQcoLcZShuuU3ZEYxQpMnld9/cTjuh13fxt/2Tbn8qPKtNmKAe5ZRNiItqDi
hLbo41DBrYov/n5/QpN0ljTLaHI1zT9zMoPmS++ISS1JA4GC6O3x6Tx16Ktsuel9
seCQfBMSS2l0hfcKRXb6
=DXdG
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages