Cuidado con la gestión de nombres
Dar un curso de desarrollo seguro (y de seguridad en general) es bastante ‘agradecido’ desde el punto de vista de encontrar ejemplos, porque la actualidad siempre nos trae sorpresas.
Estábamos hablando en clase sobre los problemas de los nombres y de tomar decisiones sobre ellos y justo aparece el fallo en git: Vulnerability announced: update your Git clients
The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem.
La negrita la he puesto yo.
Se puede leer también el anuncio en la lista de desarrollo de git, [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks) y Git 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land.
Si nos interesa ver el código, al menos a una parte, podemos echarle un vistazo a path: add is_ntfs_dotgit() helper, donde hablan de:
On NTFS (and FAT32), there exist so-called “short names” for backwards-compatibility: 8.3 compliant names that refer to the same files as their long names. As “.git” is not an 8.3 compliant name, a short name is generated automatically, typically “git~1”
Y también a: read-cache: optionally disallow HFS+ .git variants donde se ven las invocaciones a la función añadida y alguna cosa más.
Esta entrada se ha publicado orginalmente en Cuidado con la gestión de nombres.