3 ms·

America only seems to work on cash incentives, so they should make some hundred million dollars in grants or so for businesses to "invest" in rebuilding importa

America only seems to work on cash incentives, so they should make some hundred million dollars in grants or so for businesses to "invest" in rebuilding important infrastructure in memory safe languages. I'm not convinced of the memory safe language hype train honestly. Every single application could be 100% bulletproof and we would still live in a world where the CFO downloads a random exe from a phishing email and runs it with admin privileges. That still seems to be the main way institutions and people are compromised. We make jokes about "you can't defend yourself from a nation-state actor" but half the time the primary infection point for everything from North Korea to 15 year old Kevin playing with MyFirstRansomeware is to just put it in an email and let people do the work for you, or copy a log in page and let the user give you their credentials. Edit: lol people very very very angry that I dared to say "hey maybe rust ain't gonna save our world". Jesus guys. Have some nuance.

acdha 3y ago
> I'm not convinced of the memory safe language hype train honestly. Every single application could be 100% bulletproof and we would still live in a world where the CFO downloads a random exe from a phishing email and runs it with admin privileges. Well, if the CFO has admin you’ve already failed several audits but in general, yes, there are multiple categories of risk which you have to protect against. That doesn’t mean it’s not valuable to reduce one of them, however – in addition to the direct risk reduction, it also frees up time to work on the others.
- bongodongobob 3y ago
  You have to remember that most businesses don't perform any kind of security auditing whatsoever. Any non-tech business with 50 or less people has gaping security holes. I say that with absolute certainty.
  - b112 3y ago
    I saw someone running win98se 5 years ago, the box seething, writhing in pain with highly apparent malware, as a controller for industry grade, niche market machinery. It was network connected for "the IT company to log in and fix things", had software that would only work in win98se, and because the machine was "in the room", its browser was used because "convenient". No one cared. This is normalcy for most people. Even if the "it only works on bare metal" thing was true, and its hardware key device may make that a reality, there's zero reason to let people browse on it. Or leave it online 24x7, one could bring a switch port up/down when needed. Ah well. As you say, this is normal.
    - bongodongobob 3y ago
      Yep, especially in manufacturing. They still run windows XP machines because you can't upgrade the OS due to vendor specific hacks. It's either run XP or fork out a million dollars for an OS upgrade because they would need to replace the whole machine. I've supported many businesses like this.
  - acdha 3y ago
    True, but if the CFO is running with admin privileges how likely is it that they are otherwise enough on the ball security-wise to be writing or even making decisions about code in an unsafe language? The whole point of safety standards is to avoid everyone needing to be an expert in everything: I can look for a UL label and know that someone else has taken care of the basics, even though our CFO can still do something crazy like leaving his space heater running under a pile of newspaper. That doesn’t mean having the other safeguards wasn’t a good idea because they don’t solve every problem.
pjmlp 3y ago
Hopefully the CFO then gets shown the door and a possible lawsuit.
kokx 3y ago
Usually that CFO doesn't have admin privileges. However, the exe he ran could very easily make use of a privilege escalation exploit on a service that does run with admin privileges. An exploit that is a buffer overflow or otherwise an exploit that is possible due to memory safety issues. Or that exe tries to connect to other services in the network to exploit a buffer overflow on another system. An example of such an exploit was EternalBlue. So yes, you're probably right that from a purely external perspective, attackers are unlikely to gain initial access using exploits targeting memory safety. However, once they are in, there are all sorts of memory safety bugs that could be used.
munk-a 3y ago
Instead of a subsidy why not just make companies ineligible for security breach liability insurance if they continue to use a memory unsafe language. It'd be a quite trivial change and we'd see an immediate shift from the largest players with tooling improvements in newer languages and momentum causing smaller companies to follow suit.
hankchinaski 3y ago
It’s about reducing overall attack surface. Memory safety is better than not doing anything at all?
bongodongobob 3y ago
This is it. I think a lot of people here forgot that most businesses aren't huge corporations or tech oriented. Most businesses probably have less than 50 people and non-professional "IT Support" ie, the owners grandson who is "good with computers". The amount of door wide open security stances I've seen working with small to mid-size businesses is like 75%. The difficulty of prying local admin away from the owner of a concrete company is quite high. It's all very ephemeral and hard to explain to non-tech savvy people. Turning on MFA for everything possible, aggressive AV, social engineering/phishing training, and removing local admin daily drivers probably solves 99.99% of malware. Memory safe software would be great, yes, but it really isn't the problem.
- acdha 3y ago
  If the owner’s grandson is doing the IT they’re unlikely to be able to write or audit unsafe code, either. That means they need to be able to trust that their suppliers are using safe primitives. Memory safety is like requiring their electrician use use circuit breakers - no, it won’t protect every source of fire but we have codes specifically to avoid needing everyone to have expertise.
