Discussion :

[Celira]

Les nouvelles versions de PHP sont disponibles officiellement Nouvelles versions de PHP : PHP 5.3.5 et PHP 5.2.17

[Idelways]

PHP : deux correctifs pour le bogue des nombres à virgule flottante
L'équipe de PHP recommande de l'appliquer immédiatement

Mise à jour du 07/01/2011


L'équipe de développement de PHP vient de publier des patchs pour corriger le bogue étrange découvert cette semaine. Un bogue capable de provoquer le crash du système par le passage d'un simple paramètre dans l'URL des sites hébergés sur des systèmes x86 (pour plus de détails, lire ci-avant)

Après analyse, il s'agit vraisemblablement d'un bogue sur le code optimisé pour les x86 du GCC (le compilateur du projet GNU) à l'origine d'une incompatibilité avec x87, l'Unité de calcul en virgule flottante (ou FPU).

Deux nouvelles versions de PHP viennent donc d'être packagées : la 5.3.5 et la 5.2.17.
Ces versions n'incluent aucune autre nouveauté que ce correctif.

L'équipe de PHP "recommande vivement" l'application immédiate de ce patch disponible sur php.net.


Pour vérifier si votre installation de serveur web est vulnérable à cet bug, exécutez ce script en ligne de commande
Les deux correctifs sont téléchargeables sur cette page


Source : l'annonce du lancement de la 5.2.17 et de la 5.3.5, le rapport de bug sur le tracker de GCC

[Flaburgan]

Je ne vois pas trop pourquoi on parle de deni de service par contre, puisqu'il n'est pas question d'asperger de requêtes le serveur mais d'en faire une seule qui le fait crasher...
Enfin, si deni de service est pris dans le seul "le serveur ne peut plus répondre car occupé à autre chose", ok, je comprends.

[ctxnop]

Je ne vois pas trop pourquoi on parle de deni de service par contre, puisqu'il n'est pas question d'asperger de requêtes le serveur mais d'en faire une seule qui le fait crasher...
Enfin, si deni de service est pris dans le seul "le serveur ne peut plus répondre car occupé à autre chose", ok, je comprends.

Le Deny Of Service (refus de service) ne signifie pas qu'on asperge le serveur de requête, ca signifie juste qu'on s'arrange pour que le serveur arrête de traiter des demandes.
L'une des méthodes pour y arriver est d'asperger le serveur de requête pour qu'il n'arrive plus a répondre aux requêtes "normales".
Faire crasher le serveur est une autre méthode plus radicale.

[Jormund]

Je ne vois pas trop pourquoi on parle de deni de service par contre, puisqu'il n'est pas question d'asperger de requêtes le serveur mais d'en faire une seule qui le fait crasher...
Enfin, si deni de service est pris dans le seul "le serveur ne peut plus répondre car occupé à autre chose", ok, je comprends.

Le Deny Of Service (refus de service) ne signifie pas qu'on asperge le serveur de requête, ca signifie juste qu'on s'arrange pour que le serveur arrête de traiter des demandes.
L'une des méthodes pour y arriver est d'asperger le serveur de requête pour qu'il n'arrive plus a répondre aux requêtes "normales".
Faire crasher le serveur est une autre méthode plus radicale.

