ntlm: Clarify details on NTLM phase 3 decoding

The code was not very clear if we accept the base64 decode if the
NTLM challenge was truncated or not.  Move the related code lines
closer to where buf is first used and comment that we are not concerned
about any truncation.

If the decoded result is truncated, the NTLM server side will reject
our new response to the challenge as it will be incorrect.  The
buffer size is fixed and known to be in a cleared state before the
decode starts.

Resolves: TOB-OVPN-14
Signed-off-by: David Sommerseth <[email protected]>
Acked-by: Gert Doering <[email protected]>
Message-Id: <[email protected]>
URL: https://www.mail-archive.com/[email protected]/msg26919.html
Signed-off-by: Gert Doering <[email protected]>
(cherry picked from commit f193911)

src/openvpn/ntlm.c

@@ -209,7 +209,6 @@ ntlm_phase_3(const struct http_proxy_info *p, const char *phase_2,
      */
 
     char pwbuf[sizeof(p->up.password) * 2]; /* for unicode password */
-    uint8_t buf2[128]; /* decoded reply from proxy */
     uint8_t phase3[464];
 
     uint8_t md4_hash[MD4_DIGEST_LENGTH + 5];
@@ -232,8 +231,6 @@ ntlm_phase_3(const struct http_proxy_info *p, const char *phase_2,
 
     bool ntlmv2_enabled = (p->auth_method == HTTP_AUTH_NTLM2);
 
-    CLEAR(buf2);
-
     ASSERT(strlen(p->up.username) > 0);
     ASSERT(strlen(p->up.password) > 0);
 
@@ -266,6 +263,12 @@ ntlm_phase_3(const struct http_proxy_info *p, const char *phase_2,
     /* pad to 21 bytes */
     memset(md4_hash + MD4_DIGEST_LENGTH, 0, 5);
 
+    /* If the decoded challenge is shorter than required by the protocol,
+     * the missing bytes will be NULL, as buf2 is known to be zeroed
+     * when this decode happens.
+     */
+    uint8_t buf2[128]; /* decoded reply from proxy */
+    CLEAR(buf2);
     ret_val = openvpn_base64_decode(phase_2, buf2, -1);
     if (ret_val < 0)
     {