In the majority of places in your code, manual memory management gives you no benefit but does expose you to a possible vulnerability if you make a mistake. If the default, lazy option were to let the well-tested runtime do the job for you, yet you could do a little extra work and get manual override wherever you wanted, and manual override everywhere brought you essentially back to C, I think we would have much safer code without a noticeable loss of performance.
Edit: I just realized in the shower that I was saying "memory management" when I meant direct "memory manipulation" more generally. I'm including arrays accessed by memory address rather than by bounds-checked index, pointer arithmetic, etc., not just malloc and free.
That's true, but I would claim something even stronger. Getting safety doesn't mean giving up manual memory management, as Rust shows (disclaimer: I work on Rust). You just have to need to have a language or system that enforces that you use safe manually-managed idioms. The idea that safety requires giving up performance (e.g. opting into a garbage collector, or even a runtime) is not true in most cases. In a properly designed system, safety doesn't even require opting into a runtime.
The reverse situation, garbage-collecting systems that do nothing to prevent you from dereferencing null pointers or going out of bounds, is just as dangerous as C.
Air gap AND lasers, how cool is that?
I'll bet it was ocspd they exploited. The CRL handling code in libsecurity is awful, and ocspd runs as root without a sandbox profile.
% ps aux|grep ocspd
root 534 0.0 0.0 2442712 2036 ?? Ss 3:53PM 0:00.04 /usr/sbin/ocspd
% grep -A3 ProgramArguments /System/Library/LaunchDaemons/com.apple.ocspd.plist
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/ocspd</string>
</array>
pgrep -lf -U root | grep processname
or:
ps aux | grep root | grep processname
http://www.pwn2own.com/2014/03/pwn2own-results-thursday-day-...