Fun fact: The VT-52 didn't have a loudspeaker for the bell sound. Instead, it had a electromechanical relay which was set up to self-oscillate.

"Typing a character produced a noise by activating a relay. The relay was also used as a buzzer to sound the bell character, producing a sound that "has been compared to the sound of a '52 Chevy stripping its gears."

> 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.

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.

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.

In the sense that the company I work for would be financially harmed if copyright infringement of software was freely allowed. I benefit from the ability of people being able to sell rights to use software.

It's one thing to digitize and archive ancient software, it's another thing to allow people to freely use it without acquiring the proper license for it.