Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Backport !1926 “Add g_memdup2()” to glib-2-66

See merge request GNOME/glib!1927

The public API `GIOChannel.line_term_len` is only a `guint`. Ensure that
nul-terminated strings passed to `g_io_channel_set_line_term()` can’t
exceed that length. Use `g_memdup2()` to avoid a warning (`g_memdup()`
is due to be deprecated), but not to avoid a bug, since it’s also
limited to `G_MAXUINT`.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

The public API `g_tls_password_set_value_full()` (and the vfunc it
invokes) can only accept a `gssize` length. Ensure that nul-terminated
strings passed to `g_tls_password_set_value()` can’t exceed that length.
Use `g_memdup2()` to avoid an overflow if they’re longer than
`G_MAXUINT` similarly.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

Don’t use an `int`, that’s potentially too small. In practical terms,
this is not a problem, since no socket address is going to be that big.

By making these changes we can use `g_memdup2()` without warnings,
though. Fewer warnings is good.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

Previously, the code in `convert_path()` could not handle keys longer
than `G_MAXINT`, and would overflow if that was exceeded.

Convert the code to use `gsize` and `g_memdup2()` throughout, and
change from identifying the position of the final slash in the string
using a signed offset `i`, to using a pointer to the character (and
`strrchr()`). This allows the slash to be at any position in a
`G_MAXSIZE`-long string, without sacrificing a bit of the offset for
indicating whether a slash was found.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

This allows it to handle strings up to length `G_MAXSIZE` — previously
it would overflow with such strings.

Update the several copies of it identically.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

Previously it was handled as a `gssize`, which meant that if the
`stop_chars` string was longer than `G_MAXSSIZE` there would be an
overflow.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

The members of `URL_COMPONENTS` (`winhttp_file->url`) are `DWORD`s, i.e.
32-bit unsigned integers. Adding to and multiplying them may cause them
to overflow the unsigned integer bounds, even if the result is passed to
`g_memdup2()` which accepts a `gsize`.

Cast the `URL_COMPONENTS` members to `gsize` first to ensure that the
arithmetic is done in terms of `gsize`s rather than unsigned integers.

Spotted by Sebastian Dröge.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it

In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 by GHSL team member Kevin Backhouse.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: GHSL-2021-045
Helps: #2319

Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319

This will replace the existing `g_memdup()` function for use within
GLib. It has an unavoidable security flaw of taking its `byte_size`
argument as a `guint` rather than as a `gsize`. Most callers will
expect it to be a `gsize`, and may pass in large values which could
silently be truncated, resulting in an undersize allocation compared
to what the caller expects.

This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.

