Avoid using C99 variable length arrays

From an attacker's point of view, a VLA declaration is essentially a primitive for performing arbitrary arithmetic on the stack pointer. If the attacker can control the size of a VLA they have a very powerful tool for causing memory corruption.

To mitigate this kind of attack, and the more general class of stack clash vulnerabilities, C compilers insert extra code when allocating a VLA to probe the growing stack one page at a time. If these probes hit the stack guard page, the program will crash.

From the point of view of a C programmer, there are a few things to consider about VLAs:

• If it is important to handle allocation failures in a controlled manner, don't use VLAs. You can use VLAs if it is OK for unreasonable inputs to cause an uncontrolled crash.

• If the VLA is known to be smaller than some known fixed size, use a fixed size array and a run-time check to ensure it is large enough. This will be more efficient than the compiler's stack probes that need to cope with arbitrary-size VLAs.

• If the VLA might be large, allocate it on the heap. The heap allocator can allocate multiple pages in one shot, whereas the stack clash probes work one page at a time.

Most of the existing uses of VLAs in BIND are in test code, but there is one instance in named, in the GSS-TSIG verification code. In this case the size of the VLA comes from the size of the signature in the request; but it is safe because the code has previously checked that the signature has a reasonable size. However, the safety checks are in the generic TSIG implementation, and the risky VLA usage is in the GSS-specific code, and they are separated by the DST indirection layer, so it wasn't immediately obvious to me that the risky VLA was in fact safe. And in fact this risky VLA is completely unnecessary, because the GSS signature can be verified in place without being copied to the stack.