macOS High Sierra : Apple corrige l’énorme faille du compte root
Piratage > Nouvelle partie > Facile
Le 29 novembre 2017 à 19h15
4 min
Logiciel
Logiciel
Une très importante faille de sécurité existe actuellement dans macOS High Sierra. En passant par le panneau des réglages, il est possible d’obtenir les droits administrateurs sans avoir à entrer le moindre mot de passe. En attendant le correctif promis par Apple, on peut s'en protéger.
Pour une société évoquant régulièrement la sécurité de ses produits et en vantant les mérites sur son site officiel, on peut dire que la découverte fait tache. C’est Lemi Orhan Ergin, développeur chez Iyzico, qui a mis le doigt dessus : en passant par la section « Utilisateurs et groupes » du panneau des Préférences système, on peut court-circuiter la demande de mot de passe et obtenir les droits administrateurs.
Une manipulation très simple, y compris depuis l'écran d'accueil
La faille peut être exploitée de plusieurs manières. La plus simple – et on pourrait dire la plus dangereuse – passe par l'écran de connexion. Si un compte « Autre » est disponible, il suffira alors d'entrer « root » dans la case d'identifiant et de laisser le mot de passe vide. On valide puis on arrive sur un bureau : une session aux droits administrateurs permettant d'accéder aux autres comptes présents sur la machine.
Si « Autres » n'apparaît pas mais que vous arrivez sur une machine où une session est déjà ouverte, vous pourrez également acquérir ces droits. La démarche est on ne peut plus simple :
- Ouvrir les Préférences puis Utilisateurs et groupes
- Cliquer sur l’icône de cadenas en bas à gauche de la fenêtre
- Dans la fenêtre qui surgit, remplacer l’identifiant par root
- Répéter l’opération dans la nouvelle fenêtre apparue
Emballez, c’est pesé : High Sierra ne bronche pas devant une manipulation aussi grossière. On entend le son caractéristique du cadenas déverrouillé, le système vous faisant signe que les droits administrateur sont activés.
La technique permet donc de contourner complètement une demande ordinaire de mot de passe. macOS le réclame normalement pour toute opération un peu « sérieuse », comme la gestion des comptes, l’installation de certains logiciels, etc.
La situation est donc préoccupante, car n’importe quelle personne ayant accès au Mac peut obtenir ces droits et faire ce que bon lui semblera : accéder à des données masquées, installer un malware et ainsi de suite. La faille peut en outre être exploitée à distance via l’écran partagé.
Notez que des utilisateurs évoquaient déjà ces manipulations il y a plusieurs semaines dans les forums officiels d'Apple.
Une seule parade : imposer un mot de passe au compte root
Pour se protéger, il n’existe actuellement qu’une seule solution efficace. Retournez dans Utilisateurs et groupes, puis dans Options. Pour dégriser le panneau, il faudra cliquer sur le cadenas et saisir votre mot de passe (ou passer par l’astuce du root). Cliquez ensuite sur Rejoindre puis sur « Ouvrir Utilitaire d’annuaire ».
Dans ce dernier, il faudra à nouveau déverrouiller le cadenas. Ensuite, il suffira de se rendre dans le menu Edition et de cliquer sur « Modifier le mot de passe root ». Si le compte n’existe pas, il faudra le créer. Suite à quoi toute tentative d’utilisation de root réclamera le mot de passe que vous aurez choisi. Notez que désactiver le compte root ne supprime pas le problème.
Apple, de son côté, a pris connaissance du problème. La firme l’a donc reconnu et a indiqué qu’une solution était en préparation. Au vu de la dangerosité du problème et surtout son extrême facilité d’utilisation, on espère que le correctif sera déployé très rapidement. Sur notre machine, la manipulation a en effet fonctionné du premier coup avec trois comptes utilisateur différents. Le problème semble toutefois cantonné à High Sierra, soit la dernière révision de macOS.
On pourra regretter également que Lemi Orhan Ergin ait fait directement part de sa découverte sur Twitter sans en informer Apple discrètement dans un premier temps. La technique s’est de fait répandue comme une trainée de poudre, même si la parade l’a suivie très peu de temps après.
Le 29 novembre 2017 à 19h15
macOS High Sierra : Apple corrige l’énorme faille du compte root
-
Une manipulation très simple, y compris depuis l'écran d'accueil
-
Une seule parade : imposer un mot de passe au compte root
Commentaires (144)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 29/11/2017 à 09h05
#1
Quelques observations:
Ce qui m’étonne:
Le 29/11/2017 à 09h06
#2
definir le passwd root, première chose à faire lors d’une fresh install pourtant, UNIX rules " />
merci pour l’explication, je l’avais pas compris comme ça sur twitter (login en tant que root) " />
en espérant que le fix désactive pas le compte root …
Le 29/11/2017 à 09h10
#3
lol.
Quand on voit la politique d’Apple en matière de sécu, ce style de faille est hallucinant. ^^
Le 29/11/2017 à 09h16
#4
Quelqu’un est tombé dessus il y a 15 jours mais personne n’a remarqué : https://forums.developer.apple.com/thread/79235#277225
Je pense que le souci dans “C’est le genre de faille qui semble facile à trouver par hasard et sans grandes compétences techniques”, c’est justement la partie “sans grandes compétences techniques”. L’utilisateur lambda qui tombe dessus se dit “ah cool, il y a une solution de contournement au cas où j’oublie mon password” et ne mesure pas forcément les implications.
Le 29/11/2017 à 09h17
#5
Est-ce que cela veut dire que le compte “root” est sans mot de passe par défaut ?
Lorsque l’on démarre un MAC, pour la première fois, il ne demande pas de définir ce mot de passe comme c’est (c’était) le cas sur certains Windows ?
Le 29/11/2017 à 09h20
#6
Le 29/11/2017 à 09h23
#7
Le 29/11/2017 à 09h24
#8
Une faille aussi béante c’est moche. :o
Après il est quand même bon de se rappeler que l’UAC dans sa configuration par défaut est également bypassable, et ce depuis Windows 7…
https://github.com/hfiref0x/UACME
Testé sous Windows 10 et ça marche, par contre je testerais ça dans une VM. J’ai passé 1-2h à retrouver et effacer les traces laissées par certaines méthodes de bypass qui ont foiré et corrompu des composants de l’OS au passage.
Le 29/11/2017 à 09h28
#9
mais le root sans mdp, déja que ça soit faisable c’est pas top du tout…
ça va finir en bloquant le root et en forçant un système à la sudo façons Apple (va bien falloir payer du coup? Rhooo " />)
Le 29/11/2017 à 09h30
#10
Le 29/11/2017 à 09h33
#11
Il est quand même drôle que cette faille soit présentée comme une solution dans ce thread, d’autant plus qu’elle a été proposée par des développeurs qui se penchaient sur des problématiques d’identification de comptes. Elle n’a pas été découverte par des personnes “sans grandes compétences techniques” comme tu l’évoques.
Au final, c’est peut-être ça qui fait le plus peur: des “experts” ou “pros” qui voient les problèmes juste devant eux, les étudient, mais qui s’avèrent incapables de reconnaître que c’en est un.
" />
Le 29/11/2017 à 09h43
#12
Le 29/11/2017 à 09h45
#13
Mais, les accolades, c’est pas obligatoires?
Je veux dire, je suis système/réseaux, mais pendant mon BTS, j’ai fait un peu de C#, il fallait mettre des accolades.
Peut-être qu’il faut en mettre plus souvent que ne le demande le code?
Le 29/11/2017 à 09h45
#14
oops " />
Le 29/11/2017 à 09h50
#15
Le 29/11/2017 à 09h52
#16
c’est souvent les bugs les plus évidents qui ne sont pas testés.
en général tu penses tellement à chercher la petite bête que tu vois pas la grosse juste à côté.
Le 29/11/2017 à 09h53
#17
Le 29/11/2017 à 09h53
#18
Quand tu n’as qu’une seule instruction après ta condition, les accolades ne sont pas obligatoires.
if (toto > 0)
toto–;
donnera le même résultat que
if (toto >0){
toto–;
}
En revanche, si tu as plus d’une instruction et que tu ne mets pas d’accolades, seule ta première instruction sera prise en compte dans la condition.
Le 29/11/2017 à 10h02
#19
D’expérience, la ligne unique peut aussi générer des bugs " />
Le 29/11/2017 à 10h03
#20
Le 29/11/2017 à 10h05
#21
Le 29/11/2017 à 10h06
#22
les antibiotiques… " />
Le 29/11/2017 à 10h08
#23
Le 29/11/2017 à 10h16
#24
Le 29/11/2017 à 10h27
#25
Le 29/11/2017 à 10h37
#26
Disons qu’un programme est structuré en BLOCs d’instructions.
Un bloc, c’est soit une instruction, soit plusieurs instructions regroupées dans des accolades.
Après un if, le compilo attend un bloc. Si il trouve qu’une instruction sans accolades, c’est son bloc.
Regarde par exemple :
if (true) ;
{ trollerSurNI(); }
Ici, la fonction trollerSurNI() ne sera jamais appelée, parce que mon instruction est vide, c’est le ‘;’
PS : histoire vraie, c’était plutôt dur à trouver comme erreur " />
Le 29/11/2017 à 10h40
#27
Tu fais erreur : en l’état ta fonction sera toujours appelée, puisqu’il n’est soumis à aucune condition à cause du point-virgule.
Le 29/11/2017 à 10h41
#28
Le 29/11/2017 à 10h46
#29
oh oui !! " /> my bad
Le 29/11/2017 à 10h53
#30
Le 29/11/2017 à 10h59
#31
Le 29/11/2017 à 10h59
#32
Sous high Sierra après la mise à jour, quand j’ouvrais mon laptop, je voyais mon mot de passe (en petits points) qui se tapait et se loguait automatiquement. Ça s’est arrêté tout seul…
Ça plus le problème des mot de passe en clair ( https://www.macg.co/os-x/2017/10/high-sierra-explications-sur-le-bug-de-mot-de-p… )
Ça fait beaucoup !
Le 29/11/2017 à 11h07
#33
MacOS est plus secure que Windows ou Linux, pas de problème… " />
Cela dit avec la ligne de commande on peut mettre plus simplement un mot de passe au compte root.
Le 29/11/2017 à 11h19
#34
Au passage, je n’ai pas souvenir que le C++ autorise les blocs sans accolades pour les boucles, mais ça fait un bail que je n’en ai pas fait.
Le 29/11/2017 à 11h42
#35
Donc pour résumer, si le compte root n’a pas de mot de passe, n’importe qui peut se connecter en tant que root sans saisir de mot de passe. Sans dec’ ? " />
Le 29/11/2017 à 11h51
#36
Il n’y a effectivement aucun mot de passe root par défaut.
Le 29/11/2017 à 12h02
#37
Et à distance " />
Le 29/11/2017 à 12h06
#38
Le 29/11/2017 à 12h14
#39
Joli " />
Le 29/11/2017 à 12h18
#40
J’attends toujours une actu sur la faille wpa2, l’ai je manquée ?
Le 29/11/2017 à 12h19
#41
Le 29/11/2017 à 12h23
#42
Je n’hésiterai pas à ressortir cette faille à ceux qui me pompent le chou à dire que chez Apple il n’y a jamais de failles, jamais de malware, rien de rien.
Après, je ne leur jette pas la pierre, Apple et son système de marketo-endoctrinement… Et je suis très étonné qu’ils aient admis la faille, en général même les plus grosses failles font juste l’objet d’une ligne dans un log…
Pardon, je digresse :-)
Le 29/11/2017 à 12h25
#43
Je pense que je dois avoir mal compris quelque chose, parce que si la faille, c’est qu’on peut se logger sans mot de passe avec un compte sans mot de passe, c’est pas franchement une grosse découverte " />
Le 29/11/2017 à 12h27
#44
Pour les flemmards fenêtrophobes adeptes du clavier, la résolution de la faille peut se faire dans le Terminal :
> sudo passwd root
Le 29/11/2017 à 12h28
#45
Le 29/11/2017 à 12h29
#46
C’est pas n’importe quel compte, c’est root. Celui qui a accès à tout et a tous les droits par défaut.
Le 29/11/2017 à 12h33
#47
Le 29/11/2017 à 12h37
#48
Le 29/11/2017 à 12h38
#49
Le 29/11/2017 à 12h39
#50
Oui ok, mais quand tu installes un Linux, on va te demander ton mot de passe root, puis te demander de créer un utilisateur + mot de passe. Si tu met un mot de passe vide (quand la distribution l’accepte), bah c’est pour ta pomme, et tant pis.
Là quand tu installes un mac (enfin, quand tu démarres pour la première fois un mac, la plupart du temps), on te demandes juste de configurer ton utilisateur + mot de passe, c’est tout, jamais on te demande de mettre un mot de passe à root (les utilisateurs lambda te demanderont même de quelle “route” on leur parle ?), et la procédure graphique pour en mettre un est plus que complexe pour le lambda (les rares qui auront compris le problème).
Bref, c’est un réel bug là. La non désactivation de root, avec un mot de passe vide.
Le 29/11/2017 à 12h45
#51
Le 29/11/2017 à 12h52
#52
Repetez apres moi : Apple n’a jamais de faille, Apple n’a jamais de faille, Apple n’a jamais de faille…
Sinon la police de la bienpensance ou des fans boys en furie pourraient bien débarquer chez vous pour tout saccager!
Le 29/11/2017 à 12h53
#53
mec stp, ça serait quand même cool que tu participes quand t’as des connaissances sur le suejet, parce que là tu dis vraiment n’importe quoi.
Et root n’est pas propore à MacOS mais c’est sur du Unix en général. Et c’est une grave faille, c’est pas trop risible.
Et pour info, ta réponse prouve que t’as toujours rien compris à ce que représente l’utilisateur root sur ce genre d’OS. tu devrais aller lire un peu ;)
Le 29/11/2017 à 12h58
#54
Bah, sur les anciens macos, le bug n’y est pas, et même si techniquement le root n’a pas de mot de passe, il est aussi désactivé, et donc la procédure détaillée dans l’article ne donne rien d’autre qu’un refus pur et dur. Il a vraiment été introduit dans high sierra, sans aucun réel ajout nul part pour l’utilisateur.
Le truc marrant sur high sierra, c’est que si dans la fenêtre d’authentification, tu met “root” et un mot de passe vide, tu vas être authentifié en root si tu appuies sur la touche entrée, mais l’authentification va être refusée si tu cliques sur le bouton “Authentifier” avec la souris :)
Le 29/11/2017 à 13h05
#55
Sous Mac OS, comme sous Ubuntu me semble-t-il, le compte root est désactivé par défaut. Il n’y a normalement pas de moyen de se loguer en root en dehors de cette faille, donc pas de nécessité de mot de passe. On donne les droits d’administrateur à l’utilisateur par défaut et il faut utiliser la commande sudo pour utiliser les fonctionnalités réservé au root (en dehors de la ligne de commande, si une application a besoin de privilèges plus hauts que celle de l’utilisateur en cours, un prompt de saisie de mot de passe apparaît, comme avec l’UAC de Windows).
Le 29/11/2017 à 13h06
#56
Le 29/11/2017 à 13h08
#57
Non, pas d’exemple à montrer, car quelques employeurs en arrière.
Cela étant, c’était effectivement la création d’un if(condition); ce que effectivement gcc signale maintenant.
Le 29/11/2017 à 13h14
#58
Le 29/11/2017 à 13h16
#59
Ha ben je dois trainer depuis trop d’années sur ArchLinux alors… Je ne savais même pas que les autres distros désactivaient le compte root par défaut " />
Le 29/11/2017 à 13h18
#60
Répète après moi: j’ai utilisé le mot pomme tout à fait par hasard " />
Le 29/11/2017 à 13h19
#61
Testé au bureau fonctionne parfaitement, cependant j’ai plusieurs machine avec le bouton “Autre” ou “Other” manquant sur l’écran de login comment on fait pour l’afficher sans activer le compte guest ? es que en démarrant en mode avec une combinaison de touche on a accès à ce menu ?
Le 29/11/2017 à 13h26
#62
Désactiver le compte root via le terminal fonctionne apparement. Et c’est plus sur que de le laisser activé :
“dsenableroot -d -u root”
Le 29/11/2017 à 13h29
#63
ouuuuuuuuuuupppss " />
Le 29/11/2017 à 13h34
#64
Le 29/11/2017 à 13h58
#65
Bah j’en installe régulièrement pour tester (sous qemu, avec les nouveautés d’accélération gpu de vfio, c’est top), mais j’ai jamais été vérifier si le compte root était désactivé… Du coup j’en profiterai pour regarder une prochaine fois.
Le 29/11/2017 à 14h12
#66
C’est la nostalgie du login des Windows 9x que si tu avais oulier le mot de passe tu appuyait sur echap pour logguer le dernier user (ou user par défaut je sais plus, mais ça marchait bien au bahut à l’époque " />)
Le 29/11/2017 à 14h24
#67
Whaou !
J’ai dû m’y reprendre à 2 fois (enfin, 4x " />) pour bypasser l’élévation de droits sur ma VM HighSierra avec le root. " />
Pendant un moment, je me suis dis : C’est pas possible, y’a que chez moi que ça foire… " />
Mais non, tout va bien, c’est pareil ! " />
Le 29/11/2017 à 14h45
#68
Le 29/11/2017 à 14h51
#69
Pour bien comprendre la programmation, dans sa partie fondamentale, il faudrait avoir des notions d’assembleur et de compilation pour comprendre tout ce qu’implique la gestion de la mémoire (la pile et le tas), un appel de fonction (la mise sur la pile des paramètres)… Ca permet ainsi de comprendre par exemple les notion de portée de variables que l’on retrouve dans bon nombre de langage mais aussi, ce qu’implique la création d’un bloc d’instruction a niveau de la mémoire (la pile dans ce cas). Après, tous les langage ne gèrent pas la mémoire de la même manière et les langages de haut niveau, comme python ou R, vont être très différents (a priori pour ces 2 là, les variables sont gérées dans des sortes de dictionnaires incluant la notion de portée)
Il faut aussi de notion de “grammaire”. C’est en quelque sorte la formalisation de toutes les structures d’un langage. Par exemple ça va dire comment on écrit un valeur numérique
Le 29/11/2017 à 14h53
#70
Le 29/11/2017 à 14h56
#71
Oui, j’ai vu, le temps que je commente, il y a eu plein d’échanges.
Ah les news Apple, ça fait causer !
Le 29/11/2017 à 14h58
#72
" />
euh, non en fait je cherchais :
" />
Le 29/11/2017 à 14h59
#73
Le 29/11/2017 à 15h00
#74
Pitoyable.
Le 29/11/2017 à 15h09
#75
Le 29/11/2017 à 15h30
#76
Le 29/11/2017 à 15h42
#77
Le 29/11/2017 à 15h50
#78
Le 29/11/2017 à 15h54
#79
Le 29/11/2017 à 16h09
#80
“et qui te configure ton shell comme si tu étais avec le user root” –> non, tu ES root
Le 29/11/2017 à 16h21
#81
Tu fais partie du groupe Root mais tu n’est pas logué avec le user root qui est désactivé :
https://doc.ubuntu-fr.org/root
Le 29/11/2017 à 16h26
#82
Le 29/11/2017 à 16h41
#83
Le 29/11/2017 à 16h44
#84
Le 29/11/2017 à 17h06
#85
Bug/Faille corrigée :http://www.macg.co/os-x/2017/11/apple-corrige-le-bug-dacces-root-et-sexcuse-1005…
Le 29/11/2017 à 17h24
#86
Le 29/11/2017 à 17h32
#87
Le 29/11/2017 à 17h45
#88
Le 29/11/2017 à 17h50
#89
Le 29/11/2017 à 18h20
#90
Le 29/11/2017 à 18h32
#91
Le 29/11/2017 à 18h46
#92
Le 29/11/2017 à 18h59
#93
Mise à jour dispo.
Le 29/11/2017 à 19h32
#94
Cette faille à déjà un statut culte.
Le 29/11/2017 à 23h24
#95
« Nous regrettons profondément cette erreur et présentons nos excuses aux utilisateurs de Mac, pour la sortie d’une version boguée et pour les soucis causés. Nos clients méritent mieux. Nous procédons à un audit de nos processus de développement pour empêcher une telle erreur de se reproduire ».
C’est beau " />
Ça m’a presque tiré une larme.
Ils sont nominés aux Oscars ou pas ?
Le 30/11/2017 à 08h22
#96
Le 30/11/2017 à 08h39
#97
Vu qu’OSX est devenu un concentré de bugs, qui s’accumulent de version en version, ce serait bien qu’ils notent ça en gras sur tous les murs de l’Apple Park…
Le 30/11/2017 à 08h57
#98
Dur d’augmenter la qualité. Par contre pour les prix c’est plus facile
Le 30/11/2017 à 09h35
#99
Pour info le patch rajoute d’autres bugs " />http://news.softpedia.com/news/apple-s-emergency-macos-root-security-patch-break…
Le 30/11/2017 à 10h02
#100
Cent déconner. " />
Le 30/11/2017 à 10h54
#101
Le 30/11/2017 à 11h22
#102
Le 30/11/2017 à 11h24
#103
Développer des logiciels, c’est un métier. Il ne faut jamais confondre vitesse et précipitation.
Manifestement, ils ont raté les effets de bord de leur patch.
J’étais surpris que leur patch sorte si vite.
Le 30/11/2017 à 13h58
#104
C’est plus subtil que ça, puisque tu peux avoir des droits administrateurs avec un simple compte qui théoriquement n’en a pas le privilège. Un peu comme si tu donnais au cambrioleur les clés de ta maison en plus de ton adresse.
Le 30/11/2017 à 14h07
#105
ouf, en tant que développeur j’utilise assez souvent le compte root, et l’ai par conséquent verrouillé dès le début, ce qui est la règle. Je pense d’ailleurs que c’est la raison pour laquelle personne ne s’en était aperçu : à moins d’être développeur, qui irait chercher une telle manip ? Notons qu’une faille similaire était sur windows il y a quelques années, il suffisait d’appuyer escape une dizaine de fois lors du logging.
Le 30/11/2017 à 15h26
#106
Le 30/11/2017 à 15h46
#107
Le 30/11/2017 à 16h09
#108
Le 30/11/2017 à 18h41
#109
Le 30/11/2017 à 18h42
#110
L’utilisateur sans grande compétence technique va essayer admin, pas root.
Le 30/11/2017 à 18h52
#111
Le 30/11/2017 à 19h11
#112
Le 30/11/2017 à 19h17
#113
Le 30/11/2017 à 19h24
#114
Tu peux avoir un code de qualité ou de merde avec n’importe quel langage.
Et je ne vois même pas l’intérêt de dire qu’avec tel ou tel langage on peut faire du code de qualité et du coup dénigrer les autres.
Le 30/11/2017 à 19h26
#115
Je sais, j’ai eu à gérer ce genre de situation dans un autre domaine logiciel.
Mais jamais on n’a lâché un logiciel en 24h quand il s’agissait de modifier un truc un peu complexe, ne serait-ce que parce qu’il faut faire des tests de non régression.
Et même si je ne connais pas la cause de leur bug, quand je vois à quoi correspond le truc à lancer à la main pour corriger l’effet de la correction, je me dis qu’ils ont été un peu optimistes sur l’absence de régression.
Ils disent qu’ils vont revoir leurs procédures, mais j’ai le sentiment qu’ils se sont assis dessus sur ce coup.
Je suis d’accord avec toi que la faille était très grosse et la divulgation les a mis dans la merde, mais était-on à 24 heures près ? il fallait quand même un accès local à la machine, le cas de l’écran partagé étant assez anecdotique.
Enfin, tu parles “du programmeur”, mais justement, dans ces cas là, il ne faut pas laisser un développeur seul corriger le problème. Il faut qu’il explique la root cause, comment il a corrigé et ensuite se demander quels sont les effets de bords possibles et ce qu’il faut tester pour éviter les régressions, pour ce dernier point, le développeur ne doit pas être seul.
Le 30/11/2017 à 19h35
#116
Le 30/11/2017 à 19h36
#117
Le 30/11/2017 à 19h50
#118
Le 30/11/2017 à 20h05
#119
Le 30/11/2017 à 20h32
#120
Le 30/11/2017 à 21h28
#121
va réviser le C, et en particulier l’usage de la virgule.
Le 30/11/2017 à 21h38
#122
Le 30/11/2017 à 21h44
#123
on peut définir un passwd pour verrouiller le boot (je sais plus comment, mais il m’a demandé mon passwd lors de l’instal " /> )
Le 30/11/2017 à 23h26
#124
Le 30/11/2017 à 23h29
#125
Le 30/11/2017 à 23h33
#126
Le 01/12/2017 à 07h38
#127
Le 01/12/2017 à 08h22
#128
‘tain les mecs que se prennent la tête sur quel est le langage le plus sur alors que tout le monde sait que c’est le basic. " />
Le 01/12/2017 à 12h09
#129
Le 01/12/2017 à 12h58
#130
T’es stupide ou quoi ? Je te dis que je sais ce que c’est. " />
J’ai commencé le C à la fin des années 80…
Et ça ne change rien à ce que je disais sur le monoligne pour une instruction conditionnelle.
Le 01/12/2017 à 13h06
#131
Cette fois-ci, tu as commencé le C à la fin des années 80, et quelques posts plus haut, tu écris que c’était il y a 25 ans. 2017-25=1992. 1992, ce n’est pas exactement la fin des années 80.
Est-ce que tu comprends ce que tu lis ? Est-ce que tu comprends ce que tu écris ? Sais-tu encore ce que tu fais, ou es-tu déjà atteint par Alzheimer ?
Et puis ton concours de bite, hein, ça devrait t’être passé à ton âge.
Le 01/12/2017 à 13h43
#132
Le 01/12/2017 à 13h55
#133
Le 01/12/2017 à 14h02
#134
Le 01/12/2017 à 14h04
#135
Le 01/12/2017 à 14h22
#136
Le 01/12/2017 à 14h48
#137
Le 01/12/2017 à 15h49
#138
Le 01/12/2017 à 17h22
#139
Le 01/12/2017 à 17h27
#140
Le 01/12/2017 à 18h07
#141
Le 02/12/2017 à 16h26
#142
Le 02/12/2017 à 20h41
#143
Le 04/12/2017 à 14h04
#144