> For the complete documentation index, see [llms.txt](https://simon-6.gitbook.io/simoncyber/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://simon-6.gitbook.io/simoncyber/cves/ghsa-c78w-g4rj-q6q7.md).

# GHSA-c78w-g4rj-q6q7

#### Summary

Again, there's a lot of vulnerability when we call a variable and attach it at the end of a important operation/command. This is very prominent among a lot of other injections not, just the standards one like SQL. Attaching a semicolon (a new command) after a parameter such as the Id can also work. That's why when we include a Id among a command, sanitization is necessary in the context of it . 

The "delete GPG key" action passes an attacker-controlled key ID straight into a shell command without proper escaping, allowing arbitrary OS command execution (CWE-78) on the repository server. The endpoint performs no authorization check beyond "is the user logged in", so any authenticated user can trigger it (CWE-862). This lets a low-privileged user achieve remote code execution as the web/PHP process user. This is called "Authenticated OS command injection (RCE) via GPG key deletion"

#### Steps

1. Open Repositories → Manage source repositories → GPG keys, and click delete on a key while Burpsuite Intercept mode is on to capture the request (DevTools can also work)
2. Replace the id section with `id[]=AAAA; touch /tmp/pwned`. Any command can substitute after the semicolon
3. Check the /tmp directory in the server/container. You can run a command like `docker exec repomanager-dev ls -la /tmp/pwned`\
   On the server, /tmp/pwned now exists, proving command execution and the privilege level it ran at.

#### PoC

Sending the request via Burpsuite. `id%5B%5D=AAAA;%20touch%20%2Ftmp%2Fpwned` is partly URL encoded for `id[]=AAAA; touch /tmp/pwned`<br>

<figure><img src="/files/KgN8vrKwJTCUr1x9r1nL" alt=""><figcaption></figcaption></figure>

Checking the file change in the docker container<br>

<figure><img src="/files/FkTPDDbFSE0liu2XhTb2" alt=""><figcaption></figcaption></figure>

Lastly, checking the vulnerable code, we see that it only calls the validate function. It neutralizes < > & " ' but leaves shell metacharacters (;, |, \`, $(), spaces) untouched. (controllers/Gpg.php:485)

```
        foreach ($gpgKeysIds as $id) {
            // Deleting key from the keyring, using its ID
            $myprocess = new \Controllers\Process('/usr/bin/gpg --no-default-keyring --homedir ' . GPGHOME . ' --keyring ' . GPGHOME . '/trustedkeys.gpg --no-greeting --delete-key --batch --yes ' . Validate::string($id));
            $myprocess->execute();
```

Process::execute() (controllers/Process.php:121) runs the command via proc\_open($command, …) with a string, which Linux executes through /bin/sh -c. Any injected shell command therefore runs.

#### Recommendations/Remediation

There's two independent fixes for this type of vulnerability, which is ensuring that actions such as deleting keys GPG keys remain actions only performed by admins, and validating the id parameter properly.

controllers/Gpg.php Line 485\
Before

```
… '--delete-key --batch --yes ' . Validate::string($id));
```

After

```
… '--delete-key --batch --yes ' . escapeshellarg($id));
```

Validate::string() is an HTML escaper and is the wrong tool for a shell context; escapeshellarg() is the correct one.

Additionally adding a statement inside at the top of controller function Gpg::delete() would also ensure this is an admin only action. If it is intended for this to be done by any authenicated user, then ignore the following code suggestion.

```
if (!IS_ADMIN) {
    response(HTTP_BAD_REQUEST, 'You are not allowed to perform this action');
}
```

#### Impact

Remote code execution as the web/PHP process user (typically www-data in a standard install).

* Disclosure of everything on the host including the SQLite databases holding user password hashes, API keys, and host auth tokens, plus the GPG signing keys.
* Full tamper/destroy of application data and configuration.
* Supply-chain amplification: RCE on it allows poisoning the .deb/.rpm packages served, turning one low-privileged account into compromise downstream