6 ms·

It's not urgently necessary since all modern systems have some form of simple address space randomization at prelink or exec. Considering the time and effort i

It's not urgently necessary since all modern systems have some form of simple address space randomization at prelink or exec. Considering the time and effort it would take to safely and completely replace glibc with a new implementation, and the limited scope of its effect on Internet-wide security, it would be more productive to require the kernel itself to support patches like PaX, Exec Shield, or grsec in general, so that all applications (not just ones made with a specific language) would have stack-smashing protection.

lmm 11y ago
None of those things is reliable. They make it harder to exploit this kind of vulnerability, but not impossible; usually they just add one extra required step to the exploitation.
- peterwwillis 11y ago
  Yes. It's called a mitigation, and it's what we do to make systems more secure. But they certainly can be reliable. The Internet has been using DNS resolvers known to be vulnerable to cache poisoning birthday attacks for at least 14 years. We add basic defenses that prevent the majority of attacks, and trudge on, rather than fix the protocol itself, which is a big complicated mess. The smaller, less effective fixes reach a broader number of use cases with less effort, and so we get along okay. Likewise, we know that no matter what language we use, there will be at some point a problem with regard to accessing memory, and so we put protections in place to limit the scope of those attacks in a broad sense. It's a more effective mitigation for a greater number of use cases. It is not a panacea.
  - lmm 11y ago
    I find that a lot of security vulnerabilities result from confusion about what side of a security boundary something is on. Treating a parameter as sorta-untrusted can be actively harmful if it leads someone to believe that parameter was supposed to be untrusted. I think it's much more effective to concentrate on strict, designed security boundaries that stop 100% of attacks than to create a bunch of ad-hoc 80% barriers.

lmm 11y ago

None of those things is reliable. They make it harder to exploit this kind of vulnerability, but not impossible; usually they just add one extra required step to the exploitation.

peterwwillis 11y ago
Yes. It's called a mitigation, and it's what we do to make systems more secure. But they certainly can be reliable. The Internet has been using DNS resolvers known to be vulnerable to cache poisoning birthday attacks for at least 14 years. We add basic defenses that prevent the majority of attacks, and trudge on, rather than fix the protocol itself, which is a big complicated mess. The smaller, less effective fixes reach a broader number of use cases with less effort, and so we get along okay. Likewise, we know that no matter what language we use, there will be at some point a problem with regard to accessing memory, and so we put protections in place to limit the scope of those attacks in a broad sense. It's a more effective mitigation for a greater number of use cases. It is not a panacea.
- lmm 11y ago
  I find that a lot of security vulnerabilities result from confusion about what side of a security boundary something is on. Treating a parameter as sorta-untrusted can be actively harmful if it leads someone to believe that parameter was supposed to be untrusted. I think it's much more effective to concentrate on strict, designed security boundaries that stop 100% of attacks than to create a bunch of ad-hoc 80% barriers.