Git touché par une importante faille de sécurité, les correctifs sont là

Git touché par une importante faille de sécurité, les correctifs sont là

Git-apens

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

19/12/2014 3 minutes
55

Git touché par une importante faille de sécurité, les correctifs sont là

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.

55

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

De la différence entre « .git » et « .Git »

Des mises à jour sont déjà disponibles

Commentaires (55)


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 <img data-src=" />




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 ?

&nbsp;







CryoGen a écrit :



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 <img data-src=" />





Tu veux pas dire case sensitive ?









Winderly a écrit :



Donc si on installe son Linux sur une partition FAT32 (par exemple), on devient vulnérable à cette faille ?

&nbsp;



Si tu installe la partition et que ton depot Git est sur cette partition.



J’ai compris le message de CryoGen à l’envers, et je peux plus éditer mon message (le bouton valider fait rien).








Winderly a écrit :



Tu veux pas dire case sensitive ?







Bah non <img data-src=" /> sous Linux les FS sont majoritairement case sensitive (ce qui est une bonne chose). Ici le problème survient dans le cadre de FS case insensitive.







Winderly a écrit :



J’ai compris le message de CryoGen à l’envers, et je peux plus éditer mon message (le bouton valider fait rien).







Grilled :tranpi:



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 ?


Linus, il participe tjrs au dév de Git ou il a refilé le bébé ?




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.


il a refilé le projet à Junio C Hamano.


egit n’est pas une implémentation de git mais une surcouche à git. Donc oui il est affecté.


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.


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»


Oui autant pour moi, il s’agit lus de Jgit dans ce cas


à noter que la faille touche aussi plus ou moins Mercurial.


il est impossible d’installer linux sur du fat32, il faut un systeme de fichier ‘unix gentil’&nbsp;<img data-src=" />


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


sisi on peut mais c’est pas forcément une bonne idée.




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&nbsp;casse, le problème vient d’une confusion entre « .Git » et « .git ».





Merci&nbsp; Windows.<img data-src=" />


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”








Homedread a écrit :



Oui au temps pour moi, il s’agit plus de Jgit dans ce cas



Fixed <img data-src=" />



lol debian stable est en 1.7 donc soit pas touché soit trop vieux pour que les dev s’en soucis <img data-src=" /> :p (surement le second cas :‘( ) bon le mainteneur va ptet faire un patch…








Winderly a écrit :



Donc si on installe son Linux sur une partition FAT32 (par exemple), on devient vulnérable à cette faille ?

&nbsp;





D’après ce que j’ai lu, c’est l’inverse. Mais je pense plus qu’il y a une boulette dans la niouze…



Oui c’est ce que j’ai lu aussi <img data-src=" />


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



:)


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 !&nbsp;



sous windows … bah c’est windows ;)



apres oui cloner un git sur une partition fat32 :/&nbsp;



bref news alarmante qui au final ne touche que ceux qui on un FS foireux


Il suffit d’utiliser une clé USB, elles sont majoritairement préformatées en FAT32.








CryoGen a écrit :



Non c’est bien sur un FS qui est insensible à la casse que la faille existe :





Voir

http://article.gmane.org/gmane.linux.kernel/1853266

https://github.com/blog/1938-vulnerability-announced-update-your-git-clients



:)





Merci <img data-src=" />



Bon ben mise à jour faite <img data-src=" />


&nbsp; 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








psn00ps a écrit :



Il suffit d’utiliser une clé USB, elles sont majoritairement préformatées en FAT32.





Ce qui n’oblige pas à les y laisser, si on doit les partager avec des machines windows autant les mettre en NTFS, Linux saura gérer.

&nbsp;

Ceci dit, un FS sans gestion de droits utilisateurs ca peut parfois rendre service quand on passe d’une machine à l’autre et qu’on n’a pas les droits pour faire le chown qui va bien sur la machine destination! <img data-src=" />



En même temps, si les hackers y vont à coup de pied de biche … forcément … <img data-src=" />


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 )








