> the knowledge that a buffer overflow could be exploited for arbitrary code execution had not yet come of age.

Meaning, people hadn't figured that out, or it wasn't a commonplace technique? They must have seen buffer overflows crash running software; it doesn't take much imagination to think about the next steps.

This is Unix V4 from 1973. The total number of installations world wide was around 20, all inside Bell Labs. There was no networking support at all, so security was mostly physical, i.e., office building security (though you could dial in with a modem). Multi-user support was a bunch of serial-line terminals. Pretty much everyone knew everyone else who was on the system.

I'm not an expert, but a quick look at https://en.wikipedia.org/wiki/Buffer_overflow#History suggests that some people, at least, had figured it out by 1972 https://apps.dtic.mil/sti/citations/AD0772806 :

> By supplying addresses outside of the space allocated to the users program, it is often possible to get the monitor to obtain unauthorized data for that user, or at the very least, generate a set of conditions in the monitor that causes a system crash.

> In one contemporary operating system, one of the functions provided is to move limited amounts of information between system and user space. The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine.

(Volume 1 is at https://apps.dtic.mil/sti/citations/AD0758206 .) However general awareness of the security implications seems to have been very limited before the Morris worm, and then even for several years after that. Even in late 1996 an article which in its own words "attempt[ed] to explain what buffer overflows are, and how their exploits work" could still be published in Phrack magazine, and in fact even be quite a milestone https://en.wikipedia.org/wiki/Buffer_overflow#History . Some people had definitely been thinking about hardware bounds checking for a long time by then https://homes.cs.washington.edu/~levy/capabook/ but I don't know how much they'd specifically considered just this kind of security threat.

Most computers did not exist in an adversarial environment at the time.

Perhaps the most "adversarial" context would be: undergraduate timeshare use. So the mainframes of the day, which would be the typical platform for undergrad programming (if timeshare was even offered to undergrads in 1973) might be expected to be somewhat hardened to attacks of various kinds since undergrads trying to hack their grade higher, get more CPU time, etc, was a known thing.

But Unix machines, and minicomputers in general, were not used for undergrad purposes. They were only available to be used by PhD candidates and other higher order beings. Those dudes had the root password anyway, so no need to harden the machine against their potential attacks. There was no networking to speak of, so no malicious traffic to worry about. The first worm didn't appear until the late 1980s.

So if you had talked to a Unix sysadmin in 1973 (all...1 of them) they probably would understand the general concept of someone running a program that crapped onto kernel memory with the result they could have root privileges, but there would have been no plausible adversary around with any reason to mount that attack. Plus every cycle and every byte counted, so there would have been many more fish to fry before worrying about buffer overflow problems.

My Educated guess, both.

Malicious attempts at exploiting would require physical access.

This was 1970's running on a PDP hardware. These were not normally connected to the internet so the attack vector of attacking would be have literal.

Any bugs would probably been of been fixed prior to and isn't this the first alpha of unix? So probably patched later in versions.