4 ms·

And that memory safety is completely not an issue if you're writing something like a game, trading system, simulation, internal application or science calculati

And that memory safety is completely not an issue if you're writing something like a game, trading system, simulation, internal application or science calculation where there's no potentially hostile users who could do real harm by hacking your code. It's just a class of bug that in modern C++ is generally far outnumbered by logic bugs.

zozbot234 2y ago
The issue of memory safety goes well beyond adversaries "hacking your code". Without memory safety, your code doesn't even have any kind of well-defined semantics so it's not feasible to defend against even "logic" bugs by automated means. If you care about program correctness in any real sense, memory safety is table stakes.
- uecker 2y ago
  No, this is not how it works. Even without memory safety, the code has well-defined semantics for correct input, i.e. input that does not trigger undefined behavior. And if you prove your program correct for all inputs, this then implies that it does not have undefined behavior for any input. Memory safety is not a prerequisite for applying formal methods to show correctness.
tsimionescu 2y ago
Games absolutely are a problem for lack of memory safety - because the majority of games played today are connected to the internet explicitly. For trading system I don't even know what you mean, but I can't think of a trading system where you wouldn't care about security. For simulations and scientific calculations, I do agree, to a vast extent. But in a world that is moving more and more towards zero-trust networking, even many of those will start being looked at as potential attack vectors into other systems.
- PLG88 2y ago
  I may be off base, but as the world moves to zero-trust networking, we can always embed a zero-trust network into our C++ app so that it can be distributed across the network while having no listening ports on the underlay network - i.e., my memory safety exploit cannot just be exploited by anyone on the WAN, LAN, or host OS network. My C++ app unattackable via conventional IP-based tooling, all conventional network threats are immediately useless. This capability exists in completely open source, such as OpenZiti - https://openziti.io/ https://openziti.io/.
  - AlotOfReading 2y ago
    The way C and C++ are standardized, you can't rely on the correct functioning of anything in the presence of undefined behavior, including memory unsafety. For what it's worth, I also opened a random file in the OpenZiti C SDK and immediately found safety issues like this: https://github.com/openziti/ziti-tunnel-sdk-c/blob/9993f61e6ad4c975147ab5b15593f1cec3705d3a/lib/ziti-tunnel/ziti_tunnel.c#L671 https://github.com/openziti/ziti-tunnel-sdk-c/blob/9993f61e6... That's why this topic is such a big deal. Even people who really should know better like the OpenZiti authors aren't able to reliably write safe code.
    - drivebyhooting 2y ago
      Why is that a safety issue?
      - AlotOfReading 2y ago
        Malloc/Calloc can fail even if they typically don't on most Linux systems. You should always check for null pointers before accessing the resulting buffer, which doesn't happen here. The connections() block is also never explicitly freed anywhere I was able to find in a quick search. That's allowed, but definitely bad practice.
  - SkiFire13 2y ago
    You'll still have to e.g. parse and interpret data from the internet if you want to communicate with anyone else, and that's a potential vector for an exploit. This has commonly be the way exploitations work in games.
- PaulDavisThe1st 2y ago
  As a DAW developer, I find myself chuckling over security concerns in other kinds of apps. You see, it is absolutely expected and required that our applications will load and run arbitrary 3rd party code, generally with the expectation that it lives in the same address space as our application (though this is not formally required). No sockets, no network, no backdoor hacks. You write code, call it a VST plugin, make it sound desirable ... we are expected to load and run it. Yes, several DAWs have made the move toward out-of-process execution of plugins, but that doesn't begin to address the myriad problems caused by loosely-written plugin APIs not adequately pinning down threading, thread priority, memory access and more. Filesystem access? Of course! That code runs as you! Because you want it to!
  - lmm 2y ago
    And when someone creates a project file that sends them the personal information of anyone who opens it, is that an issue? Yes, pervasive arbitrary code plugins are game over if you can get anyone to use your plugin, but there's at least some awareness that you need to be careful opening a plugin you don't trust.
    - PaulDavisThe1st 2y ago
      Not sure that's true for the majority of DAW users. Plugins are not associated with attack vectors, even though they are literally just that.

