Tweet
Devido a falta de um tempo limite de execução (query timeout) para consultas, é possível fazer com que o MySQL fique por um determinado tempo (horas/dias) processando uma query específica. O tempo de processamento vai depender dos recursos de hardware (cpu, memória…) disponíveis no servidor.
O MySQL possui uma variável de sistema, que define a quantidade máxima de conexões que podem ser realizadas simultaneamente (max_user_connections) para o deamon. Por exemplo no caso desta variável estar configurada para –max_user_connectons=100, o MySQL apenas irá permitir que 100 conexões simultâneas sejam processadas, no caso de uma tentativa de conexão 101 for realizada, o deamon irá responder com a mensagem Too many connections e desta forma nenhuma outra requisição será processada enquanto as conexões estiverem ativas.
A função benchmark() pode ser utilizada para “segurar” uma determinada conexão por um certo intervalo de tempo. Por exemplo:.
Ao executar a função benchmark(), conforme ilustrado, é possível verificar que o MySQL levou cerca de 1.11 segundos para processar a query, ou seja, ele “segurou” a conexão atual por um período de 1.11 segudos. Se o valor referente a quantidade de vezes de processamneto da função benchmark(), for aumentado, o tempo total de processamento consequentemente aumenta.
O processamento da função benchmark() acima, levou 12 minutos para ser processada.
Como esta função não possui limites para a quantidade de vezes necessária para processar determinada tarefa, é possível incrementar este número para um valor extremamente alto de forma que uma ou mais conexões disponíveis seja ocupada por um longo período de tempo.
Através deste comportamento, é possível causar uma negação de serviço, bastando enviar múltiplas requisições de conexões simultâneas, de forma a preencher todos os slots disponíveis no MySQL (definidas no max_user_connections) e manter estas conexões ocupadas com o processamento do benchmark(). Desta forma conexões subseqüente não serão processadas pelo deamon.
Para forçar o MySQL a processar uma requisição por várias horas/dias, a seguinte query pode ser enviada:
A função nativa ENCODE() leva cerca de 4 vezes mais tempo para ser processada do que a função sha1(), logo pode ser utilizada para “segurar” as conexões do MySQL.
Durante os testes realizados no daemon, foi possível notar que o processamento da CPU mantia-se em média de 98%, além de que novas conexões ao banco eram negadas. Para restabelecer o funcionamento normal do daemon foi necessário restartar o MySQL.
Fonte: tiagoferreira
O MySQL possui uma variável de sistema, que define a quantidade máxima de conexões que podem ser realizadas simultaneamente (max_user_connections) para o deamon. Por exemplo no caso desta variável estar configurada para –max_user_connectons=100, o MySQL apenas irá permitir que 100 conexões simultâneas sejam processadas, no caso de uma tentativa de conexão 101 for realizada, o deamon irá responder com a mensagem Too many connections e desta forma nenhuma outra requisição será processada enquanto as conexões estiverem ativas.
A função benchmark() pode ser utilizada para “segurar” uma determinada conexão por um certo intervalo de tempo. Por exemplo:.
Código:
mysql> select benchmark(500000,sha1('A'));
+------------------------------+
| benchmark(500000,sha1(0x65)) |
+------------------------------+
| 0 |
+------------------------------+
1 row in set (1.11 sec)
Código:
mysql> select benchmark(500000000,sha1(0x65)); +---------------------------------+ | benchmark(500000000,sha1(0x65)) | +---------------------------------+ | 0 | +---------------------------------+ 1 row in set (12 min 5.06 sec)
Como esta função não possui limites para a quantidade de vezes necessária para processar determinada tarefa, é possível incrementar este número para um valor extremamente alto de forma que uma ou mais conexões disponíveis seja ocupada por um longo período de tempo.
Através deste comportamento, é possível causar uma negação de serviço, bastando enviar múltiplas requisições de conexões simultâneas, de forma a preencher todos os slots disponíveis no MySQL (definidas no max_user_connections) e manter estas conexões ocupadas com o processamento do benchmark(). Desta forma conexões subseqüente não serão processadas pelo deamon.
Para forçar o MySQL a processar uma requisição por várias horas/dias, a seguinte query pode ser enviada:
Código:
select benchmark(9000000000000000000000000000000,ENCODE(0x65,0x65))
Durante os testes realizados no daemon, foi possível notar que o processamento da CPU mantia-se em média de 98%, além de que novas conexões ao banco eram negadas. Para restabelecer o funcionamento normal do daemon foi necessário restartar o MySQL.
Fonte: tiagoferreira
