4 ms·

QubesOS would have saved that Bitpay executive $2mln who fell for an old phishing trick http://www.americanbanker.com/news/bank-technology/bitcoin-payment-proce

QubesOS would have saved that Bitpay executive $2mln who fell for an old phishing trick http://www.americanbanker.com/news/bank-technology/bitcoin-payment-processor-bitpay-loses-1m-in-phishing-hack-1076722-1.html http://www.americanbanker.com/news/bank-technology/bitcoin-p... Just logically separating administrative VMs with credentials from email VMs would have been good enough to thwart this. We can always fork Qubes and play around with whatever other VM templates such as OpenBSD, seL4 x86/genode port or experimental encrypted overlay kernel.org kernels

nickpsecurity 11y ago
The article states that he's just guessing at what happened leading up to the fraudulent request. (If I'm reading right.) So, no way to know what would stop the first part. The actual attack was a common one where a request comes in without strong authentication and an authorized user carries it out. Neither QubesOS nor any other low-level architecture I mentioned would stop that as it's an application-layer concern. There's a little irony in your comment, though, given that one of the Nizza demonstrators in mid-2000's was doing eCommerce by splitting the UI and security critical parts over a microkernel. Did that for GPG email, too. So, even they recognized the problem and demo'd a two-part solution. I sent that to Joanna in our exchange. "We can always fork Qubes and play around with whatever other VM templates such as OpenBSD, seL4 x86/genode port or experimental encrypted overlay kernel.org kernels" That's true. It's why I found the seL4 and QubesOS work interesting. Additionally, as they showed up, I've suggested various projects to those interested in improving QubesOS assurance. These included capability extensions for Xen, the Xenon project, several projects that knock risk out of Dom0, components like Nitpicker, and so on. To be clear, I don't see QubesOS as worthless or all bad so much as redundant in some ways, weaker technologically in others, and a vast usability improvement in yet others. Use and improve it if you want for sure with definite benefits over a vanilla Windows or Linux box. Just know the limitations of the security approach and that efforts might be better spent elsewhere. Here's a recent report on the 2005 Nizza architecture's design along with other projects that built on it if you're curious what it was like. Notice how they understood where the software risks were, systematically eliminated what they could, and kept metrics on the TCB to back it up. On other end, I couldn't even get Joanna to agree user-mode drivers were more robust despite a decade plus evidence of this. https://os.inf.tu-dresden.de/Studium/KMB/WS2014/11-Security-Architectures.pdf https://os.inf.tu-dresden.de/Studium/KMB/WS2014/11-Security-...

nickpsecurity 11y ago

The article states that he's just guessing at what happened leading up to the fraudulent request. (If I'm reading right.) So, no way to know what would stop the first part. The actual attack was a common one where a request comes in without strong authentication and an authorized user carries it out. Neither QubesOS nor any other low-level architecture I mentioned would stop that as it's an application-layer concern. There's a little irony in your comment, though, given that one of the Nizza demonstrators in mid-2000's was doing eCommerce by splitting the UI and security critical parts over a microkernel. Did that for GPG email, too. So, even they recognized the problem and demo'd a two-part solution. I sent that to Joanna in our exchange. "We can always fork Qubes and play around with whatever other VM templates such as OpenBSD, seL4 x86/genode port or experimental encrypted overlay kernel.org kernels" That's true. It's why I found the seL4 and QubesOS work interesting. Additionally, as they showed up, I've suggested various projects to those interested in improving QubesOS assurance. These included capability extensions for Xen, the Xenon project, several projects that knock risk out of Dom0, components like Nitpicker, and so on. To be clear, I don't see QubesOS as worthless or all bad so much as redundant in some ways, weaker technologically in others, and a vast usability improvement in yet others. Use and improve it if you want for sure with definite benefits over a vanilla Windows or Linux box. Just know the limitations of the security approach and that efforts might be better spent elsewhere. Here's a recent report on the 2005 Nizza architecture's design along with other projects that built on it if you're curious what it was like. Notice how they understood where the software risks were, systematically eliminated what they could, and kept metrics on the TCB to back it up. On other end, I couldn't even get Joanna to agree user-mode drivers were more robust despite a decade plus evidence of this. https://os.inf.tu-dresden.de/Studium/KMB/WS2014/11-Security-Architectures.pdf https://os.inf.tu-dresden.de/Studium/KMB/WS2014/11-Security-...