(fix): Hardware Info Root Sudoers entry was possible to hijack

[ArneTR]

This PR addresses a security vulnerability in the sudoers entries that GMT creates.

The module resolution for -m lib.hardware_info_root could b hijacked by creating a malicious directory lib somewhere and placing an alternative hardware_info_root in it.

The fix makes the sudoers entry absolute path.

Futhermore the checking mechanism was updated to fully resolve any symlinks and further hardened by checking and failing if ACLs are present.

How to update

Just run the GMT install script again as you would normally when updating. It will overwrite the old vulnerable sudoers entry

How to find out if your system has been exploited

Search for find / 2>/dev/null | grep hardware_info_root

If a hardware_info_root.py turns up that is not in the GMT directory at the expected location (lib/hardware_info_root.py) you should investigate

Impact

We know of no use of this vulnerability. It can only be exploited if a user already has access to the host the GMT is running on.
However it elevates priviledges and thus should be considered high severity.

Greptile Overview

Greptile Summary

This PR addresses a privilege escalation vulnerability where the sudoers entry using -m lib.hardware_info_root could be hijacked by creating a malicious lib directory. The fix changes to absolute paths and hardens security checks.

Key Changes:

• Sudoers entries now use absolute paths via readlink -f instead of Python module syntax (-m)
• Code invocations updated to use os.path.realpath() to match sudoers entries
• check_file_permissions() enhanced to reject symlinks, verify no ACLs, and check parent directory permissions
• Applied to hardware_info_root.py, ipmi-dcmi, powermetrics, and killall

Issues Found:

• Inconsistent symlink resolution between utils.py (uses abspath) and scenario_runner.py (uses realpath)
• macOS compatibility: readlink -f requires GNU coreutils but install only checks for stdbuf
• Path resolution inconsistency: line 304 uses readlink -f on $PWD but line 312 uses $PWD directly
• Potential edge cases in permission bit extraction logic

The security approach is sound - using absolute paths prevents the hijacking attack. However, the macOS compatibility and path consistency issues need resolution to ensure the fix works across platforms.

[ArneTR]

@greptileai

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[ArneTR]

@greptileai

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[ArneTR]

@greptileai

[greptile-apps]

_{2 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[ArneTR]

@greptileai

[greptile-apps]

_{3 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

readlink -f resolves symlinks for ${PWD}, but then creates sudoers entry for that path. If the install script is later run from a different path (not symlinked), hardware_info_root.py will have a different absolute path than the sudoers entry, breaking sudo access.

Additionally, line 312 uses $PWD directly (not via readlink -f), creating potential inconsistency if $PWD is symlinked.

For robustness: resolve $PWD once at script start and use consistently, or don't resolve it at all (to match how users typically invoke the script).

[greptile-apps]

logic issue - this check rejects symlinks at line 69-71, but then line 304 uses readlink -f "${PWD}/lib/hardware_info_root.py" which will fail if the file itself doesn't exist yet (which it doesn't until line 312 creates it).

readlink -f requires the file to exist. Should use a different approach to canonicalize the path before the file is created, or check the file after creation.

[greptile-apps]

Additional Comments (1)

lib/utils.py
inconsistency - scenario_runner.py:29 uses os.path.realpath(__file__) for CURRENT_DIR, but here uses os.path.abspath(__file__). For a security fix that resolves symlinks, both should use realpath for consistency.

CURRENT_DIR = os.path.dirname(os.path.realpath(__file__))

[ribalba]

Good catch. Looks a lot better now