Skip to content

Exception message and log path leak via subprocess argv (process listing visible) #54

Description

@soloturn

AI-assisted issue. Filed by agent driven by @soloturn via GDD.

Context

Flagged by CodeRabbit's review on PR #52 (the macOS process-isolation fix), and explicitly deferred there rather than bundled into that PR - it's a real but separate change, not a quick fix.

Problem / Current State

CrashReporter.reportInSubprocess() (cr-core/src/main/java/org/terasology/crashreporter/CrashReporter.java) passes the exception's message and the absolute log folder path as plain command-line arguments to the isolated reporter subprocess:

command.add(throwable.getClass().getName());
command.add(message == null ? "" : message);
command.add(logFileFolder == null ? "" : logFileFolder.toAbsolutePath().toString());
command.add(mode.name());

On most OSes, process argv is visible to any other local process/user via standard tools (ps, /proc/<pid>/cmdline, Activity Monitor, etc.) for as long as the subprocess is running - i.e. for as long as the crash dialog is open. Exception messages can contain PII, file paths, credentials, or other sensitive data that ends up briefly exposed to anything else running on the same machine.

Acceptance Criteria

  • The exception message and log folder path are no longer passed via subprocess argv.
  • Both values are still correctly received by the subprocess and used to reconstruct/display the crash report exactly as today.
  • The exception class name and report mode (the two non-sensitive protocol fields) can stay in argv.

Technical Notes

  • Suggested approach (from the CodeRabbit review): pass the message and log folder via stdin, or write them to a permission-restricted temporary file and pass only its path via argv, rather than argv directly.
  • Receiving side is CrashReporter.main(String[] args), which currently reads args[1]/args[2] for these two values - needs a matching update.
  • Low urgency/low likelihood of real-world exploitation (the values originate from this same application's own argv, not untrusted input), but a straightforward hardening once someone has time for the small protocol change.

Related

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions