4 ms·

Yeah. The language you pick doesn't magically make you Fort Knox regardless of "memory safety". Rewind in time and the White House would be berating all of us

by throw7 3y ago

Yeah. The language you pick doesn't magically make you Fort Knox regardless of "memory safety". Rewind in time and the White House would be berating all of us to write in Java... you know... a "memory safe" language, only for the worst security fail to come along Log4Shell.

kstrauser 3y ago
I don't like Java. Nothing about it appeals to me. It pains my eyes to look at it. And in spite of my distaste for it, I respect that it completely eliminates giant classes of vulnerabilities. You can write bad logic in any language. At least in Java you can't write bad logic that also suffers from memory issues.
- owlstuffing 3y ago
  > At least in Java you can't write bad logic that also suffers from memory issues. Oh you bet you can. There are a number of ways to screw that up. - memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs - using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly - using native calls incorrectly can be just as nasty
  - ttfkam 3y ago
    I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare). (Cue the one weird guy coming out of the woodwork who claims that all of his Java projects in the last 10 years have used Unsafe to great effect.)
    - owlstuffing 3y ago
      > Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Your project may not use it directly, but there’s a pretty good chance one of your libraries does.
      - ttfkam 3y ago
        And when I code in C, there's typically at least one library with inline assembly even though my C doesn't use any inline assembly. There is indeed a difference here between the vast majority taking part in risky behavior and library authors using focused performance improvements. There are a lot more eyes on the library code due to downstream effects than in everyday top-level code.
marcus0x62 3y ago
But language and tooling can protect you from error classes, and when the error class (“memory safety”) factors in up to 70% of security vulnerabilities (by some estimates,) it makes sense to pay attention to tools which can protect you from those errors, rather than lament the lack of protection for the other 30% or errors, which, by the way, could have just as easily happened in a language without strong memory safety protections.
- bobba27 3y ago
  70% sounds a bit high but I can accept it. You can do a lot in regards to memory safety also in C / C++ : https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf Anyway. Writing safe code in C is HARD but possible. Especially with good tooling. That is not to say everyone should use C. C is an exceptionally hard language to use safely and correctly and is not for everyone.
  - marcus0x62 3y ago
    > 70% sounds a bit high but I can accept it One meta-source for this is Prossimo[0]. They link to multiple vendor reports that range from 60 - 90%. > Writing safe code in C is HARD but possible. Especially with good tooling. I don’t disagree in theory, but I think it is so hard as to be impractical in almost every case. So, other than maintaining a legacy code base, why try at this point when other options are available? 0 - https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities https://www.memorysafety.org/docs/memory-safety/#how-common-...
    - hgs3 3y ago
      > So, other than maintaining a legacy code base, why try at this point when other options are available? What options would you recommend in 2024? I write C (not C++) and work on projects that are inherently memory unsafe (the last one required hand-written assembly code). I've explored potential C successors in the past, but have yet to discover one that matches the freedoms, simplicity, ergonomics, and performance of the C language.
pizlonator 3y ago
Yeah the logging bug was bad. That’s one bad bug. C++ has bugs that bad that are found and weaponized daily. So, Java is much safer probably by 2-3 orders of magnitude. Also - the log4j thing shows just how dangerous class loading is. It’s an eval like mechanism. Probably future languages designed with safety in mind should avoid eval-like mechanisms as well as avoiding type system escape hatches.
- nneonneo 3y ago
  FWIW, class loading isn't necessary for log4j to be bad - unchecked Java deserialization is sufficient for pretty bad pwnage. So we really should add "no unchecked deserialization" to the list of things that a safe language should have. Java's biggest mistake here, IMHO, was to have a serialization setup that was based solely on a generic interface rather than having the caller declare up front what class it expects to see. In the latter case, so long as you aren't storing naked Object/Serializable fields, type limits strongly restrict the set of naughty objects that can show up in your deserialized object graph. Rust Serde gets this right.
  - pizlonator 3y ago
    What I mean by class loading being bad isn’t that it’s bad that you can load a new class, but that it’s possible to pass a string into an api and have that api vend you a class. That’s bad even if it’s a class that exists already and doesn’t need to be newly loaded. I think unchecked serialization is bad because it leads to that “given a string you get an instance of the class named by it” problem.
- ttfkam 3y ago
  Ha! Like C & C++ coders haven't been sending and receiving structs as byte streams over networks. Less common today to be sure, but that was a VERY common practice that obviously led to a lot of CVEs. C coders before the internet went public, working on Novell Netware networks were slinging structs willy-nilly over their token ring and thin net, let me tell you!
