groumly a écrit 3282 commentaires

Ça fait une paye que j’ai pas utilisé Firefox pour être honnête, mais si je devait m’y essayer.

Le TL;DR c’est qu’ils risquaient pas de s’en sortir en n’ayant pas de browser pour LA plateform qui a explosé en 2008, a savoir le monde mobile.

• chrome a mit une tannée niveau performance a tout le monde lors de sa sortie, et a amorcé la perte de terrain (safari s’en sortait bien cela dit, mais vu sa présence anecdotique sous Windows et le peu de Mac à l’époque, ça changeait pas grand chose)
• Firefox a complètement raté le virage mobile. Ils ont rien sorti pour android avant 2011, et rien d’utilisable avant 2013/2014 si je me souvient bien. Sur iOS, c’est encore pire, on a rien eu avant 2015 (et non, je considère pas Firefox home comme quelque chose). Pendant ce temps, apple et google ont occupé le marché. On est passé de « perte de terrain » à « hémorragie totale, par absence de produit pure et simple »
• ils ont foutu en l’air leur principal différentiateur sur desktop, à savoir les extensions, ce qui a empiré une situation déjà catastrophique
• s’en est suivi quelques années de « he, regardez, on fait comme chrome, mais 6 mois après eux »

Donc je dirais une combinaison de dette technique qui les a mit derrière sur desktop et les a empêché de sortir sur mobile (le code remonte à Netscape quand même) et des choix stratégiques désastreux (Apple et Google ont sorti leurs features de synchro multi machines bien avant que Mozilla n’ait réussi à sortir un truc qui marchait). Leur absence totale du marché mobile à envoyé leurs utilisateur vers un autre browser, parce que les bookmark/historique/keychain etc synchronise, c’est plus important que de savoir s’ils utilisent gecko ou WebKit.
Et par dessus le tout, une vision très années 2000 d’un browser, à savoir un software standalone qui ne repose pas sur des services en ligne pour s’enrichir.

Et venez pas me dire que c’est la faute à Apple qui empêche d’avoir un autre browser nianiania, chrome arrive à tenir 6 à 10% de ce marché.

On peut peut être aussi se demander pourquoi Firefox a perdu la majorité de ses utilisateurs, et admettre que sorti de safari (limité à une seule meta plateforme), et chrome, y’a pas grand chose à se mettre sous la dent.

Parce que sensibiliser, c’est bien, mais si à la question « ok mais j’utilise quoi alors? » qui va inévitablement suivre, ta réponse c’est « un browser qui a perdu tout son attrait face à la concurrence, ou un browser qui n’est pas disponible pour ton matos », tu vas pas avoir beaucoup de succès.

Un mvn dependency:tree | grep log4j répondra à cette question facilement.

Si t’utilise tomcat, je suppute que tu a un war, qui inclue tous les jar de ton appli.
Une autre pratique courante est d’utiliser un serveur d’appli embedded, et de shader le jar, à savoir exploser toutes les dépendances et les mettre dans un seul gros jar.
L’avantage étant que tu te fades pas tomcat (ou autre), et surtout, tu lances l’appli avec un simple java -jar monjar.jar, ce qui rend les deploiements vachement plus simple (parce que dire à tomcat d’arrêter cette web app et la relancer, c’est vachement plus compliqué qu’un kill + java -jar monjar.jar).

Bref, le problème c’est que je vois pas comment ta commande peut marcher dans ce mode.

Ah, et sinon, même si ça marchait, y’a des chances pour que des bindings log4j soit embarqués par une dépendance transitive si t’utilise slf4j. Ce qui compte c’est de ne pas avoir log4j-core si je me rappelle bien.

Oui, sauf que c’est pas dans une usine, c’est pas un ordinausore, et des mises à jours étaient disponibles.

Bref, comme je disais, on a toujours de bonnes excuses.

Ben écoutes, je suis sur que t’as un paquet de bonnes raisons de faire tourner une machine en production sur un os pas supporté, ni d’appliquer les 4 mises à jour fournies par l’éditeur. Surtout pour un truc comme la compta, après tout, ça gère juste les sous, et est couvert par des obligations légales.

Je suis à peu près sûr que tout le monde a fait ça un jour.
Juste, vient pas faire le guignol derrière à dire que MS c’est de la merde quand tu fais de la merde toi aussi.

