Until very recently OpenBSD built xlockmore against Mesa. xlock is setgid auth. As described by Qualys in their advisory https://marc.info/?l=oss-security&m=157549260013521&w=2 "CVE-2019-19520: Local privilege escalation via xlock" the setuid check in the loader for LIBGL_DRIVERS_PATH does not handle this.
In OpenBSD we now build xlock with --without-opengl --without-mesa and build Mesa with the following patch. This is not an approach that would work on linux and other systems without issetugid(). https://man.openbsd.org/issetugid.2 But it is worth bringing this issue to people's attention. xenocara/lib/mesa/src/loader/loader.c revision 1.8 date: 2019/12/04 02:26:36; author: deraadt; state: Exp; lines: +2 -2; commitid: w6WeeZZ0y0WnF7VD; Constrain honouring of path-related environment variables based upon issetugid(), not just the sloppy uid != euid test. gid != egid cases can occur also. Part of 6.6/009_mesaxlock.patch.sig and 6.5/020_mesaxlock.patch.sig From Qualys, ok diff --git a/src/loader/loader.c b/src/loader/loader.c index 67cf92c19df..7865fe45c87 100644 --- a/src/loader/loader.c +++ b/src/loader/loader.c @@ -446,7 +446,7 @@ loader_get_driver_for_fd(int fd) * user's problem, but this allows vc4 simulator to run on an i965 host, * and may be useful for some touch testing of i915 on an i965 host. */ - if (geteuid() == getuid()) { + if (issetugid() == 0 && geteuid() == getuid()) { driver = getenv("MESA_LOADER_DRIVER_OVERRIDE"); if (driver) return strdup(driver); @@ -534,7 +534,7 @@ loader_open_driver(const char *driver_name, const struct __DRIextensionRec **(*get_extensions)(void); search_paths = NULL; - if (geteuid() == getuid() && search_path_vars) { + if (issetugid() == 0 && geteuid() == getuid() && search_path_vars) { for (int i = 0; search_path_vars[i] != NULL; i++) { search_paths = getenv(search_path_vars[i]); if (search_paths) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev