3 ms·

The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes he

by franga2000 5y ago

The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes here]. I'd consider any language that enables the top 70% of vulnerabilities to happen to be unsafe. Maybe a safety ranking is in order? How many CVEs from [year], weighed by severity, are impossible to happen in [language]. Obviously this idea has serious problems, but you see my point: C would get a straight up zero, as it should! (well, not completely zero, as many vulns come from dependencies and C's complete lack of a package and dependency system is actually an advantage here)

lionkor 5y ago
An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe". Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy. I have no idea, honestly, how you would introduce a use-after-free bug with C++'s smart pointers. Its the lack of schooling, the lack of certification, and the lack of a safety-focused selection of applicants, not a language that you can write bad code in if you ignore all warnings and advice. Even rust has unsafe{}, but I dont see anyone complain when thats used to introduce safety issues, because "youre not supposed to do that, even though technically you could". You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something.
- michaelt 5y ago
  > Don't hire people who are under qualified. Its really that easy. I understand what you're saying, but I'm not sure I agree. For example, look at Google Chrome. They've got mountains of cash. They've got loads of people working for them, and loads of job applicants if they want more. They've got a strong business case to work on security. They've got in-house pen testers, and a bug bounty program. They've got code reviews. They can afford any static analyser on the market. They've got sandboxing. They've got open source so many eyes can spot bugs easily. They can dictate terms on requirements - if Chrome vetos a new web standard and it's as good as dead, and if Google decides plugins have got to go, they go. And they've got 177 CVEs so far in 2021 [1] - including such greatest hits as use-after-free, buffer overflows and out-of-bounds access. You and I think we're writing secure C++ - but if the best-resourced team in the world can't write secure C++, isn't it more likely we're just fooling ourselves? [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome
  - lionkor 5y ago
    You make a good point. There is a lot of evidence that it's not as easy as I make it seem. I might be wrong about this, too, but I think a lot of smaller companies have the really bad practices. Google shines as one of the major "suppliers" of C++ tooling, and their code quality is undeniably very high (considering the complexity of some of their codebases), but a lot of popular libraries are written by small teams, often not even under contract, and you end up with a lot of PR'ed stuff, which is great, but it needs to be thoroughly reviewed. A good example of "unqualified" PR's was that recent one with the malicious PR into the linux kernel by some university. It was caught, but it does make you wonder how many vulnerabilities make it through because of simply trusting "random unqualified people" too much.
  - sat0ri 5y ago
    So many CVEs are due to their bug bounty program, hackers are incentivized to sell vulnerabilities to Google rather than exploiting them. CVEs are publicly disclosed after they are fixed, of course.
    - cartoonworld 5y ago
      The CVEs are due to the bug reporting, the bugs are not. The point is that memory safety bugs are the gift that keeps on giving. You can throw as much money into the problem as you want, and the inherent complexity of memory management means you are still gonna ship bugs of all severity.
    - staticassertion 5y ago
      You could have made that argument a few years ago, before we started to see in-the-wild exploitation of these vulnerabilities.
- GoblinSlayer 5y ago
  >You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something. That's needless extremism, moderate programmers benefit from safety mechanisms, and you can't hire a lot of perfect programmers.

lionkor 5y ago

An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe". Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy. I have no idea, honestly, how you would introduce a use-after-free bug with C++'s smart pointers. Its the lack of schooling, the lack of certification, and the lack of a safety-focused selection of applicants, not a language that you can write bad code in if you ignore all warnings and advice. Even rust has unsafe{}, but I dont see anyone complain when thats used to introduce safety issues, because "youre not supposed to do that, even though technically you could". You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something.

michaelt 5y ago
> Don't hire people who are under qualified. Its really that easy. I understand what you're saying, but I'm not sure I agree. For example, look at Google Chrome. They've got mountains of cash. They've got loads of people working for them, and loads of job applicants if they want more. They've got a strong business case to work on security. They've got in-house pen testers, and a bug bounty program. They've got code reviews. They can afford any static analyser on the market. They've got sandboxing. They've got open source so many eyes can spot bugs easily. They can dictate terms on requirements - if Chrome vetos a new web standard and it's as good as dead, and if Google decides plugins have got to go, they go. And they've got 177 CVEs so far in 2021 [1] - including such greatest hits as use-after-free, buffer overflows and out-of-bounds access. You and I think we're writing secure C++ - but if the best-resourced team in the world can't write secure C++, isn't it more likely we're just fooling ourselves? [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome
- lionkor 5y ago
  You make a good point. There is a lot of evidence that it's not as easy as I make it seem. I might be wrong about this, too, but I think a lot of smaller companies have the really bad practices. Google shines as one of the major "suppliers" of C++ tooling, and their code quality is undeniably very high (considering the complexity of some of their codebases), but a lot of popular libraries are written by small teams, often not even under contract, and you end up with a lot of PR'ed stuff, which is great, but it needs to be thoroughly reviewed. A good example of "unqualified" PR's was that recent one with the malicious PR into the linux kernel by some university. It was caught, but it does make you wonder how many vulnerabilities make it through because of simply trusting "random unqualified people" too much.
- sat0ri 5y ago
  So many CVEs are due to their bug bounty program, hackers are incentivized to sell vulnerabilities to Google rather than exploiting them. CVEs are publicly disclosed after they are fixed, of course.
  - cartoonworld 5y ago
    The CVEs are due to the bug reporting, the bugs are not. The point is that memory safety bugs are the gift that keeps on giving. You can throw as much money into the problem as you want, and the inherent complexity of memory management means you are still gonna ship bugs of all severity.
  - staticassertion 5y ago
    You could have made that argument a few years ago, before we started to see in-the-wild exploitation of these vulnerabilities.
GoblinSlayer 5y ago
>You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something. That's needless extremism, moderate programmers benefit from safety mechanisms, and you can't hire a lot of perfect programmers.