Ils ne sont accessible que depuis un réseau local et absolument pas prévu pour être en live sur le net.

Ah oui, parce que log4j nous a prouvé qu’il faut un accès direct à la machine pour exploiter une faille. Et jamais on a vu une machine interne se faire compromettre pour rebondir sur le réseau local.
C’est pas comme si Manutan s’était retrouvé hors ligne pendant 10 jours parce qu’ils faisaient tourner des machines hors support qui se sont faite plombées via le réseau interne. Et c’est pas comme si le nourjal en parlait.

Il fait tourner une 5.7 sortie y’a 11 ans, qui n’était pas couverte par le ELS qui a commencé en 2017 avec la 5.11, et s’est terminé y’a plus d’un an.
La 5.8 est sortie y’a 9 ans.
RHEL 5 est sorti en 2007, avec un kernel 2.6.18, donc presque 15 ans.

Soit ses mois sont vraiment très longs, soit il ne voit pas la poutre dans son œil (ce qui n’est pas étonnant vu la teneur de ses posts ici).

Je suis pas sur que se vanter de n’avoir pas fait un mise à jour en plus de 10 ans aille dans le sens que tu pense.
Ni de fanfaronner un os vieux de 15 ans qui n’est plus supporté.
‘Fin je dit ca, je dit rien.

Les autres failles de shellshock ont été trouvées par fuzzing si je me rappelle bien.

En règle générale, la majorité des failles sont trouvées comme ça. C’est bien plus simple de laisser une machine explorer les possibilités que de se fader des milliers de lignes de c abscons à la recherche des 3 lignes ou le mec à oublié de vérifier la taille du tableau avant d’assigner.
Le code peut ensuite aider à déterminer comment exploiter la faille, mais ça va pas trop dans ton sens.

On ne peut pas défendre les gens contre eux-mêmes.

Si proche, et en même temps si loin.

Creuses encore un peu, et tu comprendras peut être que cette phrase d’applique surtout à toi dans ce fil.

Oui, c’est fin une façon de voir les choses.
Ton attaque ne marche que si:

• le site ne propose pas d’https (oh ben tiens)
• le site n’est pas sur les listes hsts preload
• le site ne fait pas de hsts ET n’a jamais été visité

Note que quand on dit « offrir https », ça inclue faire du hsts, parce qu’au final, c’est juste un header à inclure, pas le bout du monde.

Ce qui réduit la surface d’attaque à peau de chagrin.
Un moteur de recherche ne va pas te donner un lien http si le https est dispo, donc il faut soit envoyer un lien http explicite à la victime et réussir à lui faire cliquer dessus, soit réussir à lui faire taper l’adresse en commençant par http://

Ce qui revient exactement à ce qu’on dit: offrir seulement du http est une très mauvaise pratique, même si ton site est trivial et utilisé par quasiment personne.

Heu, ouais, mais attends, ça marche comment ton truc, là?

Le get sur https ne va pas passer le handshake tls, pourquoi est ce que le browser repasserait en http du coup?

puis fait un redirect sur https://m0m-blog.fr Je résume: j'ai un cadena mais le pirate peut lire tout le contenu de ma lecture voir remplacer mes images.

Le dns ne peut pas faire un redirect http. Il peut mentir sur l’ip, mais le browser pensera toujours parler à Mon-blog.fr, et ton certificat pour m0n-blog ne sera pas valide pour ce domaine. Tu vas te taper la page qui fait peur « le certificat n’est pas valide, vous êtes à risque bla-bla-bla ».

Pour l’idor, c’est l’idée générale, mais c’est soit lourd, soit pas forcément trivial à implémenter.
Tu peux le faire dans le front end, mais c’est lourd et c’est facile de rater quelques endroits.
Tu peux le faire dans le backend, mais la propagation d’identité et d’autorisations dans une monde soa c’est pas trivial, surtout quand t’as des cas d’utilisations qui sont pas initiés par l’utilisateur (genre un e-mail déclenché par un événement sur un bus).
Pour repartir sur le fourchette, si t’invite des potes à ta réservation, maintenant eux aussi y ont accès. Sauf que c’est potentiellement un autre service qui gère les invit’. Maintenant ton service réservation doit comprendre ce genre de chose pour pourvoir te donner accès aux données.

