4 ms·

Did you ever think when stuff like this come out there is some guy at the NSA going "Damn it, there goes another one" as they have know about this and been usin

Did you ever think when stuff like this come out there is some guy at the NSA going "Damn it, there goes another one" as they have know about this and been using if for years :)

schoen 9y ago
Unfortunately, mitigating a vulnerability can take a long time and might never happen. When the Imperfect Forward Secrecy paper about weak Diffie-Hellman exchanges came out in 2015, not all systems using the vulnerable groups upgraded immediately, and some systems couldn't be easily upgraded either because they were hard-coded or because they had other software limitations. The IT security situation in many developing countries is also pretty alarming, for example if you look at the prevalence of old unsupported operating systems and browsers in many places. Even thinking about traditional emanations issues, the "van Eck phreaking" attacks were publicly demonstrated years ago https://www.youtube.com/watch?v=ZZ5HS8GWIec https://www.youtube.com/watch?v=ZZ5HS8GWIec but have still not been widely mitigated in practice. Neither have the emanations problems documented by Tromer. https://www.cs.tau.ac.il/~tromer/ https://www.cs.tau.ac.il/~tromer/ And we know that the vendors were notified about Spectre in June of last year and the public was told over a month ago, but pretty much all of us continue to be potentially vulnerable to it in some settings, even more than seven months after vendor notifications! It can be nice for infosec researchers to think that attackers only gain power and capability by knowing secrets, and that if those secrets are exposed the attackers will lose their capabilities, but a number of people have been pointing out that it doesn't always work that way -- or at least there can be quite a long window of vulnerability. (However, exposing secrets is definitely an important prerequisite for denying capabilities to attackers.)
- myrandomcomment 9y ago
  The thing I love about HN is that you say something to be amusing and the engineering types (I am one, so I am making fun of myself) always make some logical argument in response. The best part is 90% of the time you learn something!
- jacquesm 9y ago
  > The IT security situation in many developing countries is also pretty alarming It's pretty alarming in most of the developed countries as well.
  - schoen 9y ago
    Yes, thanks for the correction. I was mostly thinking about the narrow problem of widespread use of very old software, and for example Microsoft's visualization of IE6 market share by country after the company got involved in trying to get people to stop using it. Edit: also, for example, on the Let's Encrypt forums it's somewhat more common for people from developing countries to insist that they have to keep using server software in production that officially went EOL 2 years ago or something. But developing countries absolutely don't have a monopoly on this issue, and I've certainly seen it regularly from users in the United States.
lawlessone 9y ago
I kind of think its so impractically hard that there are easier exploits they could find.
- LargeWu 9y ago
  Right. Seems more practical to just use social engineering or an inside man.
- GCU-Empiricist 9y ago
  If you think that you might want to read the tempest security standard, think about how much extra building compliant facilities cost, and realize that someone who already understood the cost approved the requirement because of a credible threat, or a capability they had and weren't sure if the other team would have.
gist 9y ago
> Did you ever think when stuff like this come out there is some guy at the NSA going "Damn it, there goes another one" Maybe the opposite. Have other spend time on something that has little practical use given the actual utility instead of spending budget dollars on something else.
jloughry 9y ago
I have first-hand experience: Around 1999, I wrote a paper about information leakage from blinking LEDs on devices (one DES link encryption box, used by banks, for example, was sending out plaintext on the LEDs). I was working for a defense contractor at the time on a classified project, and so, following procedures, we submitted the paper to NSA for approval to publish. It took a year and a half to approve. [1] Eventually NSA wrote back and said, "No problem! Go ahead and publish." I kind of wonder what they spent all that time doing. [1] Actually, it didn't quite happen that way. Our paper was approved for publication very quickly, in only a few weeks; we submitted it to the USENIX Security Symposium, where it was immediately accepted. Later, NSA called us back, and in a panic, demanded we withdraw the paper from the conference. I had to apologize to the conference committee; it was terribly embarrassing, and the delay in publishing was two years.
- sesutton 9y ago
  > I kind of wonder what they spent all that time doing. Putting tape over all their LEDs?
- nickpsecurity 9y ago
  You been alright, Joe? Ever get the new ideas on certification or guards published you were working on when we talked on Schneier's blog? I ended up pivoting into trying to figure out how to secure the hardware. Deep submicron effects, supply chain compromises, and Clive's energy gapping recommendation led me to devise concept of putting TCB or monitors in 0.35 micron or up process node that's visually inspectable. Tear down random sample using others if they're clean. Trusted foundries for packaging. SOI for EMF/fault reductions. Bunch of little CPU's like Clive recommended with CHERI or SAFE extensions working over optical links with filtered/masked power. That's about where past year or two of ideas have led me. Havent built anything: just forwarding concepts to people making guards and such. Curious what others csme up with since most guards have dropped to using Linux on x86 or whatever. Shouldve all been decertified for that shit.
  - jloughry 9y ago
    Hi Nick! I'm still working on certification and guards, but in a very early stage company now. Do you know I can predict and (sometimes) control the progress of certification testing of cross domain solutions? That was my PhD. Now I'm working to rid the world of CDS boxes built on PCs running Linux; I know exactly what you mean. It doesn't matter that you're running SE Linux; the vulnerabilities are lower down in the hardware—Meltdown and Spectre and what's coming after Spectre will go right through your VMs and your policy enforcement and your hardened OS. What's needed is a completely different way of solving the cross domain problem; that's what I've got in prototype. I've taught Clive's energy gap notion to my students in university classes. That notion is deeply ingrained in what I'm proposing now. Could I talk with you in more detail about that idea of yours for visually inspectable process node?

