3 ms·

The problem is not the language! If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the softwa

The problem is not the language! If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C. The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. The problem is that such a critical software (well, relatively critical, because if there is a bug in a security library nobody dies in the end) is not written to that standards.

anonymousiam 6y ago
Static analysis tools should also be a normal part of the development process regardless of the language being used. Unfortunately, the good tools cost money and that discourages developers (and managers) from using them.
pas 6y ago
> if there is a bug in a security library nobody dies in the end The University Hospital Düsseldorf (UKD) in Germany suffered a ransomware attack on September 10, 2020. The attackers exploited a vulnerability in the Citrix ADC that had been known since January but the hospital, unfortunately, had not got around to implementing the fix. Unfortunately, one patient with a life-threatening illness was diverted to a distant hospital after UKD was deregistered as an emergency care facility. The additional hour’s travel may have been the cause of the patient’s death. On September 18, 2020, German prosecutors launched an official negligent homicide investigation which, if confirmed, would make the patient’s death the first known case of death by hacking. :|
- vntok 6y ago
  Is Citrix ADC a security library?
  - formerly_proven 6y ago
    It’s a network security appliance - undoubtedly contains multiple security libraries.
m00dy 6y ago
yes, the problem is not the language. The problem is that OpenSSL has just became so important that It shouldn't not rely on C language any more. We have so much better tools now.
larodi 6y ago
Planes actually have major portions of the software written in non-C languages such as ADA - see https://www.manufacturing.net/aerospace/news/21175187/airbus-chooses-gnat-pro-ada-for-development-of-unmanned-aerial-system https://www.manufacturing.net/aerospace/news/21175187/airbus... And are very proud of it. Medical equipment is not all implemented in embedded C systems. And since modern embedded systems can easily run python or embedded JS versions, well, perhaps certain critical libs can actually get implemented in something that does not deal with memory... and the 5-10% penalty in performance is not going to be something anyone really notes.
jk7tarYZAQNpTQa 6y ago
> The problem is not the language! It is. A language that lets you write unsafe code is an unsafe language. > If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C. Citation needed. I would expect those programs to be written on a language with very strict types and no pointer arithmetic bullshit, like Ada. And even if some of these software pieces are written in C, (a) that's very bad, too, and (b) it may be more suitable for those scenarios. But a program that reads and parsers unlimited amounts of user input, supports an ever growing list of complex (and often improperly defined) protocols, and is edited/expanded/updated daily, is definitely not such a suitable scenario. > The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. Again, the problem is the language, not how you use it. If the security of a piece depends on how it is manipulated, it is by default insecure. A secure language shouldn't let users make mistakes (or at least avoid them to a very high degree, both in compilation and run time). And a library that is the backbone of the confidentiality and privacy of millions of people (and billions of dollars in businesses) should be written on a secure language.
- 0xdeaddeaf 6y ago
  > A language that lets you write unsafe code is an unsafe language. Rust lets you write unsafe code, and as a matter of fact people are using unsafe abundantly.
  - yholio 6y ago
    Yes, and unsafe Rust is an unsafe language. It's easy enough to detect it's use in a project so that it can be considered a language on it's own.
cameldrv 6y ago
Even safety critical software can run reliably for the range of inputs that it's likely to ever see, but contain security holes. For something like OpenSSL, it must produce a correct output for every single possible input. Even safety critical software may extremely rarely fail in unusual conditions. For security sensitive software though, all it takes is a single possible input that will trigger a bug, because the attacker is not a random process. Writing secure software in C is extremely difficult.
diegocg 6y ago
That's like having a field full of mines and then arguing that the field is not dangerous because you have a map of the mines. If you have to develop strict coding standards not just to write reliable code but to avoid the pitfalls of a language that others don't have, then that proves that the language sucks. We have languages that can provide certain levels of MISRA safety even if you are a novice programmer.Blaming the users for not following the correct guidelines (that barely anyone follows except for the people paid to follow them) completely misses the point.
SubjectToChange 6y ago
Out of interest, when would you say a language at fault for a security problem?

