This bug only applied to grub authentication, which isn't a widely used feature. And you could achieve the same result with boot from disk/USB if that is enabled.
The vuln doesn't give you access to the actual accounts on the computer.
Yes - from what I recall there was not even a pretense of security. Everything was just unencrypted FAT (VFAT rather than FAT32) and if you logged in as one user all other user's data was clearly visible - it was just a means to have your own user workspace and customisations applied. Windows 95 and everything up to (not including) XP was a toy OS for home users ... If you wanted "grown up" features you had to go for NT.
I believe that was by design: the dialog was an opportunity to authenticate with the domain. If you just wanted local access you could hit cancel. Remember Win9x was not a secure OS itself.
Pretty sure I've seen a similar trick on XP or later as well. (I learned it from someone I didn't meet until long after I last saw a 95/98/2000 machine.)
I remember an article somewhere about these kinds of bugs. A lot of medical hardware/software combos are/can be compromised. And here comes the problem: do you disclose the vulnerabilities since it means potentially killing people? How long do you wait before manufacturers acknowledge and fix the problem (and they often don't)?
So yeah, these types of vulnerabilities are very very scary.
Honestly, I wouldn’t but that in the same class if bugs as those that preceded it because if the attacker he removed the HDD he will have access to your contents anyway (unless the HDD is encrypted) and it’s not a quick and convenient process either (unlike tapping backspace multiple times).
That said, I also don’t agree that this bug should never get fixed either.
This is a very naive estimation of what might happen when someone has access to all your running software. Since it is linux, it loads executables into memory and is able to run them even when they are deleted along with runtime dependencies.
Anything that caches anything to anywhere other than disk will be accessible. Your memcache, your redis, some databases, keychains, your non-userdata browser sessions.
I'm aware of that but it's a moot point because you'd be popping the storage device back in anyway. Which is why I didn't address that in my previous comment.
In any case, half the examples you've provided there are server specific and you really shouldn't be allowing untrusted physical access to your servers (nor running Xorg to be honest).
It's actually the opposite situation. Slackware's policy is to stick to the original software as distributed by the author with only minimal patching where necessary, so if a particular program (say, KDE) has a big support community, Slackware benefits from all those eyes on the code. This leads to a very mature and stable system at the expense of running older versions of software (though there's always the -current branch for those wishing to live on the edge).
Beyond this, the small but dedicated Slackware team is working daily to find and patch bugs when they do appear. You can look at the changelogs for examples of that workflow[1].
There's no such thing as a software project without bugs, but Slackware is consistently one of the most stable and robust OSes out there.
