CVE-2023-42456

{"id": "CVE-2023-42456", "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 3.1, "attackVector": "LOCAL", "baseSeverity": "LOW", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:L", "integrityImpact": "LOW", "userInteraction": "REQUIRED", "attackComplexity": "LOW", "availabilityImpact": "LOW", "privilegesRequired": "HIGH", "confidentialityImpact": "NONE"}, "impactScore": 2.5, "exploitabilityScore": 0.6}, {"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 8.1, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 5.2, "exploitabilityScore": 2.8}]}, "published": "2023-09-21T16:15:09.980", "references": [{"url": "http://www.openwall.com/lists/oss-security/2023/11/02/1", "source": "security-advisories@github.com"}, {"url": "https://ferrous-systems.com/blog/sudo-rs-audit/", "source": "security-advisories@github.com"}, {"url": "https://github.com/memorysafety/sudo-rs/commit/bfdbda22968e3de43fa8246cab1681cfd5d5493d", "tags": ["Patch"], "source": "security-advisories@github.com"}, {"url": "https://github.com/memorysafety/sudo-rs/security/advisories/GHSA-2r3c-m6v7-9354", "tags": ["Vendor Advisory"], "source": "security-advisories@github.com"}, {"url": "http://www.openwall.com/lists/oss-security/2023/11/02/1", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://ferrous-systems.com/blog/sudo-rs-audit/", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://github.com/memorysafety/sudo-rs/commit/bfdbda22968e3de43fa8246cab1681cfd5d5493d", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://github.com/memorysafety/sudo-rs/security/advisories/GHSA-2r3c-m6v7-9354", "tags": ["Vendor Advisory"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Modified", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-22"}, {"lang": "en", "value": "CWE-23"}]}, {"type": "Secondary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-22"}]}], "descriptions": [{"lang": "en", "value": "Sudo-rs, a memory safe implementation of sudo and su, allows users to not have to enter authentication at every sudo attempt, but instead only requiring authentication every once in a while in every terminal or process group. Only once a configurable timeout has passed will the user have to re-authenticate themselves. Supporting this functionality is a set of session files (timestamps) for each user, stored in `/var/run/sudo-rs/ts`. These files are named according to the username from which the sudo attempt is made (the origin user).\n\nAn issue was discovered in versions prior to 0.2.1 where usernames containing the `.` and `/` characters could result in the corruption of specific files on the filesystem. As usernames are generally not limited by the characters they can contain, a username appearing to be a relative path can be constructed. For example we could add a user to the system containing the username `../../../../bin/cp`. When logged in as a user with that name, that user could run `sudo -K` to clear their session record file. The session code then constructs the path to the session file by concatenating the username to the session file storage directory, resulting in a resolved path of `/bin/cp`. The code then clears that file, resulting in the `cp` binary effectively being removed from the system.\n\nAn attacker needs to be able to login as a user with a constructed username. Given that such a username is unlikely to exist on an existing system, they will also need to be able to create the users with the constructed usernames.\n\nThe issue is patched in version 0.2.1 of sudo-rs. Sudo-rs now uses the uid for the user instead of their username for determining the filename. Note that an upgrade to this version will result in existing session files being ignored and users will be forced to re-authenticate. It also fully eliminates any possibility of path traversal, given that uids are always integer values.\n\nThe `sudo -K` and `sudo -k` commands can run, even if a user has no sudo access. As a workaround, make sure that one's system does not contain any users with a specially crafted username. While this is the case and while untrusted users do not have the ability to create arbitrary users on the system, one should not be able to exploit this issue."}, {"lang": "es", "value": "Sudo-rs, una implementaci\u00f3n segura de memoria de sudo y su, permite a los usuarios no tener que ingresar autenticaci\u00f3n en cada intento de sudo, sino que solo requiere autenticaci\u00f3n de vez en cuando en cada terminal o grupo de procesos. Solo una vez que haya transcurrido un tiempo de espera configurable, el usuario deber\u00e1 volver a autenticarse. Esta funcionalidad admite un conjunto de archivos de sesi\u00f3n (marcas de tiempo) para cada usuario, almacenados en `/var/run/sudo-rs/ts`. Estos archivos se nombran seg\u00fan el nombre de usuario desde el que se realiza el intento de sudo (el usuario de origen). Se descubri\u00f3 un problema en versiones anteriores a la 0.2.1 donde los nombres de usuario que conten\u00edan los caracteres `.` y `/` pod\u00edan provocar la corrupci\u00f3n de archivos espec\u00edficos en el sistema de archivos. Como los nombres de usuario generalmente no est\u00e1n limitados por los caracteres que pueden contener, se puede construir un nombre de usuario que parezca un Path Traversal. Por ejemplo, podr\u00edamos agregar un usuario al sistema que contenga el nombre de usuario `../../../../bin/cp`. Cuando iniciaba sesi\u00f3n como usuario con ese nombre, ese usuario pod\u00eda ejecutar `sudo -K` para borrar su archivo de registro de sesi\u00f3n. Luego, el c\u00f3digo de sesi\u00f3n construye la ruta al archivo de sesi\u00f3n concatenando el nombre de usuario al directorio de almacenamiento del archivo de sesi\u00f3n, lo que da como resultado una ruta resuelta de `/bin/cp`. Luego, el c\u00f3digo borra ese archivo, lo que da como resultado que el binario `cp` se elimine efectivamente del sistema. Un atacante debe poder iniciar sesi\u00f3n como usuario con un nombre de usuario construido. Dado que es poco probable que dicho nombre de usuario exista en un sistema existente, tambi\u00e9n deber\u00e1n poder crear usuarios con los nombres de usuario creados. El problema se solucion\u00f3 en la versi\u00f3n 0.2.1 de sudo-rs. Sudo-rs ahora usa el uid del usuario en lugar de su nombre de usuario para determinar el nombre del archivo. Tenga en cuenta que una actualizaci\u00f3n a esta versi\u00f3n har\u00e1 que se ignoren los archivos de sesi\u00f3n existentes y los usuarios se ver\u00e1n obligados a volver a autenticarse. Tambi\u00e9n elimina por completo cualquier posibilidad de Path Traversal, dado que los uids son siempre valores enteros. Los comandos `sudo -K` y `sudo -k` se pueden ejecutar, incluso si un usuario no tiene acceso a sudo. Como workaround, aseg\u00farese de que su sistema no contenga ning\u00fan usuario con un nombre de usuario especialmente manipulado. Si bien este es el caso y aunque los usuarios que no son de confianza no tienen la capacidad de crear usuarios arbitrarios en el sistema, no se deber\u00eda poder explotar este problema."}], "lastModified": "2024-11-21T08:22:34.333", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:memorysafety:sudo:*:*:*:*:*:rust:*:*", "vulnerable": true, "matchCriteriaId": "B8E119A1-5AFE-4E8E-AB2A-889307A83799", "versionEndExcluding": "0.2.1"}], "operator": "OR"}]}], "sourceIdentifier": "security-advisories@github.com"}