On Wednesday, March 27, 2024, Dan <[email protected]> wrote: > Hello, I have 3 security-related questions: > (1) Does OpenBSD have a mechanism like Ctrl-Alt-Delete on Windows (Secure > Attention Key, or SAK) to prevent malware (or a website in fullscreen, for > example) from faking a logout process and/or faking a login prompt? On > Windows the kernel ensures that the operating system captures this key > combination and takes over with a real login prompt that malware can't fake > without first defeating the OS security. >
(Let me clarify for the rest of this message: malware is any program that acts maliciously; it doesn't *necessarily* bypass exploit mitigations or security features of the OS (e.g. it could work around them, or abuse the lack of them).) Something recent that I found that's relevant: https://www.bleepingcomputer.com/news/security/decade-old-linux-wall-bug-helps-make-fake-sudo-prompts-steal-passwords/ (From March 28, 2024. Note that this isn't a vulnerability in how the OS separates users or enforces security, this is a vulnerability that could be used to make a convincing "phishing" attack.) This isn't exactly the issue that SAK prevents, because the SAK is meant to be used at login time (not when already logged in as one user and trying to doas/sudo one program/command into another user), but I'll repeat the two links I sent before: https://security.stackexchange.com/a/34975 https://learn.microsoft.com/windows/win32/winstation/desktops The second link being the more relevant one. Notice how Microsoft describes that User Account Control takes over the screen with a secure desktop mode. UAC is the equivalent of doas/sudo. There's an additional problem though: malware and websites in fullscreen could mimic the sound and visual dimming effect that UAC does on Windows. While UAC doesn't ask the user to press a privileged key combination like Ctrl-Alt-Delete (so the user has no guarantee that the UAC prompt is authentic, even with the said perceptual effects), it does something else: it asks for authorization (and details what is authorized exactly) without relying on knowledge of the passphrase as proof for authorization. Malware on OpenBSD that knows the root passphrase, or the passphrase of a doas-capable/sudoer user, can escalate its privileges; malware on Windows (including web content that escapes the browser's sandbox) that knows the passphrase of a user in the Administrators group cannot escalate its privileges without first compromising the integrity of Windows, because asking Windows to escalate privileges would ensure that the user authorizes the escalation regardless of the passphrase (let's assume that UAC is set to its highest (fourth) level, rather than the default (third) level that excepts some system programs from causing a UAC prompt when escalating). (Web content that escapes the browser's sandbox of Chromium, Firefox, and Tor Browser on OpenBSD would need to compromise the integrity of OpenBSD, because it sandboxes them further using pledge(2) and unveil(2) (or find a weakness in how these two are set up). So that's already a very good thing, but that alone is not enough.) It's important to emphasize that it doesn't matter whether UAC asks or doesn't ask for a passphrase to authorize, rather the important thing here is that it takes over the computer temporarily in a way that cannot be interfered with by normal programs and asks for explicit authorization; it could as well ask for a passphrase too as a second factor. Malware that fakes a UAC prompt and get "authorized" by the user would achieve nothing, as it hasn't really asked Windows to escalate, whereas malware on OpenBSD that convincingly fakes a doas prompt and gets "authorized" by the user can then impersonate the "authorizing" user going forward.