Did you ever think when stuff like this come out there is some guy at the NSA going "Damn it, there goes another one" as they have know about this and been using if for years :)

schoen 9y ago

Unfortunately, mitigating a vulnerability can take a long time and might never happen. When the Imperfect Forward Secrecy paper about weak Diffie-Hellman exchanges came out in 2015, not all systems using the vulnerable groups upgraded immediately, and some systems couldn't be easily upgraded either because they were hard-coded or because they had other software limitations. The IT security situation in many developing countries is also pretty alarming, for example if you look at the prevalence of old unsupported operating systems and browsers in many places. Even thinking about traditional emanations issues, the "van Eck phreaking" attacks were publicly demonstrated years ago https://www.youtube.com/watch?v=ZZ5HS8GWIec https://www.youtube.com/watch?v=ZZ5HS8GWIec but have still not been widely mitigated in practice. Neither have the emanations problems documented by Tromer. https://www.cs.tau.ac.il/~tromer/ https://www.cs.tau.ac.il/~tromer/ And we know that the vendors were notified about Spectre in June of last year and the public was told over a month ago, but pretty much all of us continue to be potentially vulnerable to it in some settings, even more than seven months after vendor notifications! It can be nice for infosec researchers to think that attackers only gain power and capability by knowing secrets, and that if those secrets are exposed the attackers will lose their capabilities, but a number of people have been pointing out that it doesn't always work that way -- or at least there can be quite a long window of vulnerability. (However, exposing secrets is definitely an important prerequisite for denying capabilities to attackers.)

myrandomcomment 9y ago
The thing I love about HN is that you say something to be amusing and the engineering types (I am one, so I am making fun of myself) always make some logical argument in response. The best part is 90% of the time you learn something!
jacquesm 9y ago
> The IT security situation in many developing countries is also pretty alarming It's pretty alarming in most of the developed countries as well.
- schoen 9y ago
  Yes, thanks for the correction. I was mostly thinking about the narrow problem of widespread use of very old software, and for example Microsoft's visualization of IE6 market share by country after the company got involved in trying to get people to stop using it. Edit: also, for example, on the Let's Encrypt forums it's somewhat more common for people from developing countries to insist that they have to keep using server software in production that officially went EOL 2 years ago or something. But developing countries absolutely don't have a monopoly on this issue, and I've certainly seen it regularly from users in the United States.

lawlessone 9y ago

I kind of think its so impractically hard that there are easier exploits they could find.

LargeWu 9y ago
Right. Seems more practical to just use social engineering or an inside man.
GCU-Empiricist 9y ago
If you think that you might want to read the tempest security standard, think about how much extra building compliant facilities cost, and realize that someone who already understood the cost approved the requirement because of a credible threat, or a capability they had and weren't sure if the other team would have.

gist 9y ago

> Did you ever think when stuff like this come out there is some guy at the NSA going "Damn it, there goes another one" Maybe the opposite. Have other spend time on something that has little practical use given the actual utility instead of spending budget dollars on something else.

jloughry 9y ago

I have first-hand experience: Around 1999, I wrote a paper about information leakage from blinking LEDs on devices (one DES link encryption box, used by banks, for example, was sending out plaintext on the LEDs). I was working for a defense contractor at the time on a classified project, and so, following procedures, we submitted the paper to NSA for approval to publish. It took a year and a half to approve. [1] Eventually NSA wrote back and said, "No problem! Go ahead and publish." I kind of wonder what they spent all that time doing. [1] Actually, it didn't quite happen that way. Our paper was approved for publication very quickly, in only a few weeks; we submitted it to the USENIX Security Symposium, where it was immediately accepted. Later, NSA called us back, and in a panic, demanded we withdraw the paper from the conference. I had to apologize to the conference committee; it was terribly embarrassing, and the delay in publishing was two years.

sesutton 9y ago
> I kind of wonder what they spent all that time doing. Putting tape over all their LEDs?
nickpsecurity 9y ago
You been alright, Joe? Ever get the new ideas on certification or guards published you were working on when we talked on Schneier's blog? I ended up pivoting into trying to figure out how to secure the hardware. Deep submicron effects, supply chain compromises, and Clive's energy gapping recommendation led me to devise concept of putting TCB or monitors in 0.35 micron or up process node that's visually inspectable. Tear down random sample using others if they're clean. Trusted foundries for packaging. SOI for EMF/fault reductions. Bunch of little CPU's like Clive recommended with CHERI or SAFE extensions working over optical links with filtered/masked power. That's about where past year or two of ideas have led me. Havent built anything: just forwarding concepts to people making guards and such. Curious what others csme up with since most guards have dropped to using Linux on x86 or whatever. Shouldve all been decertified for that shit.
- jloughry 9y ago
  Hi Nick! I'm still working on certification and guards, but in a very early stage company now. Do you know I can predict and (sometimes) control the progress of certification testing of cross domain solutions? That was my PhD. Now I'm working to rid the world of CDS boxes built on PCs running Linux; I know exactly what you mean. It doesn't matter that you're running SE Linux; the vulnerabilities are lower down in the hardware—Meltdown and Spectre and what's coming after Spectre will go right through your VMs and your policy enforcement and your hardened OS. What's needed is a completely different way of solving the cross domain problem; that's what I've got in prototype. I've taught Clive's energy gap notion to my students in university classes. That notion is deeply ingrained in what I'm proposing now. Could I talk with you in more detail about that idea of yours for visually inspectable process node?