News for hackers. Stuff that matters.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by koolba on Monday June 24, 2024 @09:10PM (#40783162)
> If I access memory I didn't allocate the OS shuts the program down.

The real problem is when you access memory that did allocate.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by dheera on Monday June 24, 2024 @10:16PM (#40783640)
So we need a new flag for gcc that writes zeros to any block of allocated memory before malloc returns, not a new language.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by KMag on Monday June 24, 2024 @11:22PM (#40784102)
You'd probably want an alternative libc implementation rather than a compiler flag.

However, calloc everywhere won't save you from smashing the stack or pointer type confusion (a common source of JavaScript exploits). Very rarely is leftover data from freed memory the source of an exploit.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by kelnos on Monday June 24, 2024 @11:25PM (#40784124)
That wouldn't make it safe. It would just make it crash in a different way, and still be vulnerable to exploitation by an attacker.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by saagarjha on Tuesday June 25, 2024 @04:25AM (#40785911)
We have that already. There are still other problems that exist.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by BlobberSnobber on Tuesday June 25, 2024 @06:31AM (#40786702)
If only the very competent people that decided to create Rust had thought of asking you for the solution instead...

Have a little humility.