`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.

Spotted by Kevin Backhouse of GHSL.

In GLib 2.68, `g_memdup2()` will be a new public API. In this version
for backport to older stable releases, it’s a new `static inline` API
in a private header, so that use of `g_memdup()` within GLib can be
fixed without adding a new API in a stable release series.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: GHSL-2021-045
Helps: #2319

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Backport !1920 “Resolve GDBus regressions in setcap/setgid programs” to glib-2-66

See merge request GNOME/glib!1922

Simon McVittie (Collabora) authored 4 years ago and Philip Withnall committed 4 years ago

This is against my better judgement, but it's the least bad regression
fix I can think of. If we don't do this, at least gnome-keyring-daemon
(setcap) and msmtp (setgid) are known to regress.

Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2305
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981555


Signed-off-by: Simon McVittie <smcv@collabora.com>

Simon McVittie (Collabora) authored 4 years ago and Philip Withnall committed 4 years ago

We're using "setuid" here as shorthand for any elevated privileges
that should make us distrust the caller: setuid, setgid, filesystem
capabilities, more obscure Linux things that set the AT_SECURE flag
(such as certain AppArmor transitions), and their equivalents on
other operating systems. This is fine if we do it consistently, but
I'm about to add a check for whether we are *literally* setuid,
which would be particularly confusing without a rename.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Simon McVittie (Collabora) authored 4 years ago and Philip Withnall committed 4 years ago

Signed-off-by: Simon McVittie <smcv@collabora.com>

Backport !1902 “spawn: Don't set a search path if we don't want to search PATH” to glib-2-66

See merge request GNOME/glib!1913

Simon McVittie (Collabora) authored 4 years ago and Philip Withnall committed 4 years ago

Signed-off-by: Simon McVittie <smcv@collabora.com>

Thomas Haller authored 4 years ago and Philip Withnall committed 4 years ago

We preallocate buffers that are used after forked. That is because
malloc()/free() are not async-signal-safe and must not be used between
fork() and exec().

However, for the child process that exits without fork, valgrind wrongly
reports these buffers as leaked.
That can be suppressed with "--child-silent-after-fork=yes", but it is
cumbersome.

Work around by trying to allocate the buffers on the stack. At
least in the common cases where the pointers are small enough
so that we can reasonably do that.

If the buffers happen to be large, we still allocate them on the heap
and the problem still happens. Maybe we could have also allocated them
as thread_local, but currently glib doesn't use that.

[smcv: Cosmetic adjustments to address review comments from pwithnall]

Simon McVittie (Collabora) authored 4 years ago and Philip Withnall committed 4 years ago

For manual test coverage that would reproduce the bug fixed in !1902,
copy /bin/true (or any other harmless executable) to
/usr/bin/spawn-test-helper.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Simon McVittie (Collabora) authored 4 years ago and Philip Withnall committed 4 years ago

do_exec() and g_execute() rely on being passed a NULL search path
if we intend to avoid searching the PATH, but since the refactoring
in commit 62ce66d4, this was never done. This resulted in some spawn
calls searching the PATH when it was not intended.

Spawn calls that go through the posix_spawn fast-path were unaffected.

The deprecated gtester utility, as used in GTK 3, relies on the
ability to run an executable from the current working directory by
omitting the G_SPAWN_SEARCH_PATH flag. This *mostly* worked, because
our fallback PATH ends with ".". However, if an executable of the
same name existed in /usr/bin or /bin, it would run that instead of the
intended test: in particular, GTK 3's build-time tests failed if
ImageMagick happens to be installed, because gtester would accidentally
run display(1) instead of testsuite/gdk/display.

Fixes: 62ce66d4 "gspawn: Don’t use getenv() in async-signal-safe context"
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977961

Backport !1868 “gdesktopappinfo: Fix validation of XDG_CURRENT_DESKTOP” to glib-2-66

See merge request GNOME/glib!1872

Krzesimir Nowak authored 4 years ago and Philip Withnall committed 4 years ago

We added another desktop file, so update the file count.

Krzesimir Nowak authored 4 years ago and Philip Withnall committed 4 years ago

Split out XDG_CURRENT_DESKTOP handling to a separate function and make
sure that it drops all the invalid entries properly. Earlier a bad
entry could slip through the checks by sitting just after another bad
entry, like in env being set to `invalid1!:invalid2!`, where
`invalid2!` could slip the checks.

Backport !1862 “gio: Ignore various environment variables when running as setuid” to glib-2-66

See merge request GNOME/glib!1864

As with previous commits, this could have been used to load private data
for an unprivileged caller.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2168

It could have been used to load private data which would not normally be
accessible to an unprivileged caller.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2168

Its components are used to build filenames, so if the value of
`XDG_CURRENT_DESKTOP` comes from an untrusted caller (as can happen in
setuid programs), using it unvalidated may be unsafe.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2168

As with the previous commit, it’s unsafe to trust the environment when
running as setuid, as it comes from an untrusted caller. In particular,
with D-Bus, the caller could set up a fake ‘system’ bus which fed
incorrect data to this process.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2168

Even if the modules in the given directory never get chosen to be used,
loading arbitrary code from a user-provided directory is not safe when
running as setuid, as the process’ environment comes from an untrusted
source.

Also ignore `GIO_EXTRA_MODULES`.

Spotted by Simon McVittie.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #2168

gdatetime.c: Fix MSVC builds for lack of NAN items

See merge request GNOME/glib!1831

Backport !1827 “Windows: fix FD_READ condition flag still set on recoverable UDP socket errors.” to glib-2-66

See merge request GNOME/glib!1836

Marco Mastropaolo authored 4 years ago and Philip Withnall committed 4 years ago

Contrary to what the WSARecvFrom seem to imply, a UDP socket is perfectly recoverable and usable after a WSAECONNRESET error (and, I assume, WSAENETRESET).
However GSocket condition has the FD_READ bit set after a UDP socket fails with WSAECONNRESET, even if no data is available on the socket anymore; this causes select calls to report the socket as readable when, in fact, it's not.

The change resets FD_READ flag on a socket upon the above error conditions; there's no 'if' to filter between datagram and stream sockets as the change should be harmless in the case of stream sockets which are, however, very unlikely to be usable after a WSAECONNRESET.

Use a fallback for isnan() on Visual Studio 2012 or earlier, and define
NAN if it does not exist.

Backport !1821 “gdate: Limit length of dates which can be parsed as valid” to glib-2-66

See merge request GNOME/glib!1824

Makes the validation a tiny bit faster.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>