Meanwhile, in KDE the lock screen is managed by KDE Session Management Server which ensures that lock screen cannot be bypassed by simply crashing its process.
The way it works is follows: ksmserver draws a black rectangle over everything and spawns kscreenlocker. If kscreenlocker crashes, the black rectangle is still here, and ksmserver will spawn kscreenlocker again but this time with software rendering (just in case it crashed due to graphics driver issue). If kscreenlocker crashes four times then KDE Session Management Server gives up, stops respawning kscreenlocker and simply draws the following text on the screen.
The screen locker is broken and unlocking is not possible anymore.
In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
log in and execute the command:
loginctl unlock-session %1
Afterwards switch back to the running session (Ctrl+Alt+F%2).
I'm not sure why GNOME screensaver cannot do something like this. Lock screen crashing seems like something inevitable (especially considering buggy graphic card drivers and so on), and it makes sense to prepare for it so that crashes won't bypass the screen locker.
The OS support multiple desktops. Similar to files or registry keys, desktops have security descriptors attached (a data structure keeping who’s the owner, and optionally listing users/groups with their respective permissions on the object being controlled).
To do anything on a desktop, like create windows, paint stuff, or interact with windows on that desktop, user doing that is required to pass an access check against the security descriptor of the desktop. If failed, these GUI-related functions gonna return “access denied” status code instead of doing anything.
The login screen is simply rendered on a separate desktop. That desktop has restrictive security descriptor, most users don’t have permissions to interact with them. UAC prompts are also displayed on another desktop, that’s how it’s impossible to automate them from within a program who triggered the UAC prompt.
BTW, about crashing GPU drivers, on modern Windows the condition is recoverable. The symptoms are black screen for a second, then the OS resets the hardware, restarts the driver, and resumes rendering of the desktop. Observed quite a few times working on advanced GPU stuff, especially compute shaders.
When I mine cryptocurrency while playing games, I appear to sometimes run out of GPU memory (Both Task Manager and MSI Afterburner let me monitor usage) and I have experienced this reset. It's surprisingly graceful, even when a game is running, though NVIDIA Broadcast often doesn't like it and needs to be restarted, and I will sometimes see lingering graphical glitches in the game until I restart, but it's not game breaking.
You can also trigger a GPU reset manually with CTRL-WIN-SHIFT-B.
This actually is fixed in upstream GNOME because the screensaver is now built into the shell. The problem here is exclusively with cinnamon-screensaver and other components derived from gnome-screensaver, which is unmaintained and upstream GNOME considers it obsolete.
If you are not running xscreensaver on Linux, then it is safe to assume that your screen does not lock. Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
https://web.archive.org/web/20210117212403/https://www.jwz.o...
The trick on laptops is to block on sending the signal in the script you use to suspend, so that when the laptop resumes the display is already locked.
I have no idea what KDE is or does, sorry.
I've had many instances where my CPU was bogged down and after hitting the keyboard I could use the computer for a good several seconds before the lock screen popped up asking for a password.
That is an option Linux Mint is considering[0] among other options.
[0]: https://github.com/linuxmint/cinnamon-screensaver/issues/354...
The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.
That's a flawed concept.
What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.
You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.
In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.
a) there's no Xserver concept of a lock screen which would be hard to fix, I suspect. How would you signal X to lock/unlock; what would it do if the lock client wasn't connected, etc.
b) there's no atomic way to transfer mouse/keyboard grab to another window, which means you can't have a reliable, crash reduced screen locker that supervises a beautiful password checking program; it has to be the same program. This could probably be fixed with an X extension; yes, an extension is a lot of work, and yes, you'd have to deal with fragmentation, but you could keep the untoolkited password dialog in case the extension isn't present, nobody would see it unless they did something odd, so it's fine.
Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).
An option could be running a dedicated screen lock Xserver on a different VT, and (securely) switching to that one somehow. But that would probably involve changes to multiple layers at the same time, which is hard to pull off in Linux. People would complain about the bloat of running a second Xserver, regardless of the actual bloat or imcreased utility.
Its not an X11 problem.
(using bit.ly because he gives a testicle if referrer is HN :P)
They do nothing fancy - paint a window over everything and wait for the password to be typed in. No animation. No graphics. No anything. No enter unlock password dialog. I am sure there could be some edge cases but I'm having a hard time identifying them.
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
> The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session.
I think it's a reasonable design.
From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.
Might be better to just exit the session or load a minimalistic replacement lock program (like the original xscreensaver) to avoid an infinite crash loop.
Edit: For me stuff
I have been recommending fedora to people for a while because their defaults are far more modern and sane rather than clinging on to python 2 and X11
The thread was linked below (or above, to this same parent), or see: https://web.archive.org/web/20210116101222/https://www.jwz.o...
I don't think I could interact with the screen in any way, but I could certainly take a picture of it, if I had any private information on the screen.
It will go to sleep, then when I wake it up, I get a flash of my desktop before the lock screen shows..
Too fast to write anything down by hand, but you could certainly point a 60fps camera at it and get something I'm sure.
I wasn't too concerned about it since it still blocked all user input, but if you had sensitive info visible it could definitely be an issue.
My guess is that these lock screens are all bolted on afterwards rather than being in the design from the ground up.
Really? I have never seen this in Windows. Don't get me wrong, I've seen plenty of lock screen failures in Windows, usually in the form of it suddenly being unresponsive, just never anything that actually gave me access to the locked session again.
The closest I've seen is when using RDP, if the Window has been minimized or hidden or otherwise has had reason not to update its display, then locked due to timeout, it will briefly show the last image it rendered when reactivated before updating and showing the lock screen.
P.S.: As other users have pointed out, Windows does have some known lock screen bypasses using accessibility and help dialogs, but in regards to merely crashing the lock screen, I haven't seen it behave in an insecure way.
Off-topic, but:
It seems absurd, to me, that such a conclusion could ever be reached. Obviously, from my perspective, the economies of scale, the infrastructure, overhead, and institutional resources available to programmers at a dedicated software development firm would produce an application at better quality per dollar (however you measure it) than a high school teacher in their off-hours. To me it seems that it's certainly not cheaper for us as a society, as a species, and only appears so because you are under-paid. If you were paid your actual worth, the school would say "we don't have the funds to develop this in-house, and had to buy a commercial typing program off-the-shelf, despite its loose fit for our use case."
How can we, as rational members of society, abide this?
Where I work there is a tool that's used in hundreds of our internal services. It was written in-house during one of our hack weeks years ago, and later we open-sourced it. Despite the fact that the org relies so heavily on it, it's completely unfunded; two employees improve and maintain it in our free time. (We do have a few outside contributors, too, which is awesome!)
That's not exactly the same situation, but I think this kind of short-sightedness is pervasive in our culture, in every walk of life.
fff ggg fgf gfg ffgg fggf gffg
jjj hhh jhj hjh jjhh jhhj hjjh
This forces the student to exercise that movement pattern in a way that just telling them to put their fingers on the home row and type English words does not.
So the above sentence you quoted was a an over-simplification for story telling purposes and not the whole story. :)
If you measure it by cost to the district (for which a teacher doing it in their off hours is $0), it's clearly not, even if you only consider the sticker price of the commercial software and not the other costs associated with purchasing in a school.
> If you were paid your actual worth,
The school would fire about half it's teaching staff in order to make budget, and still not have money left over to either develop or purchase the typing program, probably.
It was 4-5 years ago when he was about 2. I had a 15+ character random password (a generated one including symbols etc) so the chances of him being lucky were rather slim. He was just mashing button on the lock screen for less than a minute when boom, I was suddenly signed in. The first time I thought it was a fluke. Then it happened again after a couple of months. After that I took my phone, sat him behind my computer and started to record him playing with the buttons but it never happened again and my hopes of getting a bug bounty from Apple vanished :(
Wow every new person who joins that thread misses the point more than the previous one. This was painful to read.
On the previous version I believe he managed to unlock the computer as well, just by hammering the keyboard.
2: Use ML to learn how to simulate it.
3: Sell it as a service, labeling it KaaS.
4: Profit, then go to jail because of a misunderstanding.
But seriously, is there such a tool to automate this?
> In 1983, Steve Capps at Apple developed "The Monkey", a tool that would generate random inputs for classic Mac OS applications, such as MacPaint [0]. The figurative "monkey" refers to the infinite monkey theorem which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will eventually type out the entire works of Shakespeare. In the case of testing, the monkey would write the particular sequence of inputs that will trigger a crash.
Read the story here:
https://www.folklore.org/StoryView.py?story=Monkey_Lives.txt
But this is pretty impressive as well!
1: jwz says if you add accessibility features to a text box, make sure they don't have any bugs that can kill a process, since that will break screen lockers
2: Cinnamon adds a buggy accessibility feature to a text box that lets you crash the screen locker
3: Github user clefebvre says something along the lines of "why is jwz being so negative >:("
Well... you did exactly what he told you not to do. If you're going to add accessibility features to a text box, you need to not screw it up. If you screw it up, then it breaks the screen locker for every user in the world, including the 99% of people who will never use the accessibility features.
If you make an obvious, stupid mistake, people will make fun of you. Complaining that people are making fun of you won't do much. Try, instead, to not make the obvious stupid mistake?
From the issue:
>With that said, I have on message for JWZ. Don't be that guy. It's too easy to just tell people no to cross the street. Work with us on building that safest path.
Huh? What? He wrote xscreensaver 20 years ago. He's supposed to fix buggy code written by other people until he dies?
Why is it his responsibility to fix your code? The distro extended his program, the extension broke. You can either ignore the problem, remove the extension, or fix the extension. None of these things sounds like xscreensaver's problem!
cinnamon-screensaver (the repo this discussion is pertinent to) is written from scratch. The commenter's intent here is to suggest that JWZ has valid criticisms, but he has voiced them before and his latest blog post doesn't add anything to the discussion.
This blog post, which links to the issue, creates additional overhead for the project to deal with. Just like this HN link does.
I think its fair for us to give them a voice in the matter if we're showing the discussion to everyone. It would be nice to assume people read the entire discussion but clearly, that is not a reality.
Pretty rich from someone who starts with "I'll fight him in a cage match"
I also remember figuring out how to share my USB key as a network drive to other users. Many fun middays were had blasting around in Halo or Soldier of Fortune II with like 10 friends, although less fun was had when our school's sysadmin found some lingering cache files that were owned by my id.
The number of emails I got from that was worth the vitriol contained in them, including threatened lawsuits.
Only approved programs software was supposed to run but you could actually run anything as long as the .exe was on the desktop.
7-zip would let you explore the entire network drive, including teachers folders that we didn't have access to.
Unplugging the reconnecting the Ethernet cable wouldn't reconnect you to the teachers monitoring software.
We had a zip filled with games like Starcraft 2, Quake 3, Halo CE that was hidden on the shared network drive that kids around the school would use to play and LAN with each other.
My daughter was 1ish at the time, and I sat her down while I grabbed something from the fridge. Windows 98, locked. When I came back the screensaver was on, the password dialog was still up, but the desktop was fully functional in front of it. I could navigate, open applications, and everything else.
Still no idea how she did it, but that’s not the first or last time she surprised me :)
In general, the way you secured a Windows 9x box was by locking the door to the room it was in.
My daughter managed to buy 24 hours of football pass with NowTV by pressing the same button repeatedly on the remote within about 5 seconds.
So a crash like this doesn't surprise me.
My daughter, whilst roaming in the US from the EU somehow managed to get unlimited data after her initial miserly roaming allowance was used up.. simply by switching airplane mode on and off repeatedly until data worked.
I was stressing getting back home to a huge bill, but kept the "all chargeable services have been stopped" messages just in case.
My final bill was £300+, zeroed.
Phew!
That was probably not a crash, on some that did a partial reset.
For example LLVM's lib fuzzer uses instrumentation to track code coverage and mutates data to find invalid behaviour.
https://llvm.org/docs/LibFuzzer.html
It uses a compiler pass to insert code to branch points functions calls etc. I think it uses genetic algorithms to increase coverage by changing the data.
There are others that work in similar ways one of them is. https://github.com/google/AFL
https://media.ccc.de/v/30C3_-_5499_-_en_-_saal_1_-_201312291...
(For example, I once wrote a hash table implementation where the insertion and resizing procedures had slightly different views on wraparound, causing failures on very specific inputs. Another time, I wrote some code to buffer out-of-order messages, which would only occur due to a race condition. It was wrong. Both times I had thought carefully about the code, and the bugs would have been painful to discover otherwise.)
(I haven't used it myself yet, but it looks interesting.)
And a quick response by the maintainer who shows thank, is focused on a clear outcome, and shows the progress transparently.
I've seen too many bugreports where one, or both actors behave vastly different. This one here should be a reference for anyone involved in 'bugreports' in some way.
If you can describe your program as a state machine, you can ask an SMT solver to find any transitions that break stuff. Unfortunately it's a lot harder to do for software than hardware because of the plasticity people expect from the former, but works it was it's really nice.
Start kiosk mode fullscreen app as a lock screen -> if app exits -> show desktop
The whole desktop architecture is out of date. I wouldn't be surprised if someone argued that screensavers aren't important because it's just your user data exposed, the root account is still safe!
Fool-proof and child-proof software is yet to come.
Hire QA kids.
I see similar behavior with smartphones.
3 y.o. figure it out better than my parents because it seems their mindset is ‘do all the things’ to see what the i/o structure is. Their brain is built that way when they are so young.
Using some a couple lines of VBScript to change a couple registry entries (computers didn't persist storage anyways) you could also give your local admin privileges, to install stuff. That one got me in a touch of trouble, and I lost my account for a couple weeks while they "looked at my files", because I stored it on my network drive folder.
The QA team had a test they called “the elbow test” where they did exactly this.
Just kind of put their elbow randomly on the keyboard to see if stuff would break.
>The source of the vulnerability is nothing but an integer underflow fault that was introduced with single commit in Grub version 1.98 (December 2009) – b391bdb2f2c5ccf29da66cecdbfb7566656a704d – affecting the grub_password_get() function.
[1] https://thehackernews.com/2015/12/hack-linux-grub-password.h...
No dialogs or confirmations. Just black screen and computer rebooting.
Color me surprised! /s
smashes keys
Unlocks
( see also http://catb.org/~esr/jargon/html/index.html and https://en.wikipedia.org/wiki/Jargon_File )
"Cracker" is the term used commonly - as in "crack the nut"; i.e. gain access to systems / break copy protection etc. Then you have the phone guys, the phreakers, whistling for free calls.
Hmm. Right spirit but not so much "hacking code together" going on at MIT's Tech Model Railroad Club in 1958.
"a project undertaken or a product built not solely to fulfill some constructive goal but with some wild pleasure taken in mere involvement, was called a `hack'".
(Steven Levy, "Hackers").
