5 ms·

Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. I work in a fairly large (for my country) fi

Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. I work in a fairly large (for my country) financial institution and the problems we deal with on a day to day basis are so far removed from buffer overflows that it's not even funny. We still have software running in excel macros that control web browsers via COM. C is nothing compared to the attack surface of that.

docandrew 4y ago
Ok, but why are the Excel macros so risky? It’s often because the underlying software or OS was written in C/C++.
- snicker7 4y ago
  You can be socially engineered to open a mallacious excel.
- delusional 4y ago
  What? No it isn't. It's because the users think they're opening a document to look at some data and suddenly it's an executable transferring money via their bank account. And that's all working as designed. Someone built it like that. There's no bug anywhere in that chain, just as extremely rickety system with no affordances for human intervention. No separation of what is trusted and what is not.
- Jtsummers 4y ago
  Excel macros are risky because they offer a kind of privilege escalation. Most Excel built-in functions (that is, what you write into the cells) have limited reach. They impact that cell and (by reference) other cells, but not the underlying filesystem and other things. Even looking at the database ones, I'm not seeing a single function that writes to the DB but plenty that read from it, that's "safe" in that it would be very hard to abuse these kinds of things to screw with other systems or the host system. But macros can run arbitrary code and access whatever the user can access in a way most Excel functions cannot and can trigger arbitrary effects. The equivalent of `rm -r ~/` is not possible in straight Excel, but is feasible with a macro. C and C++ have nothing to do with that, it's the underlying privilege model that permits it. There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.
  - docandrew 4y ago
    Broken security model/sandboxing aside (which is inexcusable), the use of C/C++ expands the attack surface - there are some excel exploits though that take advantage of C vulns like buffer overflows: https://www.exploit-db.com/exploits/18087 https://www.exploit-db.com/exploits/18087
  - P5fRxh5kUvp2th 4y ago
    > There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims. And this idea can be applied to so many things. Seriously, very often things have enough downsides that you don't need to exaggerate things that are not downsides. You're actually weakening your side by doing so because if people cannot trust even that bit of honesty, why would they trust anything you say? be trustworthy is the first rule in convincing others.
mejutoco 4y ago
OP is not claiming that it would reduce _all_ software security problems though, so this is a straw man (intentional or not). Even the analogy holds up in this regard: using other materials instead of asbestos does not remove all the construction problems. I think C has other things going for it (simplicity of the compiler), just wanted to point that out.
zamalek 4y ago
> Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. Getting rid of a class of errors (correctness) allows you to focus more on other errors (logical). It could be argued that it could slightly reduce the likelihood of the latter.
- P5fRxh5kUvp2th 4y ago
  Our industry went through this with the move to Java (and later .Net). "It will solve memory leaks!" ... "whoops, you can still leak memory in garbage collected languages, my bad everyone!".
  - bcrosby95 4y ago
    Both a paper cut and a gunshot wound bleed. It doesn't make them equal.
  - adgjlsfhk1 4y ago
    ditching C doesn't solve memory leaks but it does solve use after free. A memory leak is a performance problem that isn't generally exploitable. A use after free is almost always a security vulnerability.
    - P5fRxh5kUvp2th 4y ago
      quick, someone tell everyone locking up resources without releasing them isn't exploitable for bad actors.
      - worthless-trash 4y ago
        Memory leak is better than privesc in most cases of active exploitation.
    - ndriscoll 4y ago
      You can use resources after releasing them in pretty much any language. That's maybe not as dangerous as reinterpreting arbitrary memory, but then you can also use object pools for everything in C, which is what some very high performance code I used to work on did.
wizofaus 4y ago
Did you see the claim "70% of all security bugs are related to memory safety"? Which isn't to say 70% of successful exploitation of said bugs resulted in genuine harm, but low-level vulnerabilities in widely used system-level software (network stacks etc.) can potentially have devastating effects in the way an excel macro is unlikely to.
- delusional 4y ago
  What I'm trying to get at here is that security is not just "bugs". Nowhere in the excel macro hell that is my job are there any bugs. Using a macro to transfer money in and out of peoples accounts in bulk is bad design, It's insecure, and i have at times argued that it's unethical, but it is also not a bug, It's exactly how the system was designed to work. Edge was designed to embed an Internet Explorer OLE frame, and that frame was designed to have an IE7 compatibility mode. No part of that would count in the "70% of bugs" list. Moreover, almost no bugs are discovered in the actual reasonable software we have. That's not because we are the best engineers, or because we write it with the utmost care and attention to detail. It's because we're a total of 5 people (mostly a couple of years out of uni) looking at it. C, and other systems programming languages are greatly overrepresented in the corpus of software that is actually being combed through for bugs. Java and Cobol are heavily underrepresented. I want to make this clear again. I work in banking. If 2008 showed us anything it's that banking underpins most of our modern society so these quality issues are not unimportant, they can be devastating.
