I'll split my response on the two topics, because they got lengthy.
Here's the first... (concerning a SunOS 4 issue and similar)

On 13.03.2025 14:01, Dan Cross wrote:

In article <vquhba$3817f$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

PS: On an old SunOS 4 SPARC system I was (without privileges) able to
even change the remote users system characteristics (like mouse speed),
but I suppose that must be considered a security issue on that platform.

I no longer recall how such things were controlled on SunOS 4,
but I imagine that you opened a device file and issued an ioctl
to control things like that. What this suggests to me is that
you were able to connect to some remote machine where the device
files in question were permitted so that you could open them and
issue those controls. Had they had more restrictive permissions
(say 0600 and owned by the logged-in user) then I suspect you
would not have been able to do that. But there were bugs in
SunOS 4, which came from a simpler time, so perhaps I'm wrong.

Actually I cannot recall the details from back these days. All I
can say is that we were able (without root access) to change some
configuration file on the target machine only by means available
through shell and with the tools available to run jobs remotely
on the distributed client systems. (We might have had root access
on our own workstation but I'm not sure about that.)

(For our long lasting simulation processes the department policy
was to be able to run software on other's Sun workstations to use
their CPU capacity overnight, when they were unused, or low on CPU
load.)

We couldn't believe that this was possible, though, to change the
hardware characteristics so easily, without effort and without any
special tools or privileges on the remote machines.

We set up an experiment (call it joke), creating a cronjob to do
that change temporarily; every hour we accelerated the mouse speed
of the remote systems for a few seconds only. We didn't think that
this would get noticed at all - most people in science used mostly
the keyboard and rarely the mouse. Alas, we produced sort of panic! Unfortunately my colleague and me, the "experimenters", were a day
off, and when we came back we heard that they thought to have some
security attack - and I have to admit, even if not intended as one,
it actually turned out to be one. And they intended to reboot all
systems (or even reinstall? don't recall), which of course would
not have fixed that behavior. (Needless to say that we instantly
deactivated that cronjob.)

I also think that this type of security issue would also be hard
to localize if you'd look only onto the target machines.

I do recall once crashing my boss's workstation by accident: his
name was Dave, and we found some audio clips in Sun audio format
of HAL from the movie "2001" saying, "I'm sorry, Dave, I can't
let you do that..." or "why don't you sit back, relax, and take
a stress pill..." and were having fun rsh'ing into his machine
and `cat`'ing them into `/dev/audio` there (so they played on
the builtin speaker, which of course was in his office. Note
that we could only do this because we had write access to the
audio device; we also had root access, so he couldn't depermit
it).

Our primary system administrator did that as well. After lunch he
invited us to the coffee break in his office by sending us an (coffee-)advertisement recording through the audio device. Imagine
such a distributed sound effect coming from every office on the
floor in parallel like a symphony (but less highbrow, more thin
brew like typical US coffee - sorry for the pun).

Anyway, we would do that, and get a file playing, and he'd kill
the process writing to the audio device, and the speech would
stop. So we kept escalating by trying newer, more creative ways
to buffer the audio data in the kernel before we he could kill
off the writing process. It seems we took this a little too far
though, as I tripped a bug in the audio driver (I think a NULL
op in the cdevsw used by some system call we were using that
wasn't implemented by the driver; the details are fuzzy now) and
it crashed his machine. I didn't realize this had happened, but
we all also ran little programs that `tail -f`'d the more
important log files consolidating important events from around
our network. So I saw his workstation rebooting and thought I'd
been so clever that the only way he could stop HAL was by
rebooting. Then I saw him log into my machine, which suddenly
rebooted. "Hey! What'd you do that for?!" I shouted across the
hall. "You did it to me!" he responded.

Of course, this was all in good fun, but we stopped trying to
prank each other with random audio files after that.

Thanks for sharing that story.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)