8 ms·

Some thoughts on Spectre and Meltdown

203 points by cperciva 9y ago

2trill2spill 9y ago
> Google discovered a problem and reported it to Intel, AMD, and ARM on June 1st. Did they then go around contacting all of the operating systems which would need to work on fixes for this? Not even close. FreeBSD was notified the week before Christmas, over six months after the vulnerabilities were discovered. Absolutely shitty behavior by Google, AMD, Intel and ARM. Notifying the FreeBSD devs so late is a slap in the face to the FreeBSD community and makes the internet as a whole less safe.
- dotancohen 9y ago
  > Notifying the FreeBSD devs so late is a slap in the face to the FreeBSD community and makes the internet as a whole less safe. Absolutely. That is quite the proper response to FreeBSD leaking privileged information about vulnerabilities in the past.
  - bigiain 9y ago
    Lucky it worked out so smoothly this time sharing with the Linux dev team...
    - tedunangst 9y ago
      Will be interesting to see if Linux is cut out of any future embargo.
      - cperciva 9y ago
        Linux as a whole? I doubt it; but I can definitely imagine individual Linux distributions being contacted and asked to agree to strict terms (including "no patches get shared") before they are given details of future issues. Nobody wants to cut Linux out of things, so there's going to be an inclination to err on the side of "well maybe they didn't understand what the embargo meant...".
        tedunangst 9y ago
        I'm just following the narrative of anybody releasing a patch early gets the death penalty.
        bigiain 9y ago
        Somebody clearly wanted to cut BSD out of things... And succeeded. Also, while the Linux devs failing to honour the embargo ended up being a quite public and problematic thing, I _seriously_ doubt some of the other OS vendor dev teams didn't talk about the problem out of school - and I strongly suspect state-actors and blackhats have pipelines of information on security problems being worked on at Microsoft, Apple, Google, and many other big players. Overenthusiastic devs at local bars/cafes, boastful or bignoting devs online, or disgruntled employees/ex-employees, they are almost certainly targeted by both blackhat and state level actors. I'm pretty sure a security problem of this magnitude, requiring remediation work my this many different teams, work which took six months or more of planning and executing - could not _possibly_ have stayed completely unknown externally right up to the agreed embargo date. People just don't work that way.
  - SolarNet 9y ago
    I am now looking forward to the time a FreeBSD (or Linux) developer finds a complex-to-mitigate architectural bug, only pushes it to their kernel, and the world burns down around us because of this petty shit (including these posters, Google and hardware vendors in this). So thank you for that.
  - 2trill2spill 9y ago
    > Absolutely. That is quite the proper response to FreeBSD leaking privileged information about vulnerabilities in the past. And what vulnerability leaks are you talking about?
    - cperciva 9y ago
      I'd like to know this too...
    - whyever 9y ago
      Maybe they are confusing FreeBSD with OpenBSD?
    - rincebrain 9y ago
      They might be mixing up Free and OpenBSD, and thinking of [1], since I can't find any obvious results for FBSD making that mistake. [1] - https://marc.info/?l=openbsd-misc&m=150815942414653&w=2 https://marc.info/?l=openbsd-misc&m=150815942414653&w=2
      - cperciva 9y ago
        If that's what it was, they were both mixing up FreeBSD and OpenBSD and had a time machine. OpenBSD has been clear in the past about not respecting embargoes, however. That's their right (Linus takes the same position) but I would completely understand people deciding to not notify OpenBSD as a result. But as far as I'm aware, FreeBSD has an exceptional track record when it comes to respecting vulnerability embargoes.
  - ComputerGuru 9y ago
    Source, please? The only BSD I’m aware of that breaks embargoes is OpenBSD.
    - throwaway2048 9y ago
      This is false, OpenBSD agreed to the inital embargo on KRACK, the author wanted it extended, OpenBSD asked if they could publish a silent fix/patch, the author agreed, then later renegged, OpenBSD published it anyways, then the author got pissy. The idea that OpenBSD broke a bug embargo is misinformation.
      - ComputerGuru 9y ago
        No, it’s fact. We already went through this 3 months ago. https://news.ycombinator.com/item?id=15481946 https://news.ycombinator.com/item?id=15481946
        throwaway2048 9y ago
        The post you linked confirmed what I just said...
