Possible security risk while using updating images and howdy

londeril commented 5 days ago

Regression?

No

Hyprlock Info and Version

Hyprlock version 0.5.0

Hyprlock config

```sh # Hyprlock # general { } background { monitor = path = screenshot blur_size = 5 blur_passes = 1 noise = 0.0117 contrast = 1.3000 brightness = 0.8000 vibrancy = 0.2100 vibrancy_darkness = 0.0 } input-field { monitor = size = 250, 50 outline_thickness = 3 dots_size = 0.33 dots_spacing = 0.15 dots_center = true outer_color = rgba(B9A100ff) inner_color = $color0 font_color = $color12 fade_on_empty = true placeholder_text = Magic Word... hide_input = false position = 0, 200 halign = center valign = bottom } image { monitor = path = ~/.dotfiles/lockscreen.jpg size = 1000 rounding = 10 border_size = 2 border_color = rgba(B9A100ff) rotate = 0 reload_time = 10 reload_cmd = find ~/Pictures/LandscapeSaver/ -type f | shuf -n 1 position = 0, 0 halign = center valign = center } ```

Compositor Info and Version

System/Version info

```sh Hyprland, built from branch at commit 4520b30d498daca8079365bdb909a8dea38e8d55 (version: bump to 0.44.1). Date: Wed Oct 9 12:54:39 2024 Tag: v0.44.1, commits: 5309 built against aquamarine 0.4.3 flags: (if any) System Information: System name: Linux Node name: nova Release: 6.11.5-zen1-1-zen Version: #1 ZEN SMP PREEMPT_DYNAMIC Tue, 22 Oct 2024 18:31:33 +0000 GPU information: 00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) os-release: NAME="Arch Linux" PRETTY_NAME="Arch Linux" ID=arch BUILD_ID=rolling ANSI_COLOR="38;2;23;147;209" HOME_URL="https://archlinux.org/" DOCUMENTATION_URL="https://wiki.archlinux.org/" SUPPORT_URL="https://bbs.archlinux.org/" BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues" PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/" LOGO=archlinux-logo plugins: ```

Description

If Howdy is used to do face-unlock and an image{} widget with an update_cmd is used it can happen that Howdy/Hyprlock auto-unlocks the session without detecting a face.

Since I like a picture slideshow with a 10-ish second refresh on my lockscreen I've stumbled over this issue

How to reproduce

Steps to reproduce

setup howdy
Use my posted hyprlock.conf (you can lower the reload_time to 1 to make this problem show up even faster)
create the Folder ~/Pictures/LandscapeSaver and put some images in it (or change the path ;) )
lock the screen
cover up your camera (I just use my hand...)
press enter to trigger howdy
after some failed login attempts hyprlock will auto-unlock even with the camera covered up (you may have to run "faillock --user YOURUSER --reset" on a tty if you manage to get to a locked out state before the auto-unlock problem triggers.

Observations

The auto-unlock tends to happen if the Howdy timeout and the picture refresh happen at the same time (which could be quite frequently with 10 seconds)
removing the refresh-timer fixes the problem reliably - so it has something to do with the reload
putting the reload command in a script and pointing the reload_cmd to that script does not help

Crash reports, logs, images, videos

No response

PaideiaDilemma commented 5 days ago

That seems hard to reproduce so I am not going to try for now. But I did find a race that is probably at least partially responsible for this. Although I have no idea why it would unlock and I am very curious about that... @londeril would be greatly appreciated if you could test #536 to see if fixes it.

londeril commented 4 days ago

Hi :)

I just build from #536 and tested it - sadly this does not fix the problem.

PaideiaDilemma commented 3 days ago

@londeril can you maybe also test the new pr #539? Thanks in advance!

A bit of context to understand how a problem like this can happen:

Hyprlock depends on libpam.so and we call into that to start authentication. Modules defined in your pam config then get loaded into into hyprlock itself. the module code (so howdy pam) is executed within the process that decides to authenticate. Then when you send SIGUSR2, which is an async signal, to hyprlock, the kernel will interrupt our process. Currently that can happend during authentication. Luckily we handle authentication in a separate thread and we can block the signals there. Which I guess will be the actual fix for this. That being said, the howdy module should never unlock just because it is interrupted at an inconvenient time. (idk if they are actually supposed to be async signal safe) So actually I think this is a bug in howdy, which showed some flaws in hyprlock.

Based on my current best guess.

londeril commented 2 days ago

Thanks for the explanation and the change!

I just build from pr-539 and tested it - but the bug is still there... if I set the refresh to 1sec., lock my session, cover up my camera and trigger Howdy the system unlocks almost instantly...

if I set the refresh to10 seconds, lock the session, cover the camera and count to 10 and trigger howdy just before the image changes the session unlocks...

PaideiaDilemma commented 2 days ago

I just build from pr-539 and tested it - but the bug is still there... if I set the refresh to 1sec., lock my session, cover up my camera and trigger Howdy the system unlocks almost instantly...

That is crazy. I will install howdy and try to reproduce it. I am out of ideas.

londeril commented 2 days ago

Thanks! let me know if and how I can help!

hyprwm / hyprlock