0

Buffer overflow is a very common vulnerability, often targeted with zero-day exploits. Successful attacks often result in arbitrary code execution, while failed attempts tend to crash the target program. ASLR makes this scenario even more common: in this attack example Apache web server is repeatedly crashed until the attacker detects the address of system() function before it is exploited. The attack requires an average of 32000 attempts.

This made me think: why does Apache allow to be attacked in such obvious way? I would be surprised if properly configured web servers crash more than a couple of times per day in production, so thousands of crashes in a matter of minutes is a strong indicator that:

  • an attack is going on
  • it is actually succeeding, i.e. buffer overflow does happen

In the event of a zero-day exploit, banning the attacker's IP for a day or stopping the server altogether after 10 or so crashes would provide enough time to apply a fix and make a big difference in security.

Is there a way to enforce such a security policy for popular services like Apache, sshd and similar? Or are there HTTP and SSH servers which have such functionality built in?

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
  • This is essentially one of the functions of a SIEM - detect unusual behaviour, and react quickly. High profile organisations will often have this ability, although they may not use it in this way, since it could allow for an attacker to DoS the system. – Matthew Mar 02 '16 at 10:16
  • @Matthew thanks, I'll check out SIEM. Concerning the DoS part, I would argue that if the attacker have found a buffer overflow vulnerability, he can usually do much worse than DoS by exploiting it and hacking the server. – Dmitry Grigoryev Mar 02 '16 at 10:47
  • This is true, but often companies prefer to have a human involved in the decision to turn off a server, especially where it could impact the bottom line. Not saying this is correct! – Matthew Mar 02 '16 at 10:52

0 Answers0