Replace NTLMv1 implementation with a functionally equivalent one.

net/ntlm/ntlm_client_fuzzer.cc

Index: net/ntlm/ntlm_client_fuzzer.cc
diff --git a/net/ntlm/ntlm_client_fuzzer.cc b/net/ntlm/ntlm_client_fuzzer.cc
new file mode 100644
index 0000000000000000000000000000000000000000..5cae3970189a2837ef84db6acd2c5a1169b67203
--- /dev/null
+++ b/net/ntlm/ntlm_client_fuzzer.cc
@@ -0,0 +1,22 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include <stddef.h>
+#include <stdint.h>
+
+#include "net/ntlm/ntlm_client.h"
+#include "net/ntlm/ntlm_test_data.h"
+
+extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
+  net::ntlm::NtlmClient client;
+
+  // The challenge message is the input to the fuzzer. This data would
+  // normally come from the server. The returned Authenticate message is
+  // ignored.
+  client.GenerateAuthenticateMessage(
+      net::ntlm::test::kNtlmDomain, net::ntlm::test::kUser,
+      net::ntlm::test::kPassword, net::ntlm::test::kHostnameAscii,
+      net::ntlm::test::kClientChallenge, net::ntlm::Buffer(data, size));

[mmenke, 2017/07/20 19:44:50]

Is there any benefit to fuzzing any of the other fields?  Differing challenge
flags in particular may be interesting.

It's pretty easy to split up input - see base::FuzzedDataProvider.  It has a
bunch of options fox fixed-size input.  For variable sized input, 
ConsumeRandomLengthString is the best way (And if some inputs can't possible be
passed in, you can then just check for them and exit the test early, though that
will make the fuzzer explore the space of your input validator, too).

[zentaro, 2017/08/02 15:01:41]

Done.

+  return 0;
+}

[asanka, 2017/07/20 19:39:56]

Given that the library is for explicit credentials, and the credentials
themselves are provided by extensions and other external sources (including URL
embedded credentials currently), we'd need to consider the username/password to
also be possibly unsafe inputs.

As such, we'd need to fuzz the credentials as well in another fuzzer. This one
could respond to a known valid server challenge with fuzzed credentials.

[asanka, 2017/07/20 19:42:24]

If the server is allowed to disable Unicode, then we'd need at least two server
challenges that we can fuzz each credential input against.

[zentaro, 2017/08/02 15:01:41]

Done. I think using the fuzzed data provider covers all the combinations of
challenges (and hence challenge flags) and other inputs.