Howdy's pam module causes unlocks when using reload commands (security risk! DONT use Howdy for Lockscreen unlocks!)

[londeril]

Regression?

No

Hyprlock Info and Version

Hyprlock version 0.5.0

Hyprlock config

# 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 = <i>Magic Word...</i>
    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

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]

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]

Hi :)

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

[PaideiaDilemma]

@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]

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]

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]

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

[PaideiaDilemma]

It's a pretty bad flaw in howdy's pam module.

They use wait to wait for their child process (howdy's python implementation) to finish.
But wait just waits for ANY child process. So when our reload_cmd exits, it triggers this and unlocks due to a lack of checks in the pam module.

I will open an issue or pr in the howdy repo. But it does not seem like there is a lot of development there. So for now I would advocate for not using howdy.

This can be closed on our side.

[PaideiaDilemma]

For reference:
This is were it calls wait: howdy/src/pam/main.cc#L293
Then it just passes status down until we get past this check cause status is actually from one of hyprlocks child processes: howdy/src/pam/main.cc#L117

[PaideiaDilemma]

@londeril can you change the title to something like "Howdy's pam module causes unlocks when using reload commands".

This is also reproducible with label updates.

[londeril]

WOW! Thanks for all you did! I hope the Howdy team will address this!

I'll stop using Howdy to unlock my sessions for the time being and only use it for sudo auth...

[vaxerski]

closing