pbsd 9y ago
I'm gonna go and take issue with the claim that you were the first to come up with microarchitectural attacks, and that their story begins in 2004: - Dan Page published [1] in 2002, describing an attack on DES exploiting cache timings. In 2003, he published [2] describing countermeasures to this class of attacks. - Concurrently, a Japanese team also attacked DES (and MISTY1) with cache timing [3, 4]. - Dan Bernstein published the first version of his AES cache timing attack in late 2004 [5]. [1] https://eprint.iacr.org/2002/169 https://eprint.iacr.org/2002/169 [2] https://doi.org/10.1016/S1363-4127(03)00104-3 https://doi.org/10.1016/S1363-4127(03)00104-3 [3] https://link.springer.com/chapter/10.1007/978-3-540-45238-6_6 https://link.springer.com/chapter/10.1007/978-3-540-45238-6_... [4] https://web.archive.org/web/20060906064630/http://web.engr.oregonstate.edu/~aciicmez/osutass/data/Tsunoo02.pdf https://web.archive.org/web/20060906064630/http://web.engr.o... [5] https://cr.yp.to/antiforgery/cachetiming-20041121.pdf https://cr.yp.to/antiforgery/cachetiming-20041121.pdf
- dsacco 9y ago
  Thanks for writing this. I didn't like the opening paragraph either, and your comment is a better rebuttal than I could have written. Colin, I think this is a good perspective on Spectre and Meltdown, but it feels like the entire opening paragraph was an unnecessary attempt at a "me too" that implies you're the modern father of these sorts of attacks when that isn't really the case. I understand you're establishing credibility and expertise (and you have both), but it's disingenuous to begin with, The story of these attacks starts in late 2004, and then go on to describe your own work. I think the rest of your post has its own utility without writing a narrative of these attacks that inserts you at the beginning of them.
  - cperciva 9y ago
    I spent a long time wondering about this. Honestly, I think I am (along with Osvik and Tromer) modern father of these sorts of attacks. (See my reply to pbsd for why.) I think people in the field recognize my credibility and expertise here, and for them that paragraph is superfluous; but I was aiming this blog post at a wider audience (hence the effort spent on non-technical analogies to help them understand the issues) so I thought it was important to explain my background to people who had never heard of side channel attacks before.
mappu 9y ago
Are those earlier-mentioned attacks against HyperThreading and caches still viable? If not, were they resolved in OpenSSL, in the OS, or in hardware?
- cperciva 9y ago
  The particular code path which I found was leaking information was fixed in OpenSSL. Some operating systems (including FreeBSD) turned off HyperThreading by default for a while to allow software authors to fix their code, and then re-enabled it again a few years later. Intel stopped using HyperThreading for a while (it was in the Pentium 4, but that architecture was abandoned), and also made some changes to the caches which they claimed would help, but they never provided any details and I've never seen any verification of their claims in that regard. (Obviously whatever changes they made weren't enough to prevent the Spectre and Meltdown attacks conveying information through the cache!) So the best summary is that people threw up their hands and said "yeah, it's a problem, let's hope that nobody writes code which leaks any sensitive information into the microarchitectural state". Not exactly a good position to be in...