Pour les PII, je suis pas sur de comprendre la question. Le problème c’est pas tant les id, qu’exposer trop de PII au monde.
Si je commande un Uber et que l’api d’uber me retourne le nom de famille et numéro de téléphone perso du chauffeur, c’est une PII leak, même si l’appli ne les montre pas.
Et ça peut arriver relativement facilement en fonction de comment ton backend marche, la vitesse à laquelle ça a été développé et l’attention portée aux problématiques de vie privée. L’ID du chauffeur peut être un uuid, ça aide pas si les dev ne font pas gaffe à ce qu’ils font.

Insecure direct object reference. En gros quand l’appli vérifies que t’es authentifié, mais pas que t’es authorisé à accéder aux données que tu demandes. En gros, t’es connecté sur Amazon sous le compte A, et crée une requête pour accéder aux détails de la commande 1234, qui appartient au compte B. C’est assez courant comme problème, surtout dans des systemes SOA, ou la propagation de l’identité/authorization est pas si simple.

persistent xss: une faille xss, mais persistee côté serveur. Typiquement, si je poste un message sur linuxfr avec des balises html/JavaScript, et que le backend ne sanitize pas le message. Toutes les personnes lisant le message exécuteront le code js, sans que j’ai besoin de leur faire cliquer sur un lien. De la, je peux me débrouiller pour leur faire poster leur cookie de session, et me faire passer pour eux.

PII leak: personally identifiable information. Fuite de données personnelles, genre nom/prénom, numéro de téléphone. Ça va pas mal dépendre du service, mais typiquement, sur un site genre la fourchette, tu peux faire des réservations sans être connecté. Ils t’envoient derrière un e-mail avec un lien « magique » pour gérer la réservation. Souvent, ces liens sont facile à casser, et pour peu que l’ID de la réservation soit une séquence/facile à deviner, tu peux scanner le site et aspirer des données persos.

Oui, alors là pour le coup, vu le niveau de la sécurité dans l’internet grand public, y’a moyen de bien s’arrondir les fins de mois.
Je doute que ça soit facile pour n’importe qui, mais pour quelqu’un qui bosse, ou veut bosser, dans la sécu, avec des concepts de base, c’est pas bien compliqué de se faire 1000 à 2000 dol’ par mois en plus. Et ça donne de l’entraînement dans le domaine, de qui aide donc à enrichir son cv et ses compétences.
C’est en tout cas ce que je vois dans notre programme hackerone, IDOR par ci, persisted xss par la, PII leak la bas. Et le pire, c’est les mêmes problèmes qui reviennent tout le temps.

Je serais très, très, très surpris qu’on soit les seuls. Boites d’internet grand public qui sont là depuis le début des années 2000 (tech debt, produits legacy et autres features obscures que tout le monde a oublié), à priori service gratuit qui demande un gros volume pour être rentable et qui met à jour très souvent.
Filtre par salaire moyen pour un ingé front end un peu plus bas, combines ca avec une recherche sur LinkedIn qui bosse la bas. J’imagine qu’une recherche github doit aider à identifier les clampins et autres pallaissons qui disent jamais non un peu mieux.
Bonus si t’arrives a trouver des talks/blogs publiques qui montrent qu’ils sont un chtouille derrière la courbe de veille technique, mais pas trop. Ça veut dire qu’ils essayent de se tenir à jour, mais savent pas vraiment comment faire, et donc ils vont avoir des trous dans leurs implémentations.

Ça te donne une bonne idée de quelles boites ont des bras cassés qui comprennent pas vraiment ce qu’ils font. Une fois que t’as ta liste de suspects, tu passes un jour ou deux sur chaque site. Commence par le login, registration, le genre de trucs qui a des PII et qui sont des points de frictions dans le produit: les product managers détestent ça, et ont tendance à vouloir bâcler les choses la desssus. Une fois que tu trouves un fil, tu tires dessus jusqu’à ce que ça paye.

En optimisant un peu pour les sous, ca doit même pouvoir se tourner en boulot à plein temps. Payé pas forcément beaucoup, mais avec plein de temps libre, et pas de patron sur le dos.

