5 ms·

nickpsecurity's reply is dead because he used the m-word.

nickpsecurity 11y ago
Huh? If you mean mainstream, there's certainly a mainstreaming effect in INFOSEC. It sometimes promotes things that stop hackers. Mostly just tactical stuff that's bypassed later or thing inferior to more obscure stuff that worked with better design/architecture. Example (paraphrased): "Dude, what's with all this separation kernel, decomposition, and interface protection nonsense? Nobody does that shit. Real hackers use a monolithic kernel with several MB of privileged code, no POLA, implementation fully in C, and some security features/apps on top of that. Do that and you're good." Several hundred CVE's later related to the above... yeah, some things aren't popular for their actual security.
tptacek 11y ago
What's the "m-word"? (I certainly didn't flag that comment).
- wglb 11y ago
  Find It's mostly mental and possibly the m-word is what follows this. I didn't flag this. But I do object to the suggestion that Thomas learn to think like an attacker. I am pretty sure that he does this as well as anyone. But this approach seems dismissive of a lot of work that addresses the real world, whereas the approach advocated in this post and other posts reminds me strongly of back when I believed that it was worthwhile to prove programs correct. Very few outfits can do this, and perhaps most rails programmers and Java programmers don't expect to be able to prove their programs correct. It seems to boil down to "We need to build programs in a fundamentally different way". With that sentiment I agree, but I am not seeing much in the way of actionable advice in your many posts here.
  - nickpsecurity 11y ago
    I didn't mean it as a cutdown on him: more a reminder to do what he does professionally. Security evaluators and hackers alike often get into networks with attacks on gateways and firewalls setup poorly. It's on everyone's checklist. A Netgear router works similarly, albeit less features, so I tried to get him to make the mental connection between a weakness he'd readily recognize in one area and one that applies in another area. I could see how it might come off differently though... Far as my post, it's part of my larger theme that people aren't apply what the field learns. You don't need to be Paul Karger or Dan Bernstein to do better than what we see. The safety critical industry responded to C's problems by subsets, reviews, static analysis tools, and dynamic testing systems. Quality went way up. We've seen the same in academia with free prototypes of many and further work to straight-up knock out the issues (Ur/Web & Softbound are recents). No uptake. There were system languages such as Ada that, by default, eliminated many of the common problems. Little to no uptake. There were concerns about a steady stream of compiler problems. They could improve/use the model with constant problems or the one (CompCert + ML implementation) with the solution. No uptake. Safety- and security-critical work showed microkernels greatly improved security by eliminating much kernel code, isolating others behind mediated interfaces, and allowing recovery in simple failure modes (eg drivers). Most ignored it and Linus deplored it but at least GenodeOS took it up with an active community. Rare exception. There's a recurring pattern in INFOSEC where proven solutions to problems are either forgotten or ignored. I fight that trend in my posts where I identify known issues or promote alternatives (design or implementation) that were previously field-proven. I also give credit to those that make solid attempts to do it better often with results: qmail, GenodeOS, Minix 3, INTEGRITY RTOS, Secure64's SourceT OS for DNS systems, Sentinel's HYDRA PCI firewall, CheriBSD, Cornell's SWIFT, Praxis's Correct by Construction w/ SPARK Ada, Python with Cleanroom methodology, and so on. There's lots of amateurs and pro's alike doing stronger methods in academia and commercial sector. It doesn't have to be a full EAL7 system or even that formal. Yet, if a tool exists that immunizes against big problems, why aren't we using or breaking/improving it? Why do I see another presentation at DEFCON breaking a vanilla bug or a new tech that delivers a tiny fraction of that protection? Why are security-critical apps not leveraging free tech to improve them and decomposition/least-privilege at the least? I'm not asking much. Just using what exists, what's shown to deliver most bang for buck, what's free, and what takes only a small portion of the labor. Do that from language to architecture to protocols. Baseline will be so much better. I noted in both comments I was grateful to the fragment of INFOSEC that does this. Yet, most of the field just reinforces the status quo while occasionally calling out or bandaiding the preventable problems it introduces. Many get a rush out of these attacks they create they don't get out of building tools that create immunity to attack classes. Hence, that other m-word as a metaphor for what they're doing. In the end, nothing changes with that approach but at least they're having fun. ;)
    - tptacek 11y ago
      Frankly: this EAL7 stuff has basically no applicability to the real world. People get EAL6-EAL7-EAL6+ certification for things where they're (a) willing to spend 2x the implementation dollars just for the privilege of selling a product (or part) to a tiny subset of all GSA buyers and (b) things that are actually straightforward to specify fully. Look at the list of EAL6+ products. They're all things like smartcard chips: things with very limited interactions and very well-defined functionality. Real-world software simply isn't like that. Nobody is going to EAL6+ a web browser, or a PDF reader, or even a desktop or server OS kernel (the fact that the best known example of a formally verified OS kernel is L4 should tell you something). You bring Common Criteria certification up on a lot of different threads about security. The industry has literally nothing to learn about security from Common Criteria. Regardless of what you may think about that sentiment: this has very little at all to do with the market for zero-day vulnerabilities.
      - nickpsecurity 11y ago
        You're selective again. I named all kinds of existing products and solutions that do a better job at solving real-world problems in a safe/secure way than mainstream alternatives. You ignored that to focus on the EAL7 thing, claimed high assurance hasn't done anything beyond smart cards (lol), and kind of stopped there. Ok, let's get back to foundations since you didn't read my framework. The methods are more important than the certs themselves. The old stuff (Orange Book) called for strong specifications of requirements, design, each thing a system did, failure modes and so on. The implementation had to be done in safest known way, be modular, have well-defined interfaces with input checks, and provably correspond to that spec. Testing, covert channel analysis, configuration management, pentesting, trusted distribution... many requirements on top of it. Later, static analysis, rigorously evaluated code generators, and so on added to the mix. Early projects, which you claim have no practical value, built secure email, VPN's, databases, object storage, thin clients, web servers, logistics systems, and so on. The empirical assessments (eg "lessons learned from...") showed the various methods caught all kinds of problems albeit with different payoff rates in different situations. Following NSA's finishing off high assurance market, the mainstream stuff and all the hacks one could desire prevaled for years. Eventually, DOD/NSA demanded high assurance again with their separation kernel concept which academia and private companies built. Academia had also been doing strong verification, from math to clever testing, for all kinds of things up to this moment. A common theme from old days repeated in that they focused EAL6-7 type of effort on critical mechanisms that could be easily leveraged for safety/security benefit since we couldn't do everything like that (good guess on your part). The mechanism could be isolation, analysis, transformation, and so on. More flexible the better. MILS and Nizza architectures split systems between isolated apps and VM's with eg Linux running on top of strong kernels (eg EAL6+). Results of some did well against NSA pentesters. For others, tiny amount of trusted code by itself shows it could never have the number of problems of... whatever you wrote that post with. Others focused on compilers, language type systems, processor enhancements, code generators, DSL's, and so on. Are you saying a fully-documented, predictable, rigorously tested C compiler isn't practical? Or the finished WCET analysis during compilation or pluggable optimizations other groups are working on now? Meanwhile, there were plenty of medium assurance offerings. Software such as qmail, Secure64, and HYDRA used architecture that greatly reduced risk. GenodeOS took it quite further by making their architecture plug and play with your choice of assured components. Tools such as Astree and SPARK knocked out all kinds of errors in embedded systems plus components of larger systems. Ada, the ML's, Eiffel (esp Design by Contract & Scoop concurrency) did the same in regular ones. Cornell's SWIFT, Ur/Web, Opa, and SPECTRE all made web applications immune to certain types of attacks in different ways without much effort by developers. We saw the formation of all kinds of secure storage, networking, backup, synchronization, virtualization, recovery, etc in academia with a subset rigorously analyzed and some also integrated with production software in prototypes. We saw hypervisor and paravirtualization work that made the OS itself untrusted. We saw CPU designs such as SAFE, CHERI, DIFT stuff, and those leveraging crypto beat vast majority of attacks down to CPU level with one proving properties down to the gates. Tons and tons of work. Best stuff being things where effort is expended once to pay off many times. Tagged/capability CPU's, better architectures for OS's, compilers that automatically enforce strong safety/security, static analysis tools that prove absence of common bugs, type systems for high level languages easy to code in... the list goes on. These are all very practical with many used in real projects or products. The thing they all have in common is they (a) believably do their job and (b) result in drastic reduction of risk and attack surface at every layer of our systems. Widespread adoption and investment in such methods that work rather than mainstream one's that don't will have a direct impact on "the market for zero-day vulnerabilities." Given pervasive deployment, that market would mostly disappear outside subversions and interdictions. And I encourage naysayers such as yourself to put effort into such strong methods to get those that aren't at mainstream readiness to mainstream readiness. Your own mind would be very beneficial to academics designing secure filesystems and messaging systems that rely on necessarily complex protocols and crypto. You might knock out problems they didn't see. There might be many other people on HN with similar things to offer and great results to show for it in future. It's why I respond to these misleading comments of yours in detail. One day, someone reading them might be inspired to do better than any project I referenced or simply put effort into those proven to already get plenty results. It is worth it even if the troll or failure-to-get-it rate of those reading it is 99%. That 1% might make one of these real and everything I cited started with one of them that decided to build on proven theory and practice in contrast to mainstream. So, I'll stay at it even if you think highly secure processors, kernels, compilers, type systems, web apps, databases, middleware, and so on has... "no applicibility to the real world." Not the majority of it, I'll agree. They prefer their IT assets served to their opponents on a silver platter. I write for the others.
  - ectoplasm 11y ago
    > Find It's mostly mental and possibly the m-word is what follows this. Yes this, pretty sure it kills any comment immediately.
    - nickpsecurity 11y ago
      I'll try to remember that. Thanks for the tip to the both of you.

