Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kids find a security flaw in Linux Mint by mashing keys

github.com

Post reply on HN
Print view View original

131–140 of 340 posts

Re: Kids find a security flaw in Linux Mint by mashing keys

#131

Post by joefife »

AnIdiotOnTheNet wrote: post #115
globular-toast wrote: post #16

Earlier quoted context omitted.

I've seen Windows do that too. It's not just Linux. My guess is that these lock screens are all bolted on afterwards rather than being in the design from the ground up.

> I've seen Windows do that too. 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,…

I see this maybe once a week. It only seems to happen when I'm waking the PC.

Re: Kids find a security flaw in Linux Mint by mashing keys

#132

Post by m45t3r »

toast0 wrote: post #58
astrange wrote: post #10

Earlier quoted context omitted.

Bad design in X11 which can't be fixed. https://news.ycombinator.com/item?id=25801693

The underlying design issues are: 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 h…

> 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).

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.

Re: Kids find a security flaw in Linux Mint by mashing keys

#133

Post by ascar »

gambiting wrote: post #128
metafunctor wrote: post #126

Earlier quoted context omitted.

I don't understand the part about JWZ's testicles, so here are the links without bit.ly tracking for those whose ad blockers don't allow them: - 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!

You still get the testicles if you click this link, at least using Chrome you do. It's because the referrer field is set to HN so they know where the traffic is coming from.

Time to switch to Firefox and give Google less data. Firefox doesn't seem to send the referrer :)

Re: Kids find a security flaw in Linux Mint by mashing keys

#134

Post by chaganated »

josephg wrote: post #35
gambiting wrote: post #7

Does anyone know why lockscreens in Linux have been such a joke? I remember trying Ubuntu couple years ago and when waking up my laptop it would show me my entire desktop with all the information displayed right there in the open for about 10-20 seconds before suddenly engaging the lockscreen. All you had to do was close the lid and open it again and you could just copy whatever was on the screen before the lock scre…

Can anyone explain why a crash in xscreensaver results in the computer being unlocked? 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.

I believe that's how JWZ's XScreenSaver works, but every distro decided to re-invent the wheel there for whatever reason, then blame it all on X11 when it inevitably fails.

Re: Kids find a security flaw in Linux Mint by mashing keys

#135

Post by erhan24 »

sontek wrote: post #121
astrange wrote: post #10

Earlier quoted context omitted.

Bad design in X11 which can't be fixed. https://news.ycombinator.com/item?id=25801693

JWZ has been complaining about these screensavers for a decade. His screensaver from 20 years ago still doesn't have these issues. Its not an X11 problem. - https://bit.ly/3o2qekz - https://bit.ly/38Y6pGO (using bit.ly because he gives a testicle if referrer is HN :P)

Xscreensaver has crashed twice in my life and opened the desktop. That's still a good statistic but it may have crashed because of the animation.

Re: Kids find a security flaw in Linux Mint by mashing keys

#136

Post by marcthe12 »

toast0 wrote: post #58
astrange wrote: post #10

Earlier quoted context omitted.

Bad design in X11 which can't be fixed. https://news.ycombinator.com/item?id=25801693

The underlying design issues are: 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 h…

I like the dedicated VT, as DE users usually have a DM to login and for wayland that prob must a separate VT any way. The question is how to securely do this.

Re: Kids find a security flaw in Linux Mint by mashing keys

#137

Post by FriedrichN »

gambiting wrote: post #128
metafunctor wrote: post #126

Earlier quoted context omitted.

I don't understand the part about JWZ's testicles, so here are the links without bit.ly tracking for those whose ad blockers don't allow them: - 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!

You still get the testicles if you click this link, at least using Chrome you do. It's because the referrer field is set to HN so they know where the traffic is coming from.

In Firefox set network.http.referer.XOriginPolicy and network.http.referer.XOriginTrimmingPolicy.

Source: https://wiki.mozilla.org/Security/Referrer

Post reply on HN