Ah oui, ça a été corrigé. Ca été tellement corrigé qu’ils ont du corrigé la correction:

I appreciate the effort made in patch bash43-026, but this patch doesn't even BEGIN to solve the underlying shellshock problem. This patch just continues the "whack-a-mole" job of fixing parsing errors that began with the first patch. Bash's parser is certain have many many many other vulnerabilities; it was never designed to be security-relevant…

Sinon:

Toutes les distributions actives ont proposé le binaire corrigé en moins de quarante-huit heures. La transparence n'a pas fait défaut mais visiblement tu as préféré fermer les yeux et faire comme si c'était comparable à du Wana Cry…

La question c’est pas la transparence ou pas.

L’assertion initiale était, je le rappelle, « vu que le code est dispo, il est audite par tout le monde sur internet, donc c’est plus sûr » (aka « with enough eyes, all bugs are shallow »).
Ce que je dit c’est que cette méthodologie est une connerie monstrueuse, et shellshock en est la preuve. Ça fait pas de mal d’avoir le code dispo, mais de la à en conclure que c’est audite parce que le code est dispo, c’est du grand n’importe quoi.

On a un bug qui a existé pendant 25 ans, dans un outil fondamental et critique. C’est pas une question d’avoir assez d’yeux à ce niveau. La question c’est surtout d’avoir les bons yeux dessus: a savoir des gens qui savent ce qu’ils font et comment auditer, et surtout, les payer pour qu’ils fassent ça. Une fois qu’ils sont payés, leur donner le source me parait pas être un problème insurmontable.

D’autre part, ce bug a été affreusement géré. Il était là depuis 25 ans, disclosé de façon responsable. Il s’est écoulé 12 jours entre la notification et la release. Une fois disclosé, la communauté (celle qui sait ce qu’elle fait) a trouvé 4 autres problèmes en 24 heures. Ce qui renforce le point précédent, et jette de l’ombre sur le « les mises à jours de sécu sont mieux gérées ». Et aussi me fait questionner la compétence sécurité du projet.
Dit autrement, ils pouvaient pas prendre quelques jours de plus pour s’assurer qu’il n’y avait pas autre chose? Visiblement y’avait beaucoup de doutes sur la qualité du patch de la part de la communauté sécurité.

Savoir que les distros ont distribué le patch en 2 jours, qu’est ce qu’on s’en cogne. C’est arrivé en 2014, recompiler un soft et le distribuer en 2 jours, c’est meme pas la base de la base, surtout quand c’est pas eux qui ont écrit le patch.

D’une part, comme dit au dessus, le salaire représente beaucoup la difficulté à embaucher.

D’autre part, un salaire median sur un pays à l’échelle des us est pas super pertinent, surtout avec un titre aussi vague. Tu peux facilement avoir plus de 50% d’écarts entre SF et des villes, disons, moins attrayantes, et encore plus si un gros employeur se met à décider d’embaucher tout ce qui bouge. Et j’imagine que ça inclue pas le stock/bonus courants dans les boites high tech, et qui rajoute bien encore 20-50% du salaire.

Y’a des chances pour que les “Windows administrator” incluent beaucoup de postes bas niveau, genre “maintenir le contrôleur de domaine pour la pizzeria du coin et ses 2 employés”, qui demande beaucoup moins de compétences. Et qui vont donc être sur-représenté par rapport aux postes style “gérer l’infrastructure de stackoverflow”.
Et inversement, les postes “Linux admin” vont être sur-représentés dans les catégories “gérer toute l’infrastructure de Facebook”.

Dit autrement, ces postes mélangent allègrement “IT old school pour toute petites boites”, “IT plutôt sérieuse” et “admin d’un gros environment de production avec un gros traffic”.

Bref, faudrait commencer par définir ce qu’on veut dire par “admin sys” en premier lieu, parce que sinon ça va être la fête au cueillage de cerises.

Ca prouve qu’ils ne sont pas audités. Ou en tout cas, pas plus que les logiciels propriétaires.

Shell Shock a duré 25 ans, donc les “with enough eyes all bugs are shallow”, on repassera. Surtout sur des outils critiques écrits en c.
Et avec ses 2 patches coup sur coup, ça montre que la résolution a été bâclée, donc les “mieux mis à jour”, on repassera aussi.

