{"id":5714,"date":"2020-01-21T13:00:10","date_gmt":"2020-01-21T13:00:10","guid":{"rendered":"http:\/\/writeasync.net\/?p=5714"},"modified":"2020-01-19T23:32:18","modified_gmt":"2020-01-19T23:32:18","slug":"lets-do-dhcp-fuzzing","status":"publish","type":"post","link":"https:\/\/writeasync.net\/?p=5714","title":{"rendered":"Let’s do DHCP: fuzzing"},"content":{"rendered":"

The DHCP server project<\/a> is still alive and well. It’s definitely sample code, for demonstration purposes only, and other disclaimers. Even so, it is a technology that processes arbitrary network data, and we ought to worry about malicious input<\/a>. To quote from RFC 1122<\/a>, “assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect.”<\/p>\n

If we want this DHCP server to be robust<\/a>, we cannot allow read operations to result in any undesirable behavior (hangs, crashes, etc.). Note that we will not attempt to protect write<\/strong> operations in the same way; these do not stem from untrusted input, but rather programmer errors (“boneheaded exceptions” in Eric Lippert’s classification<\/a>).<\/p>\n

Let’s start by devising a strategy to detect bad read behavior. Ideally, we want a set of operations which are simple and exhaustive<\/em> — guaranteed to touch all relevant parts of the read buffer. String formatting is a good choice to meet both criteria. As of now, there are four general areas where this would be relevant:<\/p>\n

    \n
  1. The entire DHCP message header<\/li>\n
  2. The entire DHCP options buffer<\/li>\n
  3. DHCP sub-options contained in a DHCP option (e.g. relay agent information<\/a>)<\/li>\n
  4. Data contained within a DHCP sub-option (e.g. RADIUS attributes<\/a>)<\/li>\n<\/ol>\n

    In practice, this results in TryFormat<\/code> methods<\/a> on these data types:<\/p>\n