L'équipe de développement de Git vient d'annoncer qu'une importante faille de sécurité avait été découverte dans l'outil de gestion de versions. Elle touche le client officiel, mais également ceux qui l'exploitent, comme GitHub. Les conséquences peuvent être fâcheuses puisqu'il est question de l'exécution de code à distance sur Linux (dans certains cas seulement), OS X et Windows.
Git est un logiciel libre de gestion de versions pour les projets qui est utilisé par de nombreux développeurs. Problème, une importante faille de sécurité (CVE-2014-9390) vient d'être découverte et cela ne concerne pas uniquement le client officiel puisque toutes les applications tierces sont également touchées, comme celles du service GitHub par exemple.
De la différence entre « .git » et « .Git »
Ce dernier a d'ailleurs publié un billet sur son blog afin de donner quelques explications et inciter ses utilisateurs à se mettre à jour sans attendre. On y apprend que cette faille concerne tous les dépôts hébergés sur des systèmes qui ne sont pas sensibles à la casse, le problème vient d'une confusion entre « .Git » et « .git ». Il y est indiqué qu'« un pirate peut concevoir une arborescence malveillante qui aura pour conséquence l'écrasement du fichier .git/config lors d'un clonage ou d'une vérification d'un dépôt, cela permet ensuite d'exécuter du code arbitraire sur la machine ». C'est donc une porte grande ouverte qui s'offre ainsi aux pirates qui pourraient s'en donner à cœur joie pour infecter des ordinateurs à distance.
De son côté, l'équipe en charge du développement de Git précise que les applications pour OS X (système de fichiers HFS+) et Windows (NTFS et FAT) ont droit à d'autres correctifs spécifiques. Dans le premier cas, un chemin du type « .g\u200cit/config » était en fait traité comme étant « .git/config », tandis que dans le second cas le problème se produisait avec « git~1/config » par exemple. Linux n'est pas totalement épargné, mais cela n'affecte que les machines utilisant un système de fichier non sensible à la casse. Red Hat en profite pour préciser que ce n'est pas le cas de son système Linux Entreprise et qu'il n'est donc pas vulnérable à cette faille.
Des mises à jour sont déjà disponibles
Bien évidemment, des mises à jour ont été mises en ligne. Git passe ainsi à la mouture 2.2.1 (voir les notes de version), mais des versions de « maintenances » sont également disponibles pour des versions plus anciennes : Git 1.8.5.6, 1.9.5, 2.0.5 et 2.1.4. GitHub est également à jour avec la mouture 2.6.5 de son application. Dans tous les cas, il est donc important de se mettre rapidement à jour.
Commentaires (55)
#1
Mouais, la faille n’est pas si évidente, en fait faut que le dépôt soit déjà attaqué et trafiqué. Mais bon c’est tout de même une bonne chose que ce soit corrigé.
Sous Linux, les FS cas insensitive ca ne court pas les rues, sauf si on monte un FS windows " />
#2
Linux n’est pas totalement épargné, mais cela n’affecte que les machines
utilisant un système de fichier non sensible à la casse.
Donc si on installe son Linux sur une partition FAT32 (par exemple), on devient vulnérable à cette faille ?
#3
#4
J’ai compris le message de CryoGen à l’envers, et je peux plus éditer mon message (le bouton valider fait rien).
#5
#6
Avez vous une idée si eGit (l’implémentation git en Java utilisé par Eclipse) est concerné par cette faille du lors du clonage d’un dépôt ?
#7
Linus, il participe tjrs au dév de Git ou il a refilé le bébé ?
#8
Various implementations and ports, including Git for Windows, Git OS
X installer, JGit & EGit, libgit2 (and Visual Studio which uses it)
have been updated at the same time.
Je crois que ca touche tout le monde GIT en fait.
#9
il a refilé le projet à Junio C Hamano.
#10
egit n’est pas une implémentation de git mais une surcouche à git. Donc oui il est affecté.
#11
J’ai trouvé la réponse :https://answers.launchpad.net/ubuntu/+source/git/+question/259248. Qd les depot d’éclipse seront a jours ont aura le fix. En même temps étant sur linux FS case sensitive, y a pas trop à s’inquiéter.
#12
Finalement les dev Android ne doivent pas regretter d’avoir rajouté au début de leur make un test qui passe en erreur si le FS courant est «case insensitive»
#13
Oui autant pour moi, il s’agit lus de Jgit dans ce cas
#14
à noter que la faille touche aussi plus ou moins Mercurial.
#15
il est impossible d’installer linux sur du fat32, il faut un systeme de fichier ‘unix gentil’ " />
#16
certes mais meme si l’OS se trouve sur un FS case sensitive, il est tout a fait possible d’avoir les arbo GIT stockées ailleurs, et pourquoi pas sur un autres FS qui serait pas case sensitive, lui
#17
sisi on peut mais c’est pas forcément une bonne idée.
#18
On y apprend que cette faille concerne tous les dépôts hébergés sur des systèmes qui ne sont pas sensibles à la casse, le problème vient d’une confusion entre « .Git » et « .git ».
Merci Windows." />
#19
Ce qu’il faut noter surtout, c’est que ce sont les devs mercurial qui ont découvert le souci chez eux, puis ont prévenu les devs git, soumis au même problème et les deux teams ont décidé de coordonner une release ensemble.
http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html
Mais la news a tellement été déformée entre temps que /. annonçait hier que “github a découvert et corrigé une faille dans git”
#20
#21
lol debian stable est en 1.7 donc soit pas touché soit trop vieux pour que les dev s’en soucis " /> :p (surement le second cas :‘( ) bon le mainteneur va ptet faire un patch…
#22
#23
Oui c’est ce que j’ai lu aussi " />
#24
Non c’est bien sur un FS qui est insensible à la casse que la faille existe :
The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem
Voir
http://article.gmane.org/gmane.linux.kernel/1853266
https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
:)
#25
au debut j’ai eu peur… puis quand j’ai lu que ca ne concerne que les FS qui confondent .git et .Git ca m’a fait rire ^^
sous Linux, normalement le FS est sensible a la difference … S’il ne l’est pas c’est que l’on installe linux de facon tres tres bizare :/
sous osX on a le choix a l’installation, venant de linux j’ai volontairement laisser pareil !
sous windows … bah c’est windows ;)
apres oui cloner un git sur une partition fat32 :/
bref news alarmante qui au final ne touche que ceux qui on un FS foireux
#26
Il suffit d’utiliser une clé USB, elles sont majoritairement préformatées en FAT32.
#27
#28
Bon ben mise à jour faite " />
#29
Personnellementje ne développe jamais à partir d’une clé usb, c’est bien trop long en terme d’accès disque pour les fichiers temporaires de build
#30
#31
En même temps, si les hackers y vont à coup de pied de biche … forcément … " />
#32
Pour plus d’infos sur la situation de mercurial, cf les commentaires de sid0 surhttp://arstechnica.com/security/2014/12/critical-git-bug-allows-malicious-code-e… :
Contrairement à git, le bug de la collision de la case a été corrigé il y a très longtemps dans mercurial (genre en 2008), ce qui est nouveau pour eux, c’est la découverte de subtilités non documentées dans la façon dont darwin gère/ne gère pas certains caractères spéciaux dans HFS+ (http://selenic.com/hg/rev/885bd7c5c7e3 )
#33
#34
Oausi c’est la plaie… j’en cherchais un (FS) il y a quelque mois pour les clés usb ou les hdd externe qui se baladent… bah rien de bien probant ou alors en NTFS mais voilà les perf d’écriture…
#35
#36
Il y a encore des gens pour utiliser des file systems non sensible à la casse! Ça parait peu probable sous Linux mais bon s’ils aiment ça…" />
#37
#38
#39
j’insiste ce n’est pas possible d’installer linux sur une partition FAT32
, il manque tous les attributs unix dans FAT32 ce qui nous reviens à 2 solution, l’installer dans un gros fichier LOOP, ou utiliser UMSDOS qui n’existe plus. Le premier cas n’est pas ce que j’appel une installation, c’est du bricolage car le fichier est formaté en ext2 " />, pour le deuxieme même argument, ce n’est pas du fat32. c’est une surcouche à fat32 incompatible avec Windows.
#40
#41
Toujours pas de FS adapté aux clés, merci les brevets.
#42
#43
De la différence entre « .git » et « .Git »
Rien compris et j’attends toujorus dans le paragraphe l’explication …
#44
Impossible d’editer sur cette nouvelle. Il semblerait que cela varie en fonction de la personne qui a ecrite la nouvelle et uniquement lorsque l’on quote ou repond a un message. Veuillez corriger vos bug, merci.
#45
#46
#47
#48
#49
http://linuxfr.org/news/vulnerabilite-dans-git-sur-certains-systemes-de-fichiers-fat-ntfs-hfs-etc
#50
#51
#52
#53
#54
#55
c’est dimanche