Justin Swartz wrote in <20260321201652.9287-1-justin.swartz () risingedge co za>: |Sat, 21 Mar 2026 19:00:13 +0100, Solar Designer wrote: |> On Sat, Mar 21, 2026 at 01:13:47PM -0400, kf503bla () k com wrote: |>> why assign cve to something irrelvent? |> |> I guess because (ir)relevance isn't among criteria for (not) assigning a |> CVE, and because there may be value in having a non-ambiguous way to |> refer to historical vulnerabilities for illustration of how the current |> ones fit in historical context. | |Beyond the historical context, there is an argument to be made |for being aware of known defects in legacy codebases which have |been resurrected for use on modern resource-constrained hardware.

I do not disagree with that. But regarding old Unix code the "great old ones upon which' shoulders we stand" (and luckily so, that is) themselves say ... please let me just quote Douglas McIlroy, who said (on January 5th on TUHS):

So somebody spotted a buffer overflow in v4.5, ironically in su.

Overflowable buffers were common in those days. It was all too easy when programming to shrug one's shoulders and opine that nobody would ever want to input a 200-character line, say, so why bother writing the extra code to catch it? We did gradually learn that automatically generated input lines--particularly lines of code--could be much longer than any person would write, so buffer overflows that actually happened gradually got fixed.

Dennis once fed a couple-of-thousand-byte line on standard input to everything in /bin. Crashes abounded, but so what? Wasn't a crash just an ungraceful way for a program to say "I can't handle this"? Not until the Morris worm (1988) did folks wake up to the real danger of overflows.

Sometime after Dennis's casual experiment, a paper that announced the same results got the reaction, "So what else is new?" from the Unix room. It would be interesting to find the paper and compare its "shocked, shocked" presentation to that of the rediscovery posted on the cryptography mailing list.

|For example, the RetroBSD [1] project provides a port of 2.11BSD |intended for PIC32 (MIPS) targets. There's also an actively |maintained RetroBSD fork, called DiscoBSD [2], which adds support |for STM32F4 (ARM Cortex-M4) targets and had its last release [3] |last month. | |And then there's Serge Vakulenko's LiteBSD [4], a 4.4BSD port to |PIC32. | |And who knows where Robert Nordier's port of UNIX V7, v7/x86 [5], |may be running?

The 2.11 BSD is also actively maintained; in fact patch #499 from January is huge (largest in ~30 years?, entire 4.4BSD I/O library ported back by ragge@ who maintains the PCC compiler).

|While these projects might modernize parts of the kernel and/or |userland, there's always the possibility of bug-ridden code (and |bug-ridden assumptions) being inherited from their respective BSD |and/or Research UNIX lineage - as we've all seen with BSD derived |telnet server and client implementations recently. | |Regards, |Justin | | |--- Links --- | |[1] https://retrobsd.org |[2] http://discobsd.org |[3] https://github.com/chettrick/discobsd/releases/tag/DISCOBSD26 |[4] https://github.com/sergev/LiteBSD |[5] https://www.nordier.com/#v7x86 --End of <20260321201652.9287-1-justin.swartz () risingedge co za>

--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

why assign cve to something irrelvent?

On Saturday, March 21st, 2026 at 5:14 AM, Alan Coopersmith <alan.coopersmithatoracle.comkf503bla () duck com> wrote: On 1/5/26 09:27, Alan Coopersmith wrote: Late last year, a tape was found containing the only known copy of Bell Labs Research Unix Version 4 from 1973 - the version in which UNIX was rewritten from assembly into the then-new C programming language. Since then a number of folks have been running the recovered software in PDP-11 simulators.

https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ examines the source code for su.c and shows that the buffer for password input is a simple 100 character array, but the loop to read password input has no boundary checks and will happily keep writing long past the end of the buffer. This has been assigned CVE-2025-71263 now: https://www.cve.org/CVERecord?id=CVE-2025-71263

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

On 1/5/26 09:27, Alan Coopersmith wrote: Late last year, a tape was found containing the only known copy of Bell Labs Research Unix Version 4 from 1973 - the version in which UNIX was rewritten from assembly into the then-new C programming language.  Since then a number of folks have been running the recovered software in PDP-11 simulators.

https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ examines the source code for su.c and shows that the buffer for password input is a simple 100 character array, but the loop to read password input has no boundary checks and will happily keep writing long past the end of the buffer. This has been assigned CVE-2025-71263 now: https://www.cve.org/CVERecord?id=CVE-2025-71263

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

In UNIX Fourth Research Edition (v4), the su command is vulnerable to a buffer overflow due to the 'password' variable having a fixed size of 100 bytes. A local user can exploit this to gain root privileges. It is unlikely that UNIX v4 is running anywhere outside of a very small number of lab environments. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

I believe the bug in su was found earlier; I remember that if you type a password and follow it with the encrypted password, you would get in. Looking at the code, you'd need to make sure that the encrypted password of the password you just typed in would need to be at position 105 (100+"root:")

Casper

From: Alan Coopersmith <alan.coopersmith () oracle com> Sent: 05 January 2026 18:27 To: oss-security () lists openwall com Subject: [External] : [oss-security] Buffer overflow in /bin/su from UNIX v4

Late last year, a tape was found containing the only known copy of Bell Labs Research Unix Version 4 from 1973 - the version in which UNIX was rewritten from assembly into the then-new C programming language. Since then a number of folks have been running the recovered software in PDP-11 simulators.

https://urldefense.com/v3/https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/;!!ACWV5N9M2RV99hQ!Px94aM2iBzLwDRhX4zhSX89cVDosduXv7mNqmv7HMgwJHi4FhtNHHhlzrhKONdsG8YQvXzRqmsruAgbbjwwY8jw3A$ examines the source code for su.c and shows that the buffer for password input is a simple 100 character array, but the loop to read password input has no boundary checks and will happily keep writing long past the end of the buffer.

Doug McIlroy from the original Bell Labs Unix team points out that "Overflowable buffers were common in those days." and that there are likely more to be found in the UNIX v4 source code, in the thread at https://urldefense.com/v3/https://www.tuhs.org/pipermail/tuhs/2026-January/032966.html;!!ACWV5N9M2RV99hQ!Px94aM2iBzLwDRhX4zhSX89cVDosduXv7mNqmv7HMgwJHi4FhtNHHhlzrhKONdsG8YQvXzRqmsruAgbbjwKopG4mw$

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Late last year, a tape was found containing the only known copy of Bell Labs Research Unix Version 4 from 1973 - the version in which UNIX was rewritten from assembly into the then-new C programming language. Since then a number of folks have been running the recovered software in PDP-11 simulators.

https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ examines the source code for su.c and shows that the buffer for password input is a simple 100 character array, but the loop to read password input has no boundary checks and will happily keep writing long past the end of the buffer.

Doug McIlroy from the original Bell Labs Unix team points out that "Overflowable buffers were common in those days." and that there are likely more to be found in the UNIX v4 source code, in the thread at https://www.tuhs.org/pipermail/tuhs/2026-January/032966.html

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Integer overflow in the envwrite function in the Alcatel-Lucent Bell Labs Plan 9 kernel allows local users to overwrite certain memory addresses with kernel memory via a large n argument, as demonstrated by (1) modifying the iseve function to gain privileges and (2) making the devpermcheck function grant unrestricted device permissions.