GeekyBear 4y ago
> Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. According to studies done at Google and Microsoft, about 70% of their serious security issues are a result of memory safety errors. >Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... and >Nearly 70% of the high severity security bugs in Chrome's code are memory unsafety problems, Google's engineers have revealed. https://tech.hindustantimes.com/tech/news/70-of-security-bugs-are-memory-safety-problems-chrome-71590483623525.html https://tech.hindustantimes.com/tech/news/70-of-security-bug...
- lelanthran 4y ago
  As has been pointed out repeatedly whenever this statistic is brought up in discussion, that figure is not indicative of much. And in discussions like this, it's verging on the dishonest - leading with a large number makes readers think that a large difference to bug count will result. > Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference. What's the total bug count? A codebase with 10000 bugs logged against it might have maybe 10[1] that are CVEs, of which, according to that statistic, only 7 would be fixed by moving to a safer language (either GC or Rust or similar). That's just not enough motivation for switching when the payoff for preventing "70% of CVEs" is so small it may never even happen. [1] I've worked on C codebases that were developed over a decade, and 1000:1 of all-bugs:memory-safety-bugs is a very conservative ratio. IME, it's been closer to 10000:1.
  - GeekyBear 4y ago
    > that figure is not indicative of much Microsoft does not appear to agree. >Mark Russinovich, the chief technology officer of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns. https://www.zdnet.com/article/programming-languages-its-time-to-stop-using-c-and-c-for-new-projects-says-microsoft-azure-cto/ https://www.zdnet.com/article/programming-languages-its-time...
stubish 4y ago
Nobody believes that all software security problems will be solved if we get rid of C. Nobody. Absolutely nobody. Really. What people do believe is it would remove whole classes of security problems that affect everybody. Even if you have software running in excel macros. Maybe in your environment that is a minority of your problems. That is probably not a good thing, and we feel for you, and respect preferring to tackle that problem first. But it would be a good idea to not entrench C further while you are doing that. Once you shrink your attack surface, it would be great if the code being invoked doesn't have exploitable memory overflows to make all your hard work pointless.

docandrew 4y ago

Ok, but why are the Excel macros so risky? It’s often because the underlying software or OS was written in C/C++.

snicker7 4y ago
You can be socially engineered to open a mallacious excel.
delusional 4y ago
What? No it isn't. It's because the users think they're opening a document to look at some data and suddenly it's an executable transferring money via their bank account. And that's all working as designed. Someone built it like that. There's no bug anywhere in that chain, just as extremely rickety system with no affordances for human intervention. No separation of what is trusted and what is not.
Jtsummers 4y ago
Excel macros are risky because they offer a kind of privilege escalation. Most Excel built-in functions (that is, what you write into the cells) have limited reach. They impact that cell and (by reference) other cells, but not the underlying filesystem and other things. Even looking at the database ones, I'm not seeing a single function that writes to the DB but plenty that read from it, that's "safe" in that it would be very hard to abuse these kinds of things to screw with other systems or the host system. But macros can run arbitrary code and access whatever the user can access in a way most Excel functions cannot and can trigger arbitrary effects. The equivalent of `rm -r ~/` is not possible in straight Excel, but is feasible with a macro. C and C++ have nothing to do with that, it's the underlying privilege model that permits it. There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.
- docandrew 4y ago
  Broken security model/sandboxing aside (which is inexcusable), the use of C/C++ expands the attack surface - there are some excel exploits though that take advantage of C vulns like buffer overflows: https://www.exploit-db.com/exploits/18087 https://www.exploit-db.com/exploits/18087
- P5fRxh5kUvp2th 4y ago
  > There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims. And this idea can be applied to so many things. Seriously, very often things have enough downsides that you don't need to exaggerate things that are not downsides. You're actually weakening your side by doing so because if people cannot trust even that bit of honesty, why would they trust anything you say? be trustworthy is the first rule in convincing others.

mejutoco 4y ago

OP is not claiming that it would reduce _all_ software security problems though, so this is a straw man (intentional or not). Even the analogy holds up in this regard: using other materials instead of asbestos does not remove all the construction problems. I think C has other things going for it (simplicity of the compiler), just wanted to point that out.

