harden: reduce PATH hijacking risk for xdg desktop tools

[orbisai0security]

Summary

This PR attempts to harden desktop-entry installation in jadx-gui by avoiding unintended execution of xdg-desktop-menu or xdg-icon-resource from an unexpected location in PATH.

Context

The current implementation resolves the xdg helper commands from PATH and invokes them with ProcessBuilder during desktop integration.

This is not shell command injection: arguments are passed directly to ProcessBuilder, not through a shell. The concern is narrower: in a hostile or unusual launch environment, a modified PATH could cause jadx to execute a different binary named xdg-desktop-menu or xdg-icon-resource.

Security impact

This should be considered defensive hardening rather than a standalone high-severity vulnerability.

An attacker would generally already need the ability to influence the user’s environment or place a malicious executable earlier in PATH, so the practical impact is limited. The goal of this PR is only to reduce one possible executable-resolution footgun in the desktop-entry installation flow.

Changes

• Prefer resolving xdg desktop helper binaries from common system locations.
• Avoid blindly trusting arbitrary earlier PATH entries for these helper commands.

Notes

I understand the concern that hard-coding binary locations may reduce portability and partially bypass the purpose of PATH. If preferred, I can revise this to a smaller approach, such as:

• keeping the current PATH behavior,
• warning when the resolved binary is in a user-writable or unexpected directory, or
• closing this as acceptable existing behavior.

Verification

• Build passes
• Desktop integration code path reviewed

---

Automated security fix by OrbisAI Security

[skylot]

Hm, from my understanding, if attacker can change environment variables or put files in system directories mean that system already compromised to the point attacker can directly execute malicious binary, so jadx not needed 🤣
Also, hard-coding all possible system binary directories feels not right, it is exactly point of having PATH env variable.

Maybe someone can correct me or suggest better solution, so I will keep this PR open for some time.

[orbisai0security]

Thanks for taking a look. I agree that calling this “HIGH severity” is probably overstated.

The issue I was trying to address is narrower: jadx resolves xdg-desktop-menu and xdg-icon-resource through PATH before invoking them. In a hostile or unusual launch environment, this could allow PATH hijacking when the desktop-entry installation flow is triggered.

That said, I agree this requires the attacker to already influence the user’s environment or filesystem, so it is better described as defensive hardening rather than a standalone vulnerability. I also see your point that hard-coding system directories is not ideal and may hurt portability.

A better approach might be to either:

1. Keep the existing PATH-based behaviour and treat this as acceptable for a desktop utility, or
2. Add a smaller hardening change, such as warning when the resolved xdg binary is in a user-writable or unexpected directory, without breaking PATH-based resolution.

I'll revise the PR accordingly.

[shreyasminocha]

Hm, from my understanding, if attacker can change environment variables or put files in system directories mean that system already compromised to the point attacker can directly execute malicious binary, so jadx not needed 🤣

I agree, this seems like a non-issue. "Outside the threat model", one might say.

FWIW, on my system, xdg-icon-resource is at /etc/profiles/per-user/shreyas/bin/xdg-icon-resource.