Oui, le "denial of service" désigne l'état du serveur qui ne répond pas, et pas la manière de l'obtenir.
En allant chercher loin, couper le courant serait aussi au sens strict une attaque DoS. (même si bien sûr je n'ai jamais vu employer ce terme dans ce cas)

DDoS=distributed denial of service (attack)="asperger de requêtes le serveur"

[Rom_1]

Enfin, si deni de service est pris dans le seul "le serveur ne peut plus répondre car occupé à autre chose", ok, je comprends.

Une attaque par déni de service est une attaque visant à rendre un service inutilisable.

Si ca marche avec une seule requête, l'attaque n'en est que plus efficace.
Mais normalement, le serveur web devrait utiliser un thread par requête (donc une requête ne bloque au maximum qu'un cœur et pas le service entier) et tuer le thread après un certain temps d'exécution.

Enfin c'est quand même sacrément efficace.

EDIT : vu les explications de la personne qui a découvert le bug, le problème vient du fait que la FPU des processeurs x86 utilise une précision étendue (80 bits) dans tous les cas, et ne sait pas calculer en double précision (64 bits). Donc ca viendrait plus de la plate-forme que du langage.

Et donc, ce ne serait pas étonnant que d'autres langages soient touchés, par exemple .net ou python...

[LhIaScZkTer]

Et donc, ce ne serait pas étonnant que d'autres langages soient touchés, par exemple .net ou python...

Quand le bug est apparu sur PHP, je me suis demandé s'il touchait d'autres langages. J'aurais dû tester... en tout cas en vb.net et c# j'ai pas réussi à reproduire l'erreur et ça sous le framework 2.0

[Idelways]

Le bogue des nombres à virgule flottante refait surface en Java
Et plonge le compilateur et les programmes dans des boucles infinies

Mise à jour du 08/02/2011


Quelque temps après sa correction sur PHP, le bogue étrange des nombres à virgule flottante refait surface sur un langage tout aussi populaire : Java.

Ce bogue provoquait sur PHP avant sa correction le crash du système par le passage d'un simple paramètre dans l'URL, pour peu que le script convertisse en nombres ou utilise ces variables dans des opérations arithmétiques (pour plus de détails, lire ci-devant)

Sur Java, un bogue similaire plongerait les programmes à l'exécution (ou leur compilateur) dans des boucles infinies d'après Exploring Binary, le site où ont été mis en lumière les deux bogues.

Le nombre en question, le désormais célèbre 2.2250738585072012e-308 et ses différentes représentations sont supposés être convertie en 0x1p-1022, qui correspond à la constante DBL_MIN.
Au lieu de cela, Java se retrouve coincé, oscillant sans arrêt entre les valeurs 0x1p-1022 et 0x0.fffffffffffffp-1022, le plus grand nombre dénormalisé à double précision et à virgule flottante.

Le bogue serait provoqué par la boucle de correction de la classe FloatingDecimal, chargée de trouver la meilleure approximation, qui la trouve mais la remplace et la retrouve infiniment...

Le bogue a été reporté à Oracle depuis plusieurs semaines, son rapport a récemment été assigné pour analyse interne non accessible sur Sun Developer Network (SDN).




Pour reproduire ce bogue à l'exécution des programmes, compilez et exécutez ce programme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class runhang {
public static void main(String[] args) {
  System.out.println("Test:");
  double d = Double.parseDouble("2.2250738585072012e-308");
  System.out.println("Value: " + d);
 }
}

Pour provoquer une boucle infinie au niveau du compilateur, il suffit de tenter de compiler cette classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
class compilehang {
public static void main(String[] args) {
  double d = 2.2250738585072012e-308;
  System.out.println("Value: " + d);
 }
}

Source : Exploring Binary

Et vous ?

Arrivez-vous à reproduire ce bug ?
Sur quelle plateforme, architecture et version de JRE/JDK ?

[mojorisin]

Pour php, il faut que la plateforme soit en 32bits me semble-t-il.

[camus3]

C'est à mon avis un moindre problème dans java ou les données sont strictement typées. Mais je peux me tromper

[stealth35]

C'est à mon avis un moindre problème dans java ou les données sont strictement typées. Mais je peux me tromper

non c'est pareil.

[igor24]

Eclipse a planté rien qu'en collant le 2nd bout de code ..., normal il compile à la volée

[ztor1]

Question idiote ?

Je peux ?

Qui utilise un chiffre pareil ? 2.2250738585072011e-308

Cela me fait penser au bug du pentium I à sa sortie.

Les exemples cités java ou php ... On utilise vraiment cela ?

[YannPeniguel]

Question idiote ?

Je peux ?

Qui utilise un chiffre pareil ? 2.2250738585072011e-308

Cela me fait penser au bug du pentium I à sa sortie.

Les exemples cités java ou php ... On utilise vraiment cela ?

Toute personne malveillante connaissant ce bug et souhaitant dégommer ton application par un moyen, exposé publiquement, de lui fournir cette valeur en entrée. Mettons par exemple dans les appels AJAX utilisant des JSP, ou dans les parametres d'url pour tes servlets Java...

[Derek Corgan]

Effectivement, Eclipse plante lamentablement à l'exécution (Eclipse 3.4, JKD1.6_20 + Windows XP).

Avant, la probabilité de survenance de ce bug était quasi nulle.

Maintenant que cela est connu il risque d'apparaitre dans des flux de données, soit pour faire une petite blague à un collègue ou pour faire chier

[atha2]

Question idiote ?

Je peux ?

Qui utilise un chiffre pareil ? 2.2250738585072011e-308

Cela me fait penser au bug du pentium I à sa sortie.

Les exemples cités java ou php ... On utilise vraiment cela ?

Un exemple entre autre : je veux développer une IA pour un jeu (échecs, dames, othello...), je vais utiliser l'agorithme minimax :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public double minimax(Node node, int depth){
    if(node instance of Leaf || depth == 0){
        return node.value;
    }
    double alpha = Double.MIN_VALUE; // <=> 2.2250738585072012e-308
    for(Node n : node.children){
        alpha = max(alpha, -minimax(n, depth - 1));
    }
    return alpha;
}

Bon j'ai pas tester s'il plante vraiment mais l'idée est là. Même s'il est vrai que généralement, on implémente cet algo en utilisant des entiers

[Cryde]

Comme quoi, les détracteurs du PHP auront vite compris qu'il n'y a pas que ce langage qui posait problème avec ça ^^

[nidget]

Je confirme ce bug sur JDK 1.6.0_20

[Thes32]

Il me semble que cela a été corrigé par leurs équipes http://blogs.oracle.com/security/201...e-2010-44.html

[centsoucis]

Bonjour, Pourquoi ne pas être rationnelle? Ce n'est pas l'étendu du nombre qui permet ma précision. Un nombre calculé peut être irationnel. Le stockage d'une valeur même flotante peut être relative dans la mesure de son exploitation. Alors pourquoi (mis à part certains domaine bien spécifique) approcher au plus juste une valeur irrationnelle? Tant que ce bug n'e'st pas résolu, il est toujours possible d'avoir une précision qui nous dépasse sans remédier au bug.