5 ms·

I remember one good argument she made, a reductionist one that if the firmware on your Ethernet adapter can be hacked without recourse or relief from the OS (sh

by hga 11y ago

I remember one good argument she made, a reductionist one that if the firmware on your Ethernet adapter can be hacked without recourse or relief from the OS (she gave a specific example), reducing the Xen part of TCB was not too relevant. It's worth noting that the seL4 people haven't tried to formally verify it on x86 (and there's no 64 bit port to date that I know of, outside of possibly the lowRISC GSoC effort which I should check up on), only ARMv6 and v7 (which, I'll grant, also has to do with academic efforts to verify ARM in general). If you're that serious, seL4 serious, there's a good argument you should eschew Intel and start with some of the less chaotic ARM systems (i.e. not so much kitchen sink ones from the mobile world like the Broadcom chips the Raspberry Pies use). I take her as trying something rather different, the pragmatic approach of getting the best security possible out of our existing infrastructure, hence the use of x86, Xen, Fedora, etc., based in part on her experience when figuratively putting on a black hat. She's discovered a lot of exploits, hasn't she? (lowRISC also includes an effort with tags to make our existing C/C++ infrastructure safer). And without the prospect of a "secure" web browser aside from perhaps Servo someday, maybe....

nickpsecurity 11y ago
re firmware. It's true and orthogonal. Just as the DARPA project is doing, you use the best tech and method for each part of the job. The recommendations I gave her were for kernel up mainly for isolation. Drivers should be written robustly, synthesized, use trusted hardware, and/or mediate the hardware. re x86 vs ARM. It's true. Remember, though, that I didn't tell her to use seL4: just re-use work in L4 family projects like Nizza or OKL4 to get their security + performance benefits. The idea is you get a good start, make sure you can swap in/out components, and someone puts a verified one in place later. This is exactly the approach GenodeOS team took along with using many things I recommended in other post. Only gripe with them is they're doing too many things at once rather than focusing on getting at least one in best, production mode. That said, I agree with keeping off x86. I've recommended ARM, MIPS, SPARC, and RISC-V for future work. SPARC is nice due to open specs, no licensing past $99 trademark, and GPL hardware available. RISC-V people building all kinds of things. SPARC and MIPS have already been modified for enhanced security by academics several times over. So, SPARC (esp Gaisler), MIPS, and RISC-V are my recommendations in that order putting usability/extensibility over pricing. re pragmatic approach. Sure, I agree with that part. The resulting approach combined things top on the CVE list onto a platform she published exploits for and criticized in other posts. Gotta wonder how far its security would go. ;) She was a good bug-hunter, though, when she understood how something worked. Didn't seem to understand strong, security engineering so I predicted QubesOS would be good for vanilla malware w/ some containment of advanced attacks. Basically, a nice improvement on and replacement for Compartmented Mode Workstations's. The TCB size and implementation are just too complex for high security. re secure browsers. For full-featured experience, you'll need either virtualization or my old KVM-switch method. More research in the former has only made the latter look more trustworthy over time haha. Anyway, I referenced a number of more-secure browser architectures in the comment below. Enjoy seeing variations of The Right Thing in action. :) Now, if only mainstream would put effort into improving those instead of the monolithic ones. Chrome was at least an OP-inspired attempt. Due credit for them. https://news.ycombinator.com/item?id=9969961 https://news.ycombinator.com/item?id=9969961
- hga 11y ago
  My complaint about browsers is less about architecture (I mean, when using multiple processes is a vast improvement of the state of the art on the ground...), than what I gather is the vast amount of work required to get today's standard web pages to render well. There are, what, 4 state of the art rendering engines? (Two Microsoft, which has lots of money to spend, Webkit (now Apple and Google forked??), and Firefox's.) And there's much, much more to the security story for browsers. Then again, this is not a topic I've looked closely at, maybe there's more hope than I think, and continuing financial losses might prompt more rigor, although I don't recall the worse ones being purely browser exploits.
  - nickpsecurity 11y ago
    Oh I see what you mean. Yes, it's become an oligopoly with a huge barrier to entry. The typical solution is to separate all these components with safer implementations, isolation, and/or interfaces. What I referenced do those. If you want to solve it directly, you have to make the code trustworthy. That's... another matter entirely. There are a few approaches to this. One is to apply compiler transformations that make the code memory-safe along with interface checks at sys-call level. An example is Softbound+CETS albeit I'm not saying it's worked on a browser. Several have compiled C programs to run in a Java or other managed environment. Another example is a lighter security approach called control flow integrity where you just try to block code injections with data or pointer protection. Control Pointer Integrity is most interesting right now with several HW accelerators. The next approach is using software or hardware obfuscation to make it where the incoming attack (a) wouldn't hit its target or (b) would be mangled/detected by crypto work at HW level. This has been ported to Linux. CheriBSD is another, DARPA-funded effort that uses custom hardware (CHERI) and tooling to let you incrementally protect legacy stuff with capabilities. So, quite a few ways to deal with it. As usual, the problem is that our machines and languages make it easy to cause a vulnerability with common, fundamental operations. Making those operations fundamentally safe[r] knocks out a lot of that risk. Traditional techniques, like separation kernels, can try to isolate and detect the rest. That's my take on how to deal with being stuck with codebases like Webkit. Still work but feels less impossible.
pakled_engineer 11y ago
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-...

by hga 11y ago

nickpsecurity 11y ago

re firmware. It's true and orthogonal. Just as the DARPA project is doing, you use the best tech and method for each part of the job. The recommendations I gave her were for kernel up mainly for isolation. Drivers should be written robustly, synthesized, use trusted hardware, and/or mediate the hardware. re x86 vs ARM. It's true. Remember, though, that I didn't tell her to use seL4: just re-use work in L4 family projects like Nizza or OKL4 to get their security + performance benefits. The idea is you get a good start, make sure you can swap in/out components, and someone puts a verified one in place later. This is exactly the approach GenodeOS team took along with using many things I recommended in other post. Only gripe with them is they're doing too many things at once rather than focusing on getting at least one in best, production mode. That said, I agree with keeping off x86. I've recommended ARM, MIPS, SPARC, and RISC-V for future work. SPARC is nice due to open specs, no licensing past $99 trademark, and GPL hardware available. RISC-V people building all kinds of things. SPARC and MIPS have already been modified for enhanced security by academics several times over. So, SPARC (esp Gaisler), MIPS, and RISC-V are my recommendations in that order putting usability/extensibility over pricing. re pragmatic approach. Sure, I agree with that part. The resulting approach combined things top on the CVE list onto a platform she published exploits for and criticized in other posts. Gotta wonder how far its security would go. ;) She was a good bug-hunter, though, when she understood how something worked. Didn't seem to understand strong, security engineering so I predicted QubesOS would be good for vanilla malware w/ some containment of advanced attacks. Basically, a nice improvement on and replacement for Compartmented Mode Workstations's. The TCB size and implementation are just too complex for high security. re secure browsers. For full-featured experience, you'll need either virtualization or my old KVM-switch method. More research in the former has only made the latter look more trustworthy over time haha. Anyway, I referenced a number of more-secure browser architectures in the comment below. Enjoy seeing variations of The Right Thing in action. :) Now, if only mainstream would put effort into improving those instead of the monolithic ones. Chrome was at least an OP-inspired attempt. Due credit for them. https://news.ycombinator.com/item?id=9969961 https://news.ycombinator.com/item?id=9969961

hga 11y ago
My complaint about browsers is less about architecture (I mean, when using multiple processes is a vast improvement of the state of the art on the ground...), than what I gather is the vast amount of work required to get today's standard web pages to render well. There are, what, 4 state of the art rendering engines? (Two Microsoft, which has lots of money to spend, Webkit (now Apple and Google forked??), and Firefox's.) And there's much, much more to the security story for browsers. Then again, this is not a topic I've looked closely at, maybe there's more hope than I think, and continuing financial losses might prompt more rigor, although I don't recall the worse ones being purely browser exploits.
- nickpsecurity 11y ago
  Oh I see what you mean. Yes, it's become an oligopoly with a huge barrier to entry. The typical solution is to separate all these components with safer implementations, isolation, and/or interfaces. What I referenced do those. If you want to solve it directly, you have to make the code trustworthy. That's... another matter entirely. There are a few approaches to this. One is to apply compiler transformations that make the code memory-safe along with interface checks at sys-call level. An example is Softbound+CETS albeit I'm not saying it's worked on a browser. Several have compiled C programs to run in a Java or other managed environment. Another example is a lighter security approach called control flow integrity where you just try to block code injections with data or pointer protection. Control Pointer Integrity is most interesting right now with several HW accelerators. The next approach is using software or hardware obfuscation to make it where the incoming attack (a) wouldn't hit its target or (b) would be mangled/detected by crypto work at HW level. This has been ported to Linux. CheriBSD is another, DARPA-funded effort that uses custom hardware (CHERI) and tooling to let you incrementally protect legacy stuff with capabilities. So, quite a few ways to deal with it. As usual, the problem is that our machines and languages make it easy to cause a vulnerability with common, fundamental operations. Making those operations fundamentally safe[r] knocks out a lot of that risk. Traditional techniques, like separation kernels, can try to isolate and detect the rest. That's my take on how to deal with being stuck with codebases like Webkit. Still work but feels less impossible.

pakled_engineer 11y ago

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-...