yl a écrit :



Ce qui n’oblige pas à les y laisser, si on doit les partager avec des machines windows autant les mettre en NTFS, Linux saura gérer.

&nbsp;

Ceci dit, un FS sans gestion de droits utilisateurs ca peut parfois rendre service quand on passe d’une machine à l’autre et qu’on n’a pas les droits pour faire le chown qui va bien sur la machine destination! <img data-src=" />





Depuis le temps, on n’a toujours pas un FS adapté et universel pour les clés? Je veux dire, NTFS et EXT ne vont pas à cause des droits. FAT est juste trop vieux et a des limitations qui ne sont plus acceptables. Il faudrait une sorte de nouveau FAT.



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…








gokudomatic a écrit :



Depuis le temps, on n’a toujours pas un FS adapté et universel pour les clés? Je veux dire, NTFS et EXT ne vont pas à cause des droits. FAT est juste trop vieux et a des limitations qui ne sont plus acceptables. Il faudrait une sorte de nouveau FAT.





exFAT a été fait pour ça, il me semble… &nbsp;Bon, ça reste du Microsoft, hein…&nbsp;



&nbsphttp://en.wikipedia.org/wiki/ExFAT



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…<img data-src=" />








gokudomatic a écrit :



Depuis le temps, on n’a toujours pas un FS adapté et universel pour les clés? Je veux dire, NTFS et EXT ne vont pas à cause des droits. FAT est juste trop vieux et a des limitations qui ne sont plus acceptables. Il faudrait une sorte de nouveau FAT.





exFAT? Le problème étant que c’est encore Microsoft qui l’a sorti et que l’adoption reste faible (elle sera sans doute au final tirée par les fichiers de video HD des APN pour qui les 4GB deviennent emmerdants) et problématique (brevets côté linux?).









yl a écrit :



exFAT? Le problème étant que c’est encore Microsoft qui l’a sorti et que l’adoption reste faible (elle sera sans doute au final tirée par les fichiers de video HD des APN pour qui les 4GB deviennent emmerdants) et problématique (brevets côté linux?).





Justement. Il faudrait que je-ne-sais-quelle-fondation neutre, open source et tout fasse les spec de cela.

Note que si MS fait un boulot correct avec son exFat pour que celui-ci réponde aux mêmes conditions (libre, documenté, reproduisible exactement, et sans brevet payant), alors pas besoin de réinventer la roue. Après tout, lorsque le format PDF est devenu libre, tout le monde l’a adopté.



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 à&nbsp;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&nbsp;<img data-src=" />, pour le deuxieme même argument, ce n’est pas du fat32. c’est une surcouche à fat32 incompatible avec Windows.








gokudomatic a écrit :



Justement. Il faudrait que je-ne-sais-quelle-fondation neutre, open source et tout fasse les spec de cela.

Note que si MS fait un boulot correct avec son exFat pour que celui-ci réponde aux mêmes conditions (libre, documenté, reproduisible exactement, et sans brevet payant), alors pas besoin de réinventer la roue. Après tout, lorsque le format PDF est devenu libre, tout le monde l’a adopté.



de la part de MS, tu rêves là <img data-src=" />

exFAT est sous licence proprio, et ils ne sont pas prêt de le lacher…



Toujours pas de FS adapté aux clés, merci les brevets.








sscrit a écrit :



il est impossible d’installer linux sur du fat32, il faut un systeme de fichier ‘unix gentil’&nbsp;<img data-src=" />





Excellente ta nouvelle traduction entre guillemets <img data-src=" /> .





De la différence entre « .git » et « .Git »





Rien compris et j’attends toujorus dans le paragraphe l’explication …


Impossible d’editer sur cette nouvelle.&nbsp; 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.








yl a écrit :



exFAT? Le problème étant que c’est encore Microsoft qui l’a sorti et que l’adoption reste faible (elle sera sans doute au final tirée par les fichiers de video HD des APN pour qui les 4GB deviennent emmerdants) et problématique (brevets côté linux?).





