[MEDIUM] Search auto-executes executable files from recent-files/favorites/folder scan without confirmation (openfile:) #49

Summary

The openfile: action executes a file as a program in a terminal when the file happens to be executable — without any confirmation dialog. The code's own comments admit the gap:

• lib/services/action_handler.dart:147-160 — openfile: handler:

  bool isExecutable = await Linux.isFileExecutable(file);
  if (isExecutable) {
    // TODO: Ask the user, if the file should be run (possible security risk).
    // TODO: Ask the user, if the file should be run in a terminal.
    unawaited(Linux.runExecutableInTerminal(file));
  } else {
    unawaited(Linux.runCommandWithCustomArguments("xdg-open", [file]));
  }

• lib/services/linux.dart:2634-2643 — runExecutableInTerminal hands the path to gnome-terminal -- <path> / term -e <path> / xterm -e <path>.

openfile: entries are built from three untrusted sources and injected into the search results automatically:

• lib/services/linux.dart:1046-1060 (getRecentFiles) — every URI in the GTK RecentManager list (additional/python/get_recent_files.py, ~/.local/share/recently-used.xbel) becomes an openfile: entry with priority -15.
• lib/services/linux.dart:1716-1727 (getFavoriteFiles) — xapp favorites (additional/python/get_favorite_files.py).
• lib/services/linux.dart:921-1005 (getAllFolderEntriesOfUser) — a folder scan of the user's home (find up to folder_recursion_depth).

The recent-files source is the dangerous one: recently-used.xbel is per-user state that any application running as the user can write (including sandboxed apps with home access), so entries in the search list are third-party data, not app-owned. The search also matches by filename, so an entry surfaces for whatever the user types.

This is distinct from the quoting defect tracked in #42: even with runInShell: false everywhere, the file is still executed — the sink here is "untrusted path becomes a running program", not "untrusted text becomes shell code".

Impact

A file planted by another app (or a downloaded file with a misleading name — e.g. an executable named invoice_2026.pdf or Anleitung.txt) is offered as "Open " in the main search. One click runs it under the invoking user in a terminal window with no confirmation dialog. An attacker who can write into a directory the user scans (Downloads, a synced cloud folder, a mounted USB stick) or into recently-used.xbel gets a one-click code-execution vector that rides on the user trusting Linux Assistant's search results.

Complexity

• Complexity: 2 (Easy)

Evidence

Repro path:

1. As another local app (or by hand): register an executable file in the GTK recent list — e.g. gio recent:/// semantics or simply open any file once with an editor after chmod +x:

   echo -e '#!/bin/sh\ntouch /tmp/pwned' > "$HOME/Downloads/Anleitung.txt"
   chmod +x "$HOME/Downloads/Anleitung.txt"
   gio open "$HOME/Downloads/Anleitung.txt"   # adds a recently-used.xbel entry

2. Start Linux Assistant, search for Anleitung — the entry "Open Anleitung.txt" appears (lib/services/linux.dart:1046-1060).
3. Click it → isExecutable is true → runExecutableInTerminal runs #!/bin/sh touch /tmp/pwned (lib/services/action_handler.dart:157-158, lib/services/linux.dart:2634-2643).

# confirms the code path exists without any confirmation gate:
grep -n "Ask the user, if the file should be run" -A 8 lib/services/action_handler.dart

Recommended Fix

In ActionHandler.handleActionEntry (lib/services/action_handler.dart:147-160):

1. Show a confirmation dialog before executing an entry whose target isExecutable — mirror the pattern already used by clean_timeshift.dart's _confirmDeletion (MintY dialog, await the answer, bail on false).
2. Make the dialog name what will happen ("This file is executable — run it in a terminal?"), and keep the plain xdg-open branch (non-executables) unconfirmed, as today.
3. Optionally mark executable entries in the search list (icon/badge) so the user sees the risk before clicking.

Related: #42 (same call sites, quoting defect — fix both, but note the confirmation is still required after #42 lands).

References

• OWASP: Unrestricted File Upload / handling untrusted files — execution without user intent: https://owasp.org/www-community/vulnerabilities
• Freedesktop recently-used.xbel spec (per-user, app-writable): https://specifications.freedesktop.org/recent-file-spec/latest/
• GNOME HIG: destructive/confirm actions: https://developer.gnome.org/hig/patterns/feedback/dialogs.html

Validation

• attacker_source: third-party file names and paths — GTK RecentManager (recently-used.xbel, writable by any app as the user), xapp favorites, and the home folder scan (find up to folder_recursion_depth)
• missing_guard: lib/services/action_handler.dart:147-160 checks only isExecutable and then executes; no confirmation dialog, no content/type check, no "was this file opened as a document?" distinction (the two TODO comments mark the missing guard)
• sink_effect: Linux.runExecutableInTerminal(file) (lib/services/linux.dart:2634-2643) launches gnome-terminal -- <path> / xterm -e <path> — the untrusted file runs as a program under the invoking user
• preconditions: the attacker-controlled file exists on disk and carries the executable bit (directly or via a planted recently-used.xbel entry), and the user clicks its search entry
• proof_anchors: lib/services/action_handler.dart:147-160 (TODO: Ask the user, if the file should be run (possible security risk). → unawaited(Linux.runExecutableInTerminal(file));); lib/services/linux.dart:1057 (action: "openfile:$recentFile" built from additional/python/get_recent_files.py output)
• suggested_validation: grep -n "runExecutableInTerminal(file)" -B 6 lib/services/action_handler.dart — shows the execute branch with only an isExecutable check and no confirmation; after the fix, the same grep should show a dialog result gate, and the manual repro above should show a confirmation prompt instead of running the file