4 ms·

> Repeat after me: there is no silver bullet! There is no single silver bullet, but there exists silver bullets for a variety of problems. When was the last ti

by BoppreH 11y ago

> Repeat after me: there is no silver bullet! There is no single silver bullet, but there exists silver bullets for a variety of problems. When was the last time you saw a pure Python or pure Java code segfaulting from invalid memory accesses? When was the last time you saw a C/C++ code doing the same? It is simply negligent to use a language or system that exposes you to that many more classes of vulnerabilities. Imagine a language where the compiler randomly accesses another variable if you mistype a name. No error, you just get a random value. Would you defend such a language? "All languages have faults! There is no silver bullet!" Except for this* particular problem, there is a silver bullet. I agree wholeheartedly with your dismissal of rewriting battle tested code. But the need to migrate is clear, and we don't have to do it at once. It can be done slowly, one piece at a time. And it should be. * For non-trivial code exposed to untrusted input.

tomjen3 11y ago
I have segfaulted the Java vm plenty of times. Technically that is not pure Java code, because the vm is written in C++, but it was triggered by pure Java code. I don't use much complex code written in C++ that I can see crash, but I do remember Rails being very happy to execute whatever code you feed it as yaml. Ultimately every language will have bugs when people neglect to validate all possible user input. There is one class of bugs that typically doesn't happen outside C (segfaults) but I can't imagine a C version of Rails executing YAML as code - and at least the segfault is more difficult to exploit.
- BoppreH 11y ago
  > I can't imagine a C version of Rails executing YAML as code This is the crux of the matter, so please take a moment to reflect on why you believe that. Ruby code is used in much more dynamic environments; environments that would exist in some other language if Ruby didn't exist, and probably would show the same error. By choosing C you are not allowing some vulnerabilities to gain resistance against others. The gains are in other places: performance, code inertia. And that's the problem. You are deliberately sacrificing safety. Truth or not, that's why everyone is so pissed at this class of bugs.
- pcwalton 11y ago
  Nobody is saying (or, at least, nobody should be saying) that memory-safe languages don't have memory safety errors. The point, and this is empirically backed up by tons of data, is that remote code execution due to memory safety problems happens way way less in memory-safe languages.
takeda 11y ago
> When was the last time you saw a pure Python or pure Java code segfaulting from invalid memory accesses? When was the last time you saw Python or pure Java being used to write an interface between applications and kernel? Those are different languages made for different purposes. They have their own issues (from top of my head pickle module allows to execute code if served with untrusted input), and generally applications written in them are not as wildly deployed as glibc. Also it's kind of ironic to compare them because both Python and Java are written in C and C++.

by BoppreH 11y ago

tomjen3 11y ago

I have segfaulted the Java vm plenty of times. Technically that is not pure Java code, because the vm is written in C++, but it was triggered by pure Java code. I don't use much complex code written in C++ that I can see crash, but I do remember Rails being very happy to execute whatever code you feed it as yaml. Ultimately every language will have bugs when people neglect to validate all possible user input. There is one class of bugs that typically doesn't happen outside C (segfaults) but I can't imagine a C version of Rails executing YAML as code - and at least the segfault is more difficult to exploit.

BoppreH 11y ago
> I can't imagine a C version of Rails executing YAML as code This is the crux of the matter, so please take a moment to reflect on why you believe that. Ruby code is used in much more dynamic environments; environments that would exist in some other language if Ruby didn't exist, and probably would show the same error. By choosing C you are not allowing some vulnerabilities to gain resistance against others. The gains are in other places: performance, code inertia. And that's the problem. You are deliberately sacrificing safety. Truth or not, that's why everyone is so pissed at this class of bugs.
pcwalton 11y ago
Nobody is saying (or, at least, nobody should be saying) that memory-safe languages don't have memory safety errors. The point, and this is empirically backed up by tons of data, is that remote code execution due to memory safety problems happens way way less in memory-safe languages.

takeda 11y ago

> When was the last time you saw a pure Python or pure Java code segfaulting from invalid memory accesses? When was the last time you saw Python or pure Java being used to write an interface between applications and kernel? Those are different languages made for different purposes. They have their own issues (from top of my head pickle module allows to execute code if served with untrusted input), and generally applications written in them are not as wildly deployed as glibc. Also it's kind of ironic to compare them because both Python and Java are written in C and C++.