Closed dmik closed 3 years ago
Also, from what I see, setenv
will expose memory leaks a certain variable is set more than once and the new value is longer than the previous one. I will try to fix that too within this ticket.
Created #103 to track setenv
memory leaks.
There is a version of the test showing the problem w/o using the parent-child mechanism:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
char str [] = "ENV1\0ENV2=VAL2";
char * newenv [] = { str, str + 5, NULL };
int main(int argc, char **argv)
{
environ = newenv;
char * * e = environ;
while (*e)
printf ("environ[%s]\n", *e++);
setenv("ENV1", "1", 1);
e = environ;
while (*e)
printf ("environ[%s]\n", *e++);
return 0;
}
Note that the first testcase works fine after just efb19af (because dead variables are no longer passed to the child) so a second test case was necessary which adds them manually to environ
(something an app can still legally do). The second test case works well after 42ba446. Closing.
The standard environment variable format for
DosExecPgm
is NAME=VAL. However, It turns out thatDosExecPgm
accepts environment variables which only contain the NAME part (no VAL part and not even a=
character). This makes the standard Cenviron
array contain such variables as well. Thesetenv
code supports such a case when looking for an existing variable but when assigning its new value it performs an out of bounds access and exposes a serious security risk with an arbitrary memory overwrite. The following program will demonstrate this:The expected output:
The actual output:
I.e. a call to
setenv("ENV1", "1", 1);
overwrites the memory contents after ENV1 with a new value (1). In this particular case another environment variable, ENV2, comes after ENV1 and it just vanishes. It can be any other memory location in the data segment, depending on the C heap usage.Discovered when working on https://github.com/bitwiseworks/libcx/issues/91.