3 ms·

Can you please expand on > Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea afaik, it depends on how you use Ru

Can you please expand on > Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea afaik, it depends on how you use Ruby right? I agree that using metaprogramming could lead to issues, but i would like to hear your view points on security?

Yoric 4y ago
I assume this is because the number of properties that can be statically audited in Ruby (or in most dynamic programming languages) is extremely small wrt what you can do in strongly-typed programming languages such as Rust, Ada, Haskell, OCaml, F#, ... Static audits (including, but not limited to static typing) are very strong barriers against entire classes of safety issues. Not supporting them doesn't automatically make code bad, but it prevents lots of defense-in-depth (what the Rust community calls "fearless programming").
- UncleMeat 4y ago
  Unfortunately, there are a lot of overloaded terms. Languages like Ruby are indeed nightmares for static analysis. Even constructing a call graph is a disaster. But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Do you want to prove that your Ruby program won't crash? Good luck. But do you want to prove that your Ruby program won't read key material out of memory when it shouldn't? Pretty easy. The security problems in these sorts of managed languages tend to either be logical errors (also present in a C++ codebase) or dynamic code loading / unsafe deserialization (not present often in C++ codebases, but much easier to eliminate in principle).
  - Yoric 4y ago
    For what it's worth, I am not attempting to compare Ruby (or generally dynamic languages) to C++. I am comparing Ruby to statically, strongly-typed languages. C++ is statically typed but is generally not a strongly-typed language, since there are many ways to escape strong typing, either willingly (e.g. with a cast to `void*`) or by accident (e.g. through UB). > But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Good remark. However, as a former safety (not security) researcher, it feels to me like the consensus in some parts of the security community is that once you have lost safety guarantees (i.e. you're not sure what your program is going to do), you have lost this entire line of defense and need to move to the next one (e.g. containerization). Example: Python has a very clear syntax and it is often easy to audit code to find out whether the algorithm implemented matches the specifications. However, Python is also a language in which `True`, `False` or integer literals can be redefined dynamically. So, with this in mind, how can you be sure that your Python code that appears to calculate fibonacci is not going to actually `ctype` into something memory-unsafe that could be used to escape into the shell? Of course, this example (and anything analogous in other dynamic languages) requires active malicious intent by the author of the code or one of the module it uses, but it's not too hard to come up with examples that end up with OS or XSS injections, without malicious intent by the code author. I believe that we both agree that these examples are safety issues escalating into security issues.*

Yoric 4y ago

I assume this is because the number of properties that can be statically audited in Ruby (or in most dynamic programming languages) is extremely small wrt what you can do in strongly-typed programming languages such as Rust, Ada, Haskell, OCaml, F#, ... Static audits (including, but not limited to static typing) are very strong barriers against entire classes of safety issues. Not supporting them doesn't automatically make code bad, but it prevents lots of defense-in-depth (what the Rust community calls "fearless programming").

UncleMeat 4y ago
Unfortunately, there are a lot of overloaded terms. Languages like Ruby are indeed nightmares for static analysis. Even constructing a call graph is a disaster. But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Do you want to prove that your Ruby program won't crash? Good luck. But do you want to prove that your Ruby program won't read key material out of memory when it shouldn't? Pretty easy. The security problems in these sorts of managed languages tend to either be logical errors (also present in a C++ codebase) or dynamic code loading / unsafe deserialization (not present often in C++ codebases, but much easier to eliminate in principle).
- Yoric 4y ago
  For what it's worth, I am not attempting to compare Ruby (or generally dynamic languages) to C++. I am comparing Ruby to statically, strongly-typed languages. C++ is statically typed but is generally not a strongly-typed language, since there are many ways to escape strong typing, either willingly (e.g. with a cast to `void*`) or by accident (e.g. through UB). > But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Good remark. However, as a former safety (not security) researcher, it feels to me like the consensus in some parts of the security community is that once you have lost safety guarantees (i.e. you're not sure what your program is going to do), you have lost this entire line of defense and need to move to the next one (e.g. containerization). Example: Python has a very clear syntax and it is often easy to audit code to find out whether the algorithm implemented matches the specifications. However, Python is also a language in which `True`, `False` or integer literals can be redefined dynamically. So, with this in mind, how can you be sure that your Python code that appears to calculate fibonacci is not going to actually `ctype` into something memory-unsafe that could be used to escape into the shell? Of course, this example (and anything analogous in other dynamic languages) requires active malicious intent by the author of the code or one of the module it uses, but it's not too hard to come up with examples that end up with OS or XSS injections, without malicious intent by the code author. I believe that we both agree that these examples are safety issues escalating into security issues.*