summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRoy Marples <roy@marples.name>2018-04-29 21:28:15 +0100
committerRoy Marples <roy@marples.name>2018-04-29 21:28:15 +0100
commit5b0fec0584b2eda14f9a3ab8c7c18e91c1e7be39 (patch)
treef3ad188a66d533e3bbcc0d32432de3a01c80a593
parentfb0a2abbcdda8eb7cec3ef1f8ae8122ed7296e06 (diff)
downloaddhcpcd-5b0fec0584b2eda14f9a3ab8c7c18e91c1e7be39.tar.xz
auth: allow zero value replay detection data
It seems one ISP doesn't use Replay Data and always sets it to zero. See the comment in the commit as to why this is technically legal, even if it goes against the intent of the RFC.
-rw-r--r--src/auth.c19
1 files changed, 18 insertions, 1 deletions
diff --git a/src/auth.c b/src/auth.c
index be7dd7ad..93e8b774 100644
--- a/src/auth.c
+++ b/src/auth.c
@@ -151,7 +151,24 @@ dhcp_auth_validate(struct authstate *state, const struct auth *auth,
memcpy(&replay, d, sizeof(replay));
replay = ntohll(replay);
- if (state->token) {
+ /*
+ * Test for a replay attack.
+ *
+ * NOTE: Some servers always send a replay data value of zero.
+ * This is strictly compliant with RFC 3315 and 3318 which say:
+ * "If the RDM field contains 0x00, the replay detection field MUST be
+ * set to the value of a monotonically increasing counter."
+ * An example of a monotonically increasing sequence is:
+ * 1, 2, 2, 2, 2, 2, 2
+ * Errata 3474 updates RFC 3318 to say:
+ * "If the RDM field contains 0x00, the replay detection field MUST be
+ * set to the value of a strictly increasing counter."
+ *
+ * Taking the above into account, dhcpcd will only test for
+ * strictly speaking replay attacks if it receives any non zero
+ * replay data to validate against.
+ */
+ if (state->token && state->replay != 0) {
if (state->replay == (replay ^ 0x8000000000000000ULL)) {
/* We don't know if the singular point is increasing
* or decreasing. */