mozumder 9y ago
If you're worried about servers being cracked, the best thing is to avoid shared cloud servers and use dedicated private servers. These attacks rely on some other user-process malware running on the server to gain information via side channels. If every process in your server is your own, for your web services or whatever, you don't have to worry about it. As usual, nothing beats dedicated private servers.
- yeukhon 9y ago
  If you plan to run one VM on one physical machine, perhaps you don’t have to worry your neighbor reading your data. But a malicious program running on your machine CAN still exploit the bugs. In fact one can exploit the browrser via Javascript by taking advantage of Spectre. There is no way to avoid the vulnerabilities until you have patchrd your system and your software. The three bugs we know of is not a cloud vs dedicated choice.
  - snaky 9y ago
    > a malicious program running on your machine If a malicious program could make the way to the private server, the problem is much worse than side-channel attacks. > the browrser via Javascript Server. We are talking about server.
    - yeukhon 9y ago
      I was illustrating the point that these bugs are not limited to a cloud vs dedicated server sevicd model. I don’t think OP would risk not patching its dedicated server, then it echoes my point that these bugs are just as dangerous as in dedicated server model too.
    - baq 9y ago
      If your server does eh scraping, it'd better not have access to your network.
      - snaky 9y ago
niftich 9y ago
These side-channel attacks -- which, as illustrated, are not new -- are becoming perceived as more acute because more so than before we're intermingling processes with vastly different purposes, responsibilities, and origins, on the same hardware. When you do this, it's exceedingly difficult to cloak intrinsic attributes of execution, such as cache timing, or even execution timing, from other contexts of execution that have access to observe enough facets of the system. This applies at all levels of reading, really. We're mixing the trafficking of sensitive authentication information in the same process as code that executes instantly upon clicking on hyperlinks. We're mixing business and pleasure on the same filesystem, in the same OS and memory space. We're mixing mutually untrusting entities' private data and code on timesharing systems that we're renting in someone else's datacenter. Process boundaries, both in terms of physical reality and design choices on what constitutes a system boundary, are critical, and will need additional thought. At the same time, a boundary that's more robust to side-channel attacks than most is having all the hardware exclusive to yourself. Also, this entire issue neatly demonstrates the problems with executing untrusted code. Solving the issue of vetting code and evaluating trust, especially by average users, is extremely difficult; but the current culture of the Web largely consists of running untrusted code immediately from a single user-entered string, or through automatic or manual navigation thenceforth. This is a frightening proposition, and yet entirely mainstream today.
- willtim 9y ago
  This problem is made worse by technologies like JavaScript, which resemble system programming languages in the lack of restrictions placed on untrusted code. JS code can create threads, sockets, timers, perform I/O, loop or allocate forever. This is complete overkill for something that is mostly needed for interactive websites. Web Assembly doesn't fix this problem either. JavaScript has killed accessibility for the web and created numerous security problems. I don't want it and try to block it when I can.
mhandley 9y ago
In section 5.2 of Bernstein's paper, he discusses isolating single-source transformations. His example is locking down jpegtopnm using standard Unix mechanisms so it can only read stdin and write stdout and do absolutely nothing else. It seems this pattern really should be one that is trivial for the programmer to use, without having to go through the process of managing a pool of UIDs, remember about setting process limits, etc. Then it might be used correctly more often. Would be a useful building block for lots of code, especially if it were portable across many versions of *nix.
- cperciva 9y ago
  This is basically what Capsicum (FreeBSD + Linux) and pledge (OpenBSD) are for. I agree that it would be nice to have a standard interface, but the functionality provided by those is sufficiently different that it's hard to imagine how a single API could be created which usefully covers both.
  - bringtheaction 9y ago
    Speaking of which, anyone have examples of how to restrict a process to using stdin and stdout only with Capsicum and pledge?
