5 ms·

Along with a legal battle I hope these companies are engaging in a technical battle as well. Because suppressing NSO using legal means will not make the vulnera

Along with a legal battle I hope these companies are engaging in a technical battle as well. Because suppressing NSO using legal means will not make the vulnerabilities go away -- it will still be there, waiting to be exploited by someone else. Microsoft for example has 30+ year old C/C++ code in Office applications that customers install on their machines. This is an attack vector. Adobe Acrobat is another well known attack vector. These products should be rewritten in a safer language, like Rust. Roughly 70% of the security issues seen by Microsoft are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. See: https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... These companies should be held accountable for not investing in securing their code, instead of brushing them under the carpet and pretending that breaches are simply law-and-order issues, or that we need more laws to solve the problem.

adamc 6y ago
Rewriting in Rust, however, would likely introduce many new bugs, as most rewrites do. The economics of it would be terrible.
- flowerlad 6y ago
  Yes, fixing security bugs may introduce functionality bugs. But that's not a reason to not fix security bugs. Yes, the economics of it would not be great, which is why these companies are not already doing it. But someone else is paying the price, when information systems are compromised and data is stolen. We have to exact a heavy penalty on tech companies each time that happens, until the penalties change the economics.
  - Rexxar 6y ago
    Fixing security bugs by changing everything may also introduce new security bugs.
    - flowerlad 6y ago
      If you hesitate to fix security bugs out of fear of introducing new security bugs that's the point at which you have to hire better programmers.
      - Rexxar 6y ago
        > If you hesitate to fix security bugs out of fear of introducing new security bugs I never say that. But maybe you just don't need to rewrite the whole project to fix some bugs? Sometime it is maybe the right answer but it should not be the default answer.
      - AnimalMuppet 6y ago
        But you're going to introduce them anyway. Sure, hire the best programmers that you can. But recognize that your rewrite is going to introduce new bugs (funny, your answer to that was "deal with it" instead of "hire better programmers"). And recognize that, better programmers or no, some of those new bugs are going to be security bugs. Now, that may still be better than the current situation. But glibly saying "just hire better programmers" means you're hiding your head in the sand.
        weswpg 6y ago
        Taking precautions can always backfire but would you argue that the status quo is preferable to taking those precautions in this case?
        AnimalMuppet 6y ago
        flowerlad seems to have the position that only security bugs matter; other bugs can be dealt with. I disagree with that position - non-security bugs can also be devastating. Second, even if you accept the starting position, I disagree with the idea that re-writing C++ code in Rust will remove all the security bugs. So there's two categories of "taking those precautions". One is "fix security bugs", which, yes, of course take those precautions. But the second category of "taking those precautions" is "re-write the whole thing in Rust". That's much more questionable whether it's worth it. How much time and effort will the rewrite take? What else could those people do with that much time? How bad are the security holes? How bad will it be to introduce the new bugs? What fraction of security holes will be closed by the rewrite? flowerlad's idea seems to be that, in light of this latest attack, it's worth going to any lengths to fix every security hole. I think that idea is mistaken. And, which software are we talking about? The network stack? Excel? Everything ever written in C/C++? The trade-offs are different for each piece of software. And if the answer is "everything", that sounds like roughly a decade of work for the entire software engineering workforce. That seems totally unrealistic, even in light of this latest attack. Look, the attack was huge. I'm not trying to minimize it at all. But it still isn't worth the measures that flowerlad proposes.
  - Arainach 6y ago
    What's the bigger threat - a theoretical unknown vulnerability in Excel or very real consequence of the entire economy and government grinding to a halt when their Excel macros and Word 97 VBA don't work with the rewritten codebase?
    - flowerlad 6y ago
      You don't rewrite the entire codebase overnight, or even in a single release. Instead, rewrite 10% of the code in 1 year, and within 10 years the entire product will be rewritten.
      - Arainach 6y ago
        You have no idea of the size or complexity of the Office codebase. It's enormous and external developers have taken hard dependencies on every aspect of it, even undocumented behavior. Therr aren't enough Rust experts in the world, much less at Microsoft, to review code changes at that rate. https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41363 https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41... - there are probably just as many companies relying on old Office docs as old Windows programs at this point Rewrites are always a bad idea. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
        flowerlad 6y ago
        So leave it to customers to deal with security breaches arising from use of your software, in perpetuity?
        Arainach 6y ago
        You fix things as they are discovered, continue adding more static analysis to catch new classes of issue, and continue on. You don't rewrite - certainly not in a new language with all new problems. This isn't a startup with 10 developers - there are literally thousands of developers working on Office and all sorts of internal tooling built around the codebase.