jerf 3y ago
Explain to me why you need a language that is pervasively memory unsafe. And be sure you don't cite reasons why you need unsafe callouts to unsafe capabilities. Nobody denies that. Explain why you need a language that is pervasively unsafe, unsafe by default. Explain to me what code you are writing that has to routinely access memory outside of arrays. Explain to me what code you are writing that simply must be able to use pointers to access memory in unsafe ways. In a nutshell, explain what these amazing benefits are to memory-unsafe languages that somehow offset the many and manifold costs we've found over years of usage. Memory safety in a modern language is not only virtually free, it's a positive benefit. I simple do not see an argument for memory unsafe languages, especially given that every single one of them ship with "unsafe" capabilities available on demand and fully documented. (Also recall "memory safe" does not imply Rust. Rust is a particularly strong language on that front, sure, but memory safety is basically every currently-used language except C and C++. People advocating for memory safety are not advocating for everything to be moved to Haskell or Rust.) So why? Why should we keep using memory unsafe languages? It's all cost and no benefit. Who wants that? (The only practical answer is "I've got a system here written in C/C++", and I concede the engineering pressures that can keep you there. But my personal opinion at this point is that greenfielding a project in C or C++ without adjoining a strong code analysis on day one is rapidly approaching, if not already reaching, professional negligence. And I've got my stink eye on C or C++ with strong code analysis.)
MattPalmer1086 3y ago
So bored of these "we don't need to fix this because of something else" arguments. And if the article was about the other thing, then we'd hear the opposite argument. Look - on the level of coding vulnerabilities, memory safety is by far the biggest problem. You want to talk about phishing attacks and privilege management, fine. There's a bunch of different controls for those. We would never address anything following the path of what-aboutism.

acdha 3y ago

> I'm not convinced of the memory safe language hype train honestly. Every single application could be 100% bulletproof and we would still live in a world where the CFO downloads a random exe from a phishing email and runs it with admin privileges. Well, if the CFO has admin you’ve already failed several audits but in general, yes, there are multiple categories of risk which you have to protect against. That doesn’t mean it’s not valuable to reduce one of them, however – in addition to the direct risk reduction, it also frees up time to work on the others.

bongodongobob 3y ago
You have to remember that most businesses don't perform any kind of security auditing whatsoever. Any non-tech business with 50 or less people has gaping security holes. I say that with absolute certainty.
- b112 3y ago
  I saw someone running win98se 5 years ago, the box seething, writhing in pain with highly apparent malware, as a controller for industry grade, niche market machinery. It was network connected for "the IT company to log in and fix things", had software that would only work in win98se, and because the machine was "in the room", its browser was used because "convenient". No one cared. This is normalcy for most people. Even if the "it only works on bare metal" thing was true, and its hardware key device may make that a reality, there's zero reason to let people browse on it. Or leave it online 24x7, one could bring a switch port up/down when needed. Ah well. As you say, this is normal.
  - bongodongobob 3y ago
    Yep, especially in manufacturing. They still run windows XP machines because you can't upgrade the OS due to vendor specific hacks. It's either run XP or fork out a million dollars for an OS upgrade because they would need to replace the whole machine. I've supported many businesses like this.
- acdha 3y ago
  True, but if the CFO is running with admin privileges how likely is it that they are otherwise enough on the ball security-wise to be writing or even making decisions about code in an unsafe language? The whole point of safety standards is to avoid everyone needing to be an expert in everything: I can look for a UL label and know that someone else has taken care of the basics, even though our CFO can still do something crazy like leaving his space heater running under a pile of newspaper. That doesn’t mean having the other safeguards wasn’t a good idea because they don’t solve every problem.

pjmlp 3y ago

Hopefully the CFO then gets shown the door and a possible lawsuit.

kokx 3y ago

Usually that CFO doesn't have admin privileges. However, the exe he ran could very easily make use of a privilege escalation exploit on a service that does run with admin privileges. An exploit that is a buffer overflow or otherwise an exploit that is possible due to memory safety issues. Or that exe tries to connect to other services in the network to exploit a buffer overflow on another system. An example of such an exploit was EternalBlue. So yes, you're probably right that from a purely external perspective, attackers are unlikely to gain initial access using exploits targeting memory safety. However, once they are in, there are all sorts of memory safety bugs that could be used.

munk-a 3y ago

Instead of a subsidy why not just make companies ineligible for security breach liability insurance if they continue to use a memory unsafe language. It'd be a quite trivial change and we'd see an immediate shift from the largest players with tooling improvements in newer languages and momentum causing smaller companies to follow suit.

hankchinaski 3y ago

It’s about reducing overall attack surface. Memory safety is better than not doing anything at all?

bongodongobob 3y ago

This is it. I think a lot of people here forgot that most businesses aren't huge corporations or tech oriented. Most businesses probably have less than 50 people and non-professional "IT Support" ie, the owners grandson who is "good with computers". The amount of door wide open security stances I've seen working with small to mid-size businesses is like 75%. The difficulty of prying local admin away from the owner of a concrete company is quite high. It's all very ephemeral and hard to explain to non-tech savvy people. Turning on MFA for everything possible, aggressive AV, social engineering/phishing training, and removing local admin daily drivers probably solves 99.99% of malware. Memory safe software would be great, yes, but it really isn't the problem.

acdha 3y ago
If the owner’s grandson is doing the IT they’re unlikely to be able to write or audit unsafe code, either. That means they need to be able to trust that their suppliers are using safe primitives. Memory safety is like requiring their electrician use use circuit breakers - no, it won’t protect every source of fire but we have codes specifically to avoid needing everyone to have expertise.

jerf 3y ago

Explain to me why you need a language that is pervasively memory unsafe. And be sure you don't cite reasons why you need unsafe callouts to unsafe capabilities. Nobody denies that. Explain why you need a language that is pervasively unsafe, unsafe by default. Explain to me what code you are writing that has to routinely access memory outside of arrays. Explain to me what code you are writing that simply must be able to use pointers to access memory in unsafe ways. In a nutshell, explain what these amazing benefits are to memory-unsafe languages that somehow offset the many and manifold costs we've found over years of usage. Memory safety in a modern language is not only virtually free, it's a positive benefit. I simple do not see an argument for memory unsafe languages, especially given that every single one of them ship with "unsafe" capabilities available on demand and fully documented. (Also recall "memory safe" does not imply Rust. Rust is a particularly strong language on that front, sure, but memory safety is basically every currently-used language except C and C++. People advocating for memory safety are not advocating for everything to be moved to Haskell or Rust.) So why? Why should we keep using memory unsafe languages? It's all cost and no benefit. Who wants that? (The only practical answer is "I've got a system here written in C/C++", and I concede the engineering pressures that can keep you there. But my personal opinion at this point is that greenfielding a project in C or C++ without adjoining a strong code analysis on day one is rapidly approaching, if not already reaching, professional negligence. And I've got my stink eye on C or C++ with strong code analysis.)

MattPalmer1086 3y ago

So bored of these "we don't need to fix this because of something else" arguments. And if the article was about the other thing, then we'd hear the opposite argument. Look - on the level of coding vulnerabilities, memory safety is by far the biggest problem. You want to talk about phishing attacks and privilege management, fine. There's a bunch of different controls for those. We would never address anything following the path of what-aboutism.