4 ms·

Memory unsafe language strikes again. How much longer are we going to put up with this?

mort96 4y ago
Forever. Computers are fundamentally unsafe if you tell them to do something you shouldn't have. That's true for every language which has ever been useful.
- flangola7 4y ago
  Formal verification is a thing. Good architectures make undesirable action rare. What's the last time you heard about a worm that spreads from one Android phone to the next, without the owners realizing it?
  - mavhc 4y ago
    Given that the majority of android phones have dozens of well known security flaws (because they don't get updates, or get them very late), it's kinda weird they're not all one massive botnet. Why is that?
    - flangola7 4y ago
      Mostly because the underlying design makes that difficult. On a traditional desktop an application running as root can do anything, and one running as user can do slightly less than everything. On Android running as root doesn't even exist as a function, and running as user comes with significant limitations enforced structurally by low level SELinux code in the kernel and OS. Android malware can't infect an existing application because the OS both segregates their storage and verifies code signatures. TPMs take this a step further and create not only logical but physical separation between the main CPU and many cryptographic functions. Exploits still happen but you need a much longer chain of vulnerabilities to pull it off.
  - mort96 4y ago
    Are you claiming the entirety of Android is formally verified? Do you have links to those papers?
    - flangola7 4y ago
      No, I'm claiming Android has good architecture. If you combined good arch with verification then exploits would be very rare indeed.
- woodruffw 4y ago
  This isn’t a meaningful response: “the computer does what you tell it to do” doesn’t mean the same thing as “the computer ends up in an exploitable state when you don’t tell it to do the right thing.”
  - mort96 4y ago
    Yet computers necessarily end up in an exploitable state when you don't tell them to do the right thing. Your back-end is written in Rust? If you don't do your auth checks right, one user can delete another user's content.
    - majewsky 4y ago
      Sure, but given a fixed probability of introducing a bug at each possible place, "doing an auth check correctly" has much less probability of being buggy than "doing every memory allocation correctly" because it happens in several magnitudes less places.
      - deleted 4y ago
        [deleted]
    - woodruffw 4y ago
      No, not necessarily: Rust is by no means the first language to prevent missing bounds checks from becoming exploitable memory unsafety, as just one small example. All programs are exploitable; the objective is to limit the nature and scope of their exploitability.
- kaba0 4y ago
  Just because we can’t go 100% safe, we shouldn’t even try? That’s a logical fallacy right there.
  - mort96 4y ago
    I'm not saying we shouldn't make safer languages. Rust is okay.
Cthulhu_ 4y ago
This comment adds nothing tbh; you're mentioning a known problem, but repeating the problem and asking open-ended questions isn't going to solve it. The solutions are there and people are working on them, but this isn't an overnight change.
- quotemstr 4y ago
  > The solutions are there and people are working on them People keep writing new programs in C.
  - yeenieee 4y ago
    What other options are there? It's the only systems level language with a formally verified compiler afaik. rust is a no go because you can't trust the compiler's output (remember, we can't trust people to write correct code, so we obviously can't trust the compiler writers either).
    - lapinot 4y ago
      Both formally proven compilers and black-box SMT-based translation verification are a thing. Rust is not there yet but both exist for C.
    - antientropic 4y ago
      The vast majority of C programmers do not use a formally verified C compiler, and most of them wouldn't care about that anyway. From a security perspective, demanding a formally verified C compiler is rearranging the deck chairs on the Titanic. Switching to a safer language like Rust will do much more to improve security, even if the compiler is not verified.
    - kaba0 4y ago
      The biggest formally verified program is tiny compared to your regular software suit. That method simply doesn’t scale. Also, it “trusts the hardware” which itself can be (surprisingly) buggy. So there is no 100% safe solution, should we not even try to better our softwares then? Trusting trust is an interesting paper, but it was never meant as a gotcha, it was meant as a “don’t forget to look at the whole picture from time to time”.
notorandit 4y ago
Memory safe languages rely on someone else's software and someone else's compiler/interpreter. Rust and go are memory safe languages because their compiler are (said to be) checking all memory usage either statically or dynamically. It's still software written by someone, running on hardware designed by someone. If I write software in assembler I can just blame myself and the hardware. If I do it in C I can blame myself, the hardware, the compiler and the libraries. If I do it in Java I need to add the JRE and all the Java libraries, plus C etc. Memory safeness is just an illusion to me or a way to avoid responsibilities in case of issues.
- flangola7 4y ago
  And yet companies like Google have reported significant drops in memory related vulnerabilities.
  - blackhaz 4y ago
    I wonder if there ever could be a C compiler doing all those checks. What is so radically different about Rust?
    - woodruffw 4y ago
      As a single example: C’s semantics prevent perfect alias analysis, meaning that a C compiler (no matter how smart) can never provide many of Rust’s basic guarantees without significantly altering the C language.
    - tialaramex 4y ago
      The lifetime analysis is only possible in Rust because Rust has lifetimes. Even if you write a toy Rust program where you didn't apparently write any lifetimes, they were implied and the implied lifetimes were checked - the language was constrained by the fact you didn't specify a lifetime and so the implied lifetime was checked, whereas in C you can't express the lifetime and so it can't be checked. The most glorious example of this is comparing C23's #embed with Rust's include_bytes! macro. These are both ways to include a file full of data into your program - which if you're a C programmer you will know was really annoying to do cross-platform before #embed In C23 the data is just some literals like 1, 86, 69, 204 that are promised to be one unsigned byte each and you do with them whatever you want. How long do they live? -shrug- in some sense forever, but, then again maybe not, it depends. But in Rust it's specifically &'static [u8; N] -- a reference to an array of N bytes which has the 'static lifetime, it lives potentially for the life of your program.
pjmlp 4y ago
Until security liabilty clauses affect all kind of software, just like they affect physical goods. If people don't put up with buying a defect pair of shoes, they should behave the same towards software.
dmitrygr 4y ago
> How much longer are we going to put up with this? Until you rewrite it all in rust
nix23 4y ago
Stop lamenting and help X.org, i am pretty sure they have nothing against if you re-implement stuff in rust. Also, why have you forgot telling linus in 1991, that he should implement linux in something like ADA?

Forever. Computers are fundamentally unsafe if you tell them to do something you shouldn't have. That's true for every language which has ever been useful.

flangola7 4y ago
Formal verification is a thing. Good architectures make undesirable action rare. What's the last time you heard about a worm that spreads from one Android phone to the next, without the owners realizing it?
- mavhc 4y ago
  Given that the majority of android phones have dozens of well known security flaws (because they don't get updates, or get them very late), it's kinda weird they're not all one massive botnet. Why is that?
  - flangola7 4y ago
    Mostly because the underlying design makes that difficult. On a traditional desktop an application running as root can do anything, and one running as user can do slightly less than everything. On Android running as root doesn't even exist as a function, and running as user comes with significant limitations enforced structurally by low level SELinux code in the kernel and OS. Android malware can't infect an existing application because the OS both segregates their storage and verifies code signatures. TPMs take this a step further and create not only logical but physical separation between the main CPU and many cryptographic functions. Exploits still happen but you need a much longer chain of vulnerabilities to pull it off.
- mort96 4y ago
  Are you claiming the entirety of Android is formally verified? Do you have links to those papers?
  - flangola7 4y ago
    No, I'm claiming Android has good architecture. If you combined good arch with verification then exploits would be very rare indeed.
woodruffw 4y ago
This isn’t a meaningful response: “the computer does what you tell it to do” doesn’t mean the same thing as “the computer ends up in an exploitable state when you don’t tell it to do the right thing.”
- mort96 4y ago
  Yet computers necessarily end up in an exploitable state when you don't tell them to do the right thing. Your back-end is written in Rust? If you don't do your auth checks right, one user can delete another user's content.
  - majewsky 4y ago
    Sure, but given a fixed probability of introducing a bug at each possible place, "doing an auth check correctly" has much less probability of being buggy than "doing every memory allocation correctly" because it happens in several magnitudes less places.
    - deleted 4y ago
      [deleted]
  - woodruffw 4y ago
    No, not necessarily: Rust is by no means the first language to prevent missing bounds checks from becoming exploitable memory unsafety, as just one small example. All programs are exploitable; the objective is to limit the nature and scope of their exploitability.
kaba0 4y ago
Just because we can’t go 100% safe, we shouldn’t even try? That’s a logical fallacy right there.
- mort96 4y ago
  I'm not saying we shouldn't make safer languages. Rust is okay.

Cthulhu_ 4y ago

This comment adds nothing tbh; you're mentioning a known problem, but repeating the problem and asking open-ended questions isn't going to solve it. The solutions are there and people are working on them, but this isn't an overnight change.

quotemstr 4y ago
> The solutions are there and people are working on them People keep writing new programs in C.
- yeenieee 4y ago
  What other options are there? It's the only systems level language with a formally verified compiler afaik. rust is a no go because you can't trust the compiler's output (remember, we can't trust people to write correct code, so we obviously can't trust the compiler writers either).
  - lapinot 4y ago
    Both formally proven compilers and black-box SMT-based translation verification are a thing. Rust is not there yet but both exist for C.
  - antientropic 4y ago
    The vast majority of C programmers do not use a formally verified C compiler, and most of them wouldn't care about that anyway. From a security perspective, demanding a formally verified C compiler is rearranging the deck chairs on the Titanic. Switching to a safer language like Rust will do much more to improve security, even if the compiler is not verified.
  - kaba0 4y ago
    The biggest formally verified program is tiny compared to your regular software suit. That method simply doesn’t scale. Also, it “trusts the hardware” which itself can be (surprisingly) buggy. So there is no 100% safe solution, should we not even try to better our softwares then? Trusting trust is an interesting paper, but it was never meant as a gotcha, it was meant as a “don’t forget to look at the whole picture from time to time”.

notorandit 4y ago

Memory safe languages rely on someone else's software and someone else's compiler/interpreter. Rust and go are memory safe languages because their compiler are (said to be) checking all memory usage either statically or dynamically. It's still software written by someone, running on hardware designed by someone. If I write software in assembler I can just blame myself and the hardware. If I do it in C I can blame myself, the hardware, the compiler and the libraries. If I do it in Java I need to add the JRE and all the Java libraries, plus C etc. Memory safeness is just an illusion to me or a way to avoid responsibilities in case of issues.

flangola7 4y ago
And yet companies like Google have reported significant drops in memory related vulnerabilities.
- blackhaz 4y ago
  I wonder if there ever could be a C compiler doing all those checks. What is so radically different about Rust?
  - woodruffw 4y ago
    As a single example: C’s semantics prevent perfect alias analysis, meaning that a C compiler (no matter how smart) can never provide many of Rust’s basic guarantees without significantly altering the C language.
  - tialaramex 4y ago
    The lifetime analysis is only possible in Rust because Rust has lifetimes. Even if you write a toy Rust program where you didn't apparently write any lifetimes, they were implied and the implied lifetimes were checked - the language was constrained by the fact you didn't specify a lifetime and so the implied lifetime was checked, whereas in C you can't express the lifetime and so it can't be checked. The most glorious example of this is comparing C23's #embed with Rust's include_bytes! macro. These are both ways to include a file full of data into your program - which if you're a C programmer you will know was really annoying to do cross-platform before #embed In C23 the data is just some literals like 1, 86, 69, 204 that are promised to be one unsigned byte each and you do with them whatever you want. How long do they live? -shrug- in some sense forever, but, then again maybe not, it depends. But in Rust it's specifically &'static [u8; N] -- a reference to an array of N bytes which has the 'static lifetime, it lives potentially for the life of your program.

pjmlp 4y ago

Until security liabilty clauses affect all kind of software, just like they affect physical goods. If people don't put up with buying a defect pair of shoes, they should behave the same towards software.

dmitrygr 4y ago

> How much longer are we going to put up with this? Until you rewrite it all in rust

nix23 4y ago

Stop lamenting and help X.org, i am pretty sure they have nothing against if you re-implement stuff in rust. Also, why have you forgot telling linus in 1991, that he should implement linux in something like ADA?