3 ms·

I already countered him on microarchitectural covert channels. Goes back further to VAX Security Kernel (1992) being designed to certify to A1-class which manda

I already countered him on microarchitectural covert channels. Goes back further to VAX Security Kernel (1992) being designed to certify to A1-class which mandated covert-channel analysis that regular, "secure coders" didn't do. INFOSEC pioneers had already found them in software and hardware like disks. A person on that project reported them for cache timing as well. Aside from the Trojan model, they also described them back then as inherent design flaws where shared resources leak details about one computation to another. In other words, cpercival's model. They talked about Trojan model mostly because solving the threat of superset model, subversion, solved other one as side effect. Knocking out all backdoors and leaks was what culture of the time highlighted the most. I pointed it out plus some follow up commentary here: https://lobste.rs/s/tj55ox/counterpoint_intel_weaknesses_known https://lobste.rs/s/tj55ox/counterpoint_intel_weaknesses_kno... I didn't respond to the later nonsense dismissals on HN and elsewhere about the Intel CPU Security submission since I had surgery shortly after that on an impacted tooth. Didn't want to be online all drugged up talking about these things. ;) Suffice it to say, high-assurance security had already found piles of risk areas for both penetration and side channels in Intel CPU's with some attempts at mitigation (including avoid Intel CPU's) by the mid-1990's. They encouraged Intel, purchasers, and security community to deal with it as part of routine work in improving security. As usual, the mainstream security community just ignored everything they said when they bumped into each other. It's not like high-security folks stopped trying to tell them about prior successes and problems: http://www.cse.psu.edu/~trj1/papers/ieee-sp-vaxvmm.pdf http://www.cse.psu.edu/~trj1/papers/ieee-sp-vaxvmm.pdf Then, a bright researcher independently discovered the side channels in caches later. They started reacting to that claim. They found some similar issues in other stuff looking narrowly. Now, we have another clever attack that started with a shared resource as would've been identified in the 1992 methodology that got stretched in really creative ways. It was still same root cause they ignored or justified for things like lowest price/performance versus alternatives doing it securely. Or just physical separation of different security domains which highest-security setups stuck with grudgingly. My prediction in one of the Lobsters comments was that piles of comments would happen about this that didn't involve actually solving it (social gratification), more people would similarly write articles boasting their understanding to generate extra rep since talking problems in is rewarded in mainstream INFOSEC more than preventing/solving them, a few mitigations would show up that were narrowly-focused on just this new kind of problem (like happened with caches), they'd still ignore prior work in high-assurance like Kemmerer or Wray's analyses that found similar problems 20+ years before analyzing whole system, they'd mostly ignore the new work on information-flow analysis (some in link below), and we'd at best get some time until the next problem that could've been prevented by 1990's or recent methods since that's how mainstream security industry and culture works. They're right on track since that's about all I saw while in recovery for a week. Endless articles using the buzzwords to their advantage plus people who don't know we could've beaten this in the 1990's because security professionals in industry suppress that knowledge for some reason. That needs to stop. At least they're rediscovering 60's-90's knowledge at an accelerated rate now. Work on Information Flow Security in Hardware https://pastebin.com/ajqxDJ3J https://pastebin.com/ajqxDJ3J

