Log Overflow

Description

See CWE-400 for a general description.
Related CWEs are CWE-779 CWE-779 and CWE-770
Printing out to a console or logger usually ends up in a text file. If an attacker knows this, and the logging is unrestricted, then attackers can fill up the log file and crash the machine by filling up the hard drive. This is a denial of service attack that is particularly difficult to recover from. Plus, weird things happen when the entire hard drive is completely out of bytes, so attackers can take advantage of this.

Use a properly-configured logging library (e.g. log4j). In configuring your logger, be sure to use rolling log files. These can be rotated on a daily basis, or by size. Be sure to actually test this functionality yourself.
Don’t log so much. Separate out the debugging logs from useful logs. Don’t ship with debugging information turned on.

The Linux kernel has had this issue in a myriad of forms. In CVE-2013-0231, a certain driver was flooding the kernel with messages and the fix was to handle the error another way than just printing a message.

Don’t forget to inspect configuration files! You can have vulnerabilities there too.
Mostly an issue in applications that run on servers, although desktop clients are not immune to this
The disadvantage of this mitigation is that you can potentially lose your logs if they get over-rotated. Attackers can potentially take advantage of this fact by intentionally overflowing the logs to erase the evidence. But other protections, like request limits, can mitigate that problem too.
As a general rule, avoid unlimited hard drive storage (e.g. uploading photos). Sometimes it’s easier to just store images as BLOBS in a database (where the table sizes are often limited by default), as opposed to dealing with the OS directly.

  $ cd log-overflow
  $ make