J’oubliais, y’a sudo aussi qui était troué pendant 10 ans.

Après, je cherche pas à dire que le proprio est vachement mieux la dessus. Mais préjuger de la sécurité d’un soft à partir de sa licence est ridicule. C’est du même tonneau que de préjuger de la compétence d’une personne sur son costard.

Pourquoi les deux seraient liés? C’est des compétences et champs complètement différents.
Et surtout, y’en a qui sert à mesurer directement l’augmentation de ca, et l’autre qui apparaît surtout comme un coup sans aucun intérêt direct.

C’est comme si je te disait “puisqu’il habite en appartement, il doit pas aimer la glace à la vanille”.

Et d’autre part, non, c’est pas ce que tu dit depuis le début.

Par défaut, un serveur Linux sous une distribution classique est mieux sécurisé

Ton admin Linux-qui-est-plus-competent-que-la-moyenne, il va te laisser la config par défaut? Ou il va la changer? C’est un peu un argument à la con “la config qu’on est pas censé utilisé est mieux”. Ok, cool.

Les serveurs Linux sont enrichis en logiciels libres, qui sont probablement mieux audités et mieux mis à jour que certains logiciels propriétaires, et les failles de sécurité sont gérées de manière plus transparente (à commencer par l'OS)

Ouais, alors là, pour le coup, on a un certain nombre d’exemples cette derniere décennie qui prouvent que non, pas du tout. Genre Shell shock, genre heart bleed, genre Debian OpenSSL.

Les admins des serveurs Linux sont probablement plus compétents et expérimentés que ceux des serveurs Windows

“Comme j’aime pas Windows, je vais sortir un truc à la con du chapeau sans aucune source”

Les décideurs qui choisissent des solutions Linux sont plus compétents (ils écoutent mieux les "gars de la technique") que ceux qui choisissent des solutions Windows

c’est les décideurs qui s’occupent d’administrer l’infrastructure chez toi? Et dans le genre argument récursif “Linux est mieux parce que les décideurs qui choisissent Linux sont plus compétents parce que Linux est mieux”

La diversité des distributions et des logiciels fait que la plupart des serveurs Linux ont une configuration unique, donc l'attaque se fait au cas par cas
Chaque argument offre un peu de sécurité supplémentaire, mais tous ensemble, ça commence à faire une sacrée différence.

Enfin un argument qui tient vaguement la route. Sauf qu’en fait, pas tant que ça au final. Y’a pas tant de distro qui sont viables en production, et si tu te limites aux lts, t’as quoi, 6 à 10 candidats pour 95% des installs. C’est plus que Windows, mais c’est pas non plus le bout du monde.

C’est une façon de voir les choses. Tu peux aussi zapper l’analyse statistique, et conclure via tes métriques techniques (success/failure et response times), bien plus vite, sans avoir à te demander si t’as choisi la bonne p-value, si t’as pas un biais de sélection qui influence les résultats et autres joyeusetés qui viennent avec l’analyse d’un ab test.

Dit autrement, tu peux enfoncer un clou avec un tournevis, mais c’est pas forcément le plus adapté.

La question c’est surtout combien de clients ils ont. La majorité de ces serveurs sont là pour eux, pas les employés. ‘Fin c’est très bizarre comme métrique, surtout qu’on sait pas si ces 800 machines Windows sont des VM ou des serveurs physiques.

C’est dur d’estimer quel genre de traffic ils prennent, mais une autre façon de voir les choses c’est que chaque serveur génère plus de 650k euros de chiffre d’affaire par an.
C’est assez incongru comme métrique aussi, mais vu sous cet angle, ça devient moins stupide.

Ab test, pas test test.
C’est censé tester l’impact de nouvelles (ou changement de) fonctionnalités sur le business, pas valider l’infrastructure sous jacente.

Y’a des moyens beaucoup plus simple de valider qu’une mise à jour de Windows pete pas le service. Tu déploies un canary, et tu gardes un œil sur tes métriques techniques et tes logs.

Quand il s’agit de mises à jour systèmes, t’as pas toujours l’option de faire ça non plus. Si t’as updaté ton sqlserver, c’est pas garantit que tu puisses le downgrader derrière et que ça continue à marcher.

Il dit qu’il a plus de genoux.
C’est quoi le rapport?