antirez 9y ago
On the topic of explaining Spectre and Meltdown to non technical audience, this is my try (in Italian but Google Translate does a reasonable translation): https://medium.com/@antirez/spectre-e-meltdown-spiegati-al-mio-idraulico-cd4567ce6991 https://medium.com/@antirez/spectre-e-meltdown-spiegati-al-m... The reason why I thought it's so important to do this effort is that, this bug was in the news for days, everybody is going to do upgrades in one way or the other, and even to pay for the performance cost, yet most of the people out there will not understand what it is about. I've the feeling that this disconnects non technical people from technology in a very bad way. That's the reason I believe that divulgation is so crucial.
alain94040 9y ago
The analogies with the visa/passport are good, except the one about Meltdown: Because she doesn't have a North Korean visa, she (somehow) checks the expiry date on someone else's North Korean visa, and then (if it is about to expire) runs out to renew it Maybe try this version: she calls the embassy to ask if she needs to renew her visa (which she doesn't have). The clerk, who has access to all the visas ever issued, tells her that no one has a visa that expires in the next few months, so she is good. This way, you find out about other people's expiration dates.
- cperciva 9y ago
  I agree that analogy makes more sense, but I wanted an analogy which involved my girlfriend doing something impossible -- because a process accessing memory it doesn't have permission to access is supposed to be impossible.
mickster99 9y ago
Good write up. The following blurb got me thinking: "In the industry we refer to "airgapped" systems; this is a reference back to the days when connecting to a network required wires, so if there was a literal gap with just air between two systems, there was no way they could communicate." If we know the Internet is a scary place why do nuclear plants, power plants, etc. have Internet connectivity?
- draw_down 9y ago
  If we know nuclear power plants might blow up, why do we have them?
- MrRadar 9y ago
  Because it's the most efficient way to communicate with the corporate headquarters and clients/customers? These places are fundamentally businesses and they have the same communication needs as any other.
shishiwakamaru1 9y ago
I've read the ppapers and lots of articles on the subject and still can't get how do I know where I land using Spectre Variante 1. I know I can read some byte in Memory, but do I know where exactly it comes from? I know that I can increase the x value so that I can read other values, but until which point? Thanks
Maken 9y ago
> For my Tarsnap online backup service I compile and cryptographically sign the packages on a system which has never been connected to the Internet. Before I turned it on for the first time, I opened up the case and pulled out the wifi card; and I copy files on and off the system on a USB stick. How can you be sure the system you copied those files from is not compromised, the micro-controller on the USB stick has not been compromised, and now it's not going to take control of the build system and replace the compiler chain with a modified one which will make all your software vulnerable?
- cperciva 9y ago
  I can't. Having an airgapped system doesn't solve every problem; but it does solve some of them.

203 points by cperciva 9y ago

> Google discovered a problem and reported it to Intel, AMD, and ARM on June 1st. Did they then go around contacting all of the operating systems which would need to work on fixes for this? Not even close. FreeBSD was notified the week before Christmas, over six months after the vulnerabilities were discovered. Absolutely shitty behavior by Google, AMD, Intel and ARM. Notifying the FreeBSD devs so late is a slap in the face to the FreeBSD community and makes the internet as a whole less safe.

dotancohen 9y ago
> Notifying the FreeBSD devs so late is a slap in the face to the FreeBSD community and makes the internet as a whole less safe. Absolutely. That is quite the proper response to FreeBSD leaking privileged information about vulnerabilities in the past.
- bigiain 9y ago
  Lucky it worked out so smoothly this time sharing with the Linux dev team...
  - tedunangst 9y ago
    Will be interesting to see if Linux is cut out of any future embargo.
    - cperciva 9y ago
      Linux as a whole? I doubt it; but I can definitely imagine individual Linux distributions being contacted and asked to agree to strict terms (including "no patches get shared") before they are given details of future issues. Nobody wants to cut Linux out of things, so there's going to be an inclination to err on the side of "well maybe they didn't understand what the embargo meant...".
      - tedunangst 9y ago
        I'm just following the narrative of anybody releasing a patch early gets the death penalty.
      - bigiain 9y ago
        Somebody clearly wanted to cut BSD out of things... And succeeded. Also, while the Linux devs failing to honour the embargo ended up being a quite public and problematic thing, I _seriously_ doubt some of the other OS vendor dev teams didn't talk about the problem out of school - and I strongly suspect state-actors and blackhats have pipelines of information on security problems being worked on at Microsoft, Apple, Google, and many other big players. Overenthusiastic devs at local bars/cafes, boastful or bignoting devs online, or disgruntled employees/ex-employees, they are almost certainly targeted by both blackhat and state level actors. I'm pretty sure a security problem of this magnitude, requiring remediation work my this many different teams, work which took six months or more of planning and executing - could not _possibly_ have stayed completely unknown externally right up to the agreed embargo date. People just don't work that way.
- SolarNet 9y ago
  I am now looking forward to the time a FreeBSD (or Linux) developer finds a complex-to-mitigate architectural bug, only pushes it to their kernel, and the world burns down around us because of this petty shit (including these posters, Google and hardware vendors in this). So thank you for that.
- 2trill2spill 9y ago
  > Absolutely. That is quite the proper response to FreeBSD leaking privileged information about vulnerabilities in the past. And what vulnerability leaks are you talking about?
  - cperciva 9y ago
    I'd like to know this too...
  - whyever 9y ago
    Maybe they are confusing FreeBSD with OpenBSD?
  - rincebrain 9y ago
    They might be mixing up Free and OpenBSD, and thinking of [1], since I can't find any obvious results for FBSD making that mistake. [1] - https://marc.info/?l=openbsd-misc&m=150815942414653&w=2 https://marc.info/?l=openbsd-misc&m=150815942414653&w=2
    - cperciva 9y ago
      If that's what it was, they were both mixing up FreeBSD and OpenBSD and had a time machine. OpenBSD has been clear in the past about not respecting embargoes, however. That's their right (Linus takes the same position) but I would completely understand people deciding to not notify OpenBSD as a result. But as far as I'm aware, FreeBSD has an exceptional track record when it comes to respecting vulnerability embargoes.
- ComputerGuru 9y ago
  Source, please? The only BSD I’m aware of that breaks embargoes is OpenBSD.
  - throwaway2048 9y ago
    This is false, OpenBSD agreed to the inital embargo on KRACK, the author wanted it extended, OpenBSD asked if they could publish a silent fix/patch, the author agreed, then later renegged, OpenBSD published it anyways, then the author got pissy. The idea that OpenBSD broke a bug embargo is misinformation.
    - ComputerGuru 9y ago
      No, it’s fact. We already went through this 3 months ago. https://news.ycombinator.com/item?id=15481946 https://news.ycombinator.com/item?id=15481946
      - throwaway2048 9y ago
        The post you linked confirmed what I just said...

pbsd 9y ago

I'm gonna go and take issue with the claim that you were the first to come up with microarchitectural attacks, and that their story begins in 2004: - Dan Page published [1] in 2002, describing an attack on DES exploiting cache timings. In 2003, he published [2] describing countermeasures to this class of attacks. - Concurrently, a Japanese team also attacked DES (and MISTY1) with cache timing [3, 4]. - Dan Bernstein published the first version of his AES cache timing attack in late 2004 [5]. [1] https://eprint.iacr.org/2002/169 https://eprint.iacr.org/2002/169 [2] https://doi.org/10.1016/S1363-4127(03)00104-3 https://doi.org/10.1016/S1363-4127(03)00104-3 [3] https://link.springer.com/chapter/10.1007/978-3-540-45238-6_6 https://link.springer.com/chapter/10.1007/978-3-540-45238-6_... [4] https://web.archive.org/web/20060906064630/http://web.engr.oregonstate.edu/~aciicmez/osutass/data/Tsunoo02.pdf https://web.archive.org/web/20060906064630/http://web.engr.o... [5] https://cr.yp.to/antiforgery/cachetiming-20041121.pdf https://cr.yp.to/antiforgery/cachetiming-20041121.pdf

dsacco 9y ago
Thanks for writing this. I didn't like the opening paragraph either, and your comment is a better rebuttal than I could have written. Colin, I think this is a good perspective on Spectre and Meltdown, but it feels like the entire opening paragraph was an unnecessary attempt at a "me too" that implies you're the modern father of these sorts of attacks when that isn't really the case. I understand you're establishing credibility and expertise (and you have both), but it's disingenuous to begin with, The story of these attacks starts in late 2004, and then go on to describe your own work. I think the rest of your post has its own utility without writing a narrative of these attacks that inserts you at the beginning of them.
- cperciva 9y ago
  I spent a long time wondering about this. Honestly, I think I am (along with Osvik and Tromer) modern father of these sorts of attacks. (See my reply to pbsd for why.) I think people in the field recognize my credibility and expertise here, and for them that paragraph is superfluous; but I was aiming this blog post at a wider audience (hence the effort spent on non-technical analogies to help them understand the issues) so I thought it was important to explain my background to people who had never heard of side channel attacks before.

mappu 9y ago

Are those earlier-mentioned attacks against HyperThreading and caches still viable? If not, were they resolved in OpenSSL, in the OS, or in hardware?

cperciva 9y ago
The particular code path which I found was leaking information was fixed in OpenSSL. Some operating systems (including FreeBSD) turned off HyperThreading by default for a while to allow software authors to fix their code, and then re-enabled it again a few years later. Intel stopped using HyperThreading for a while (it was in the Pentium 4, but that architecture was abandoned), and also made some changes to the caches which they claimed would help, but they never provided any details and I've never seen any verification of their claims in that regard. (Obviously whatever changes they made weren't enough to prevent the Spectre and Meltdown attacks conveying information through the cache!) So the best summary is that people threw up their hands and said "yeah, it's a problem, let's hope that nobody writes code which leaks any sensitive information into the microarchitectural state". Not exactly a good position to be in...

mozumder 9y ago

If you're worried about servers being cracked, the best thing is to avoid shared cloud servers and use dedicated private servers. These attacks rely on some other user-process malware running on the server to gain information via side channels. If every process in your server is your own, for your web services or whatever, you don't have to worry about it. As usual, nothing beats dedicated private servers.

yeukhon 9y ago
If you plan to run one VM on one physical machine, perhaps you don’t have to worry your neighbor reading your data. But a malicious program running on your machine CAN still exploit the bugs. In fact one can exploit the browrser via Javascript by taking advantage of Spectre. There is no way to avoid the vulnerabilities until you have patchrd your system and your software. The three bugs we know of is not a cloud vs dedicated choice.
- snaky 9y ago
  > a malicious program running on your machine If a malicious program could make the way to the private server, the problem is much worse than side-channel attacks. > the browrser via Javascript Server. We are talking about server.
  - yeukhon 9y ago
    I was illustrating the point that these bugs are not limited to a cloud vs dedicated server sevicd model. I don’t think OP would risk not patching its dedicated server, then it echoes my point that these bugs are just as dangerous as in dedicated server model too.
  - baq 9y ago
    If your server does eh scraping, it'd better not have access to your network.
    - snaky 9y ago

niftich 9y ago

These side-channel attacks -- which, as illustrated, are not new -- are becoming perceived as more acute because more so than before we're intermingling processes with vastly different purposes, responsibilities, and origins, on the same hardware. When you do this, it's exceedingly difficult to cloak intrinsic attributes of execution, such as cache timing, or even execution timing, from other contexts of execution that have access to observe enough facets of the system. This applies at all levels of reading, really. We're mixing the trafficking of sensitive authentication information in the same process as code that executes instantly upon clicking on hyperlinks. We're mixing business and pleasure on the same filesystem, in the same OS and memory space. We're mixing mutually untrusting entities' private data and code on timesharing systems that we're renting in someone else's datacenter. Process boundaries, both in terms of physical reality and design choices on what constitutes a system boundary, are critical, and will need additional thought. At the same time, a boundary that's more robust to side-channel attacks than most is having all the hardware exclusive to yourself. Also, this entire issue neatly demonstrates the problems with executing untrusted code. Solving the issue of vetting code and evaluating trust, especially by average users, is extremely difficult; but the current culture of the Web largely consists of running untrusted code immediately from a single user-entered string, or through automatic or manual navigation thenceforth. This is a frightening proposition, and yet entirely mainstream today.