zozbot234 2y ago

The issue of memory safety goes well beyond adversaries "hacking your code". Without memory safety, your code doesn't even have any kind of well-defined semantics so it's not feasible to defend against even "logic" bugs by automated means. If you care about program correctness in any real sense, memory safety is table stakes.

uecker 2y ago
No, this is not how it works. Even without memory safety, the code has well-defined semantics for correct input, i.e. input that does not trigger undefined behavior. And if you prove your program correct for all inputs, this then implies that it does not have undefined behavior for any input. Memory safety is not a prerequisite for applying formal methods to show correctness.

tsimionescu 2y ago

Games absolutely are a problem for lack of memory safety - because the majority of games played today are connected to the internet explicitly. For trading system I don't even know what you mean, but I can't think of a trading system where you wouldn't care about security. For simulations and scientific calculations, I do agree, to a vast extent. But in a world that is moving more and more towards zero-trust networking, even many of those will start being looked at as potential attack vectors into other systems.

PLG88 2y ago
I may be off base, but as the world moves to zero-trust networking, we can always embed a zero-trust network into our C++ app so that it can be distributed across the network while having no listening ports on the underlay network - i.e., my memory safety exploit cannot just be exploited by anyone on the WAN, LAN, or host OS network. My C++ app unattackable via conventional IP-based tooling, all conventional network threats are immediately useless. This capability exists in completely open source, such as OpenZiti - https://openziti.io/ https://openziti.io/.
- AlotOfReading 2y ago
  The way C and C++ are standardized, you can't rely on the correct functioning of anything in the presence of undefined behavior, including memory unsafety. For what it's worth, I also opened a random file in the OpenZiti C SDK and immediately found safety issues like this: https://github.com/openziti/ziti-tunnel-sdk-c/blob/9993f61e6ad4c975147ab5b15593f1cec3705d3a/lib/ziti-tunnel/ziti_tunnel.c#L671 https://github.com/openziti/ziti-tunnel-sdk-c/blob/9993f61e6... That's why this topic is such a big deal. Even people who really should know better like the OpenZiti authors aren't able to reliably write safe code.
  - drivebyhooting 2y ago
    Why is that a safety issue?
    - AlotOfReading 2y ago
      Malloc/Calloc can fail even if they typically don't on most Linux systems. You should always check for null pointers before accessing the resulting buffer, which doesn't happen here. The connections() block is also never explicitly freed anywhere I was able to find in a quick search. That's allowed, but definitely bad practice.
- SkiFire13 2y ago
  You'll still have to e.g. parse and interpret data from the internet if you want to communicate with anyone else, and that's a potential vector for an exploit. This has commonly be the way exploitations work in games.
PaulDavisThe1st 2y ago
As a DAW developer, I find myself chuckling over security concerns in other kinds of apps. You see, it is absolutely expected and required that our applications will load and run arbitrary 3rd party code, generally with the expectation that it lives in the same address space as our application (though this is not formally required). No sockets, no network, no backdoor hacks. You write code, call it a VST plugin, make it sound desirable ... we are expected to load and run it. Yes, several DAWs have made the move toward out-of-process execution of plugins, but that doesn't begin to address the myriad problems caused by loosely-written plugin APIs not adequately pinning down threading, thread priority, memory access and more. Filesystem access? Of course! That code runs as you! Because you want it to!
- lmm 2y ago
  And when someone creates a project file that sends them the personal information of anyone who opens it, is that an issue? Yes, pervasive arbitrary code plugins are game over if you can get anyone to use your plugin, but there's at least some awareness that you need to be careful opening a plugin you don't trust.
  - PaulDavisThe1st 2y ago
    Not sure that's true for the majority of DAW users. Plugins are not associated with attack vectors, even though they are literally just that.