Il y a quelques mois était publiée la version 5.3.7 de PHP, sans s'assurer que certains bugs critiques, comme celui de la fonction crypt(), avaient été corrigés.
Cela avait conduit a une sortie précipitée de PHP 5.3.8 contenant les correctifs nécessaires avec une alerte pour la version 5.3.7 .
Beaucoup ont alors espéré que les développeurs de PHP allaient changer de méthodes de travail.
Le 10 janvier sortait la version 5.3.9 de PHP qui contenait, entre autres, un correctif pour une vieille faille de sécurité qui permettait de fabriquer facilement des collisions dans une hashtable conduisant à un déni de service (faille déjà mentionnée ici-même).
Le hic fut que le correctif introduisait une nouvelle faille de sécurité qui, pour éviter de permettre de faire des collisions, permettait une exécution arbitraire de code.
Le 2 février fut publié la version 5.3.10, qui corrige la faille introduite par le correctif précédent.
Aller plus loin
- Serious Crypto Bug Found in PHP 5.3.7 (98 clics)
- Annonce de PHP 5.3.8 et alerte sur la 5.3.7 (33 clics)
- Le change log des dernieres version de php (42 clics)
- Critical PHP Remote Vulnerability Introduced in Fix for PHP Hashtable Collision DOS (54 clics)
- PHP before 5.3.9 computes hash values for form parameters without restricting the ability to trigger (45 clics)
- Le courriel d'explication de Stefan Esser (148 clics)
# Encore et toujours...
Posté par gasche . Évalué à 10.
Ce n'est pas nouveau, déjà en 2007 un développeur se plaignant des mauvaises pratiques de sécurité avait lancé le Month of PHP Bugs (une vulnérabilité divulguée par jour pendant un mois).
[^] # Re: Encore et toujours...
Posté par rogo . Évalué à 10.
Ce développeur, c'était Stephan Esser, qui co-dirige une société de services sur la sécurité web en PHP. Ses relations humaines avec les principaux développeurs du noyau sont très tendues, depuis longtemps. Autrement dit, malgré sa compétence indéniable, il n'est pas neutre. A mon avis, au vu de ce que j'ai lu, son agressivité le dessert souvent.
Cette même personne est à l'origine du patch "Suhosin" pour sécuriser PHP. Ce patch vient d'être abandonné par Debian. Je cite une des 5 raisons de ce changement :
Toujours dans le même mail, selon les mainteneurs Debian, "PHP has improved a lot, in fact I haven't seen a canary report in past few years (probably 5.3.x)". Donc le bilan est "globalement positif".
[^] # Re: Encore et toujours...
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Je ne suis pas d'accord. PHP fait de gros progrès, mais vu de la situation catastrophique dont ils sont partis, ça ne suffit pas encore pour avoir un bilan "globalement positif". Qu'un patch pour un correctif de sécurité ne soit pas revu par qui ce soit, ça fait doucement rire. Il reste encore du boulot pour que la sécurité de PHP soit gérée de manière convenable.
[^] # Re: Encore et toujours...
Posté par rogo . Évalué à 10.
Ma tentative de faire un trait d'esprit est tombée à plat. Un bilan "globalement positif", tout particulièrement entre guillemets, est une référence à des propos de Georges Marchais. Il fut le premier secrétaire du PCF pendant mon enfance , et à un journaliste qui lui demandait en 79 ce qu'il pensait des crimes du stalinisme, Marchais répondit que « le bilan des pays communistes est globalement positif ». L'expression fit florès ; il fallait donc voir une forte ironie dans mes louanges.
[^] # Re: Encore et toujours...
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
C'était pourtant évident ! Qui ne se souvient pas immédiatement de la phrase "globalement positif" de Georges Marchais sur linuxfr ?!
hrhrhr
[^] # Re: Encore et toujours...
Posté par syj . Évalué à 3.
Mais enfin, tout le monde sait que LFR est un repaire de vieux gauchiste.
[^] # Re: Encore et toujours...
Posté par gasche . Évalué à 8.
Je trouve la remarque un peu limite. Certes, tout le monde n'est pas bien au courant de la politique des années 80 (en particulier les gens qui n'étaient pas en âge de la suivre en direct), mais on parle quand même d'un parti qui à l'époque avait grosso-modo autant de voix aux élections que le parti socialiste. Oui oui, ça paraît lointain aujourd'hui mais à l'époque le PCF c'était 20% des électeurs, donc pas vraiment un détail de "vieux gauchiste".
Je ne connaissais pas la référence de rogo; j'en ai pris note, c'est enrichissant, et je me suis senti un peu inculte pour le coup. Il ne me semble pas surprenant de ne pas connaître, mais sa précision est tout à fait respectueuse généreuse, et lui tomber dessus avec ironie et suffisance comme vous le faites me paraît déplacé.
[^] # Re: Encore et toujours...
Posté par syj . Évalué à 1.
Vous vous méprenez. Ce n'est pas de la suffisance ou de l'ironie.
Je suis très sérieux quand je dis que LFR est un repaire de vieux gauchiste.
Premièrement, aucun d'entre nous ne rajeunis et je suis sûr qu'il y en a qui sont plus proche du recyclage que de la production.
Enfin, Les valeurs fortes des logiciels libres sont le partage et la mutualisation.
Des valeurs qui sont commune à la gauche (au sens large).
Même si tout le monde n'est pas à mettre dans le même sac. On peut trouver des libéraux
qui estiment que ces valeurs sont compatible avec leurs idéalisation de l’économie et de la société. Ils ont raison.
L'idéologie du libre tend plus à gauche qu'à droite car les libéraux ne comprennent pas qu'on ne fasse pas de l'argent directement d'une production intellectuel.
Un peu comme l'écologie tend plus à gauche qu'à droite car elle s'oppose au capitalisme aveugle qui privilégie la production à l'environnement.
[^] # Re: Encore et toujours...
Posté par Zenitram (site web personnel) . Évalué à 6.
Ca, c'est ce que certains voudraient faire croire. faut arrêter de gober le message qu'ils voudraient faire passer. Le libre, c'est les 4 libertés. Aucune relation avec le partage (le libre se soucie que de celui qui reçoit, le libre n'a absolument rien à faire des autres) et la mutualisation (celui qui reçoit est libre de mutualiser, ou pas. Il est libre de choisir)
Ça va peut-être te déprimer, mais les 4 libertés du logiciel libre, c'est autant "vieux gauchiste" que "libéral".
Le libre est politiquement neutre, et c'est pour ça que ça marche.
Archi-faux. Les libéraux peuvent très bien adhérer aux principe du libre (les libéraux y voient la liberté pour chacun de faire du business). La droite moins bourrine peut très bien y voir une réduction des coûts (réduction des salariés).
Tu crois vraiment que chez RedHat, SuSE, MySql (maintenant Oracle, hum), Facebook, Tweeter ou Google, ce sont des gauchos? Il font pourtant pas mal de libre...
[^] # Re: Encore et toujours...
Posté par syj . Évalué à 4.
Au même titre que l'écologie n'est pas uniquement un courant de gauche.
Si tu relies mon message précédent , tu verras que notre avis diverge uniquement sur le sens et le poids qu'on donne au mot "tendance".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Encore et toujours...
Posté par vpinon . Évalué à 1.
Bravo Zenitram, toujours courageux pour rappeler les idées à contre-courant. Dommage que la notation "inutile" soit utilisée pour "pas d'accord", et fasse plonger le commentaire, pourtant enrichissant (on a tous tendance à oublier que tout le monde n'a pas la même approche que soi)…
[^] # Re: Encore et toujours...
Posté par gasche . Évalué à 2.
Les deux commentaires entre celui de rogo et le mien sont suffisamment ambigus pour pouvoir être interprétés de multiples façons différentes. J'avais envisagé que l'un d'entre eux ne soit effectivement pas pensé pour se moquer de lui (logiquement ce serait plutôt le deuxième si l'on suppose que chaque commentaire tend à contredire son parent).
Le problème c'est que quand on fait passer un message, ce n'est pas la volonté de l'auteur qui importe, mais la façon dont il est reçu par l'audience; je me hasarde à parier qu'ici les gens ayant plussé vos réponses les ont en majorité interprétées comme des répliques mesquines au message de rogo (tout simplement parce que noteurs anonymes de LinuxFR sont fondamentalement mesquins, moi le premier les mauvais jours). J'ai donc tiré dans le tas.
Le mieux serait de savoir comment rogo a pris vos remarques; après tout c'est le premier concerné.
[^] # Re: Encore et toujours...
Posté par rogo . Évalué à 10.
Très bien merci. Je dois être un peu naïf, je n'ai pas vu de moquerie et encore moins d'agressivité dans ces messages.
Et puis j'ai assez de bouteille (sans être un vieux gauchiste) pour ne pas être trop susceptible sur internet.
Ce qui me désole dans l'affaire, c'est que ceux qui ne connaissent pas Georges Marchais n'ont donc jamais écouté Pierre Desproges. Et ça, c'est vraiment dommage pour eux !
[^] # Re: Encore et toujours...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Jean Ferrat a été bronsonisé il y aura bientôt deux ans, et les jours qui ont suivi son décès, la plupart des médias ont rediffusé ses chansons les plus célèbres, dont « Le bilan » .
[^] # Re: Encore et toujours...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1.
Le célèbre acteur politique ? Il est pas bronsonisé, celui-là ?
[^] # Re: Encore et toujours...
Posté par Pierre Bourdon . Évalué à 9.
Et c'est le même Stefan Esser qui a dévoilé la faille critique dans PHP 5.3.9. Il a d'ailleurs posté récemment sur la liste php-internals pour donner encore une fois son avis sur la version PHP "upstream" : http://news.php.net/php.internals/57655
[^] # Re: Encore et toujours...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Voir aussi le Twitter de Stefan, pour ceux qui s'intéressent à ce sujet : [https://twitter.com/#!/i0n1c]
[^] # Re: Encore et toujours...
Posté par windu.2b . Évalué à 8.
J'avais lu Stéphane Essel, l'auteur du livre "indignez-vous"... Ceci dit, le titre de son livre se prête fort bien à la situation ! :-D
[^] # Re: Encore et toujours...
Posté par Antoine . Évalué à 7.
Hessel.
[^] # Re: Encore et toujours...
Posté par krouik . Évalué à 8.
C'est pas celui qui chante "déjeuner en paix" ?
# Pour compléter...
Posté par rogo . Évalué à 10. Dernière modification le 04 février 2012 à 18:52.
En l'état cette dépêche me semble trop sommaire pour représenter la situation. Quelques point qui me semblent importants dans l'évolution récente de PHP :
Tests unitaires
Désormais, les test unitaires accompagnant PHP seront tous valides. Cela semble une évidence, mais ne n'était pas le cas jusqu'à maintenant. En 2011, si on compilait soi-même PHP puis lançait un
make test, on se retrouvait avec plusieurs dizaines de tests ayant échoués. Mais c'était "normal", certains tests n'étaient pas supposés réussir ! Personnellement, ça m'a surpris puis mis en rage quand j'ai expérimenté ça.C'est ce dysfonctionnement qui a provoqué la grosse cagade de PHP 5.3.7. La régression était bien repéré par un échec de test, mais celui-ci était noyé parmi les faux-positifs. Pire, ce problème avait été signalé sur la liste de diffusion php-dev, avec référence précise au test, mais les développeurs étaient tellement habitués aux tests qui foirent qu'ils n'ont pas réagi.
À mon avis, cette prise au sérieux des tests unitaires est le plus important progrès de PHP en 2011.
Passage de svn à git
Après un sondage en interne, le code source est passé sous git. Le passage à un DVCS un progrès mineur, mais cela simplifiera en particulier les forks, comme le fameux php-fpm qui avait été développé séparément avant d'être fusionné dans PHP 5.3.
Réorganisation du projet PHP
Il y a eu ces derniers mois une volonté de mieux s'organiser et d'être plus transparents. Par le passé, certains épisodes ont nuit à l'image de PHP (des questions fondamentales tranchées en 10 minutes d'IRC privé avec des arguments vaseux du genre "'\' est plus facile à taper que ':'"). Le besoin de se réorganiser est aussi venu après la sortie prématurée d'une version 3.5.8 qui aurait dû être repoussée car un problème de compatibilité avait été détecté. Le passif de feu PHP6 a aussi joué.
Il y a désormais un texte pour décrire le release process là où tout se faisait auparavant au jugé.
Compatibilité
Le langage se débarrasse enfin des erreurs du passé (enfin, certaines, vu que la liste en est longue). PHP 5.4 abandonne supprime enfin les catastrophiques "register_globals" (génération spontanée de variables à partir des paramètres GET, POST et des cookies). En terme de sécurité, c'est bien d'enlever de PHP des parties de code obsolètes et dangereuses quand activées.
[^] # Re: Pour compléter...
Posté par Anonyme . Évalué à 10.
Et la cohérence du langage, c’est pour quand ?
[^] # Re: Pour compléter...
Posté par wismerhill . Évalué à 6.
Vu qu'ils ont introduit le goto dans la version 5.3, je dirais plutôt qu'ils y vont a reculons.
[^] # Re: Pour compléter...
Posté par Antoine . Évalué à 10.
Il me semble que le goto est assez cohérent avec la philosophie de PHP.
[^] # Re: Pour compléter...
Posté par wismerhill . Évalué à 2.
«vite fait, mal fait», oui c'est dans l'idée.
Rien que dans les commentaires de la documentation officielle on a un exemple de très mauvais usage de goto:
http://www.php.net/manual/fr/language.exceptions.php#104791
[^] # Re: Pour compléter...
Posté par William Steve Applegate (site web personnel) . Évalué à 6.
Et si quelqu'un poste un commentaire débile sur LinuxFR, je peux en rendre les concepteurs du site responsables ? Je veux bien qu'on attaque les mauvais choix des devs, mais là c'est exagéré : ils ne vont quand même pas passer leur temps à surveiller si quelqu'un ne poste pas une ânerie sur le site des docs…
Envoyé depuis mon PDP 11/70
[^] # Re: Pour compléter...
Posté par Prae . Évalué à 5.
Je me souviens d'un article d'un excellent codeur qui disait qu'entre choisir un mauvais code avec des if/while/do/for imbriqués et une simplification du code avec un goto bien placé, le 2nd choix était mille fois plus pertinent, que ce soit la lisibilité, le refactoring mais aussi la rapidité du code compilé (ou interprété)
[^] # Re: Pour compléter...
Posté par Jean B . Évalué à 8.
Effectivement dans des languages comme C, les goto peuvent parfois être salvateurs, principalement dans la gestion des erreurs: c.f. http://eli.thegreenplace.net/2009/04/27/using-goto-for-error-handling-in-c/
Mais bon PHP est censé supporter les exceptions, qui répondent bien mieux au besoin.
[^] # Re: Pour compléter...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Ce n'était pas les linux coding guidelines ?
"La première sécurité est la liberté"
[^] # Re: Pour compléter...
Posté par Guillaume Denry (site web personnel) . Évalué à 5. Dernière modification le 06 février 2012 à 15:40.
Un return, c'est un goto déguisé.
Et l'usage de "return" bien placés sont plutôt conseillés pour la lisibilité du code, pour élaguer les cas au sein d'une fonction par exemple :
[^] # Re: Pour compléter...
Posté par djano . Évalué à 3.
Je suis tout a fait d'accord.
La suggestion d'un return unique par méthode est bien pour des langages comme le C++ qui vont générer une tétra chiée d'appels aux destructeurs pour chaque return (quoique, j’espère que les compilateurs ont amélioré ça de nos jours?). Par contre, pour des langages comme Java, C#, Python, Perl, PHP, etc. ça ne sert strictement a rien et ça nuit a la lisibilité du code.
[^] # Re: Pour compléter...
Posté par Guillaume Denry (site web personnel) . Évalué à 0.
Ah bon ? les return nuisent à la lisibilité du code pour ces langages ? J'aimerais bien comprendre pourquoi
[^] # Re: Pour compléter...
Posté par claudex . Évalué à 3.
Il dit que le return unique nuit à la lisibilité du code.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pour compléter...
Posté par rogo . Évalué à 7.
La cohérence, ils s'en balancent. Honnêtement, je crois que c'est vraiment un souci archi minoritaire parmi les développeurs PHP. On peut apprécier ou pas, mais leurs objectifs sont ailleurs. Il n'y a aucun projet de réformer le langage en profondeur. À la limite, le seul changement prévu qui aurait un impact universel en PHP, c'est le support d'UTF-8.
Certes la syntaxe de PHP est bordélique (sensible à la casse sur les variables mais pas sur les fonctions), le nommage interne est incohérent (
fetchAll()ouget_file_contents()?strtolower()ouip2long()?), la jungle des fonctions de tri est hideuse, etc, etc. Mais est-ce essentiel ? Pour les langues humaines, le corpus est souvent plus important que la cohérence grammaticale. La langue française, même s'il est difficile de maîtriser parfaitement ce fouillis, a des atouts face à un esperanto très raisonné. Pour la plupart des incongruités, nous y sommes tellement habitués qu'elles deviennent normales. Est-ce que des réformes de l'orthographe sont nécessaires pour donner plus de cohérence à notre langue ?Une comparaison plus technique : Scala est un langage magnifique. Moderne, riche, cohérent et même élégant. Ce fut un vrai bonheur d'apprendre le langage, et j'ai toujours plaisir à programmer avec. Sauf que peu à peu, j'ai déchanté en me confrontant à son environnement. Par exemple, le "build system" usuel est SBT qui m'a semblé un vrai calvaire, surtout depuis le changement (incompatible) de version. Du coup, beaucoup utilisent Maven, un outil Java qui peut s'adapter au monde Scala. Tout ça est très pénible à mettre en place, mais nécessaire pour certaines applis. Je ne dis pas que SBT ou Maven sont mauvais, c'est juste qu'ils sont lourds et difficiles à maîtriser. Ça colle assez bien à l'état d'esprit Java/Scala, mais c'est plutôt éloigné des objectifs de PHP.
[^] # Re: Pour compléter...
Posté par Antoine . Évalué à 3.
Nous, peut-être. Pour un étranger c'est plutôt compliqué à apprendre, le français...
En tout cas ce ne serait pas inédit, la langue a déjà été réformée plusieurs fois, je crois.
Je ne vois pas trop le rapport entre le système de build et le langage.
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
C'est vrai, et avec beaucoup de succès (ironie). Qui écrit maintenant portemonnaie plutôt que porte-monnaie ? Ou charriot plutôt que chariot ? cout plutôt que coût ? Etc.
La réforme de l'orthographe de 1990 est restée très largement lettre morte.
http://fr.wikipedia.org/wiki/Rapport_de_1990_sur_les_rectifications_orthographiques
Quand aux autres langues c'est pas mieux :
http://fr.wikipedia.org/wiki/Réforme_de_l'orthographe_allemande_de_1996
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par Antoine . Évalué à 2.
Je pensais plutôt aux évolutions recensées sur :
http://fr.wikipedia.org/wiki/Histoire_de_la_langue_fran%C3%A7aise
[^] # Re: Pour compléter...
Posté par djano . Évalué à 2.
Est ce que Gradle correspond mieux a Scala? J'ai lu du bien de cet outil de build pour les langages de le JVM autres que Java. Gradle est un mélange entre Maven et Ant. Il te propose des conventions précises pour Java (tout comme Maven), tout en étant beaucoup plus facilement configurable et il est plus facile d'écrire des taches custom dans les fichiers de build.
Par exemple, tout besoin non conventionnel avec Maven va nécessiter l’écriture d'un plugin Maven (Bah!), il est difficile de changer le comportement par défaut, XML c'est sympa un moment mais ça devient quand même lourd au bout d'un moment.
Gradle c'est:
* la possibilité de scripter son build en Groovy dans le fichier de build,
* la possibilité de changer le comportement par défaut de certaines taches,
* des notations compactes pour décrire les dépendances.
* un outil de build pensé pour construire des projets codé en multi langages.
Malheureusement je ne l'ai pas encore essayé, et je suis sur que le revers de la médaille est que les fichiers de builds peuvent vite devenir illisible si un goret est passé par la. Alors qu'avec Maven, le fichier XML reste a peu près potable en tout circonstances (enfin, pour du XML quoi).
Bref, je conseille de jeter un œil sur Gradle aui a l'air très intéressant.
[^] # Re: Pour compléter...
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Marf ils vont faire quoi ? Si j'étais mauvaise langue, je dirais supprimer ceux qui ne passent pas ?
Plus généralement (et n'oublions pas qu'ils nous avaient déja fait le coup avec la 5.2.15), il y a deux problèmes fondamentaux :
Cela est un problème fondamental car, il implique un comportement aléatoire du code en fonction des spécificités de l'environnement (typiquement ça marche sur mon ubuntu mais pas chez mon hébergeur).
Le cas typique est une fonction qui boucle à l'infinie avec un final une page en module apache, pas de page en fastcgi.
Suhosin est pour l'heure le seul mécanisme à sécuriser ce point un tant soit peu (suhosin.executor_maxdepth par exemple). Mais finalement le travail est gigantesque. Car c'est le fonctionnement de l'interpréteur lui même qu'il faudrait pouvoir remettre en cause.
La contrainte est qu'il faut assurer le recyclage des process, ce qui avec du code mal branlé et en haute charge peut se finir par un système qui passe son temps à forker. C'est aussi l'impossibilité d'utiliser php directement en threads ou en event.
Le problème de cette approche est qu'elle donne l'illusion d'une sécurité alors qu'elle n'est en soit qu'un ralentisseur (en gros ça sécurise pour peu que l'attaquant soit mauvais). La encore elles rendent l’exécution du code très dépendante du déploiement.
A mon sens ce code devrait se retrouver dans la partie sapi (lien avec le serveur) en tirant partie des fonctionnalités de l'OS et pas dans le core. Elles sont en plus souvent mal branlés. L'open_basedir par exemple effectue un nombre d'appels système stat simplement hallucinant. Cela veux aussi dire qu'il y a une grosse partie du code à refactoriser, pour augmenter l’homogénéité des contrôles et des appels.
Ces fonctions favorisent inutilement l'écriture de mauvais code.
Bref, j’espère que php va s'améliorer en terme de sécurité. Mais pour l'heure ce que je connais du code et la pratique que j'en ai comme sysadmin, me font douter de cette possibilité si ce n'est en passant par une quasi réécriture du core qui s'il pouvait en plus être lisible, me permettrait de classer php dans autre chose que la liste des softs insecure by design.
J'aime bien php. Il permet à plein de gens de faire des sites facilement. Il est un élément fondamental de la démocratisation du web. Mais de la à parler de sécurité ...
[^] # Re: Pour compléter...
Posté par Maclag . Évalué à 7. Dernière modification le 05 février 2012 à 04:34.
À une époque où on n'a jamais eu autant de CMS mâtures et faciles à utiliser ainsi qu'une tripotée de frameworks également très aboutis, a-t-on toujours besoin d'un PHP qui permet de coder facilement pour les non-initiés?
Parce que de ce que j'en vois, il n'est pas "sécurisé" en lui-même, et est beaucoup utilisé par des débutants qui vont rajouter leur couche d'erreur de débutants pour finalement faire des sites passoires.
Ce serait peut-être mieux de ne plus le recommander aux non-experts PHP jusqu'à ce qu'il soit un peu plus robuste...
[^] # Re: Pour compléter...
Posté par gasche . Évalué à 10.
Ou de ne plus le recommander à personne ? PHP est un langage moisi, c'est la vie, à une époque il avait le monopole du déploiement facile sur le web, maintenant on peut facilement choisir l'environnement qu'on veut. Tu peux donc coder pour le web dans le langage de ton choix (Ruby, Python, Java, C++, OCaml, Scala, Racket, Smalltalk..), pourquoi se flageller avec PHP ?
[^] # Re: Pour compléter...
Posté par dave . Évalué à 3.
Oui, pourquoi ?
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Pour compléter...
Posté par Laurent Morel . Évalué à 4.
NE pas confondre mature (adj.) et mâture (nom féminin), qui désigne l'ensemble des mâts d'un navire.
Dans "mûr" il y a un accent circonflexe, de là peut-être la confusion...
[^] # Re: Pour compléter...
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
De toute façon maintenant on dit cougar
[^] # Re: Pour compléter...
Posté par Jux (site web personnel) . Évalué à 5.
Je ne sais pas si PHP est récupérable. Avec les incohérences de la lib standard (nommage, ordre des arguments), les tables de comparaisons de type, l'impossibilité d'indexer directement un tableau retourné par une fonction, l'utilisation chiante (ça c'est subjectif) du $ devant les variables, etc...
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
Ça c'est dans PHP 5.4 je crois (hourra !).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par djano . Évalué à 2.
Des CMS développés en PHP? (Joomla, Drupal, etc.) :)
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
safe_mode, register_globals, magic_quotes disparaissent dans PHP 5.4.
La possibilité d'utiliser des urls dans les fopen, file_get_contents etc. : je vois pas trop le souci ?
Parler d'efficacité mémoire et des avantages de Suhosin me semble un peu contradictoire : Suhosin étant un consommateur de ressources plutôt important (+25 à +50% de mémoire utilisée avec suhosin, et pareil pour le temps d'exécution).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Pour open_basedir je n'ai rien constaté d'hallucinant personnellement (+7 appels stat effectués avec), par contre oui c'est un peu plus lent car ça désactive realpath_cache qui permet d'accélérer la résolution des chemins (d'où l'intérêt d'utiliser partout des chemins absolus).
Cf. https://bugs.php.net/bug.php?id=52312
Je déconseille quand même fortement d'utiliser open_basedir et d'utiliser une stratégie plus bas niveau, comme par exemple mpm-itk pour apache2 (paquet debian apache2-mpm-itk) qui permet de lancer apache avec des droits utilisateur différents par virtualhost.
ITK est ~2 à 5 fois plus lent que apache-prefork, mais beaucoup plus rapide que suphp ou suexec. Le plus efficace semble être mpm-peruser, mais n'est pas packagé dans debian. Des infos : http://blog.stuartherbert.com/php/2008/03/20/using-mpm-peruser-to-secure-a-shared-server/
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
teste avec magento c'est flagrant. Après est-ce l'open_basedir ou un effet induit par l'open_basedir. Je ne saurais le dire.
Mon propose concernait la suppression de ces fonctions de "sandboxing".
[^] # Re: Pour compléter...
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Le problème est complexe et n'a pas de bonnes solutions. Pour ma part mes tests montrent de bien moins bons résultats avec itk qu'avec suexec. suphp est disqualifié pour cause de cgi.
En tout état de cause je déconseillerai vivement l'utilisation de itk ou peruser pour la simple et bonne raison qu'ils nécessitent de faire tourner apache en tant que root.
[^] # Re: Pour compléter...
Posté par rogo . Évalué à 5.
Une bonne piste pour réaliser un sandboxing performant en php, c'est d'utiliser php-fpm.
Au niveau des performances, c'est apparemment meilleur que mod_php. Chaque spool php peut être lancé par un utilisateur différent, pas besoin de suexec et compagnie. Au passage, cela permet aussi de résoudre les problèmes d'exécution infinie évoqués plus haut. A mon sens, on a donc une solution optimale, et j'avais d'ailleurs été très satisfait de mes premiers tests.
Seul bémol, ce mode php-fpm n'a été intégré qu'en PHP 5.3.3, avec le statut "expérimental". Il sera déclaré stable en version 5.4, laquelle n'est encore qu'à l'état de RC.
Je me demande si PHP ne va pas encourager ceci pour remplacer mod_php, un peu à la façon dont wsgi a remplacé mod_python.
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
J'ai vu (enfin j'ai pas fouillé énormément non plus) dans la doc de PHP-FPM que ça ne permet la config que d'un utilisateur, comment arrives-tu à avoir un user différent ? Par exemple que le vhost bohwaz.net soit servi par l'utilisateur bohwaz, que le vhost machin.com soit servi par l'utilisateur machin etc. ? Car c'est bien l'intérêt de ITK/peruser.
Sans compter que j'ai pas mal lu des benchs qui disaient que FPM est plus lent que mod_php, ce qui ne m''étonne pas des masses si j'ai bien compris le fonctionnement des deux trucs.
Mais dans l'absolu je suis intéressé, même si je reste sceptique pour le moment.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par __o . Évalué à 4.
php-fpm permet de définir plusieurs "pools", avec des configs différentes (user, nombre de process, chroot, config php; tout en fait), et qui écoutent sur un socket tcp/unix différent.
Tu configure chaque vhost pour utiliser le bon pool (en spécifiant l'url de la socket).
FastCGI a un peu d'overhead par rapport à mod_php (vu que le serveur http et fastcgi communiquent via une socket), mais c'est négligeable comparé au temps d'exécution des scripts (par sûr que ça se voit sur un benchmark).
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 1.
Oui donc ça fait plusieurs process php-fpm. Sur un serveur avec des milliers d'users c'est juste pas tenable...
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par Juke (site web personnel) . Évalué à 0.
juste c'est son prénom ?
[^] # Re: Pour compléter...
Posté par claudex . Évalué à 2.
Je ne suis pas sûr qu'un serveur web avec des milliers de vhosts soit une bonne idée.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pour compléter...
Posté par siegfried . Évalué à -1.
itk et peruser ne sont que des alternatives à SuExec, pas à open_basedir.
Dans un environnement mutualisé avec des centaines de vhosts, je ne vois pas l'avantage, vas-tu dire à tous tes utilisateurs de "chmoder" leurs fichiers php en X00, ou le faire toi-même au risque de tout casser?
A leur actuelle il n'y a pas de mpm qui fasse aussi office de "chroot" en même temps, et utilisable en mutualisé, open_basedir peut dormir sur ses 2 oreilles.
Quant à php-fpm il est très performant, possible d'utiliser un pool par vhost, mais là encore ce n'est pas pour le mutu, et aucun chroot.
[^] # Re: Pour compléter...
Posté par Antoine . Évalué à 2.
Heu, dans ce cas c'est à l'hébergeur de fixer le umask correctement.
[^] # Re: Pour compléter...
Posté par siegfried . Évalué à -1.
J'imagine même pas combien d'applications cela casserait..
Et puis cela ne résoud pas tout du chroot/sandbox.
Quelle alternative existe-t-il concrètement à open_basedir?
Moi je pense qu'il manque clairement un mpm qui sorte du lot, itk/peruser sont orientés sécurité et paradoxalement ils tournent en root, puis ils remplacement que Suexec, il faudrait un mpm qui fonctionne en chrootant+peruser mais c'est l'un ou l'autre. Est-ce que c'est possible, je n'en sais rien..
Si vous voulez laisser les utilisateurs naviguer sur votre système, grand bien vous fasse, mais à un moment donné il faut savoir sacrifier un peu des performances si on veut de la sécurité.. Et à l'heure actuelle je ne vois pas ce qui remplace SuExec+open_basedir .
[^] # Re: Pour compléter...
Posté par siegfried . Évalué à -1.
Je me réponds:
Apparemment il existe un apache-itk-chroot dans AUR:
http://aur.archlinux.org/packages.php?ID=39440
Et un vieux projet chroot-suexec sur sourceforge:
http://chroot-suexec.sourceforge.net/
Ca parle d'un autre chroot-suexec ici mais les liens sont cassés: http://www.modsecurity.org/blog/archives/2006/03/apache_suexec_c.html
Que des projets "persos" malheureusement.
[^] # Re: Pour compléter...
Posté par Antoine . Évalué à 2.
Pourquoi régler le umask correctement casserait-il quoi que ce soit sur un hébergement où les utilisateurs sont censés être totalement cloisonnés les uns des autres ?
[^] # Re: Pour compléter...
Posté par siegfried . Évalué à -1.
C'est pas bête comme sécurité en plus, par contre je sais pas pour itk/peruser mais suexec les fichiers non *.php sont lus par apache et il faut que les répertoires soient au minimum avec 0066 et les fichiers php peuvent avoir un umask 0077, je crois pas que des regles d'umask en fonction du fichier ça soit faisable, mais je ne connais pas bien.
Pis je me méfie des applications PHP qui vérifient un peu n'importe comment si tel ou tel répertoire/fichier a les permissions d'écriture..
Si quelqu'un sait pour un umask de fichiers/rep différents je suis preneur :)
Sauf que mod_chroot est un chroot commun à tous les vhosts, comme mod_security je crois, ce qui est pas mal mais finalement moins bien que open_basedir car ne protège pas les utilisateurs les uns des autres, mais protège le serveur. Si j'ai bien compris le chroot d'itk, comme celui pour suexec, c'était afin de chrooter chaque virtualhost, peut-être au moment de l'appel à un CGI, surement lourd (plus qu'open_basedir j'imagine), mais ça doit être diablement sécurisé.
Bref tout ça pour dire qu'open_basedir est pas si pourri, et c'est pour ça qu'il est encore là..
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Il existe mod_chroot pour apache, et la fonctionnalité est aussi proposée par mod_security.
Et comme mentionné plus bas, itk+chroot dans archlinux, mais l'auteur d'ITK est pas chaud du tout pour une telle fonctionnalité dans ITK, donc peu de chances que ça soit intégré à ITK.
Je suis pas sûr que le chroot soit plus efficace niveau perfs que open_basedir quand même... (même si ok c'est le même niveau de sécurité).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par Moonz . Évalué à 2.
Si, tu as une option « chroot » dans la configuration de ton pool.
Je comprend pas ton problème.
Si /home/$user est en 700, il ne sera pas traversable par quelqu’un d’autre que l’utilisateur, donc tu peux mettre 777 sur tous les autres fichiers à l’intérieur sans que ça pose de problème de sécurité.
[^] # Re: Pour compléter...
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
je dirais que c'est bien ça le problème. Coder un client http robuste ne se limite pas à faire un fopen. C'est bien pour un environnement de bureau mais pour du code serveur il y a un tas de problèmes à gérer qui méritent un minimum d'attention. Tu ne peux pas présumer d'un tas de circonstances au niveau du réseau ou du serveur en face. Curl t'offres les moyens de faire ça, url_fopen non.
Je ne parle pas d'efficacité. Je parle de sécurité.
[^] # Re: Pour compléter...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
Je t'invite à regarder du côté des contextes de stream utilisables avec fopen etc., tu trouvera à peu près la même chose que ce que permet curl.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Pour compléter...
Posté par __o . Évalué à 6.
La gestion de la mémoire n'a rien à se reprocher à mon avis. Et il n'y a pas de fuite de mémoire notable.
PHP utilise un allocateur spécial qui est réinitialisé après chaque requête (un peu comme Apache utilise un pool mémoire pour chaque requête). Donc même en cas de fuite mémoire, la mémoire serait récupérée à la fin de la requête.
Tu peux détailler ?
Je pense que tu parle de récusion. En effet, PHP crash en cas de récursion trop profonde, parce que chaque niveau de récursion prend un peu de place sur la pile, et quand la pile est pleine, ça crash.
C'est pas spécique à PHP, si tu fais une "récursion infinie" en C tu obtiens exactement le même résultat.
D'ailleurs la seule façon d'obtenir un dépassement de pile depuis PHP 5.3 est de faire une récursion de fonctions natives, les fonctions utilisateur étant exécutées sans récursion, en interne.
Le fait est que dans un module apache, php est appelé par apache et donc la stack est déjà un peu remplie. Donc ça crash peut être une dizaine de récursions plus tôt, mais le comportement est le même en fastcgi.
De quoi tu parles ?
Ce sont des "features" dépréciée et désactivée par défaut dans 5.3.
même chose
[^] # Re: Pour compléter...
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
l'empreinte mémoire d'un processus php laissé en tâche de fond augmente. C'est d'ailleurs pour cela que la variable PHP_FCGI_MAX_REQUESTS a été créée.
Je parlais de tous ces exploits qui ont permis la désactivation de l'open_basedir, du safe_mode, du disable_functions. J'avais lu un article à ce sujet (dans misc peut-être) je n'arrives pas à remettre la main dessus. De ce que j'ai compris dans la quasi totalité des cas c'est on arrivait dans un traitement (particulièrement dans un traitement d'erreur) à modifier une variable dans la conf. Il faut vraiment que je retrouve cet article sinon je vais dire des conneries.
Je parle aussi du fait que l'utilisation sur des serveurs en thread n'est pas possible. Parce qu'au dernières nouvelles le parser n'est ni thread-safe ni réentrant.
L'utilisation en event n'est pas possible non plus car le processus php ne peut rester en tâche de fond pour cause de gonflement de l'empreinte mémoire.
On doit donc rester dans un modèle un processus par requête.
Oui ça crashe et c'est bien normal. Par contre sous apache ça te sert une page et pas en fastcgi. Il n'y a pas de mystère la dedans. C'est la gestion de la sortie standard qui est différente. Le problème ici n'est pas d'avoir une erreur 500 en fastcgi mais d'avoir un 200 sous apache.
Voir plus haut
Non. Les fonctions de sandboxing ne sont pas dépréciées (sauf le safe_mode).
Et permet moi d'avoir un léger doute quand je vois comment un serveur http a été introduit à l'arache dans la sapi cli. Php 5.3 est un progres peut-être mais beaucoup de travail reste à faire.
[^] # Re: Pour compléter...
Posté par __o . Évalué à 1.
Quand un processus réclame de la mémoire au système il ne la rend jamais; c'est le cas de tous les processus, pas seulement ceux de PHP.
Donc à la fin de la journée, la mémoire occupée par tes processus PHP c'est MAX(mémoire occupée par les scripts exécutés)
Apache aussi a un MaxRequestsPerChild.
Non tu disais que php n'était pas réentrant; je pense que tu mélanges pas mal de choses
En même temps ce sont des features dépréciées, il est recommandé de ne pas les utiliser.
C'était peut être un article sur l'exploitation d'une faille en particulier. La faille a certainement été corrigée avant même la publication de l'article. Je suis sûr que je peux trouver un article sur l'exploitation d'une faille dans python, ruby, et tous les moteurs js.
PHP est thread safe quand il est compilé avec l'option qui va bien. D'ailleurs c'est la seule manière d'utiliser PHP en tant que module IIS sous windows. (Certaines bibliothèques peuvent ne pas l'être par contre; ou des trucs comme putenv/getenv; mais rien de spécifique à PHP ici.)
Par contre il n'y a aucun intéret à utiliser des threads plutôt que des processus séparrés.
C'est ton script qui fuit.
ou l'inverse non ? si le module php crash, apache aussi, donc connexion terminée; si un process fastcgi crash, apache va retourner une error 500.
C'est pour le dev, pas pour la prod.
Pourquoi tu veux absolument utiliser tous les trucs dépréciés / non recommandés en prod ?
# Plus sûr
Posté par Arthur Accroc . Évalué à -4. Dernière modification le 06 février 2012 à 08:15.
Il y a pourtant très peu à changer à PHP pour avoir quelque chose de sûr, juste une lettre, et seulement pour celle qui la précède dans l’alphabet : PGP, c’est très sûr...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Détails sur les 2 dernières vulnérabilités PHP, méthodes de développement
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Il y a quelques mois était publiée la version 5.3.7 de PHP, sans s'assurer que certains bugs critiques, comme celui de la fonction crypt(), avaient été corrigés.
Euh non, il n'y avait pas de bug. La fonction a été modifié suite à un avertissement d'un outil d'analyse statique, modification faite par l'auteur du langage et censé améliorer la sécurité. Plus d'info sur cette vulnérabilité :
https://plus.google.com/111631720833482085895/posts/G3pKmqn4VFZ
Au sujet de la faille introduite par un correctif de l'attaque par déni de service de la table de hachage (PHP 5.3.9), j'ai également écrit sur un bref article :
https://plus.google.com/111631720833482085895/posts/dJ7RyRSj31f
Ce n'est pas Stefan Esser qui a trouvé la faille 20 jours après PHP 5.3.9, mais masugata qui a rapporté le bug 1 jour après PHP 5.3.9. Par contre, sûrement que quand Stefan rapporte un bug, il fait plus de bruit et donc les développeurs sont plus pressés de corriger le bug.
Contribuant à Python, je suis étonné des méthodes de travail des développeurs PHP. Ils n'écrivent pas ou peu de test, et à l'époque de PHP 5.3.7, il y avait 200 tests qui ne passaient pas, et pourtant ils ont publié une nouvelle version. Pour le correction pour le DoS (hash), je doute qu'un test ait été écrit vu que le correctif ne corrigeait pas la faille (dumoins, pas tous les cas). Pour le correctif du correctif, je ne vois pas non plus de test de non-régression. Là il y a 82 tests qui ne passent pas sur PHP 5.3, 86 tests sur PHP 5.4, et 104 sur HEAD. C'est beaucoup mieux !
À côté de ça, ça plusieurs semaines qu'un débat enflammé a lieu sur la liste de diffusion et le bug tracker Python pour choisir le meilleur correctif pour le même bug (DoS sur la table de hash). Je me dis que ce débat n'est pas si inutile : relire un patch à plusieurs permet d'avoir un meilleur code, même si la moindre modification prend plus de temps.
Python est blindé niveau tests et gare à celui qui pête un des 70 buildbots ! Pour Python 3.3, la majorité des buildbots sont verts, mis à part bugs connus et rapportés, pour les autres versions, buildbot est plus instable.
[^] # Re: Détails sur les 2 dernières vulnérabilités PHP, méthodes de développement
Posté par Emmanuel C . Évalué à 1.
Tiens d'ailleurs, quitte à squatter un thread sur PHP, ça avance la correction en Python ?
[^] # Re: Détails sur les 2 dernières vulnérabilités PHP, méthodes de développement
Posté par Antoine . Évalué à 4.
Ça avance tellement bien qu'on aura probablement un correctif intégré avant fin 2012 :)
Sérieusement, oui, une décision de principe générale a été prise après beaucoup de discussions sur les diverses approches possibles :
http://mail.python.org/pipermail/python-dev/2012-January/115892.html
Maintenant le patch est mis au point sur le bug-fleuve qui suit :
http://bugs.python.org/issue13703
(la décision sur l'approche à privilégier est rendue complexe par le fait que Python expose les valeurs de hash via la fonction hash() : rendre le comportement de cette fonction imprévisible d'une exécution à l'autre peut casser la compatibilité avec certains programmes, probablement rares).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.