Désormais, les test unitaires accompagnant PHP seront tous valides
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 :
la gestion de la mémoire. php fuit, php est capable de s'écraser lui même en parti, php n'est pas réentrant ...
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.
l'approche par sandboxing dans le core mais oui mais non (j'ai nommé le safe_mode, l'open_basedir, le disable_functions, le logging de la fonction mail, le memory_limit, le max_execution_time ...).
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.
Les fonctions magiques register_globals, magic_quotes, url_fopen ...
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 Joris Dedieu (site web personnel) . En réponse à la dépêche État d'insécurité chez PHP. É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é ...