tptacek 9y ago
Your argument here being that a mysterious group of old-school TCSEC people understood microarchitectural side channel attacks years ago, so much so that we could have eliminated them in the 1990s, but chose to say nothing about them --- until now. My rebuttal would be that if these people had discovered cache timing attacks (and not covert channel issues that weren't directly relevant to the x86 server threat model, but are six-degrees-of-Kevin-Bacon away from cache timing), they would have discovered cache timing attacks. It's a little like those people who keep saying that if we only had length-delimited strings instead of ASCIIZ, we'd have no memory corruption.
- nickpsecurity 9y ago
  "Your argument here being that a mysterious group of old-school TCSEC people understood microarchitectural side channel attacks years ago, so much so that we could have eliminated them in the 1990s, but chose to say nothing about them --- until now." There you go misrepresenting and slandering folks again. What I've said since I joined HN is that a group of people in military, private companies, and academia did the following: invented INFOSEC, did assessments/pentests, and tried to build clean-slate systems that were secure; regularly published that stuff in security publications and/or conferences [1][2]; built products with those methods [3][4][5]; put it in computer security texts to teach next generation [6]; led others to do the same [7][8][9]. This large group of people doing tens of millions of dollars of research, development, education, and outreach over 40-50 year period was anything but a "mysterious group." They were a group you and a lot of other people were ignoring, dismissing, mischaracterizing, and so on. That's an entirely, different thing that says more about you and others that ignored them than the people working hard to secure our systems publishing how to do it for everyone's benefit for decades on end. I find it interesting that many in INFOSEC ignore or trash talk their pioneers so much. These people invented the field, made the landmark contributions, and addressed many fundamental problems from early 60's to early 90's. Mainstream INFOSEC and hacker culture seems to start giving credit from about 90's on for just specific kinds of attack and defense publications in specific places. A few, rare exceptions exist but it's the general rule. That's like aeronautical engineers not recognizing Wright Brothers, computer scientists ignoring Turing, electrical engineers ignoring work in boolean logic, mathematicians ignoring algebra/calculus, and so on. While ignoring that, they claim to be concerned about the same things wanting solutions to those problems. Then, when pioneers' solutions are shown to them, they keep insisting there were no pioneers, no solutions, or claim they were ineffective without reading their work. Then, they give credit to some like themselves for re-solving a tiny part of the same problems. It's a disgraceful thing to do with no rational or moral justification, esp as computer security suffers for it. So, I'll continue calling it out for as long as I see any of you do it. "Mysterious group..." Perfect example... "My rebuttal would be that if these people had discovered cache timing attacks (and not covert channel issues that weren't directly relevant to the x86 server threat model, but are six-degrees-of-Kevin-Bacon away from cache timing), they would have discovered cache timing attacks. " My argument is security assessment of a major project contained a covert channel analysis, that they reported [10] the cache leaked secrets via a timing channel, that they kept finding more shared resources throughout hardware, and those needed to be mitigated. The predecessors I mentioned above had invented covert-channel, analysis techniques to spot leaks. They used them. Previous work found them in software and hardware, but not CPU's. To make it extra clear, the work I cited found (adding emphasis) a "timing channel" using the "CPU cache" that could "leak secrets" across security boundaries. Later in 2005 or so, Colin notices a "timing channel" in the "CPU cache" that can "leak secrets" across security boundaries. That's the same thing. Timing channels via CPU cache. Even models the same way in a security lattice. Starting in 1992, it was published, discussed by members of the field, put in a patent by one, and that noted "cache-related" channels as a general problem to always look for. The field then knew that caches leaked secrets unless they were designed not to. We assume that about all of them per TCSEC rules until standard, mandatory analysis shows they don't have the weakness. Intel contains a CPU cache that's not designed for security, has code using secrets, and might run hostile code. Intel's cache therefore can or does leak secrets to hostile code. The end. They didn't stop there. Another group in security field analyzed Intel CPU's [11] in mid-1990's. It identified numerous risk areas for both penetration and covert channels. It includes a whole section, "Cache and TLB Timing Channels," that warns of their existence referencing Wray's 1991 work. Throughout the paper, it argued the x86 CPU's had numerous security weaknesses with some obvious attacks and more coming. With all that said, the status quo was to not use x86 for secure systems unless absolutely forced to by the market because they were insecure. Those that did have to build on x86 attempted timing channel mitigations but they didn't work. It has to be fixed at the root cause. So the very work you dismissed here on HN had the x86 side channels in caches you just asked me for. I wonder if you even read it. While folks like you ignored that research, those paying attention freaked the hell out. Caches are everywhere. Turning them off made performance horrible. After software mitigations failed, the solution was fall-back to separate CPU's for trusted and untrusted respectively. Many in military stayed with fully-separate hardware. After it became popular again in 2000's, partitioning and masking caches were designed by academics hoping to stop the leaks. Big vendors didn't use them. Mainstream security sector ignored them so no crowd-sourcing was going to happen. Now, we have The Big One hitting that starts with cache problems warned about in general by 1992 with x86-specific warnings by 1995. And well-known members of the security community of 2018 are still pretending that work didn't happen. Fortunately, there's CompSci folks that stay building on the prior work you thought didn't exist with recent attempts at cache protection having a lot better penalties than it did in the 1990's. Maybe someone will build it into a RISC-V or something later if we're lucky. In the meantime, you might want to study the prior methods that seemed to find a lot of problems and solutions you later talked about or were looking for. You can bet those lines of research have found and solved even more problems than that. It's how I keep citing old work when people want solutions to "current" problems. I'm willing to learn about problems and solutions from anyone in any style of INFOSEC if it will protect our systems. Try reading pioneers' work instead of dismissing or smearing it sometime. Who knows: you might learn how to solve another root problem with some clever approach, theirs or yours building on it, that I'll be citing in the future. I hope so since we can use all the eyes we can get. [1] http://seclab.cs.ucdavis.edu/projects/history/seminal.html http://seclab.cs.ucdavis.edu/projects/history/seminal.html [2] http://ieeexplore.ieee.org/document/5504784/?arnumber=5504784 http://ieeexplore.ieee.org/document/5504784/?arnumber=550478... [3] https://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm https://www.smecc.org/The%20Architecture%20%20of%20the%20Bur... [4] http://cap-lore.com/CapTheory/upenn/ http://cap-lore.com/CapTheory/upenn/ [5] http://www.sigada.org/conf/sigada2000/private/SIGAda2000-CDROM/SIGAda2000-Proceedings/Chapman-Presentation.pdf http://www.sigada.org/conf/sigada2000/private/SIGAda2000-CDR... [6] http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf [7] https://en.wikipedia.org/wiki/Cyclone_%28programming_language%29 https://en.wikipedia.org/wiki/Cyclone_%28programming_languag... [8] https://www.usenix.org/legacy/events/sec04/tech/wips/wips/04-hohmuth-nizza.pdf https://www.usenix.org/legacy/events/sec04/tech/wips/wips/04... [9] https://vtechworks.lib.vt.edu/bitstream/handle/10919/29244/edmison_joshua_dissertation.pdf?sequence=1&isAllowed=y https://vtechworks.lib.vt.edu/bitstream/handle/10919/29244/e... [10] https://www.google.ch/patents/US5574912 https://www.google.ch/patents/US5574912 [11] https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653...