anonymousiam 6y ago

Static analysis tools should also be a normal part of the development process regardless of the language being used. Unfortunately, the good tools cost money and that discourages developers (and managers) from using them.

pas 6y ago

> if there is a bug in a security library nobody dies in the end The University Hospital Düsseldorf (UKD) in Germany suffered a ransomware attack on September 10, 2020. The attackers exploited a vulnerability in the Citrix ADC that had been known since January but the hospital, unfortunately, had not got around to implementing the fix. Unfortunately, one patient with a life-threatening illness was diverted to a distant hospital after UKD was deregistered as an emergency care facility. The additional hour’s travel may have been the cause of the patient’s death. On September 18, 2020, German prosecutors launched an official negligent homicide investigation which, if confirmed, would make the patient’s death the first known case of death by hacking. :|

vntok 6y ago
Is Citrix ADC a security library?
- formerly_proven 6y ago
  It’s a network security appliance - undoubtedly contains multiple security libraries.

m00dy 6y ago

yes, the problem is not the language. The problem is that OpenSSL has just became so important that It shouldn't not rely on C language any more. We have so much better tools now.

larodi 6y ago

Planes actually have major portions of the software written in non-C languages such as ADA - see https://www.manufacturing.net/aerospace/news/21175187/airbus-chooses-gnat-pro-ada-for-development-of-unmanned-aerial-system https://www.manufacturing.net/aerospace/news/21175187/airbus... And are very proud of it. Medical equipment is not all implemented in embedded C systems. And since modern embedded systems can easily run python or embedded JS versions, well, perhaps certain critical libs can actually get implemented in something that does not deal with memory... and the 5-10% penalty in performance is not going to be something anyone really notes.

jk7tarYZAQNpTQa 6y ago

> The problem is not the language! It is. A language that lets you write unsafe code is an unsafe language. > If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C. Citation needed. I would expect those programs to be written on a language with very strict types and no pointer arithmetic bullshit, like Ada. And even if some of these software pieces are written in C, (a) that's very bad, too, and (b) it may be more suitable for those scenarios. But a program that reads and parsers unlimited amounts of user input, supports an ever growing list of complex (and often improperly defined) protocols, and is edited/expanded/updated daily, is definitely not such a suitable scenario. > The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. Again, the problem is the language, not how you use it. If the security of a piece depends on how it is manipulated, it is by default insecure. A secure language shouldn't let users make mistakes (or at least avoid them to a very high degree, both in compilation and run time). And a library that is the backbone of the confidentiality and privacy of millions of people (and billions of dollars in businesses) should be written on a secure language.

0xdeaddeaf 6y ago
> A language that lets you write unsafe code is an unsafe language. Rust lets you write unsafe code, and as a matter of fact people are using unsafe abundantly.
- yholio 6y ago
  Yes, and unsafe Rust is an unsafe language. It's easy enough to detect it's use in a project so that it can be considered a language on it's own.

cameldrv 6y ago

Even safety critical software can run reliably for the range of inputs that it's likely to ever see, but contain security holes. For something like OpenSSL, it must produce a correct output for every single possible input. Even safety critical software may extremely rarely fail in unusual conditions. For security sensitive software though, all it takes is a single possible input that will trigger a bug, because the attacker is not a random process. Writing secure software in C is extremely difficult.

diegocg 6y ago

That's like having a field full of mines and then arguing that the field is not dangerous because you have a map of the mines. If you have to develop strict coding standards not just to write reliable code but to avoid the pitfalls of a language that others don't have, then that proves that the language sucks. We have languages that can provide certain levels of MISRA safety even if you are a novice programmer.Blaming the users for not following the correct guidelines (that barely anyone follows except for the people paid to follow them) completely misses the point.

SubjectToChange 6y ago

Out of interest, when would you say a language at fault for a security problem?