Potential Command Injection Risk in OS_ShellOutputToFile() via sh -c Execution of Caller-Controled String

[Fuzz0X]

Describe the bug
A potential command injection risk exists in OS_ShellOutputToFile() when OSAL is built with shell support enabled. The function accepts a caller-provided command string and, in the POSIX implementation, executes it through sh -c. Because the command is interpreted by a shell rather than executed as a fixed program with explicit arguments, any application that passes untrusted or externally influenced input into the Cmd parameter may become vulnerable to command injection.

This means the issue is not necessarily that OSAL itself is directly remotely exploitable in all deployments, but that the current API/implementation provides a dangerous shell-execution primitive. If attacker-controlled input can reach Cmd, shell metacharacters may alter command behavior and result in unintended command execution.

To Reproduce
Steps to reproduce the behavior:

1. Build OSAL on a POSIX target with shell support enabled (OSAL_CONFIG_INCLUDE_SHELL=TRUE).
2. Create or obtain a valid OSAL file descriptor that can receive command output.
3. Call OS_ShellOutputToFile() with a command string containing shell metacharacters, for example:
   echo SAFE; id; uname -a; echo PWNED >/tmp/osal_shell_poc_marker.txt
4. Observe that the shell interprets the full command string and executes the injected command segments.
5. Confirm that the file /tmp/osal_shell_poc_marker.txt is created.
   . A minimal demonstration of the execution model can also be reproduced by directly invoking:
   /bin/sh -c 'echo SAFE; id; uname -a; echo PWNED >/tmp/osal_shell_poc_marker.txt'

Expected behavior
OS_ShellOutputToFile() should not expose a shell-interpreted execution path for caller-controlled strings without a clear trusted-only contract. A safer design would execute a fixed binary with explicit argument vectors, or otherwise ensure that untrusted input cannot be interpreted by a shell.

At minimum, if this API is intended for trusted-only use, that requirement should be clearly documented so that applications do not inadvertently pass untrusted input into Cmd.

Code snips

int32 OS_ShellOutputToFile(const char *Cmd, osal_id_t filedes)
{
    OS_object_token_t token;
    int32             return_code;

    OS_CHECK_POINTER(Cmd);

    return_code = OS_ObjectIdGetById(OS_LOCK_MODE_REFCOUNT, OS_OBJECT_TYPE_OS_STREAM, filedes, &token);
    if (return_code == OS_SUCCESS)
    {
        return_code = OS_ShellOutputToFile_Impl(&token, Cmd);
        OS_ObjectIdRelease(&token);
    }

    return return_code;
}

POSIX implementation executes the supplied string via sh -c:

int32 OS_ShellOutputToFile_Impl(const OS_object_token_t *token, const char *Cmd)
{
    pid_t                           cpid;
    osal_index_t                    local_id;
    int                             wstat;
    const char *                    shell = getenv("SHELL");
    OS_impl_file_internal_record_t *impl;

    impl = OS_OBJECT_TABLE_GET(OS_impl_filehandle_table, *token);

    if (shell == NULL)
    {
        shell = "/bin/sh";
    }

    cpid = fork();
    if (cpid == 0)
    {
        dup2(impl->fd, STDOUT_FILENO);
        dup2(impl->fd, STDERR_FILENO);

        for (local_id = 0; local_id < OS_MAX_NUM_OPEN_FILES; ++local_id)
        {
            if (OS_ObjectIdIsValid(OS_global_stream_table[local_id].active_id))
            {
                close(OS_impl_filehandle_table[local_id].fd);
            }
        }

        execl(shell, "sh", "-c", Cmd, NULL);
        exit(EXIT_FAILURE);
    }

    ...
}

System observed on:

• Hardware x86_64 test environment
• OS: Linux
• Versions POSIX-target OSAL build with shell support enabled (OSAL_CONFIG_INCLUDE_SHELL=TRUE)

Additional context
The security impact depends on whether untrusted or attacker-influenced input can reach the Cmd parameter in a real application. If Cmd is always fully trusted and hard-coded by the integrator, this may be better treated as a dangerous API design / hardening concern rather than a directly exploitable product vulnerability.

However, because the implementation uses sh -c, any unsafe caller usage can become high-impact. For that reason, it may be worth considering one or more of the following:

1.documenting Cmd as trusted-only input,
2.disabling shell support where not required,
3.avoiding $SHELL and using a fixed interpreter path,
4.or replacing this interface with a safer structured execution API.