tptacek 9y ago

Your argument here being that a mysterious group of old-school TCSEC people understood microarchitectural side channel attacks years ago, so much so that we could have eliminated them in the 1990s, but chose to say nothing about them --- until now. My rebuttal would be that if these people had discovered cache timing attacks (and not covert channel issues that weren't directly relevant to the x86 server threat model, but are six-degrees-of-Kevin-Bacon away from cache timing), they would have discovered cache timing attacks. It's a little like those people who keep saying that if we only had length-delimited strings instead of ASCIIZ, we'd have no memory corruption.

nickpsecurity 9y ago
"Your argument here being that a mysterious group of old-school TCSEC people understood microarchitectural side channel attacks years ago, so much so that we could have eliminated them in the 1990s, but chose to say nothing about them --- until now." There you go misrepresenting and slandering folks again. What I've said since I joined HN is that a group of people in military, private companies, and academia did the following: invented INFOSEC, did assessments/pentests, and tried to build clean-slate systems that were secure; regularly published that stuff in security publications and/or conferences [1][2]; built products with those methods [3][4][5]; put it in computer security texts to teach next generation [6]; led others to do the same [7][8][9]. This large group of people doing tens of millions of dollars of research, development, education, and outreach over 40-50 year period was anything but a "mysterious group." They were a group you and a lot of other people were ignoring, dismissing, mischaracterizing, and so on. That's an entirely, different thing that says more about you and others that ignored them than the people working hard to secure our systems publishing how to do it for everyone's benefit for decades on end. I find it interesting that many in INFOSEC ignore or trash talk their pioneers so much. These people invented the field, made the landmark contributions, and addressed many fundamental problems from early 60's to early 90's. Mainstream INFOSEC and hacker culture seems to start giving credit from about 90's on for just specific kinds of attack and defense publications in specific places. A few, rare exceptions exist but it's the general rule. That's like aeronautical engineers not recognizing Wright Brothers, computer scientists ignoring Turing, electrical engineers ignoring work in boolean logic, mathematicians ignoring algebra/calculus, and so on. While ignoring that, they claim to be concerned about the same things wanting solutions to those problems. Then, when pioneers' solutions are shown to them, they keep insisting there were no pioneers, no solutions, or claim they were ineffective without reading their work. Then, they give credit to some like themselves for re-solving a tiny part of the same problems. It's a disgraceful thing to do with no rational or moral justification, esp as computer security suffers for it. So, I'll continue calling it out for as long as I see any of you do it. "Mysterious group..." Perfect example... "My rebuttal would be that if these people had discovered cache timing attacks (and not covert channel issues that weren't directly relevant to the x86 server threat model, but are six-degrees-of-Kevin-Bacon away from cache timing), they would have discovered cache timing attacks. " My argument is security assessment of a major project contained a covert channel analysis, that they reported [10] the cache leaked secrets via a timing channel, that they kept finding more shared resources throughout hardware, and those needed to be mitigated. The predecessors I mentioned above had invented covert-channel, analysis techniques to spot leaks. They used them. Previous work found them in software and hardware, but not CPU's. To make it extra clear, the work I cited found (adding emphasis) a "timing channel" using the "CPU cache" that could "leak secrets" across security boundaries. Later in 2005 or so, Colin notices a "timing channel" in the "CPU cache" that can "leak secrets" across security boundaries. That's the same thing. Timing channels via CPU cache. Even models the same way in a security lattice. Starting in 1992, it was published, discussed by members of the field, put in a patent by one, and that noted "cache-related" channels as a general problem to always look for. The field then knew that caches leaked secrets unless they were designed not to. We assume that about all of them per TCSEC rules until standard, mandatory analysis shows they don't have the weakness. Intel contains a CPU cache that's not designed for security, has code using secrets, and might run hostile code. Intel's cache therefore can or does leak secrets to hostile code. The end. They didn't stop there. Another group in security field analyzed Intel CPU's [11] in mid-1990's. It identified numerous risk areas for both penetration and covert channels. It includes a whole section, "Cache and TLB Timing Channels," that warns of their existence referencing Wray's 1991 work. Throughout the paper, it argued the x86 CPU's had numerous security weaknesses with some obvious attacks and more coming. With all that said, the status quo was to not use x86 for secure systems unless absolutely forced to by the market because they were insecure. Those that did have to build on x86 attempted timing channel mitigations but they didn't work. It has to be fixed at the root cause. So the very work you dismissed here on HN had the x86 side channels in caches you just asked me for. I wonder if you even read it. While folks like you ignored that research, those paying attention freaked the hell out. Caches are everywhere. Turning them off made performance horrible. After software mitigations failed, the solution was fall-back to separate CPU's for trusted and untrusted respectively. Many in military stayed with fully-separate hardware. After it became popular again in 2000's, partitioning and masking caches were designed by academics hoping to stop the leaks. Big vendors didn't use them. Mainstream security sector ignored them so no crowd-sourcing was going to happen. Now, we have The Big One hitting that starts with cache problems warned about in general by 1992 with x86-specific warnings by 1995. And well-known members of the security community of 2018 are still pretending that work didn't happen. Fortunately, there's CompSci folks that stay building on the prior work you thought didn't exist with recent attempts at cache protection having a lot better penalties than it did in the 1990's. Maybe someone will build it into a RISC-V or something later if we're lucky. In the meantime, you might want to study the prior methods that seemed to find a lot of problems and solutions you later talked about or were looking for. You can bet those lines of research have found and solved even more problems than that. It's how I keep citing old work when people want solutions to "current" problems. I'm willing to learn about problems and solutions from anyone in any style of INFOSEC if it will protect our systems. Try reading pioneers' work instead of dismissing or smearing it sometime. Who knows: you might learn how to solve another root problem with some clever approach, theirs or yours building on it, that I'll be citing in the future. I hope so since we can use all the eyes we can get. [1] http://seclab.cs.ucdavis.edu/projects/history/seminal.html http://seclab.cs.ucdavis.edu/projects/history/seminal.html [2] http://ieeexplore.ieee.org/document/5504784/?arnumber=5504784 http://ieeexplore.ieee.org/document/5504784/?arnumber=550478... [3] https://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm https://www.smecc.org/The%20Architecture%20%20of%20the%20Bur... [4] http://cap-lore.com/CapTheory/upenn/ http://cap-lore.com/CapTheory/upenn/ [5] http://www.sigada.org/conf/sigada2000/private/SIGAda2000-CDROM/SIGAda2000-Proceedings/Chapman-Presentation.pdf http://www.sigada.org/conf/sigada2000/private/SIGAda2000-CDR... [6] http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf [7] https://en.wikipedia.org/wiki/Cyclone_%28programming_language%29 https://en.wikipedia.org/wiki/Cyclone_%28programming_languag... [8] https://www.usenix.org/legacy/events/sec04/tech/wips/wips/04-hohmuth-nizza.pdf https://www.usenix.org/legacy/events/sec04/tech/wips/wips/04... [9] https://vtechworks.lib.vt.edu/bitstream/handle/10919/29244/edmison_joshua_dissertation.pdf?sequence=1&isAllowed=y https://vtechworks.lib.vt.edu/bitstream/handle/10919/29244/e... [10] https://www.google.ch/patents/US5574912 https://www.google.ch/patents/US5574912 [11] https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653...