More like the VT-05. The VT-52 came a few years later. But yeah, the VT-420 is way later.

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

I wrote a VT52 hardware simulation: https://github.com/larsbrinkhoff/terminal-simulator

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.

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.

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.

Well-known vulns are all over this code. For example, mkdir had a TOCTTOU which persisted into v7 (and I believe 2BSD); it was implemented as a setuid binary which did a mknod followed by a chown to create the directory. Code which invoked mkdir could set up a race replacing the root-owned directory, before the chown, with a link to something else -- which would then get chowned to the user running mkdir. The target had to be on the same filesystem as some writable directory, but on many installations of the day, a mkdir in /tmp followed by this race was good enough to get you ownership of /etc/passwd.

This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.

Exploiting this is close to trivial because the adjacent buffer contains the pw entry. So, you can control what the input is compared with. That way the password check can be bypassed without injecting code.

  0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345678901234567890123456789012345root:p3Y0ydAx:

/proc is only copied (and extended) by Linux. It was introduced in UNIX V8. It is also in Solaris and FreeBSD.