gitoxide An idiomatic, lean, fast & safe pure Rust implementation of Git. `gix-path` can be tricked into running another `git.exe` placed in an untrusted location by a limited user account on Windows systems. Windows permits limited user accounts without administrative privileges to create new directories in the root of the system drive. While `gix-path` first looks for `git` using a `PATH` search, in version 0.10.8 it also has a fallback strategy on Windows of checking two hard-coded paths intended to be the 64-bit and 32-bit Program Files directories. Existing functions, as well as the newly introduced `exe_invocation` function, were updated to make use of these alternative locations. This causes facilities in `gix_path::env` to directly execute `git.exe` in those locations, as well as to return its path or whatever configuration it reports to callers who rely on it. Although unusual setups where the system drive is not `C:`, or even where Program Files directories have non-default names, are technically possible, the main problem arises on a 32-bit Windows system. Such a system has no `C:\Program Files (x86)` directory. A limited user on a 32-bit Windows system can therefore create the `C:\Program Files (x86)` directory and populate it with arbitrary contents. Once a payload has been placed at the second of the two hard-coded paths in this way, other user accounts including administrators will execute it if they run an application that uses `gix-path` and do not have `git` in a `PATH` directory. (While having `git` found in a `PATH` search prevents exploitation, merely having it installed in the default location under the real `C:\Program Files` directory does not. This is because the first hard-coded path's `mingw64` component assumes a 64-bit installation.). Only Windows is affected. Exploitation is unlikely except on a 32-bit system. In particular, running a 32-bit build on a 64-bit system is not a risk factor. Furthermore, the attacker must have a user account on the system, though it may be a relatively unprivileged account. Such a user can perform privilege escalation and execute code as another user, though it may be difficult to do so reliably because the targeted user account must run an application or service that uses `gix-path` and must not have `git` in its `PATH`. The main exploitable configuration is one where Git for Windows has been installed but not added to `PATH`. This is one of the options in its installer, though not the default option. Alternatively, an affected program that sanitizes its `PATH` to remove seemingly nonessential directories could allow exploitation. But for the most part, if the target user has configured a `PATH` in which the real `git.exe` can be found, then this cannot be exploited. This issue has been addressed in release version 0.10.9 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
gitoxide Una implementación Rust pura idiomática, sencilla, rápida y segura de Git. Se puede engañar a `gix-path` para que ejecute otro `git.exe` colocado en una ubicación que no es de confianza mediante una cuenta de usuario limitada en sistemas Windows. Windows permite cuentas de usuario limitadas sin privilegios administrativos para crear nuevos directorios en la raíz de la unidad del sistema. Mientras que `gix-path` primero busca `git` usando una búsqueda `PATH`, en la versión 0.10.8 también tiene una estrategia alternativa en Windows para verificar dos rutas codificadas destinadas a ser de 64 bits y 32 bits. Directorios de archivos de programa. Las funciones existentes, así como la función `exe_invocation` recientemente introducida, se actualizaron para hacer uso de estas ubicaciones alternativas. Esto hace que las funciones en `gix_path::env` ejecuten directamente `git.exe` en esas ubicaciones, así como que devuelvan su ruta o cualquier configuración que informe a las personas que llaman y dependen de ella. Aunque técnicamente son posibles configuraciones inusuales donde la unidad del sistema no es `C:`, o incluso donde los directorios de Archivos de programa tienen nombres no predeterminados, el problema principal surge en un sistema Windows de 32 bits. Un sistema de este tipo no tiene el directorio `C:\Program Files (x86)`. Por lo tanto, un usuario limitado en un sistema Windows de 32 bits puede crear el directorio `C:\Program Files (x86)` y llenarlo con contenidos arbitrarios. Una vez que se ha colocado una carga útil en la segunda de las dos rutas codificadas de esta manera, otras cuentas de usuario, incluidos los administradores, la ejecutarán si ejecutan una aplicación que usa `gix-path` y no tienen `git` en un directorio `PATH`. (Aunque encontrar `git` en una búsqueda `PATH` previene la explotación, simplemente tenerlo instalado en la ubicación predeterminada en el directorio real `C:\Program Files` no lo hace. Esto se debe a que `mingw64` de la primera ruta codificada componente asume una instalación de 64 bits). Sólo Windows se ve afectado. La explotación es poco probable excepto en un sistema de 32 bits. En particular, ejecutar una versión de 32 bits en un sistema de 64 bits no es un factor de riesgo. Además, el atacante debe tener una cuenta de usuario en el sistema, aunque puede ser una cuenta relativamente sin privilegios. Dicho usuario puede realizar una escalada de privilegios y ejecutar código como otro usuario, aunque puede resultar difícil hacerlo de manera confiable porque la cuenta de usuario objetivo debe ejecutar una aplicación o servicio que use `gix-path` y no debe tener `git` en su `RUTA`. La principal configuración explotable es aquella en la que se instaló Git para Windows pero no se agregó a "PATH". Esta es una de las opciones de su instalador, aunque no es la opción predeterminada. Alternativamente, un programa afectado que desinfecte su `PATH` para eliminar directorios aparentemente no esenciales podría permitir la explotación. Pero en su mayor `PATH`, si el usuario objetivo ha configurado una `PATH` en la que se puede encontrar el "git.exe" real, entonces esto no se puede explotar. Este problema se solucionó en la versión 0.10.9 y se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.
