1 |
On Mon, May 7, 2018 at 7:15 AM Mick <michaelkintzios@×××××.com> wrote: |
2 |
|
3 |
> Rich was right when he mentioned more related vulnerabilities are bound to |
4 |
> show up soon: |
5 |
|
6 |
|
7 |
I haven't dug up the details on that report, but again Spectre should be |
8 |
seen as a class of vulnerabilities and not one particular bug. I'm not |
9 |
sure whether we'll see buffer overflow attacks eradicated before or after |
10 |
Spectre. |
11 |
|
12 |
I guess the one thing Spectre has going for it is that it isn't a "feature" |
13 |
in common programming languages. You could probably kill off a lot of |
14 |
future buffer overflow attacks if you just removed strcpy from the C |
15 |
standard library (good luck with that), because it more-or-less makes |
16 |
buffer overflows a feature of the language. Then again some of the Spectre |
17 |
vulnerabilities are due to lower-level languages like C forcing the |
18 |
programmer to do their own bounds checking and using pointers, which I'm |
19 |
sure will make it harder to protect these activities in the compiler. |
20 |
|
21 |
Higher-level languages will probably become nearly immune to Spectre just |
22 |
as most are nearly immune to buffer overflows. As variants are discovered |
23 |
their compilers can be fixed to avoid them, and then the benefits apply to |
24 |
any program that is built. However, in the short term I'm sure we'll see |
25 |
issues there as new variants are discovered. |
26 |
|
27 |
-- |
28 |
Rich |