Linux n’en a rien à faire des brevets US, du moins ailleurs qu’aux US.



On peut déjà depuis 2011 (si pas avant) lire du exFAT sur Linux :http://apcmag.com/how-to-enable-exfat-in-ubuntu.htm&nbsp;&nbsp;









psn00ps a écrit :



Toujours pas de FS adapté aux clés, merci les brevets.





Ah bon ? Peux-tu en dire plus ?

&nbsp;

Plus sérieusement, on a des FS adaptés aux clés (à la Flash) en libre, encore faudrait-il que MS les inclue dans son OS sinon ça ne prendra pas. Et rien n’interdit de formater une clé en ext4, j’en utilise une comme ça.









gokudomatic a écrit :



Justement. Il faudrait que je-ne-sais-quelle-fondation neutre, open source et tout fasse les spec de cela.

Note que si MS fait un boulot correct avec son exFat pour que celui-ci réponde aux mêmes conditions (libre, documenté, reproduisible exactement, et sans brevet payant), alors pas besoin de réinventer la roue. Après tout, lorsque le format PDF est devenu libre, tout le monde l’a adopté.





Ce qui tire le truc pour les cartes mémoires… c’est surtout ce que l’industrie (tablettes, APN…) choisit!









OlivierJ a écrit :



rien n’interdit de formater une clé en ext4, j’en utilise une comme ça.





Reste qu’on ne peut pas les utiliser sur un PC windows/tablette… windows est même assez con pour ne voir que la première partition sur une clef/carte mémoire qui en comporte plus d’une! Alors des systèmes de fichiers EXT4!



Pourtant ce serait utile, ne serait-ce que pour le TRIM qui commence a être supporté par certains modèles et que les vieux FS ne supportent pas (Ext4 avec l’option de montage “discard”, oui, par exemple).









pentest a écrit :



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.







Tu as un temps défini pour pouvoir éditer ton message, si tu dépasses ce temps, tu ne peux plus éditer.



Rien avoir avec un bug ! <img data-src=" />









Ricard a écrit :



Merci&nbsp; Windows.<img data-src=" />





Pour info (bon je sais que c’est vendredi, troll’s day toussa…) :http://support.microsoft.com/kb/100625/en-us

Donc NTFS est case sensitive en mode POSIX.



Et pour un utilisateur lambda, je suis pas sûr que ça ait du sens d’avoir deux fichiers du même nom, à la casse différente…

&nbsp;



pentest a écrit :



Rien compris et j’attends toujorus dans le paragraphe l’explication …





En gros, si tu crée un dossier “.Git/config” sur le repo Git, alors lorsqu’il va faire le clone/fetch/rebase/pull, Git va écraser la configuration locale. Tu peux par exemple ajouter des hooks Git au repo local et (admettons) envoyer la clef privée (genre dans ~/.ssh/id_rsa par défaut) via curl.



C’est en tout cas comme ça que je le comprends.









Baldurien a écrit :



Donc NTFS est case sensitive en mode POSIX.





NTFS est case-sensitive&nbsp;<img data-src=" />

Après, ce n’est pas géré par beaucoup d’applications (dont l’explorer Windows) et certaines API ne sont pas case-sensitive, mais ça c’est un autre problème.









jrbleboss a écrit :



NTFS est case-sensitive&nbsp;<img data-src=" />

Après, ce n’est pas géré par beaucoup d’applications (dont l’explorer Windows) et certaines API ne sont pas case-sensitive, mais ça c’est un autre problème.





Après, moi, je trouve que ce n’est pas forcément un mal que ce soit case insensitive dans l’explorateur.









FRANCKYIV a écrit :



Tu as un temps défini pour pouvoir éditer ton message, si tu dépasses ce temps, tu ne peux plus éditer.




  Rien avoir avec un bug ! <img data-src=">










 Si si c'est bien un bug. Je ne peux pas du tout valider mon message édité <img data-src=">