soared 6y ago
> potential security issue > rewrite entire codebase
sn_master 6y ago
Rewriting isn't the solution to everything, unless the code is really small and well-contained. High-profile security bugs were found in programs written in C# and Java and every other "safe" language out there. The unknown-unknowns are often far worse than what you currently have. Check the Uber Swift rewrite horror that was posted last week, and that was a super tiny app compared to even the smallest Office app. Another critical factor is: C++ is currently the only true "portable" language out there, that can be compiled into Windows/Mac/iOS/Android and everything else that exists or will come up in the future. Nothing else comes even close in terms of native platform support. And its completely unrealistic to have copies with different languages for each platform like "small" apps do like Uber or Facebook. We're talking about business logic that if it isn't exactly the same everywhere (with its bugs), people can lose billions of dollars. Even if Rust can compile into all of those platforms, I assure you, there will be dozens of very serious compiler bugs that will be uncovered over time if an app the size of Office gets rewritten into it. A good number of those will be of serious security consequences. Hell, back in the day, Excel had its own C++ compiler because of compiler bugs that couldn't be fixed on time!
- Shared404 6y ago
  > C++ is currently the only true "portable" language out there, I thought that was C? Or am I misunderstanding, and you're using C++ because it's more advanced and can still be used anywhere C can?
  - a1369209993 6y ago
    Microsoft is somewhat notorious for not correctly supporting C in Visual Studio. There's MinGW, which basically works, but it arguably doesn't count as 'native' support. I've heard people claim that recent versions of VS are better, but I've also heard people claim that they just corrupted the standards process to get everything they didn't support relegated to optional extensions, so... [shrug].
    - asddubs 6y ago
      you can also use clang these days without MinGW AFAIK
justapassenger 6y ago
If you think that rewriting huge legacy software that's powering most of the world in a current hot language is a solution to security issues, you clearly have no idea about software security.
- chuckSu 6y ago
  This!
Traster 6y ago
>These products should be rewritten in a safer language, like Rust. Sorry, but get over yourself. Firstly, if stuff had been written in Rust it would have been written 30 years after it was relevant. Secondly, if you're expecting companies to re-write code after 30 years to make it safer and do a good job? Good luck. There's a handful of people on the planet capable of doing it, there's a handful of people on the planet willing to do it, and there's 0 overlap between the two. If these companies were seriously held accountable for bug free code, there wouldn't be better code, there would be a lot less code. Entire applications just wouldn't exist. Dozens of products would've died due to dev costs.

adamc 6y ago

Rewriting in Rust, however, would likely introduce many new bugs, as most rewrites do. The economics of it would be terrible.

flowerlad 6y ago
Yes, fixing security bugs may introduce functionality bugs. But that's not a reason to not fix security bugs. Yes, the economics of it would not be great, which is why these companies are not already doing it. But someone else is paying the price, when information systems are compromised and data is stolen. We have to exact a heavy penalty on tech companies each time that happens, until the penalties change the economics.
- Rexxar 6y ago
  Fixing security bugs by changing everything may also introduce new security bugs.
  - flowerlad 6y ago
    If you hesitate to fix security bugs out of fear of introducing new security bugs that's the point at which you have to hire better programmers.
    - Rexxar 6y ago
      > If you hesitate to fix security bugs out of fear of introducing new security bugs I never say that. But maybe you just don't need to rewrite the whole project to fix some bugs? Sometime it is maybe the right answer but it should not be the default answer.
    - AnimalMuppet 6y ago
      But you're going to introduce them anyway. Sure, hire the best programmers that you can. But recognize that your rewrite is going to introduce new bugs (funny, your answer to that was "deal with it" instead of "hire better programmers"). And recognize that, better programmers or no, some of those new bugs are going to be security bugs. Now, that may still be better than the current situation. But glibly saying "just hire better programmers" means you're hiding your head in the sand.
      - weswpg 6y ago
        Taking precautions can always backfire but would you argue that the status quo is preferable to taking those precautions in this case?
        AnimalMuppet 6y ago
        flowerlad seems to have the position that only security bugs matter; other bugs can be dealt with. I disagree with that position - non-security bugs can also be devastating. Second, even if you accept the starting position, I disagree with the idea that re-writing C++ code in Rust will remove all the security bugs. So there's two categories of "taking those precautions". One is "fix security bugs", which, yes, of course take those precautions. But the second category of "taking those precautions" is "re-write the whole thing in Rust". That's much more questionable whether it's worth it. How much time and effort will the rewrite take? What else could those people do with that much time? How bad are the security holes? How bad will it be to introduce the new bugs? What fraction of security holes will be closed by the rewrite? flowerlad's idea seems to be that, in light of this latest attack, it's worth going to any lengths to fix every security hole. I think that idea is mistaken. And, which software are we talking about? The network stack? Excel? Everything ever written in C/C++? The trade-offs are different for each piece of software. And if the answer is "everything", that sounds like roughly a decade of work for the entire software engineering workforce. That seems totally unrealistic, even in light of this latest attack. Look, the attack was huge. I'm not trying to minimize it at all. But it still isn't worth the measures that flowerlad proposes.
