CVE-2019-18276

An issue was discovered in disable_priv_mode in shell.c in GNU Bash through 5.0 patch 11. By default, if Bash is run with its effective UID not equal to its real UID, it will drop privileges by setting its effective UID to its real UID. However, it does so incorrectly. On Linux and other systems that support "saved UID" functionality, the saved UID is not dropped. An attacker with command execution in the shell can use "enable -f" for runtime loading of a new builtin, which can be a shared object that calls setuid() and therefore regains privileges. However, binaries running with an effective UID of 0 are unaffected.

An issue was discovered in disable_priv_mode in shell.c in GNU Bash through 5.0 patch 11. By default, if Bash is run with its effective UID not equal to its real UID, it will drop privileges by setting its effective UID to its real UID. However, it does so incorrectly. On Linux and other systems that support "saved UID" functionality, the saved UID is not dropped. An attacker with command execution in the shell can use "enable -f" for runtime loading of a new builtin, which can be a shared object that calls setuid() and therefore regains privileges. However, binaries running with an effective UID of 0 are unaffected.

Se descubrió un problema en la función disable_priv_mode en el archivo shell.c en GNU Bash versiones hasta la versión 5.0 parche 11. Por defecto, si Bash es ejecutado con su UID efectivo no igual a su UID real, perderá privilegios al establecer su UID efectivo en su UID real. Sin embargo, lo hace incorrectamente. En Linux y otros sistemas que admiten la funcionalidad "saved UID", el UID guardado no se descarta. Un atacante con ejecución de comando en el shell puede utilizar "enable -f" para la carga del tiempo de ejecución un nuevo builtin, que puede ser un objeto compartido que llama a setuid() y, por lo tanto, recupera privilegios. Sin embargo, los archivos binarios que son ejecutados con un UID efectivo de 0 no están afectados.