Huh? If you mean mainstream, there's certainly a mainstreaming effect in INFOSEC. It sometimes promotes things that stop hackers. Mostly just tactical stuff that's bypassed later or thing inferior to more obscure stuff that worked with better design/architecture. Example (paraphrased): "Dude, what's with all this separation kernel, decomposition, and interface protection nonsense? Nobody does that shit. Real hackers use a monolithic kernel with several MB of privileged code, no POLA, implementation fully in C, and some security features/apps on top of that. Do that and you're good." Several hundred CVE's later related to the above... yeah, some things aren't popular for their actual security.

tptacek 11y ago

What's the "m-word"? (I certainly didn't flag that comment).

wglb 11y ago
Find It's mostly mental and possibly the m-word is what follows this. I didn't flag this. But I do object to the suggestion that Thomas learn to think like an attacker. I am pretty sure that he does this as well as anyone. But this approach seems dismissive of a lot of work that addresses the real world, whereas the approach advocated in this post and other posts reminds me strongly of back when I believed that it was worthwhile to prove programs correct. Very few outfits can do this, and perhaps most rails programmers and Java programmers don't expect to be able to prove their programs correct. It seems to boil down to "We need to build programs in a fundamentally different way". With that sentiment I agree, but I am not seeing much in the way of actionable advice in your many posts here.
- nickpsecurity 11y ago
  I didn't mean it as a cutdown on him: more a reminder to do what he does professionally. Security evaluators and hackers alike often get into networks with attacks on gateways and firewalls setup poorly. It's on everyone's checklist. A Netgear router works similarly, albeit less features, so I tried to get him to make the mental connection between a weakness he'd readily recognize in one area and one that applies in another area. I could see how it might come off differently though... Far as my post, it's part of my larger theme that people aren't apply what the field learns. You don't need to be Paul Karger or Dan Bernstein to do better than what we see. The safety critical industry responded to C's problems by subsets, reviews, static analysis tools, and dynamic testing systems. Quality went way up. We've seen the same in academia with free prototypes of many and further work to straight-up knock out the issues (Ur/Web & Softbound are recents). No uptake. There were system languages such as Ada that, by default, eliminated many of the common problems. Little to no uptake. There were concerns about a steady stream of compiler problems. They could improve/use the model with constant problems or the one (CompCert + ML implementation) with the solution. No uptake. Safety- and security-critical work showed microkernels greatly improved security by eliminating much kernel code, isolating others behind mediated interfaces, and allowing recovery in simple failure modes (eg drivers). Most ignored it and Linus deplored it but at least GenodeOS took it up with an active community. Rare exception. There's a recurring pattern in INFOSEC where proven solutions to problems are either forgotten or ignored. I fight that trend in my posts where I identify known issues or promote alternatives (design or implementation) that were previously field-proven. I also give credit to those that make solid attempts to do it better often with results: qmail, GenodeOS, Minix 3, INTEGRITY RTOS, Secure64's SourceT OS for DNS systems, Sentinel's HYDRA PCI firewall, CheriBSD, Cornell's SWIFT, Praxis's Correct by Construction w/ SPARK Ada, Python with Cleanroom methodology, and so on. There's lots of amateurs and pro's alike doing stronger methods in academia and commercial sector. It doesn't have to be a full EAL7 system or even that formal. Yet, if a tool exists that immunizes against big problems, why aren't we using or breaking/improving it? Why do I see another presentation at DEFCON breaking a vanilla bug or a new tech that delivers a tiny fraction of that protection? Why are security-critical apps not leveraging free tech to improve them and decomposition/least-privilege at the least? I'm not asking much. Just using what exists, what's shown to deliver most bang for buck, what's free, and what takes only a small portion of the labor. Do that from language to architecture to protocols. Baseline will be so much better. I noted in both comments I was grateful to the fragment of INFOSEC that does this. Yet, most of the field just reinforces the status quo while occasionally calling out or bandaiding the preventable problems it introduces. Many get a rush out of these attacks they create they don't get out of building tools that create immunity to attack classes. Hence, that other m-word as a metaphor for what they're doing. In the end, nothing changes with that approach but at least they're having fun. ;)
  - tptacek 11y ago
    Frankly: this EAL7 stuff has basically no applicability to the real world. People get EAL6-EAL7-EAL6+ certification for things where they're (a) willing to spend 2x the implementation dollars just for the privilege of selling a product (or part) to a tiny subset of all GSA buyers and (b) things that are actually straightforward to specify fully. Look at the list of EAL6+ products. They're all things like smartcard chips: things with very limited interactions and very well-defined functionality. Real-world software simply isn't like that. Nobody is going to EAL6+ a web browser, or a PDF reader, or even a desktop or server OS kernel (the fact that the best known example of a formally verified OS kernel is L4 should tell you something). You bring Common Criteria certification up on a lot of different threads about security. The industry has literally nothing to learn about security from Common Criteria. Regardless of what you may think about that sentiment: this has very little at all to do with the market for zero-day vulnerabilities.
    - nickpsecurity 11y ago
      You're selective again. I named all kinds of existing products and solutions that do a better job at solving real-world problems in a safe/secure way than mainstream alternatives. You ignored that to focus on the EAL7 thing, claimed high assurance hasn't done anything beyond smart cards (lol), and kind of stopped there. Ok, let's get back to foundations since you didn't read my framework. The methods are more important than the certs themselves. The old stuff (Orange Book) called for strong specifications of requirements, design, each thing a system did, failure modes and so on. The implementation had to be done in safest known way, be modular, have well-defined interfaces with input checks, and provably correspond to that spec. Testing, covert channel analysis, configuration management, pentesting, trusted distribution... many requirements on top of it. Later, static analysis, rigorously evaluated code generators, and so on added to the mix. Early projects, which you claim have no practical value, built secure email, VPN's, databases, object storage, thin clients, web servers, logistics systems, and so on. The empirical assessments (eg "lessons learned from...") showed the various methods caught all kinds of problems albeit with different payoff rates in different situations. Following NSA's finishing off high assurance market, the mainstream stuff and all the hacks one could desire prevaled for years. Eventually, DOD/NSA demanded high assurance again with their separation kernel concept which academia and private companies built. Academia had also been doing strong verification, from math to clever testing, for all kinds of things up to this moment. A common theme from old days repeated in that they focused EAL6-7 type of effort on critical mechanisms that could be easily leveraged for safety/security benefit since we couldn't do everything like that (good guess on your part). The mechanism could be isolation, analysis, transformation, and so on. More flexible the better. MILS and Nizza architectures split systems between isolated apps and VM's with eg Linux running on top of strong kernels (eg EAL6+). Results of some did well against NSA pentesters. For others, tiny amount of trusted code by itself shows it could never have the number of problems of... whatever you wrote that post with. Others focused on compilers, language type systems, processor enhancements, code generators, DSL's, and so on. Are you saying a fully-documented, predictable, rigorously tested C compiler isn't practical? Or the finished WCET analysis during compilation or pluggable optimizations other groups are working on now? Meanwhile, there were plenty of medium assurance offerings. Software such as qmail, Secure64, and HYDRA used architecture that greatly reduced risk. GenodeOS took it quite further by making their architecture plug and play with your choice of assured components. Tools such as Astree and SPARK knocked out all kinds of errors in embedded systems plus components of larger systems. Ada, the ML's, Eiffel (esp Design by Contract & Scoop concurrency) did the same in regular ones. Cornell's SWIFT, Ur/Web, Opa, and SPECTRE all made web applications immune to certain types of attacks in different ways without much effort by developers. We saw the formation of all kinds of secure storage, networking, backup, synchronization, virtualization, recovery, etc in academia with a subset rigorously analyzed and some also integrated with production software in prototypes. We saw hypervisor and paravirtualization work that made the OS itself untrusted. We saw CPU designs such as SAFE, CHERI, DIFT stuff, and those leveraging crypto beat vast majority of attacks down to CPU level with one proving properties down to the gates. Tons and tons of work. Best stuff being things where effort is expended once to pay off many times. Tagged/capability CPU's, better architectures for OS's, compilers that automatically enforce strong safety/security, static analysis tools that prove absence of common bugs, type systems for high level languages easy to code in... the list goes on. These are all very practical with many used in real projects or products. The thing they all have in common is they (a) believably do their job and (b) result in drastic reduction of risk and attack surface at every layer of our systems. Widespread adoption and investment in such methods that work rather than mainstream one's that don't will have a direct impact on "the market for zero-day vulnerabilities." Given pervasive deployment, that market would mostly disappear outside subversions and interdictions. And I encourage naysayers such as yourself to put effort into such strong methods to get those that aren't at mainstream readiness to mainstream readiness. Your own mind would be very beneficial to academics designing secure filesystems and messaging systems that rely on necessarily complex protocols and crypto. You might knock out problems they didn't see. There might be many other people on HN with similar things to offer and great results to show for it in future. It's why I respond to these misleading comments of yours in detail. One day, someone reading them might be inspired to do better than any project I referenced or simply put effort into those proven to already get plenty results. It is worth it even if the troll or failure-to-get-it rate of those reading it is 99%. That 1% might make one of these real and everything I cited started with one of them that decided to build on proven theory and practice in contrast to mainstream. So, I'll stay at it even if you think highly secure processors, kernels, compilers, type systems, web apps, databases, middleware, and so on has... "no applicibility to the real world." Not the majority of it, I'll agree. They prefer their IT assets served to their opponents on a silver platter. I write for the others.
- ectoplasm 11y ago
  > Find It's mostly mental and possibly the m-word is what follows this. Yes this, pretty sure it kills any comment immediately.
  - nickpsecurity 11y ago
    I'll try to remember that. Thanks for the tip to the both of you.