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

55

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

Par Sébastien Gavois

Le 19 décembre 2014 à 10h03
Internet
3 min

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)


CryoGen
Le 19/12/2014 à 10h10

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=" />


Winderly Abonné
Le 19/12/2014 à 10h14



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 ?



seb2411
Le 19/12/2014 à 10h15







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.



Winderly Abonné
Le 19/12/2014 à 10h18

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


CryoGen
Le 19/12/2014 à 10h19







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:



Homedread Abonné
Le 19/12/2014 à 10h22

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é ?


CryoGen
Le 19/12/2014 à 10h33



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.


moi1392
Le 19/12/2014 à 10h35

il a refilé le projet à Junio C Hamano.


millman42 Abonné
Le 19/12/2014 à 10h35

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


Homedread Abonné
Le 19/12/2014 à 10h36

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.


levhieu
Le 19/12/2014 à 10h51

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»


Homedread Abonné
Le 19/12/2014 à 10h54

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


CryoGen
Le 19/12/2014 à 10h57

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


sanscrit
Le 19/12/2014 à 11h02

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


nikon56
Le 19/12/2014 à 11h32

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


Lordtoniok
Le 19/12/2014 à 11h33

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


Ricard
Le 19/12/2014 à 11h53



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=" />


Yolélé
Le 19/12/2014 à 11h54

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”


Ricard
Le 19/12/2014 à 11h55







Homedread a écrit :



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



Fixed <img data-src=" />



roger21
Le 19/12/2014 à 11h58

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…


Ricard
Le 19/12/2014 à 11h59







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…



CryoGen
Le 19/12/2014 à 12h09

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


CryoGen
Le 19/12/2014 à 12h11

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



:)


alain57
Le 19/12/2014 à 12h12

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


psn00ps
Le 19/12/2014 à 12h17

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


Ricard
Le 19/12/2014 à 12h26







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=" />



Ricard
Le 19/12/2014 à 12h27

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


A-D
Le 19/12/2014 à 12h36

&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


yl
Le 19/12/2014 à 12h37







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=" />



FRANCKYIV
Le 19/12/2014 à 12h41

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


Yolélé
Le 19/12/2014 à 12h58

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.



CryoGen
Le 19/12/2014 à 13h06

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



jeanfig
Le 19/12/2014 à 13h17

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=" />


yl
Le 19/12/2014 à 13h31







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é.



sanscrit
Le 19/12/2014 à 13h56

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.


Patch Abonné
Le 19/12/2014 à 14h26







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…



psn00ps
Le 19/12/2014 à 14h36

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


OlivierJ Abonné
Le 19/12/2014 à 15h50







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.


OlivierJ Abonné
Le 19/12/2014 à 16h26







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;



OlivierJ Abonné
Le 19/12/2014 à 16h29







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.



yl
Le 19/12/2014 à 16h53







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!



yl
Le 19/12/2014 à 16h57







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).



FRANCKYIV
Le 19/12/2014 à 19h34







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=" />



Baldurien Abonné
Le 19/12/2014 à 21h51







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.



jrbleboss
Le 20/12/2014 à 12h06







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.



Baldurien Abonné
Le 20/12/2014 à 16h01







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 ! :langue:











 Si si c'est bien un bug. Je ne peux pas du tout valider mon message édité :non:


c’est dimanche


Fermer