Not only did Multics happened, even without the help of Bell Labs, a later DoD security assessment proved that thanks to the fact of Multics being written in PL/I it wasn't susceptible to the security exploits that plague UNIX clones to this day.
> The call stack grew from lower addresses to higher, making it less likely that a buffer overrun would damage a return address pointer.
I believe that's from Jerome Saltzer's 1974 paper (https://multicians.org/saltzer-pacisim.pdf) but I can't for the life of me find it in there today. I know I've read it in the past.
Two things about that:
1. They knew about buffer overflows, and had them despite writing everything in PL/1 (or whatever). Buffer overflows may be endemic to C programs, but they're not limited to C programs.
2. HP's "HP-PA" RISC architecture had the same stack up/heap down behavior. I found HP's software to be so old that development on HP-UX was a chore, but maybe someone who has done more could address how many buffer overflows became security problems.
Sure bound exploits aren't limited to C, however there is a big difference between having them in easily locatable unsafe blocks, or areas where one has to explicitly disable them, and having every line of code being a possible source of exploits due to either memory corruption or UB.
According to Google's security team 68% of security exploits in Linux kernel are caused by buffer overflows. Check their talk at Linux Kernel Summit 2018.
At Linux Kernel Summit 2019, they have a couple of newer statistics and are adding hardware memory tagging to Android, based on their collaboration with ARM. And Android's native code (including NDK) are probably the most locked down after OpenBSD, in terms of security frameworks that can't be turned off.
SPARC Solaris, is the only other UNIX that can actually tame C security issues, and even ADI doesn't cover 100% of all possible cases.
Reading the Multics B2 security analysis reveals that the review team did find security holes in Multics which were fixed as part of the review process.
Recently, a buffer overflow vulnerability was found in the Multics CKermit implementation, despite it's being written in PL/I.
Security is hard, and is achieved through good programming, not by (just) trusting tools.
I guess it was in unsafe code with disabled bounds checking, which in C is every line of code.
