3 ms·

Can you clarify why memory safety isn't your main problem? Do you just mean that UB isn't your biggest problem, or that memory safety isn't your biggest source

Can you clarify why memory safety isn't your main problem? Do you just mean that UB isn't your biggest problem, or that memory safety isn't your biggest source of UB? The latter sounds unlikely, and the former is interesting as all the code I give away for free gets used by people who very much care if it has UB.

uecker 2y ago
When we talk to companies that are in the business of helping other companies that were hacked, the stories we hear are never that they were hacked by some 0-day in the Linux kernel or a server software caused by some memory-safety issue. Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part.
- lelanthran 2y ago
  > Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part. Last I checked (a few months ago) 8 out of 10 breaches were due to human error. As far as reducing breaches go, you'll get more bang for your buck by ensuring employees are up to date on their routine security awareness training. Your employees are much much easier to hack than your computers. "Choice of language" is a blip in the stats.
- adrianN 2y ago
  > because some did not install updates of some component on the webserver But how many of those updates fix memory issues?
  - galangalalgol 2y ago
    I guess his point is that these bugs get found and patches are available before most people have to worry about it, because people don't burn zero day exploits unless it is very likely to net them more than the price of a zero day. But the people who handle enough value that they are worth a zero day still often use the same kernel, so they have an interest in paying to secure it. And separately, the people willing to burn a zero day are likely to be more careful in maintaining their access undetected, sometimes inserting evidence ahead of an investigation to indicate a different compromise route to preserve their zero day and potentially their access. And even if we are finding all these UB vulnerabilities before they get used, that is a giant cost we don't have to pay in new projects of we start them with something like rust. The infamous learning curve isn't a thing of you are coming from modern c++. I have never come across someone coming from c++ that didn't take to it immediately. Modern c might be a different story but I doubt it. Rewriting things should be reserved for codebases that are small, high risk, producing lots of vulnerabilities, or some combination of those. Unless someone just wants to do it for fun.
bluGill 2y ago
Most security breeches find vulnerabilities in humans not their computers. Yes if you find a software (or hardware) vulnerability that you can exploit you can get many many computers are once, but those are much harder to find. However the vast majority are not from that source. There is a lot we can do in UX to make human vulnerabilities less common, but no language change will help.
- unboundedjiure 2y ago
  Are you sure about that? Throughout auditing a lot of codebases in my lifetime I've found loads of ways to bypass authentication, spoof identity, cause denial of service in every one. These are very big and widely used applications with a lot of userbase. While unauthorized people waltzing on in to company premises hasn't not happened, it's been way rarer than the amount of serious bugs or security flaws I find. Traditional phone and email scams happen more often, but their impact has materialized much less severe thanks to very limited user privileges
  - bluGill 2y ago
    Phone and email scams happen far more often than you think and the people doing them have gotten much better at looking real over time.
    - unboundedjiure 2y ago
      For better or for worse we've received substantially less international scam attempts due to the seemingly intractable problem of writing them in our language and the relatively small pool of viable targets, but the ones we do get are usually well-crafted and targeted. We run loads of internal email scams ourselves trying to see why people trip, and try to improve our practices based on those findings. Currently there has been negligible impact on any of the products I've looked over because of traditional human scams. Conversely there have been significant troubles from real exploits being found and abused in the wild with dire consequences for legal and financial, but maybe my experience just happens to heavily skew the opposite of norm?. I expect things to change in the medium-term future as LLMs and such improve so that they can generate coherent text above a single sentence

uecker 2y ago

When we talk to companies that are in the business of helping other companies that were hacked, the stories we hear are never that they were hacked by some 0-day in the Linux kernel or a server software caused by some memory-safety issue. Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part.

lelanthran 2y ago
> Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part. Last I checked (a few months ago) 8 out of 10 breaches were due to human error. As far as reducing breaches go, you'll get more bang for your buck by ensuring employees are up to date on their routine security awareness training. Your employees are much much easier to hack than your computers. "Choice of language" is a blip in the stats.
adrianN 2y ago
> because some did not install updates of some component on the webserver But how many of those updates fix memory issues?
- galangalalgol 2y ago
  I guess his point is that these bugs get found and patches are available before most people have to worry about it, because people don't burn zero day exploits unless it is very likely to net them more than the price of a zero day. But the people who handle enough value that they are worth a zero day still often use the same kernel, so they have an interest in paying to secure it. And separately, the people willing to burn a zero day are likely to be more careful in maintaining their access undetected, sometimes inserting evidence ahead of an investigation to indicate a different compromise route to preserve their zero day and potentially their access. And even if we are finding all these UB vulnerabilities before they get used, that is a giant cost we don't have to pay in new projects of we start them with something like rust. The infamous learning curve isn't a thing of you are coming from modern c++. I have never come across someone coming from c++ that didn't take to it immediately. Modern c might be a different story but I doubt it. Rewriting things should be reserved for codebases that are small, high risk, producing lots of vulnerabilities, or some combination of those. Unless someone just wants to do it for fun.

bluGill 2y ago

Most security breeches find vulnerabilities in humans not their computers. Yes if you find a software (or hardware) vulnerability that you can exploit you can get many many computers are once, but those are much harder to find. However the vast majority are not from that source. There is a lot we can do in UX to make human vulnerabilities less common, but no language change will help.

unboundedjiure 2y ago
Are you sure about that? Throughout auditing a lot of codebases in my lifetime I've found loads of ways to bypass authentication, spoof identity, cause denial of service in every one. These are very big and widely used applications with a lot of userbase. While unauthorized people waltzing on in to company premises hasn't not happened, it's been way rarer than the amount of serious bugs or security flaws I find. Traditional phone and email scams happen more often, but their impact has materialized much less severe thanks to very limited user privileges
- bluGill 2y ago
  Phone and email scams happen far more often than you think and the people doing them have gotten much better at looking real over time.
  - unboundedjiure 2y ago
    For better or for worse we've received substantially less international scam attempts due to the seemingly intractable problem of writing them in our language and the relatively small pool of viable targets, but the ones we do get are usually well-crafted and targeted. We run loads of internal email scams ourselves trying to see why people trip, and try to improve our practices based on those findings. Currently there has been negligible impact on any of the products I've looked over because of traditional human scams. Conversely there have been significant troubles from real exploits being found and abused in the wild with dire consequences for legal and financial, but maybe my experience just happens to heavily skew the opposite of norm?. I expect things to change in the medium-term future as LLMs and such improve so that they can generate coherent text above a single sentence