It reminds me of this MacOS bug from last year, where simply hitting the login box over and over with no password would eventually bypass the security entirely:
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.
I remember turning on my iPhone and briefly seeing a picture of myself from a time when I had not taken any photos of myself. In fact I had not been using the front facing camera at all.
I think user ‘sixothree’ was stating that a picture would show after unlocking the phone, not after a call. I myself, have had it happen to me several times couple months ago and thought it was really creepy. It almost seemed as if someone was using the front camera without my knowledge. Thought it to be glitch or something at that time.
I remember some people discovered that you could kill the xscreensaver lock screen on Debian with Alt+SysRq+F some years back. Well, a decade back actually — 2009.
A fee years ago, I discovered that if someone was running dual monitors and using XScreenlock, you could unplug one of the monitors and it would bypass the lock screen. I have no idea if this is still possible, I've not used XScreenlock since then.
On Windows 10, if you have dual screens and unplug one while the screen is locked, it will reconfigure the displays and give you a flash of what was under the lock screen. Hope you didn't leave anything sensitive on your screen!
I find those bugs less puzzling because the timeline makes sense. You're not logged in, there's a prompt, you're logged in. Obvious bug in the prompt, but the A happens before B happens before C order is there. Call comes in, audio is recorded, call is accepted is not the expected order. I could imagine a bug where declining the call still accepts the call, because that still obeys the proper ordering, but this bug does not.
I don’t use face time often, but isn’t there a "preview" of the camera feed during the prompt? I guess so that the user can check if he’s looking decent before engaging the call.
The bug could then be that the feed is sent over the call too early instead of being used solely for this local feedback.
From the details, it sounds like "adding" the caller to the call before the call recipient accepts probably puts it in a weird state. Could be some kind of off-by-one error, where for some purposes Participant 2 is the caller and for some it's the recipient.
Yes, I experience this routinely. As do many other people at my company.
In particular it happens when attaching external monitors while the screen is locked. There's a flash of the unlocked desktop.
I am guessing this is because the screen lock is an application drawing over top of the monitor, like XScreensaver on Linux does. A more secure-by-default architecture would have screen locking built into the display server at some lower level: If the screen is not unlocked, it will not allow the data to be passed to the GPU. It's easy for me to arm-chair architect though.
There was one guy on reddit who had a scare when his computer flashed a picture of a dead person when shutting down, and he thought his computer was haunted. It turned out to be a frame from a youtube video he was watching earlier. It may be that macOS is not that good at clearing out GPU memory sometimes.
I have the exact opposite problem. When I reboot after system updates, half a dozen YouTube videos in Chrome tabs start playing over each other on the password screen. They get through about 20 seconds before I can stop the last of them.
Audio only on the password screen, but all audible.
I’ve long had a similar problem on iOS. Whenever I return to an app, I briefly see an image from a few minutes ago. Which can be bad if I’m showing the phone to someone that old state was exposing sensitive data.
I used to see this regularly but haven't noticed it in a long while. I always assumed they were doing something like a double-buffering type trick and switching framebuffers before wiping stale content from the destination.
https://www.theregister.co.uk/2017/11/28/root_access_bypass_...
And this other MacOS bug, also from last year, where the password hint would contain the plain text encryption password:
https://www.theregister.co.uk/2017/10/05/apple_patches_passw...
All within a month of each other.