gonzo41 3y ago
That was a library bug, not a language bug. Allowing external logging configuration by default is not like having a buffer overflow issue.

by throw7 3y ago

kstrauser 3y ago

I don't like Java. Nothing about it appeals to me. It pains my eyes to look at it. And in spite of my distaste for it, I respect that it completely eliminates giant classes of vulnerabilities. You can write bad logic in any language. At least in Java you can't write bad logic that also suffers from memory issues.

owlstuffing 3y ago
> At least in Java you can't write bad logic that also suffers from memory issues. Oh you bet you can. There are a number of ways to screw that up. - memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs - using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly - using native calls incorrectly can be just as nasty
- ttfkam 3y ago
  I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare). (Cue the one weird guy coming out of the woodwork who claims that all of his Java projects in the last 10 years have used Unsafe to great effect.)
  - owlstuffing 3y ago
    > Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects. Your project may not use it directly, but there’s a pretty good chance one of your libraries does.
    - ttfkam 3y ago
      And when I code in C, there's typically at least one library with inline assembly even though my C doesn't use any inline assembly. There is indeed a difference here between the vast majority taking part in risky behavior and library authors using focused performance improvements. There are a lot more eyes on the library code due to downstream effects than in everyday top-level code.

marcus0x62 3y ago

But language and tooling can protect you from error classes, and when the error class (“memory safety”) factors in up to 70% of security vulnerabilities (by some estimates,) it makes sense to pay attention to tools which can protect you from those errors, rather than lament the lack of protection for the other 30% or errors, which, by the way, could have just as easily happened in a language without strong memory safety protections.

bobba27 3y ago
70% sounds a bit high but I can accept it. You can do a lot in regards to memory safety also in C / C++ : https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf Anyway. Writing safe code in C is HARD but possible. Especially with good tooling. That is not to say everyone should use C. C is an exceptionally hard language to use safely and correctly and is not for everyone.
- marcus0x62 3y ago
  > 70% sounds a bit high but I can accept it One meta-source for this is Prossimo[0]. They link to multiple vendor reports that range from 60 - 90%. > Writing safe code in C is HARD but possible. Especially with good tooling. I don’t disagree in theory, but I think it is so hard as to be impractical in almost every case. So, other than maintaining a legacy code base, why try at this point when other options are available? 0 - https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities https://www.memorysafety.org/docs/memory-safety/#how-common-...
  - hgs3 3y ago
    > So, other than maintaining a legacy code base, why try at this point when other options are available? What options would you recommend in 2024? I write C (not C++) and work on projects that are inherently memory unsafe (the last one required hand-written assembly code). I've explored potential C successors in the past, but have yet to discover one that matches the freedoms, simplicity, ergonomics, and performance of the C language.

pizlonator 3y ago

Yeah the logging bug was bad. That’s one bad bug. C++ has bugs that bad that are found and weaponized daily. So, Java is much safer probably by 2-3 orders of magnitude. Also - the log4j thing shows just how dangerous class loading is. It’s an eval like mechanism. Probably future languages designed with safety in mind should avoid eval-like mechanisms as well as avoiding type system escape hatches.

nneonneo 3y ago
FWIW, class loading isn't necessary for log4j to be bad - unchecked Java deserialization is sufficient for pretty bad pwnage. So we really should add "no unchecked deserialization" to the list of things that a safe language should have. Java's biggest mistake here, IMHO, was to have a serialization setup that was based solely on a generic interface rather than having the caller declare up front what class it expects to see. In the latter case, so long as you aren't storing naked Object/Serializable fields, type limits strongly restrict the set of naughty objects that can show up in your deserialized object graph. Rust Serde gets this right.
- pizlonator 3y ago
  What I mean by class loading being bad isn’t that it’s bad that you can load a new class, but that it’s possible to pass a string into an api and have that api vend you a class. That’s bad even if it’s a class that exists already and doesn’t need to be newly loaded. I think unchecked serialization is bad because it leads to that “given a string you get an instance of the class named by it” problem.
ttfkam 3y ago
Ha! Like C & C++ coders haven't been sending and receiving structs as byte streams over networks. Less common today to be sure, but that was a VERY common practice that obviously led to a lot of CVEs. C coders before the internet went public, working on Novell Netware networks were slinging structs willy-nilly over their token ring and thin net, let me tell you!

gonzo41 3y ago

That was a library bug, not a language bug. Allowing external logging configuration by default is not like having a buffer overflow issue.