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...
https://github.com/linuxmint/cinnamon-screensaver/issues/354...
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 can't tell if this is sarcasm or if you're serious. If you're serious, please tell me what product you've butchered so I can avoid it like the plague.
Clear error messages only confuse people who shouldn't be using the product in the first place. More importantly: a clear error message at the cost of a few confused users is far more important than an unclear error message that costs even more users hours or days of trouble.
I would far rather have a message that tells me that the software broke because the desktop manager found a crash loop and point me to the crash loop logs even if some other poor unfortunate soul has no idea what a crash log is or can't figure out how to access or understand the crash log.
A clear error message should not necessarily clearly explain what the issue is - a clear error message should clearly explain how to solve the issue, or at least point the user in the direction of a solution.
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.
Mac OS almost gets this right, except it annoyingly defaults to sharing the remote session with the local console unless someone is already logged in locally.
Maybe using Xdummy instead of Xvfb would work better?
This wiki article makes such an approach look promising: https://xpra.org/trac/wiki/Xdummy
Expressed otherwise: just because someone’s written one piece of bad software for Wayland doesn’t mean Wayland doesn’t allow you to write good software. (Whereas I get the impression from what I’m reading that X makes it impossible to write a good screen locker, if by that you require that it be crash-proof and use the usual platform toolkit for the UI.)
(Remember in this that I’m saying I don’t know. I’d like to hear if Wayland does have a good answer to this, or from anyone with definite knowledge that it doesn’t.)
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.
This particular issue is fixed in logind, when you ask it to lock the season/suspend/hibernate it first calls the lock screen, wait it to signal it finishes and them it proceed to suspend/hibernate.
Not saying you need systemd to fix this issue, but it is one of the things that systemd allows you to do correctly without reinventing the wheel.
Why not just require that it is there? Is there even a valid reason for someone to keep the extension out unless it is to give another "this is the reason X sucks" speech?
Its not an X11 problem.
(using bit.ly because he gives a testicle if referrer is HN :P)
> X11 ... was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. ... This mistake of the X11 architecture can never, ever be fixed.
He also claims in the second post that Xscreensaver is actually vulnerable to exactly the same kind of attack:
> The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash.
- https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
- https://www.jwz.org/xscreensaver/toolkits.html
[Edit]: I understand now. My browser doesn't send referrer URLs, and I think that's the real fix instead of using something like bit.ly!
Which can be found via this thread: https://news.ycombinator.com/item?id=11412081 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#400
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.
I'm imagining 2 processes:
1. Process monitor shows a fullscreen black window. Launches xscreensaver --lock or something as a child process
2. Xscreensaver shows the lock screen over the top of the process monitor, with a password prompt
When the correct password is entered, xscreensaver signals to its parent process. Then both processes close gracefully.
If xscreensaver crashes without signalling, the process manager silently restarts xscreensaver.
None of that requires any changes to X. You'd just want to be sure xscreensaver is displayed on top of the process manager's black window.
Argh. That would be the window manager, of course.
There is also xsecurelock [1] by Google.
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.
Also this bug (and probably most other bugs xscreensaver has had over the years) wouldn't result in an infinite crash loop anyway.
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
> python 2
In contrast to Wayland that can be installed in parallel to python 3. So the only reason to remove it is if you enjoy breaking working software.
To be fair to swaylock, they actually fixed some of those issues, in contrast to kscreenlocker which are just ignoring most edge-case bugs, because it's nearly impossible to fix them.
And really if you're being DDoSed by a small thing like HN comment links you really have to up your game :) Wait till you get featured on reddit (previously called slashdotting when slashdot was still a big thing).
How do I get the testicle in an egg cup?
The thread was linked below (or above, to this same parent), or see: https://web.archive.org/web/20210116101222/https://www.jwz.o...
When I open it again, the desktop is accessible for a few seconds (sometimes long enough to launch programs) before the lock screen activates and I have to input my password. The workaround I use is to manually lock with Win+L before closing the lid.
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.
* Do you use a nvidia GPU * Do you need to screen share from electron or other x11 only applications (MS teams, etc)
Its ready if you said no to both of those.
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.
Sometimes, while at work, I am thinking of leisure. Sometimes, while at leisure, I am thinking of work.
At the end of the day, the school pays their employee. And the rest of society pays them during "off-hours", e.g. in depreciation of common resources if, say, they drive on the road.
My point is that people cost society to keep alive, but some of those people are better equipped for certain tasks than others. The question is only where do those costs come from, and to what particular efforts are the particularly-equipped assigned.
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.
> I don't see the point of pressing the wrong series of key combinations nine or more times in a row constitutes a "Login Window ScreenShot Problem" any more than dropping my MacBook from various heights until it breaks is a reliability problem.
Why do people hold computers to such a lower standard than other complex devices in their life? (Serious question -- I don't understand people very well here.)
Can you imagine a car that wouldn't unlock or start if a passerby without the key plays with the door handles too much? If this has happened and is documented, that alone is a testament to its rarity and people's unwillingness to excuse the behavior.
Unless it happened to early Tesla, because they were held to the lower standard applied to computers and OSs. That doesn't seem to be as true anymore, thankfully.
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.
The commit is at https://github.com/linuxmint/cinnamon-screensaver/commit/38a... where mtwebster writes:
> We'll use the old screensaver auth code instead - this ports gs-auth-pam.c and gs-auth.h from the old screensaver,
Cinnamon tried to re-invent the wheel. They made it very sparkly and shiny and colourful and forgot that it had to be robust, round and capable of rolling.
Jesus wept, you criticise other people for not reading the entire discussion, and yet you somehow missed the part in JWZ's post where he explains that Cinnamon-screensaver was NOT written from scratch. So congratulations, you hypocritically own-goaled yourself there too. Which again, makes me question the charitability of assuming sincerity.
And JWZ is supposed to "work with them" when their code fouls up for the Nth time? No, the idiots should've been writing modules for JWZ's engine, seeing as JWZ's is the one that a) they did indeed steal from and b) still screwed up.
Yes, he's voiced his valid criticisms before. And the damn Cinnamon tards STILL KEEP MAKING THE SAME MISTAKES. This adds to the discussion. It adds useful, educational history that the Cinnamon morons are so stupid that they repeatedly, in the face of history, keep making the same goddamn stupid mistakes.
I get to "the other side of the road" just fine with JWZ's screensaver. I just FIFTEEN MINUTES AGO had to step the housemate through replacing her new Mint install's Cinnamon screensaver with xscreensaver; because what a surprise, it's 2021 and the $hitpile that is Cinnamon screensaver lock would NOT RESPOND to keyboard or mouse and wouldn't let her log in. And either she had to either magic-sysrq, or I had to ssh in to the root account to kill the stupid pile of crap that is cinnamon-screensaver.
And I found this ridiculous comment on this thread, because I was trying to show her a reference as to WHY Cinnamon-screensaver is stupidly broken in its principles and why xscreensaver should be used instead.
Clement Lefebvre has some pretty big balls to have written what he did; and that's good. Because it'll make it easier to repeatedly kick him in them as he deserves for this. And defence of his positions is... not particularly defensible.
I don't wish to be rude to you; but I finally stopped lurking on HN after years and created an account for the purpose of telling you these things. And by years, I mean that my Slashdot ID is in the 500,000s, rather than say the 60-millions.
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!
After long research, we found correlation with marketing moving their target from only students to 'older people'. Apparently the latter 'doubleclick' on links and buttons in webforms far more often. At least for us they did.
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").
HACK: 1) something done without constructive end;
2) a project undertaken on bad self-advice;
3) an entropy booster;
4) to produce, or attempt to produce, a hack.
HACKER: one who hacks, or makes them.
----
[1] "An Abridged Dictionary of the TMRC Language", 1959: http://www.gricer.com/tmrc/dictionary1959.html