> Bell Labs pulled out of the Multics program in 1969. Multics wasn't going to happen.
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.
I would argue that Multics security was due more to the ring and gate hardware architecture, that security was designed into the software from day 0 (rather then being grafted in afterwards), and code review practices.
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 particularly liked this item from the "b2.html" page:
> 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.
Surely they knew about buffer overflows, that is something that Burroughs B5500 (nowadays known as Unisys ClearPath) were already trying to tackle in 1961 with ESPOL/NEWP, and C.A.R Hoare has a couple of Algol-60 papers talking about safety and use of bounds checking as one of the preventive measures.
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.
5 comments
[ 8561 ms ] story [ 808 ms ] threadNot 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.
https://multicians.org/b2.html
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.
> 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.