1

If an adversary could identify a buffer's capacity, what would be the possible consequences?

Michael
  • 403
  • 2
  • 9
  • Wouldn't all open source code have this situation? In some languages, the buffer capacity needs to be specified. – schroeder Sep 29 '15 at 17:37

1 Answers1

2

The attacker already knows the capacity of all your buffers. This is the normal basic assumption: buffers in your software are defined by the software itself, which exists as source code, executable, backup copies, and in the heads of the designers. The same software may have been purchased by the attacker, and reverse-engineered; or the software could simply be opensource. Software cannot be considered to be secret in any way, because there are way too many ways for outsiders to learn that secret software.

Suppose that you run some software on your server, that expects from connected clients a user name and a password. The software will store the received data into in-memory buffers before processing that information. Suppose that the buffers are apt at receiving 200 characters each. The attacker also knows that (see above). So far so good.

The problem is not that the attacker knows the size of your buffers; the problem is when the attacker supplies more data than can fit into the said buffers, and the software, erroneously, tries to push the data into the buffer even though it makes no sense. This is the buffer overflow: the stupid, gullible software is induced into trying to do something nonsensical, and the data spills over other data elements in the machine RAM.

Some programming languages, in fact most of them except prehistoric languages like C, systematically check array accesses and thus detect the buffer overflow attempt even if the developer failed to include the necessary checks. This does not solve the issue (the problem being that the software still want to do things that make no sense), but at least it contains the damage (the offending process is swiftly killed, and that's the extent of it).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949