Browse code

Fix potential null-pointer dereference

Commit a070f75b (master branch only) changed the openvpn_encrypt logic and
now prepends the contents of the work buffer to buf if no encryption is
used (which is the case for tls-auth packets). In that case, the code
would potentially dereference a null-pointer in a memcpy(some-dest, 0, 0)
call. Fortunately, memcpy() inplementations usually do not actually
derefence the src (or dst) pointer for zero-length copies.

And since I'm touching this code now anyway, remove a slightly confusing
jump back to a cleanup label in openvpn_encrypt_aead().

Issue spotted by Daniel Hirche.

Signed-off-by: Steffan Karger <steffan@karger.me>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1459528980-8304-1-git-send-email-steffan@karger.me>
URL: http://article.gmane.org/gmane.network.openvpn.devel/11372
Signed-off-by: Gert Doering <gert@greenie.muc.de>

Steffan Karger authored on 2016/04/02 01:43:00
Showing 1 changed files
... ...
@@ -166,14 +166,14 @@ openvpn_encrypt_aead (struct buffer *buf, struct buffer work,
166 166
 
167 167
   dmsg (D_PACKET_CONTENT, "ENCRYPT TO: %s", format_hex (BPTR (buf), BLEN (buf), 80, &gc));
168 168
 
169
-cleanup:
170 169
   gc_free (&gc);
171 170
   return;
172 171
 
173 172
 err:
174 173
   crypto_clear_error();
175 174
   buf->len = 0;
176
-  goto cleanup;
175
+  gc_free (&gc);
176
+  return;
177 177
 #else /* HAVE_AEAD_CIPHER_MODES */
178 178
   ASSERT (0);
179 179
 #endif
... ...
@@ -295,7 +295,9 @@ openvpn_encrypt_v1 (struct buffer *buf, struct buffer work,
295 295
 	      hmac_start = BPTR(buf);
296 296
 	      ASSERT (mac_out = buf_prepend (buf, hmac_ctx_size(ctx->hmac)));
297 297
 	    }
298
-	  buf_write_prepend(buf, BPTR(&work), BLEN(&work));
298
+	  if (BLEN(&work)) {
299
+	    buf_write_prepend(buf, BPTR(&work), BLEN(&work));
300
+	  }
299 301
 	  work = *buf;
300 302
 	}
301 303