Prior to this commit, the code path responsible for prefix redefinition
(motivated by --define-prefix or otherwise) was visited more than
once, specifically since the check ignored pkg->owner->prefix_varname.
The current approach was to parse the .pc and, detect the prefix, throw
everything together and at the end replace all \ with / to not produce invalid
escape sequences.
This has the problem that escaping in .pc files is ignored and no longer
possible. Also in case the prefix path has a space in it the result would be
invalid because of missing escaping.
This changes the following things:
* We no longer normalize values at the end. Instead we assume .pc files use "/"
as a directory separator or "\\", same format as under Unix. "\" alone no
longer works. This shouldn't be a problem since most build tools produce .pc
files with "/" like meson, cmake, autotools.
* When injecting the prefix at runtime we convert the prefix to use "/" and
escape spaces so that in combination with the .pc content the result is a
valid escaped path value again.
This patch has been used in MSYS2 for some months now.
See #212
To avoid a crash on some platforms (like Darwin 9) provide a buffer to
realpath(3).
Darwin 9 (last PPC target) documents realpath needs to be given a buffer
to the resolved_path argument large enough to hold PATH_MAX bytes.
With NULL argument it crashes. Solaris makes no mention of
resolved_path to be allowed NULL, yet recent versions accept it and
malloc(3) accordingly.
Because the documentation explicitly mentions PATH_MAX being the limit
to what realpath(3) would write in resolved_path, switching to a static
buffer here doesn't limit resolution compared to dynamically allocating
a buffer by realpath(3).
While this change requires a bit more space on the stack, it avoids a
malloc/free sequence, and allows successful operation on (older)
platforms that lack support for dynamically allocating a return buffer
in realpath(3).
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
In case the version string has no whitespace then strcspn() returns
strlen() of the input, so whitespace is only found if len != strlen.
This fixes invalid warnings when parsing version fields.
If a file with a matching "uninstalled" name exists but cannot be
parsed, an invalid memory area is accessed.
How to reproduce:
$ touch poc-uninstalled.pc
$ PKG_CONFIG_PATH=. pkgconf poc
This is the same issue which has been fixed in dependency code.
If a line contains a variable which is longer than PKGCONF_ITEM_SIZE,
then the varname buffer overflows.
The code itself still does not check if a closing } exists and
truncates variable names which are too long. Since these would
be functional changes and this commit is about a protection against
undefined behaviour on a language level, these changes are not
included.
Proof of concept:
$ echo "Description: poc" > poc.pc
$ echo "Version: 1" >> poc.pc
$ echo -n 'Name: ${'
$ dd if=/dev/zero bs=1 count=66535 | tr '\0' 'x' >> poc.pc
$ echo >> poc.pc
$ pkgconf poc.pc
On my Linux system, when compiled with gcc, the varname buffer overflows
directly into buf, which means that no crash can be notified.
It's easiest to figure out when adding strlen() and sizeof() output
as debug lines.
fragment_quote adds quotation to fragments if needed. It allocates a
buffer and grows it as needed.
Unfortunately the dst pointer is not updated after a realloc, which
means that dst still points into the old memory area. Further writing
characters into that area leads to out of boundy writes.
Proof of concept:
$ cat > poc.pc << EOF
Name: poc
Description: poc
Version: 1
CFlags: -Ia
CFlags: -I%%%%%%%%%%%%%%%%%%%%b
CFlags: -I%%%%%%%%%%%%%%%%%%%%c
CFlags: -Id
EOF
$ pkgconf --cflags poc.pc
Most reliable attempt is to compile pkgconf with address sanitizer,
but this file should lead to an abort on a glibc system due to modified
chunk pointers (tested with Linux on amd64).
But since this is undefined behaviour, it depends on system details.
Parsing a fragment which consists only of a single dash leads to
an out of boundary read. It duplicates the following entry which
is not expected behaviour if another fragment follows.
Proof of concept:
$ cat > poc.pc << "EOF"
Name: poc
Description: poc
Version: 1
Cflags: - -I/somewhere
EOF
$ PKG_CONFIG_PATH=. pkgconf --cflags poc
-I/somewhere -I/somewhere
If - is the last entry, it leads to an out of boundary read, which is
easy to see if pkgconf is compiled with address sanitizer.
According to
https://docs.microsoft.com/fr-fr/windows/win32/fileio/naming-a-file
backslashes (with slashes) are a path separator, hence must no be
considered as an escape code.
The first fix, in argvsplit.c, disables this. But because of fragment_quote(),
the backslashes are doubled. Hence the second fix in fragment.c
With this pc file :
prefix=C:/Documents/msys2/opt/efl_64
libdir=${prefix}/lib
includedir=${prefix}/include
Name: eina
Description: efl: eina
Version: 1.24.99
Requires.private: iconv
Libs: -L${libdir} -leina -pthread -levil
Libs.private: -lpsapi -lole32 -lws2_32 -lsecur32 -luuid -lregex -lm
Cflags:-I${includedir}/eina-1 -I${includedir}/efl-1
-I${includedir}/eina-1/eina -pthread
pkgconf.exe --cflags eina
returns :
-IC:\Documents\msys2\opt\efl_64/include/eina-1
-IC:\Documents\msys2\opt\efl_64/include/efl-1
-IC:\Documents\msys2\opt\efl_64/include/eina-1/eina -pthread
-DWINICONV_CONST= -IC:\Documents\msys2\opt\ewpi_64/include
It is possible to trigger an out of boundary write in function
pkgconf_dependency_parse_str if a dependency line contains a very
long comparator. The comparator is stored in a temporary buffer which
has a size of PKGCONF_ITEM_SIZE.
The line which is parsed can be up to PKGCONF_BUFSIZE characters long,
which is larger than PKGCONF_ITEM_SIZE (although it depends on PATH_MAX).
Having a comparator which is longer than PKGCONF_ITEM_SIZE therefore
leads to an out of boundary write. Although it is undefined behaviour,
this can lead to an overridden compare variable, which in turn can lead
to an invalid instruction pointer, i.e. most likely a crash or code
execution (very unlikely).
Proof of concept:
$ echo "Requires: x " > poc.pc
$ dd if=/dev/zero bs=1 count=65535 | tr '\0' '<' >> poc.pc
$ pkgconf poc.pc
Eiter compile pkgconf with address sanitizer or run pkgconf multiple
times, eventually it might crash (assuming that ASLR is in place).
In order to fix this, I decided to use an end pointer to avoid OOB write.
Alternative would be to increase the buffer size, but I try to avoid that
since this would be additional ~60 KB stack space for a very unlikely
situation.
Windows allows both \ and / as valid path characters. A computed path
such as C:\development\libfoo\pkgconfig/foo.pc will result in a computed
pkgconf_pkg_t.id of "pkgconfig/foo".
Accordingly, correct the path normalization for checking for / after
the \ path has been dealt with in all cases.
It is possible to set the instruction pointer to undefined values by
using an operator larger than ':' in ASCII.
Since the personality function array does not have 256 entries, an
invalid operator can overflow the array.
Proof of concept:
$ echo "a _ b" > poc
$ ln -s $(which pkgconf) poc-pkgconf
$ ./poc-pkgconf
Every version line has a newline at the end; the malformed whitespace checker
should just check for trailing spaces and tabs.
Resolves https://todo.sr.ht/~kaniini/pkgconf/15
It is possible to trigger an out of boundary access with specially
crafted files. If a line consist of only a key and spaces, then
op will point to '\0'-ending of the buffer. Since p is iterated by
one byte right past this ending '\0', the next read access to p is
effectively out of bounds.
Theoretically this can also lead to out of boundary writes if spaces
are encountered.
Proof of concept (I recommend to compile with address sanitizer):
$ echo -n a > poc.pc
$ dd if=/dev/zero bs=1 count=65533 | tr '\0' ' ' >> poc.pc
$ pkgconf poc.pc
pkgconf_fgetline is called with a user-defined buffer, its size, and
a FILE stream to read input from.
If the buffer is almost completely filled and the file stream contains
an escaped character, then it is possible to trigger an off-by-one
buffer overflow with a '\0' character.
Easiest example to trigger this:
char buf[2];
pkgconf_fgetline(buf, sizeof(buf), stdin);
Enter "\\" (two backslashes) and press enter. If the library and the
program are compiled with address sanitizer, you will see the program
crashing. Otherwise it depends on your architecture what happens.
Since nobody should be using a buffer of only size 1 or 2, keep enough
space for a possibly escaped character in while loop by subtracting one
more byte for this situation, not just for '\0'.
Ariadne Conill
Sandro Mani