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.
They were already mailing distribution tapes -- the software being run here was extracted off one of them (which had literally been lost in a store room for decades).
Anthropic's ahead of you -- the LLM that the reporters were interacting with here had an AI supervisor, "Seymour Cash", which uh... turned out to have some of the same vulnerabilities, though to a lesser extent. Anthropic's own writeup here describes the setup: https://www.anthropic.com/research/project-vend-2
Ummmm... yes. The problem with versioning file systems is that they only kept the last few versions; for files under active development, it was usually difficult to recover state older than a week or two.
(SCCS handled collaborative development and merges a lot worse than anything current, but... versioning file systems were worse there, too; one war story I heard involved an overenthusiastic developer "revising" someone else's file with enough new versions that by the time the original author came back to it, their last version of the code was unrecoverable.)
According to Wikipedia,there are apps that provide an emulated Android environment ("Easy Abroad", "Droitong"), they're incomplete and glitchy, and a lot of important apps won't run at all (including banking apps and streaming services).
If the libraries were missing entirely, I'm not sure 32-bit Firefox would even start. But if they were present and nothing was keeping them updated (pretty likely on an otherwise 64-bit system), they'd pretty likely become out of date -- which could certainly explain spurious crashes.
Fair point, although Firefox also launches subprocesses, and I don't know if those use same libraries as the main process. And I also don't know if it dynamically loads supporting libs after launch.
People go through all sorts of weird mental gymnastics about this. The FSF at one point took the position that binary blobs were cool so long as they could not be upgraded, because then you could pretend they weren't software at all, but just part of the wiring. I've seen this odd line of thought attributed to RMS himself, but here's an FSF statement, from when he was running it: https://www.fsf.org/blogs/community/task2-openmoko
WASM has a better security sandbox. (Designed in from the beginning, not the thousand-fingers-in-the-dike retrofit that was the Java SecurityManager -- which was eventually deprecated and abandoned along with the Applet tech it was intended to support.)
The numbers are branding, not metrics on anything. You can't do math to, say, determine the capability jump between GPT-4 and GPT-4o. Trying to do math to determine capability gaps between "3.7" and "4.0" doesn't actually make more sense.
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.
reply