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.
:|
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.
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.
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.
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.
Rust lets you write unsafe code, and as a matter of fact people are using unsafe abundantly.
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.