CWE Rule 427

Uncontrolled Search Path Element

Since R2024a

Description

Rule Description

The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.

Polyspace Implementation

The rule checker checks for these issues:

• Execution of a binary from a relative path can be controlled by an external actor

• Load of library from a relative path can be controlled by an external actor

Examples

Execution of a binary from a relative path can be controlled by an external actor

Issue

This issue occurs when you call an external command with a relative path or without a path.

This defect also finds results that the Execution of externally controlled command defect checker finds.

Risk

By using a relative path or no path to call an external command, your program uses an unsafe search process to find the command. An attacker can control the search process and replace the intended command with a command of their own.

Fix

When you call an external command, specify the full path.

Example — Call Command with Relative Path

# define _GNU_SOURCE
# include <sys/types.h>
# include <sys/socket.h>
# include <unistd.h>
# include <stdio.h>
# include <stdlib.h>
# include <wchar.h>
# include <string.h>
# define MAX_BUFFER 100

void rel_path()
{
    char * data;
    char data_buf[MAX_BUFFER] = "";
    data = data_buf;

    strcpy(data, "ls -la");
    FILE *pipe;
    pipe = popen(data, "wb");  //Noncompliant
    if (pipe != NULL) pclose(pipe);
}

In this example, Bug Finder flags popen because it tries to call ls -la using a relative path to the ls command. An attacker can manipulate the command to use a malicious version.

Correction — Use Full Path

One possible correction is to use the full path when calling the command.

# define _GNU_SOURCE
# include <sys/types.h>
# include <sys/socket.h>
# include <unistd.h>
# include <stdio.h>
# include <stdlib.h>
# include <wchar.h>
# include <string.h>
# define MAX_BUFFER 100

void rel_path()
{
    char * data;
    char data_buf[MAX_BUFFER] = "";
    data = data_buf;

    strcpy(data, "/usr/bin/ls -la");
    FILE *pipe;
    pipe = popen(data, "wb");  
    if (pipe != NULL) pclose(pipe);
}

Load of library from a relative path can be controlled by an external actor

Issue

This issue occurs when library loading routines that load an external library use a relative path or do not use a path at all.

Risk

By using a relative path or no path to load an external library, your program uses an unsafe search process to find the library. An attacker can control the search process and replace the intended library with a library of their own.

Fix

When you load an external library, specify the full path.

Example — Open Library with Library Name

#include <dlfcn.h>
#include <stdlib.h>
#include <string.h>
#include <malloc.h>
#include <stdio.h>

void relative_path()
{
    dlopen("liberty.dll",RTLD_LAZY); //Noncompliant
}

In this example, dlopen opens the liberty library by calling only the name of the library. However, this call to the library uses a relative path to find the library, which is unsafe.

Correction — Use Full Path to Library

One possible correction is to use the full path to the library when you load it into your program.

#include <dlfcn.h>
#include <stdlib.h>
#include <string.h>
#include <malloc.h>
#include <stdio.h>

void relative_path()
{
    dlopen("/home/my_libs/library/liberty.dll",RTLD_LAZY);
}

Check Information

Category: File Handling Issues

Version History

Introduced in R2024a