willtim 9y ago
This problem is made worse by technologies like JavaScript, which resemble system programming languages in the lack of restrictions placed on untrusted code. JS code can create threads, sockets, timers, perform I/O, loop or allocate forever. This is complete overkill for something that is mostly needed for interactive websites. Web Assembly doesn't fix this problem either. JavaScript has killed accessibility for the web and created numerous security problems. I don't want it and try to block it when I can.

mhandley 9y ago

In section 5.2 of Bernstein's paper, he discusses isolating single-source transformations. His example is locking down jpegtopnm using standard Unix mechanisms so it can only read stdin and write stdout and do absolutely nothing else. It seems this pattern really should be one that is trivial for the programmer to use, without having to go through the process of managing a pool of UIDs, remember about setting process limits, etc. Then it might be used correctly more often. Would be a useful building block for lots of code, especially if it were portable across many versions of *nix.

cperciva 9y ago
This is basically what Capsicum (FreeBSD + Linux) and pledge (OpenBSD) are for. I agree that it would be nice to have a standard interface, but the functionality provided by those is sufficiently different that it's hard to imagine how a single API could be created which usefully covers both.
- bringtheaction 9y ago
  Speaking of which, anyone have examples of how to restrict a process to using stdin and stdout only with Capsicum and pledge?