zamalek 4y ago

> Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. Getting rid of a class of errors (correctness) allows you to focus more on other errors (logical). It could be argued that it could slightly reduce the likelihood of the latter.

P5fRxh5kUvp2th 4y ago
Our industry went through this with the move to Java (and later .Net). "It will solve memory leaks!" ... "whoops, you can still leak memory in garbage collected languages, my bad everyone!".
- bcrosby95 4y ago
  Both a paper cut and a gunshot wound bleed. It doesn't make them equal.
- adgjlsfhk1 4y ago
  ditching C doesn't solve memory leaks but it does solve use after free. A memory leak is a performance problem that isn't generally exploitable. A use after free is almost always a security vulnerability.
  - P5fRxh5kUvp2th 4y ago
    quick, someone tell everyone locking up resources without releasing them isn't exploitable for bad actors.
    - worthless-trash 4y ago
      Memory leak is better than privesc in most cases of active exploitation.
  - ndriscoll 4y ago
    You can use resources after releasing them in pretty much any language. That's maybe not as dangerous as reinterpreting arbitrary memory, but then you can also use object pools for everything in C, which is what some very high performance code I used to work on did.

wizofaus 4y ago

Did you see the claim "70% of all security bugs are related to memory safety"? Which isn't to say 70% of successful exploitation of said bugs resulted in genuine harm, but low-level vulnerabilities in widely used system-level software (network stacks etc.) can potentially have devastating effects in the way an excel macro is unlikely to.

delusional 4y ago
What I'm trying to get at here is that security is not just "bugs". Nowhere in the excel macro hell that is my job are there any bugs. Using a macro to transfer money in and out of peoples accounts in bulk is bad design, It's insecure, and i have at times argued that it's unethical, but it is also not a bug, It's exactly how the system was designed to work. Edge was designed to embed an Internet Explorer OLE frame, and that frame was designed to have an IE7 compatibility mode. No part of that would count in the "70% of bugs" list. Moreover, almost no bugs are discovered in the actual reasonable software we have. That's not because we are the best engineers, or because we write it with the utmost care and attention to detail. It's because we're a total of 5 people (mostly a couple of years out of uni) looking at it. C, and other systems programming languages are greatly overrepresented in the corpus of software that is actually being combed through for bugs. Java and Cobol are heavily underrepresented. I want to make this clear again. I work in banking. If 2008 showed us anything it's that banking underpins most of our modern society so these quality issues are not unimportant, they can be devastating.

GeekyBear 4y ago

> Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. According to studies done at Google and Microsoft, about 70% of their serious security issues are a result of memory safety errors. >Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... and >Nearly 70% of the high severity security bugs in Chrome's code are memory unsafety problems, Google's engineers have revealed. https://tech.hindustantimes.com/tech/news/70-of-security-bugs-are-memory-safety-problems-chrome-71590483623525.html https://tech.hindustantimes.com/tech/news/70-of-security-bug...

lelanthran 4y ago
As has been pointed out repeatedly whenever this statistic is brought up in discussion, that figure is not indicative of much. And in discussions like this, it's verging on the dishonest - leading with a large number makes readers think that a large difference to bug count will result. > Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference. What's the total bug count? A codebase with 10000 bugs logged against it might have maybe 10[1] that are CVEs, of which, according to that statistic, only 7 would be fixed by moving to a safer language (either GC or Rust or similar). That's just not enough motivation for switching when the payoff for preventing "70% of CVEs" is so small it may never even happen. [1] I've worked on C codebases that were developed over a decade, and 1000:1 of all-bugs:memory-safety-bugs is a very conservative ratio. IME, it's been closer to 10000:1.
- GeekyBear 4y ago
  > that figure is not indicative of much Microsoft does not appear to agree. >Mark Russinovich, the chief technology officer of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns. https://www.zdnet.com/article/programming-languages-its-time-to-stop-using-c-and-c-for-new-projects-says-microsoft-azure-cto/ https://www.zdnet.com/article/programming-languages-its-time...

stubish 4y ago

Nobody believes that all software security problems will be solved if we get rid of C. Nobody. Absolutely nobody. Really. What people do believe is it would remove whole classes of security problems that affect everybody. Even if you have software running in excel macros. Maybe in your environment that is a minority of your problems. That is probably not a good thing, and we feel for you, and respect preferring to tackle that problem first. But it would be a good idea to not entrench C further while you are doing that. Once you shrink your attack surface, it would be great if the code being invoked doesn't have exploitable memory overflows to make all your hard work pointless.