3 ms·

Man, am I tired of these security vulnerabilities caused by memory unsafety. I hope my children will see the day when these kinds of software vulnerabilities o

Man, am I tired of these security vulnerabilities caused by memory unsafety. I hope my children will see the day when these kinds of software vulnerabilities only exist in "legacy" software.

fsflover 3y ago
As always, Qubes OS is recommended if you really care about security. It saved me, again.
- FergusArgyll 3y ago
  Is it really your main Desktop/Laptop? I'm intrigued by it but it looks pretty inconvenient. Do you find it usable?
  - fsflover 3y ago
    Yes, it's my daily driver. It's much more convenient than people expect, can't recommend it enough. Recent discussion: https://news.ycombinator.com/item?id=38690597 https://news.ycombinator.com/item?id=38690597
    - fbdab103 3y ago
      Amusingly, the first thread in there opens up about how Docker security is comparable to a VM, yet today has a Docker exploit on the frontpage https://news.ycombinator.com/item?id=39250975 https://news.ycombinator.com/item?id=39250975
jl6 3y ago
> I hope my children will see the day when these kinds of software vulnerabilities only exist in "legacy" software. The good news: the day will come when this kind of software vulnerability will only exist in legacy software. The bad news: we’ll still be using legacy software at that time.
- agilob 3y ago
  Worse news, even fewer people will know C to fix it
pixl97 3y ago
"Dear Sir We regret to inform you your children were killed by an AI using a memory unsafe language"
- PaulHoule 3y ago
  Maybe just the ECU of a car.
hgs3 3y ago
I'm tired of sloppy testing. This issue was discoverable via a fuzzer as noted in the bug report. Software that accepts external inputs needs to be fuzzed regardless of whether it is written in a memory safe language or not. Uncaught exceptions and panics are still bugs and recovering from one without clearing internal state could lead to a security hole.
- DougBTX 3y ago
  > I'm tired of sloppy testing Exhaustive testing tops out at about two float 32s[0], so of course do that for small functions, but for full application testing type checks are much cheaper. [0] https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/ https://randomascii.wordpress.com/2014/01/27/theres-only-fou...
  - ajross 3y ago
    Fuzzing isn't exhaustive testing, it's dynamic coverage testing. You provide random input until you discover your (compiler-instrumented) binary doing something you haven't seen yet, then permute the input until you get it to do something else, etc... For almost all non-pathological algorithms, it's capable of reaching full coverage in linear time; though some algorithms are always going to have pathological edge and require some whiteboxing.
- pjmlp 3y ago
  The usual excuse for C and C++ security flaws, "This shouldn't have happened: A vulnerability postmortem " https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html https://googleprojectzero.blogspot.com/2021/12/this-shouldnt... Relevant quote, "All of the NSS fuzzers are represented in combined coverage metrics by oss-fuzz, rather than their individual coverage. This data proved misleading, as the vulnerable code is fuzzed extensively but by fuzzers that could not possibly generate a relevant input."
  - ajross 3y ago
    > The usual excuse for C and C++ security flaws, Saying "important software should be rigorously tested" isn't an excuse, it's an actionable and reasonable suggestion. Tut-tutting about implementation language choice in (literally) the platform C runtime is quite a bit less so. Grandparent was being helpful, basically. You're just sniping.
pjmlp 3y ago
As usual, my favourite quote, "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture" Thankfully the powers of the law are finally taking attention to it, after a couple of decades since that speech took place.

Man, am I tired of these security vulnerabilities caused by memory unsafety. I hope my children will see the day when these kinds of software vulnerabilities only exist in "legacy" software.

fsflover 3y ago

As always, Qubes OS is recommended if you really care about security. It saved me, again.

FergusArgyll 3y ago
Is it really your main Desktop/Laptop? I'm intrigued by it but it looks pretty inconvenient. Do you find it usable?
- fsflover 3y ago
  Yes, it's my daily driver. It's much more convenient than people expect, can't recommend it enough. Recent discussion: https://news.ycombinator.com/item?id=38690597 https://news.ycombinator.com/item?id=38690597
  - fbdab103 3y ago
    Amusingly, the first thread in there opens up about how Docker security is comparable to a VM, yet today has a Docker exploit on the frontpage https://news.ycombinator.com/item?id=39250975 https://news.ycombinator.com/item?id=39250975

jl6 3y ago

> I hope my children will see the day when these kinds of software vulnerabilities only exist in "legacy" software. The good news: the day will come when this kind of software vulnerability will only exist in legacy software. The bad news: we’ll still be using legacy software at that time.

agilob 3y ago
Worse news, even fewer people will know C to fix it

pixl97 3y ago

"Dear Sir We regret to inform you your children were killed by an AI using a memory unsafe language"

PaulHoule 3y ago
Maybe just the ECU of a car.

hgs3 3y ago

I'm tired of sloppy testing. This issue was discoverable via a fuzzer as noted in the bug report. Software that accepts external inputs needs to be fuzzed regardless of whether it is written in a memory safe language or not. Uncaught exceptions and panics are still bugs and recovering from one without clearing internal state could lead to a security hole.

DougBTX 3y ago
> I'm tired of sloppy testing Exhaustive testing tops out at about two float 32s[0], so of course do that for small functions, but for full application testing type checks are much cheaper. [0] https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/ https://randomascii.wordpress.com/2014/01/27/theres-only-fou...
- ajross 3y ago
  Fuzzing isn't exhaustive testing, it's dynamic coverage testing. You provide random input until you discover your (compiler-instrumented) binary doing something you haven't seen yet, then permute the input until you get it to do something else, etc... For almost all non-pathological algorithms, it's capable of reaching full coverage in linear time; though some algorithms are always going to have pathological edge and require some whiteboxing.
pjmlp 3y ago
The usual excuse for C and C++ security flaws, "This shouldn't have happened: A vulnerability postmortem " https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html https://googleprojectzero.blogspot.com/2021/12/this-shouldnt... Relevant quote, "All of the NSS fuzzers are represented in combined coverage metrics by oss-fuzz, rather than their individual coverage. This data proved misleading, as the vulnerable code is fuzzed extensively but by fuzzers that could not possibly generate a relevant input."
- ajross 3y ago
  > The usual excuse for C and C++ security flaws, Saying "important software should be rigorously tested" isn't an excuse, it's an actionable and reasonable suggestion. Tut-tutting about implementation language choice in (literally) the platform C runtime is quite a bit less so. Grandparent was being helpful, basically. You're just sniping.

pjmlp 3y ago

As usual, my favourite quote, "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture" Thankfully the powers of the law are finally taking attention to it, after a couple of decades since that speech took place.