antirez 9y ago

On the topic of explaining Spectre and Meltdown to non technical audience, this is my try (in Italian but Google Translate does a reasonable translation): https://medium.com/@antirez/spectre-e-meltdown-spiegati-al-mio-idraulico-cd4567ce6991 https://medium.com/@antirez/spectre-e-meltdown-spiegati-al-m... The reason why I thought it's so important to do this effort is that, this bug was in the news for days, everybody is going to do upgrades in one way or the other, and even to pay for the performance cost, yet most of the people out there will not understand what it is about. I've the feeling that this disconnects non technical people from technology in a very bad way. That's the reason I believe that divulgation is so crucial.

alain94040 9y ago

The analogies with the visa/passport are good, except the one about Meltdown: Because she doesn't have a North Korean visa, she (somehow) checks the expiry date on someone else's North Korean visa, and then (if it is about to expire) runs out to renew it Maybe try this version: she calls the embassy to ask if she needs to renew her visa (which she doesn't have). The clerk, who has access to all the visas ever issued, tells her that no one has a visa that expires in the next few months, so she is good. This way, you find out about other people's expiration dates.

cperciva 9y ago
I agree that analogy makes more sense, but I wanted an analogy which involved my girlfriend doing something impossible -- because a process accessing memory it doesn't have permission to access is supposed to be impossible.

mickster99 9y ago

Good write up. The following blurb got me thinking: "In the industry we refer to "airgapped" systems; this is a reference back to the days when connecting to a network required wires, so if there was a literal gap with just air between two systems, there was no way they could communicate." If we know the Internet is a scary place why do nuclear plants, power plants, etc. have Internet connectivity?

draw_down 9y ago
If we know nuclear power plants might blow up, why do we have them?
MrRadar 9y ago
Because it's the most efficient way to communicate with the corporate headquarters and clients/customers? These places are fundamentally businesses and they have the same communication needs as any other.

shishiwakamaru1 9y ago

I've read the ppapers and lots of articles on the subject and still can't get how do I know where I land using Spectre Variante 1. I know I can read some byte in Memory, but do I know where exactly it comes from? I know that I can increase the x value so that I can read other values, but until which point? Thanks

Maken 9y ago

> For my Tarsnap online backup service I compile and cryptographically sign the packages on a system which has never been connected to the Internet. Before I turned it on for the first time, I opened up the case and pulled out the wifi card; and I copy files on and off the system on a USB stick. How can you be sure the system you copied those files from is not compromised, the micro-controller on the USB stick has not been compromised, and now it's not going to take control of the build system and replace the compiler chain with a modified one which will make all your software vulnerable?

cperciva 9y ago
I can't. Having an airgapped system doesn't solve every problem; but it does solve some of them.