- Arainach 6y ago
  What's the bigger threat - a theoretical unknown vulnerability in Excel or very real consequence of the entire economy and government grinding to a halt when their Excel macros and Word 97 VBA don't work with the rewritten codebase?
  - flowerlad 6y ago
    You don't rewrite the entire codebase overnight, or even in a single release. Instead, rewrite 10% of the code in 1 year, and within 10 years the entire product will be rewritten.
    - Arainach 6y ago
      You have no idea of the size or complexity of the Office codebase. It's enormous and external developers have taken hard dependencies on every aspect of it, even undocumented behavior. Therr aren't enough Rust experts in the world, much less at Microsoft, to review code changes at that rate. https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41363 https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41... - there are probably just as many companies relying on old Office docs as old Windows programs at this point Rewrites are always a bad idea. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
      - flowerlad 6y ago
        So leave it to customers to deal with security breaches arising from use of your software, in perpetuity?
        Arainach 6y ago
        You fix things as they are discovered, continue adding more static analysis to catch new classes of issue, and continue on. You don't rewrite - certainly not in a new language with all new problems. This isn't a startup with 10 developers - there are literally thousands of developers working on Office and all sorts of internal tooling built around the codebase.

soared 6y ago

> potential security issue > rewrite entire codebase

sn_master 6y ago

Rewriting isn't the solution to everything, unless the code is really small and well-contained. High-profile security bugs were found in programs written in C# and Java and every other "safe" language out there. The unknown-unknowns are often far worse than what you currently have. Check the Uber Swift rewrite horror that was posted last week, and that was a super tiny app compared to even the smallest Office app. Another critical factor is: C++ is currently the only true "portable" language out there, that can be compiled into Windows/Mac/iOS/Android and everything else that exists or will come up in the future. Nothing else comes even close in terms of native platform support. And its completely unrealistic to have copies with different languages for each platform like "small" apps do like Uber or Facebook. We're talking about business logic that if it isn't exactly the same everywhere (with its bugs), people can lose billions of dollars. Even if Rust can compile into all of those platforms, I assure you, there will be dozens of very serious compiler bugs that will be uncovered over time if an app the size of Office gets rewritten into it. A good number of those will be of serious security consequences. Hell, back in the day, Excel had its own C++ compiler because of compiler bugs that couldn't be fixed on time!

Shared404 6y ago
> C++ is currently the only true "portable" language out there, I thought that was C? Or am I misunderstanding, and you're using C++ because it's more advanced and can still be used anywhere C can?
- a1369209993 6y ago
  Microsoft is somewhat notorious for not correctly supporting C in Visual Studio. There's MinGW, which basically works, but it arguably doesn't count as 'native' support. I've heard people claim that recent versions of VS are better, but I've also heard people claim that they just corrupted the standards process to get everything they didn't support relegated to optional extensions, so... [shrug].
  - asddubs 6y ago
    you can also use clang these days without MinGW AFAIK

justapassenger 6y ago

If you think that rewriting huge legacy software that's powering most of the world in a current hot language is a solution to security issues, you clearly have no idea about software security.

chuckSu 6y ago
This!

Traster 6y ago

>These products should be rewritten in a safer language, like Rust. Sorry, but get over yourself. Firstly, if stuff had been written in Rust it would have been written 30 years after it was relevant. Secondly, if you're expecting companies to re-write code after 30 years to make it safer and do a good job? Good luck. There's a handful of people on the planet capable of doing it, there's a handful of people on the planet willing to do it, and there's 0 overlap between the two. If these companies were seriously held accountable for bug free code, there wouldn't be better code, there would be a lot less code. Entire applications just wouldn't exist. Dozens of products would've died due to dev costs.