2021-06-18 05:31:49 +00:00
|
|
|
// SPDX-License-Identifier: LGPL-2.1
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
*
|
2015-03-30 21:58:17 +00:00
|
|
|
* Encryption and hashing operations relating to NTLM, NTLMv2. See MS-NLMP
|
|
|
|
* for more detailed information
|
|
|
|
*
|
2013-07-04 15:35:21 +00:00
|
|
|
* Copyright (C) International Business Machines Corp., 2005,2013
|
2005-04-16 22:20:36 +00:00
|
|
|
* Author(s): Steve French (sfrench@us.ibm.com)
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/fs.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "cifspdu.h"
|
2007-06-24 21:15:44 +00:00
|
|
|
#include "cifsglob.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "cifs_debug.h"
|
|
|
|
#include "cifs_unicode.h"
|
|
|
|
#include "cifsproto.h"
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
#include "ntlmssp.h"
|
2006-06-01 19:20:10 +00:00
|
|
|
#include <linux/ctype.h>
|
2006-06-05 16:26:05 +00:00
|
|
|
#include <linux/random.h>
|
2012-09-18 23:20:35 +00:00
|
|
|
#include <linux/highmem.h>
|
2019-06-12 16:19:59 +00:00
|
|
|
#include <linux/fips.h>
|
2021-09-09 04:59:26 +00:00
|
|
|
#include "../smbfs_common/arc4.h"
|
2016-11-03 23:47:37 +00:00
|
|
|
#include <crypto/aead.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-11-13 03:46:49 +00:00
|
|
|
int __cifs_calc_signature(struct smb_rqst *rqst,
|
|
|
|
struct TCP_Server_Info *server, char *signature,
|
|
|
|
struct shash_desc *shash)
|
2005-12-02 21:32:45 +00:00
|
|
|
{
|
2006-03-31 21:22:00 +00:00
|
|
|
int i;
|
2010-10-21 19:25:17 +00:00
|
|
|
int rc;
|
2012-09-18 23:20:34 +00:00
|
|
|
struct kvec *iov = rqst->rq_iov;
|
|
|
|
int n_vec = rqst->rq_nvec;
|
2018-06-11 22:00:58 +00:00
|
|
|
int is_smb2 = server->vals->header_preamble_size == 0;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2018-06-11 22:00:58 +00:00
|
|
|
/* iov[0] is actual data and not the rfc1002 length for SMB2+ */
|
|
|
|
if (is_smb2) {
|
2018-06-15 18:58:00 +00:00
|
|
|
if (iov[0].iov_len <= 4)
|
|
|
|
return -EIO;
|
|
|
|
i = 0;
|
2018-06-11 22:00:58 +00:00
|
|
|
} else {
|
|
|
|
if (n_vec < 2 || iov[0].iov_len != 4)
|
|
|
|
return -EIO;
|
2018-06-15 18:58:00 +00:00
|
|
|
i = 1; /* skip rfc1002 length */
|
2018-06-11 22:00:58 +00:00
|
|
|
}
|
|
|
|
|
2018-06-15 18:58:00 +00:00
|
|
|
for (; i < n_vec; i++) {
|
2007-11-03 04:34:04 +00:00
|
|
|
if (iov[i].iov_len == 0)
|
|
|
|
continue;
|
2007-06-24 21:15:44 +00:00
|
|
|
if (iov[i].iov_base == NULL) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "null iovec entry\n");
|
2006-03-31 21:22:00 +00:00
|
|
|
return -EIO;
|
2007-11-03 04:34:04 +00:00
|
|
|
}
|
2018-06-15 18:58:00 +00:00
|
|
|
|
2016-11-23 23:14:57 +00:00
|
|
|
rc = crypto_shash_update(shash,
|
|
|
|
iov[i].iov_base, iov[i].iov_len);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not update with payload\n",
|
|
|
|
__func__);
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2006-03-31 21:22:00 +00:00
|
|
|
}
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2012-09-18 23:20:35 +00:00
|
|
|
/* now hash over the rq_pages array */
|
|
|
|
for (i = 0; i < rqst->rq_npages; i++) {
|
2018-05-30 19:48:03 +00:00
|
|
|
void *kaddr;
|
|
|
|
unsigned int len, offset;
|
2015-11-13 03:46:49 +00:00
|
|
|
|
2018-05-30 19:48:03 +00:00
|
|
|
rqst_page_get_length(rqst, i, &len, &offset);
|
|
|
|
|
|
|
|
kaddr = (char *) kmap(rqst->rq_pages[i]) + offset;
|
2015-11-13 03:46:49 +00:00
|
|
|
|
2018-06-23 17:52:25 +00:00
|
|
|
rc = crypto_shash_update(shash, kaddr, len);
|
|
|
|
if (rc) {
|
|
|
|
cifs_dbg(VFS, "%s: Could not update with payload\n",
|
|
|
|
__func__);
|
|
|
|
kunmap(rqst->rq_pages[i]);
|
|
|
|
return rc;
|
|
|
|
}
|
2012-09-18 23:20:35 +00:00
|
|
|
|
|
|
|
kunmap(rqst->rq_pages[i]);
|
|
|
|
}
|
|
|
|
|
2015-11-13 03:46:49 +00:00
|
|
|
rc = crypto_shash_final(shash, signature);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc)
|
2015-11-13 03:46:49 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not generate hash\n", __func__);
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2010-10-21 19:25:17 +00:00
|
|
|
return rc;
|
2005-12-02 21:32:45 +00:00
|
|
|
}
|
|
|
|
|
2015-11-13 03:46:49 +00:00
|
|
|
/*
|
|
|
|
* Calculate and return the CIFS signature based on the mac key and SMB PDU.
|
|
|
|
* The 16 byte signature must be allocated by the caller. Note we only use the
|
|
|
|
* 1st eight bytes and that the smb header signature field on input contains
|
|
|
|
* the sequence number before this function is called. Also, this function
|
|
|
|
* should be called with the server->srv_mutex held.
|
|
|
|
*/
|
|
|
|
static int cifs_calc_signature(struct smb_rqst *rqst,
|
|
|
|
struct TCP_Server_Info *server, char *signature)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (!rqst->rq_iov || !signature || !server)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-02-16 18:19:27 +00:00
|
|
|
rc = cifs_alloc_hash("md5", &server->secmech.md5,
|
|
|
|
&server->secmech.sdescmd5);
|
|
|
|
if (rc)
|
|
|
|
return -1;
|
2015-11-13 03:46:49 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_init(&server->secmech.sdescmd5->shash);
|
|
|
|
if (rc) {
|
|
|
|
cifs_dbg(VFS, "%s: Could not init md5\n", __func__);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = crypto_shash_update(&server->secmech.sdescmd5->shash,
|
|
|
|
server->session_key.response, server->session_key.len);
|
|
|
|
if (rc) {
|
|
|
|
cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2018-06-11 22:00:58 +00:00
|
|
|
return __cifs_calc_signature(rqst, server, signature,
|
2015-11-13 03:46:49 +00:00
|
|
|
&server->secmech.sdescmd5->shash);
|
|
|
|
}
|
|
|
|
|
2011-01-07 16:30:28 +00:00
|
|
|
/* must be called with server->srv_mutex held */
|
2012-09-18 23:20:34 +00:00
|
|
|
int cifs_sign_rqst(struct smb_rqst *rqst, struct TCP_Server_Info *server,
|
2007-11-05 21:46:10 +00:00
|
|
|
__u32 *pexpected_response_sequence_number)
|
2005-12-02 21:32:45 +00:00
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
char smb_signature[20];
|
2012-09-18 23:20:34 +00:00
|
|
|
struct smb_hdr *cifs_pdu = (struct smb_hdr *)rqst->rq_iov[0].iov_base;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2016-11-23 23:14:57 +00:00
|
|
|
if (rqst->rq_iov[0].iov_len != 4 ||
|
|
|
|
rqst->rq_iov[0].iov_base + 4 != rqst->rq_iov[1].iov_base)
|
|
|
|
return -EIO;
|
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
if ((cifs_pdu == NULL) || (server == NULL))
|
2005-12-02 21:32:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2011-07-26 16:21:17 +00:00
|
|
|
if (!(cifs_pdu->Flags2 & SMBFLG2_SECURITY_SIGNATURE) ||
|
|
|
|
server->tcpStatus == CifsNeedNegotiate)
|
2005-12-02 21:32:45 +00:00
|
|
|
return rc;
|
|
|
|
|
2011-07-26 16:21:17 +00:00
|
|
|
if (!server->session_estab) {
|
2011-10-11 10:41:32 +00:00
|
|
|
memcpy(cifs_pdu->Signature.SecuritySignature, "BSRSPYL", 8);
|
2011-07-26 16:21:17 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
cifs_pdu->Signature.Sequence.SequenceNumber =
|
2005-12-02 21:32:45 +00:00
|
|
|
cpu_to_le32(server->sequence_number);
|
2007-06-24 21:15:44 +00:00
|
|
|
cifs_pdu->Signature.Sequence.Reserved = 0;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2013-04-03 15:55:03 +00:00
|
|
|
*pexpected_response_sequence_number = ++server->sequence_number;
|
|
|
|
++server->sequence_number;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2012-09-18 23:20:34 +00:00
|
|
|
rc = cifs_calc_signature(rqst, server, smb_signature);
|
2007-06-24 21:15:44 +00:00
|
|
|
if (rc)
|
|
|
|
memset(cifs_pdu->Signature.SecuritySignature, 0, 8);
|
|
|
|
else
|
|
|
|
memcpy(cifs_pdu->Signature.SecuritySignature, smb_signature, 8);
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
return rc;
|
2005-12-02 21:32:45 +00:00
|
|
|
}
|
|
|
|
|
2012-09-18 23:20:34 +00:00
|
|
|
int cifs_sign_smbv(struct kvec *iov, int n_vec, struct TCP_Server_Info *server,
|
|
|
|
__u32 *pexpected_response_sequence)
|
|
|
|
{
|
|
|
|
struct smb_rqst rqst = { .rq_iov = iov,
|
|
|
|
.rq_nvec = n_vec };
|
|
|
|
|
|
|
|
return cifs_sign_rqst(&rqst, server, pexpected_response_sequence);
|
|
|
|
}
|
|
|
|
|
2011-10-11 10:41:32 +00:00
|
|
|
/* must be called with server->srv_mutex held */
|
|
|
|
int cifs_sign_smb(struct smb_hdr *cifs_pdu, struct TCP_Server_Info *server,
|
|
|
|
__u32 *pexpected_response_sequence_number)
|
|
|
|
{
|
2016-11-23 23:14:57 +00:00
|
|
|
struct kvec iov[2];
|
2011-10-11 10:41:32 +00:00
|
|
|
|
2016-11-23 23:14:57 +00:00
|
|
|
iov[0].iov_base = cifs_pdu;
|
|
|
|
iov[0].iov_len = 4;
|
|
|
|
iov[1].iov_base = (char *)cifs_pdu + 4;
|
|
|
|
iov[1].iov_len = be32_to_cpu(cifs_pdu->smb_buf_length);
|
2011-10-11 10:41:32 +00:00
|
|
|
|
2016-11-23 23:14:57 +00:00
|
|
|
return cifs_sign_smbv(iov, 2, server,
|
2011-10-11 10:41:32 +00:00
|
|
|
pexpected_response_sequence_number);
|
|
|
|
}
|
|
|
|
|
2012-09-18 23:20:34 +00:00
|
|
|
int cifs_verify_signature(struct smb_rqst *rqst,
|
2010-10-21 11:42:55 +00:00
|
|
|
struct TCP_Server_Info *server,
|
2007-06-24 21:15:44 +00:00
|
|
|
__u32 expected_sequence_number)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-09-08 21:10:58 +00:00
|
|
|
unsigned int rc;
|
2005-04-16 22:20:36 +00:00
|
|
|
char server_response_sig[8];
|
|
|
|
char what_we_think_sig_should_be[20];
|
2012-09-18 23:20:34 +00:00
|
|
|
struct smb_hdr *cifs_pdu = (struct smb_hdr *)rqst->rq_iov[0].iov_base;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-11-23 23:14:57 +00:00
|
|
|
if (rqst->rq_iov[0].iov_len != 4 ||
|
|
|
|
rqst->rq_iov[0].iov_base + 4 != rqst->rq_iov[1].iov_base)
|
|
|
|
return -EIO;
|
|
|
|
|
2010-10-21 11:42:55 +00:00
|
|
|
if (cifs_pdu == NULL || server == NULL)
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2011-06-06 19:40:23 +00:00
|
|
|
if (!server->session_estab)
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (cifs_pdu->Command == SMB_COM_LOCKING_ANDX) {
|
2007-07-13 00:33:32 +00:00
|
|
|
struct smb_com_lock_req *pSMB =
|
2007-06-24 21:15:44 +00:00
|
|
|
(struct smb_com_lock_req *)cifs_pdu;
|
2018-11-03 15:59:44 +00:00
|
|
|
if (pSMB->LockType & LOCKING_ANDX_OPLOCK_RELEASE)
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
/* BB what if signatures are supposed to be on for session but
|
|
|
|
server does not send one? BB */
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Do not need to verify session setups with signature "BSRSPYL " */
|
2007-07-13 00:33:32 +00:00
|
|
|
if (memcmp(cifs_pdu->Signature.SecuritySignature, "BSRSPYL ", 8) == 0)
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(FYI, "dummy signature received for smb command 0x%x\n",
|
|
|
|
cifs_pdu->Command);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* save off the origiginal signature so we can modify the smb and check
|
|
|
|
its signature against what the server sent */
|
2007-07-13 00:33:32 +00:00
|
|
|
memcpy(server_response_sig, cifs_pdu->Signature.SecuritySignature, 8);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
cifs_pdu->Signature.Sequence.SequenceNumber =
|
|
|
|
cpu_to_le32(expected_sequence_number);
|
2005-04-16 22:20:36 +00:00
|
|
|
cifs_pdu->Signature.Sequence.Reserved = 0;
|
|
|
|
|
2011-04-02 11:34:30 +00:00
|
|
|
mutex_lock(&server->srv_mutex);
|
2012-09-18 23:20:34 +00:00
|
|
|
rc = cifs_calc_signature(rqst, server, what_we_think_sig_should_be);
|
2011-04-02 11:34:30 +00:00
|
|
|
mutex_unlock(&server->srv_mutex);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
if (rc)
|
2005-04-16 22:20:36 +00:00
|
|
|
return rc;
|
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
/* cifs_dump_mem("what we think it should be: ",
|
|
|
|
what_we_think_sig_should_be, 16); */
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
if (memcmp(server_response_sig, what_we_think_sig_should_be, 8))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EACCES;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2010-10-10 18:21:05 +00:00
|
|
|
/* Build a proper attribute value/target info pairs blob.
|
|
|
|
* Fill in netbios and dns domain name and workstation name
|
|
|
|
* and client time (total five av pairs and + one end of fields indicator.
|
|
|
|
* Allocate domain name which gets freed when session struct is deallocated.
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
*/
|
|
|
|
static int
|
2011-05-27 04:34:02 +00:00
|
|
|
build_avpair_blob(struct cifs_ses *ses, const struct nls_table *nls_cp)
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
{
|
2010-10-10 18:21:05 +00:00
|
|
|
unsigned int dlen;
|
cifs: Fix broken sec=ntlmv2/i sec option (try #2)
Fix sec=ntlmv2/i authentication option during mount of Samba shares.
cifs client was coding ntlmv2 response incorrectly.
All that is needed in temp as specified in MS-NLMP seciton 3.3.2
"Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,
CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)
as
Set temp to ConcatenationOf(Responserversion, HiResponserversion,
Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)"
is MsvAvNbDomainName.
For sec=ntlmsspi, build_av_pair is not used, a blob is plucked from
type 2 response sent by the server to use in authentication.
I tested sec=ntlmv2/i and sec=ntlmssp/i mount options against
Samba (3.6) and Windows - XP, 2003 Server and 7.
They all worked.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-08-25 04:05:46 +00:00
|
|
|
unsigned int size = 2 * sizeof(struct ntlmssp2_name);
|
2010-10-10 18:21:05 +00:00
|
|
|
char *defdmname = "WORKGROUP";
|
|
|
|
unsigned char *blobptr;
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
struct ntlmssp2_name *attrptr;
|
|
|
|
|
2010-10-10 18:21:05 +00:00
|
|
|
if (!ses->domainName) {
|
|
|
|
ses->domainName = kstrdup(defdmname, GFP_KERNEL);
|
|
|
|
if (!ses->domainName)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
dlen = strlen(ses->domainName);
|
|
|
|
|
cifs: Fix broken sec=ntlmv2/i sec option (try #2)
Fix sec=ntlmv2/i authentication option during mount of Samba shares.
cifs client was coding ntlmv2 response incorrectly.
All that is needed in temp as specified in MS-NLMP seciton 3.3.2
"Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,
CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)
as
Set temp to ConcatenationOf(Responserversion, HiResponserversion,
Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)"
is MsvAvNbDomainName.
For sec=ntlmsspi, build_av_pair is not used, a blob is plucked from
type 2 response sent by the server to use in authentication.
I tested sec=ntlmv2/i and sec=ntlmssp/i mount options against
Samba (3.6) and Windows - XP, 2003 Server and 7.
They all worked.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-08-25 04:05:46 +00:00
|
|
|
/*
|
|
|
|
* The length of this blob is two times the size of a
|
|
|
|
* structure (av pair) which holds name/size
|
|
|
|
* ( for NTLMSSP_AV_NB_DOMAIN_NAME followed by NTLMSSP_AV_EOL ) +
|
|
|
|
* unicode length of a netbios domain name
|
2010-10-10 18:21:05 +00:00
|
|
|
*/
|
cifs: Fix broken sec=ntlmv2/i sec option (try #2)
Fix sec=ntlmv2/i authentication option during mount of Samba shares.
cifs client was coding ntlmv2 response incorrectly.
All that is needed in temp as specified in MS-NLMP seciton 3.3.2
"Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,
CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)
as
Set temp to ConcatenationOf(Responserversion, HiResponserversion,
Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)"
is MsvAvNbDomainName.
For sec=ntlmsspi, build_av_pair is not used, a blob is plucked from
type 2 response sent by the server to use in authentication.
I tested sec=ntlmv2/i and sec=ntlmssp/i mount options against
Samba (3.6) and Windows - XP, 2003 Server and 7.
They all worked.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-08-25 04:05:46 +00:00
|
|
|
ses->auth_key.len = size + 2 * dlen;
|
2010-10-28 14:53:07 +00:00
|
|
|
ses->auth_key.response = kzalloc(ses->auth_key.len, GFP_KERNEL);
|
|
|
|
if (!ses->auth_key.response) {
|
|
|
|
ses->auth_key.len = 0;
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2010-10-10 18:21:05 +00:00
|
|
|
|
2010-10-28 14:53:07 +00:00
|
|
|
blobptr = ses->auth_key.response;
|
2010-10-10 18:21:05 +00:00
|
|
|
attrptr = (struct ntlmssp2_name *) blobptr;
|
|
|
|
|
cifs: Fix broken sec=ntlmv2/i sec option (try #2)
Fix sec=ntlmv2/i authentication option during mount of Samba shares.
cifs client was coding ntlmv2 response incorrectly.
All that is needed in temp as specified in MS-NLMP seciton 3.3.2
"Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,
CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)
as
Set temp to ConcatenationOf(Responserversion, HiResponserversion,
Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)"
is MsvAvNbDomainName.
For sec=ntlmsspi, build_av_pair is not used, a blob is plucked from
type 2 response sent by the server to use in authentication.
I tested sec=ntlmv2/i and sec=ntlmssp/i mount options against
Samba (3.6) and Windows - XP, 2003 Server and 7.
They all worked.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-08-25 04:05:46 +00:00
|
|
|
/*
|
|
|
|
* As defined in MS-NTLM 3.3.2, just this av pair field
|
|
|
|
* is sufficient as part of the temp
|
|
|
|
*/
|
2010-10-10 18:21:05 +00:00
|
|
|
attrptr->type = cpu_to_le16(NTLMSSP_AV_NB_DOMAIN_NAME);
|
|
|
|
attrptr->length = cpu_to_le16(2 * dlen);
|
|
|
|
blobptr = (unsigned char *)attrptr + sizeof(struct ntlmssp2_name);
|
2012-01-19 04:32:33 +00:00
|
|
|
cifs_strtoUTF16((__le16 *)blobptr, ses->domainName, dlen, nls_cp);
|
2010-10-10 18:21:05 +00:00
|
|
|
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Server has provided av pairs/target info in the type 2 challenge
|
|
|
|
* packet and we have plucked it and stored within smb session.
|
|
|
|
* We parse that blob here to find netbios domain name to be used
|
|
|
|
* as part of ntlmv2 authentication (in Target String), if not already
|
|
|
|
* specified on the command line.
|
|
|
|
* If this function returns without any error but without fetching
|
|
|
|
* domain name, authentication may fail against some server but
|
|
|
|
* may not fail against other (those who are not very particular
|
|
|
|
* about target string i.e. for some, just user name might suffice.
|
|
|
|
*/
|
|
|
|
static int
|
2011-05-27 04:34:02 +00:00
|
|
|
find_domain_name(struct cifs_ses *ses, const struct nls_table *nls_cp)
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
{
|
|
|
|
unsigned int attrsize;
|
|
|
|
unsigned int type;
|
|
|
|
unsigned int onesize = sizeof(struct ntlmssp2_name);
|
|
|
|
unsigned char *blobptr;
|
|
|
|
unsigned char *blobend;
|
|
|
|
struct ntlmssp2_name *attrptr;
|
|
|
|
|
2010-10-28 14:53:07 +00:00
|
|
|
if (!ses->auth_key.len || !ses->auth_key.response)
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
return 0;
|
|
|
|
|
2010-10-28 14:53:07 +00:00
|
|
|
blobptr = ses->auth_key.response;
|
|
|
|
blobend = blobptr + ses->auth_key.len;
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
|
|
|
|
while (blobptr + onesize < blobend) {
|
|
|
|
attrptr = (struct ntlmssp2_name *) blobptr;
|
|
|
|
type = le16_to_cpu(attrptr->type);
|
|
|
|
if (type == NTLMSSP_AV_EOL)
|
|
|
|
break;
|
|
|
|
blobptr += 2; /* advance attr type */
|
|
|
|
attrsize = le16_to_cpu(attrptr->length);
|
|
|
|
blobptr += 2; /* advance attr size */
|
|
|
|
if (blobptr + attrsize > blobend)
|
|
|
|
break;
|
|
|
|
if (type == NTLMSSP_AV_NB_DOMAIN_NAME) {
|
2013-07-19 01:01:36 +00:00
|
|
|
if (!attrsize || attrsize >= CIFS_MAX_DOMAINNAME_LEN)
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
break;
|
|
|
|
if (!ses->domainName) {
|
|
|
|
ses->domainName =
|
|
|
|
kmalloc(attrsize + 1, GFP_KERNEL);
|
|
|
|
if (!ses->domainName)
|
|
|
|
return -ENOMEM;
|
2012-01-19 04:32:33 +00:00
|
|
|
cifs_from_utf16(ses->domainName,
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
(__le16 *)blobptr, attrsize, attrsize,
|
2014-09-25 18:20:05 +00:00
|
|
|
nls_cp, NO_MAP_UNI_RSVD);
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
blobptr += attrsize; /* advance attr value */
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-09-17 19:40:12 +00:00
|
|
|
/* Server has provided av pairs/target info in the type 2 challenge
|
|
|
|
* packet and we have plucked it and stored within smb session.
|
|
|
|
* We parse that blob here to find the server given timestamp
|
|
|
|
* as part of ntlmv2 authentication (or local current time as
|
|
|
|
* default in case of failure)
|
|
|
|
*/
|
|
|
|
static __le64
|
|
|
|
find_timestamp(struct cifs_ses *ses)
|
|
|
|
{
|
|
|
|
unsigned int attrsize;
|
|
|
|
unsigned int type;
|
|
|
|
unsigned int onesize = sizeof(struct ntlmssp2_name);
|
|
|
|
unsigned char *blobptr;
|
|
|
|
unsigned char *blobend;
|
|
|
|
struct ntlmssp2_name *attrptr;
|
2018-06-19 15:27:58 +00:00
|
|
|
struct timespec64 ts;
|
2015-09-17 19:40:12 +00:00
|
|
|
|
|
|
|
if (!ses->auth_key.len || !ses->auth_key.response)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
blobptr = ses->auth_key.response;
|
|
|
|
blobend = blobptr + ses->auth_key.len;
|
|
|
|
|
|
|
|
while (blobptr + onesize < blobend) {
|
|
|
|
attrptr = (struct ntlmssp2_name *) blobptr;
|
|
|
|
type = le16_to_cpu(attrptr->type);
|
|
|
|
if (type == NTLMSSP_AV_EOL)
|
|
|
|
break;
|
|
|
|
blobptr += 2; /* advance attr type */
|
|
|
|
attrsize = le16_to_cpu(attrptr->length);
|
|
|
|
blobptr += 2; /* advance attr size */
|
|
|
|
if (blobptr + attrsize > blobend)
|
|
|
|
break;
|
|
|
|
if (type == NTLMSSP_AV_TIMESTAMP) {
|
|
|
|
if (attrsize == sizeof(u64))
|
|
|
|
return *((__le64 *)blobptr);
|
|
|
|
}
|
|
|
|
blobptr += attrsize; /* advance attr value */
|
|
|
|
}
|
|
|
|
|
2018-06-19 15:27:58 +00:00
|
|
|
ktime_get_real_ts64(&ts);
|
2017-05-08 22:59:16 +00:00
|
|
|
return cpu_to_le64(cifs_UnixTimeToNT(ts));
|
2015-09-17 19:40:12 +00:00
|
|
|
}
|
|
|
|
|
2011-05-27 04:34:02 +00:00
|
|
|
static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash,
|
2007-07-13 00:33:32 +00:00
|
|
|
const struct nls_table *nls_cp)
|
2006-06-05 23:34:19 +00:00
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
int len;
|
2010-10-21 19:25:17 +00:00
|
|
|
char nt_hash[CIFS_NTHASH_SIZE];
|
2013-06-25 19:03:16 +00:00
|
|
|
__le16 *user;
|
2007-07-13 00:33:32 +00:00
|
|
|
wchar_t *domain;
|
2010-10-21 19:25:17 +00:00
|
|
|
wchar_t *server;
|
2006-06-05 23:34:19 +00:00
|
|
|
|
2010-10-21 19:25:17 +00:00
|
|
|
if (!ses->server->secmech.sdeschmacmd5) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: can't generate ntlmv2 hash\n", __func__);
|
2010-10-21 19:25:17 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2010-09-08 20:57:05 +00:00
|
|
|
|
2010-09-08 21:10:58 +00:00
|
|
|
/* calculate md4 hash of password */
|
2011-10-20 18:21:59 +00:00
|
|
|
E_md4hash(ses->password, nt_hash, nls_cp);
|
2010-08-20 20:42:26 +00:00
|
|
|
|
2011-06-20 21:14:03 +00:00
|
|
|
rc = crypto_shash_setkey(ses->server->secmech.hmacmd5, nt_hash,
|
2010-10-21 19:25:17 +00:00
|
|
|
CIFS_NTHASH_SIZE);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not set NT Hash as a key\n", __func__);
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_init(&ses->server->secmech.sdeschmacmd5->shash);
|
|
|
|
if (rc) {
|
2020-04-15 05:42:53 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not init hmacmd5\n", __func__);
|
2010-10-21 19:25:17 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2006-06-05 23:34:19 +00:00
|
|
|
|
2013-06-25 19:03:16 +00:00
|
|
|
/* convert ses->user_name to unicode */
|
2012-01-17 21:09:15 +00:00
|
|
|
len = ses->user_name ? strlen(ses->user_name) : 0;
|
2006-06-08 05:41:32 +00:00
|
|
|
user = kmalloc(2 + (len * 2), GFP_KERNEL);
|
2010-10-21 19:25:17 +00:00
|
|
|
if (user == NULL) {
|
|
|
|
rc = -ENOMEM;
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
2010-10-21 19:25:17 +00:00
|
|
|
}
|
2012-01-17 21:09:15 +00:00
|
|
|
|
|
|
|
if (len) {
|
2013-06-25 19:03:16 +00:00
|
|
|
len = cifs_strtoUTF16(user, ses->user_name, len, nls_cp);
|
2012-01-17 21:09:15 +00:00
|
|
|
UniStrupr(user);
|
|
|
|
} else {
|
|
|
|
memset(user, '\0', 2);
|
|
|
|
}
|
2010-10-21 19:25:17 +00:00
|
|
|
|
2011-06-20 21:14:03 +00:00
|
|
|
rc = crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
2010-10-21 19:25:17 +00:00
|
|
|
(char *)user, 2 * len);
|
2011-06-20 21:14:03 +00:00
|
|
|
kfree(user);
|
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not update with user\n", __func__);
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2006-06-05 23:34:19 +00:00
|
|
|
|
|
|
|
/* convert ses->domainName to unicode and uppercase */
|
2007-07-13 00:33:32 +00:00
|
|
|
if (ses->domainName) {
|
2006-06-08 05:41:32 +00:00
|
|
|
len = strlen(ses->domainName);
|
2006-06-05 23:34:19 +00:00
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
domain = kmalloc(2 + (len * 2), GFP_KERNEL);
|
2010-10-21 19:25:17 +00:00
|
|
|
if (domain == NULL) {
|
|
|
|
rc = -ENOMEM;
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
2010-10-21 19:25:17 +00:00
|
|
|
}
|
2012-01-19 04:32:33 +00:00
|
|
|
len = cifs_strtoUTF16((__le16 *)domain, ses->domainName, len,
|
|
|
|
nls_cp);
|
2011-06-20 21:14:03 +00:00
|
|
|
rc =
|
2010-10-21 19:25:17 +00:00
|
|
|
crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
(char *)domain, 2 * len);
|
2006-06-08 05:41:32 +00:00
|
|
|
kfree(domain);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not update with domain\n",
|
|
|
|
__func__);
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2015-03-30 21:58:17 +00:00
|
|
|
} else {
|
2021-02-21 01:24:11 +00:00
|
|
|
/* We use ses->ip_addr if no domain name available */
|
|
|
|
len = strlen(ses->ip_addr);
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
server = kmalloc(2 + (len * 2), GFP_KERNEL);
|
|
|
|
if (server == NULL) {
|
|
|
|
rc = -ENOMEM;
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
2010-10-21 19:25:17 +00:00
|
|
|
}
|
2021-02-21 01:24:11 +00:00
|
|
|
len = cifs_strtoUTF16((__le16 *)server, ses->ip_addr, len,
|
2010-10-21 19:25:17 +00:00
|
|
|
nls_cp);
|
2011-06-20 21:14:03 +00:00
|
|
|
rc =
|
2010-10-21 19:25:17 +00:00
|
|
|
crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
(char *)server, 2 * len);
|
|
|
|
kfree(server);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not update with server\n",
|
|
|
|
__func__);
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2006-06-08 05:41:32 +00:00
|
|
|
}
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
|
2010-10-28 14:53:07 +00:00
|
|
|
ntlmv2_hash);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc)
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-05-27 04:34:02 +00:00
|
|
|
CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
|
2010-10-21 19:25:17 +00:00
|
|
|
{
|
|
|
|
int rc;
|
2013-11-07 23:40:57 +00:00
|
|
|
struct ntlmv2_resp *ntlmv2 = (struct ntlmv2_resp *)
|
|
|
|
(ses->auth_key.response + CIFS_SESS_KEY_SIZE);
|
|
|
|
unsigned int hash_len;
|
|
|
|
|
|
|
|
/* The MD5 hash starts at challenge_key.key */
|
|
|
|
hash_len = ses->auth_key.len - (CIFS_SESS_KEY_SIZE +
|
|
|
|
offsetof(struct ntlmv2_resp, challenge.key[0]));
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
if (!ses->server->secmech.sdeschmacmd5) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: can't generate ntlmv2 hash\n", __func__);
|
2010-10-21 19:25:17 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2011-06-20 21:14:03 +00:00
|
|
|
rc = crypto_shash_setkey(ses->server->secmech.hmacmd5,
|
2013-11-07 23:40:57 +00:00
|
|
|
ntlmv2_hash, CIFS_HMAC_MD5_HASH_SIZE);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not set NTLMV2 Hash as a key\n",
|
|
|
|
__func__);
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_init(&ses->server->secmech.sdeschmacmd5->shash);
|
|
|
|
if (rc) {
|
2020-04-15 05:42:53 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not init hmacmd5\n", __func__);
|
2010-10-21 19:25:17 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2013-06-13 00:52:14 +00:00
|
|
|
if (ses->server->negflavor == CIFS_NEGFLAVOR_EXTENDED)
|
2013-11-07 23:40:57 +00:00
|
|
|
memcpy(ntlmv2->challenge.key,
|
|
|
|
ses->ntlmssp->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
|
2010-10-27 20:20:36 +00:00
|
|
|
else
|
2013-11-07 23:40:57 +00:00
|
|
|
memcpy(ntlmv2->challenge.key,
|
|
|
|
ses->server->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
|
2011-06-20 21:14:03 +00:00
|
|
|
rc = crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
2013-11-07 23:40:57 +00:00
|
|
|
ntlmv2->challenge.key, hash_len);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
|
2011-06-20 21:14:03 +00:00
|
|
|
return rc;
|
|
|
|
}
|
2010-10-21 19:25:17 +00:00
|
|
|
|
2013-11-07 23:40:57 +00:00
|
|
|
/* Note that the MD5 digest over writes anon.challenge_key.key */
|
2010-10-21 19:25:17 +00:00
|
|
|
rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
|
2013-11-07 23:40:57 +00:00
|
|
|
ntlmv2->ntlmv2_hash);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc)
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
|
2010-08-20 20:42:26 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
int
|
2011-05-27 04:34:02 +00:00
|
|
|
setup_ntlmv2_rsp(struct cifs_ses *ses, const struct nls_table *nls_cp)
|
2010-08-20 20:42:26 +00:00
|
|
|
{
|
2010-09-08 21:10:58 +00:00
|
|
|
int rc;
|
2010-10-21 11:42:55 +00:00
|
|
|
int baselen;
|
2010-10-28 14:53:07 +00:00
|
|
|
unsigned int tilen;
|
2013-11-07 23:40:57 +00:00
|
|
|
struct ntlmv2_resp *ntlmv2;
|
2010-10-28 14:53:07 +00:00
|
|
|
char ntlmv2_hash[16];
|
|
|
|
unsigned char *tiblob = NULL; /* target info blob */
|
2015-09-17 19:40:12 +00:00
|
|
|
__le64 rsp_timestamp;
|
2006-06-05 16:26:05 +00:00
|
|
|
|
2020-12-10 06:06:02 +00:00
|
|
|
if (nls_cp == NULL) {
|
|
|
|
cifs_dbg(VFS, "%s called with nls_cp==NULL\n", __func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-06-13 00:52:14 +00:00
|
|
|
if (ses->server->negflavor == CIFS_NEGFLAVOR_EXTENDED) {
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
if (!ses->domainName) {
|
Fix default behaviour for empty domains and add domainauto option
With commit 2b149f119 many things have been fixed/introduced.
However, the default behaviour for RawNTLMSSP authentication
seems to be wrong in case the domain is not passed on the command line.
The main points (see below) of the patch are:
- It alignes behaviour with Windows clients
- It fixes backward compatibility
- It fixes UPN
I compared this behavour with the one from a Windows 10 command line
client. When no domains are specified on the command line, I traced
the packets and observed that the client does send an empty
domain to the server.
In the linux kernel case, the empty domain is replaced by the
primary domain communicated by the SMB server.
This means that, if the credentials are valid against the local server
but that server is part of a domain, then the kernel module will
ask to authenticate against that domain and we will get LOGON failure.
I compared the packet trace from the smbclient when no domain is passed
and, in that case, a default domain from the client smb.conf is taken.
Apparently, connection succeeds anyway, because when the domain passed
is not valid (in my case WORKGROUP), then the local one is tried and
authentication succeeds. I tried with any kind of invalid domain and
the result was always a connection.
So, trying to interpret what to do and picking a valid domain if none
is passed, seems the wrong thing to do.
To this end, a new option "domainauto" has been added in case the
user wants a mechanism for guessing.
Without this patch, backward compatibility also is broken.
With kernel 3.10, the default auth mechanism was NTLM.
One of our testing servers accepted NTLM and, because no
domains are passed, authentication was local.
Moving to RawNTLMSSP forced us to change our command line
to add a fake domain to pass to prevent this mechanism to kick in.
For the same reasons, UPN is broken because the domain is specified
in the username.
The SMB server will work out the domain from the UPN and authenticate
against the right server.
Without the patch, though, given the domain is empty, it gets replaced
with another domain that could be the wrong one for the authentication.
Signed-off-by: Germano Percossi <germano.percossi@citrix.com>
Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <smfrench@gmail.com>
2016-12-15 07:01:18 +00:00
|
|
|
if (ses->domainAuto) {
|
|
|
|
rc = find_domain_name(ses, nls_cp);
|
|
|
|
if (rc) {
|
|
|
|
cifs_dbg(VFS, "error %d finding domain name\n",
|
|
|
|
rc);
|
|
|
|
goto setup_ntlmv2_rsp_ret;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ses->domainName = kstrdup("", GFP_KERNEL);
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
2010-10-10 18:21:05 +00:00
|
|
|
rc = build_avpair_blob(ses, nls_cp);
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "error %d building av pair blob\n", rc);
|
2010-10-28 14:53:07 +00:00
|
|
|
goto setup_ntlmv2_rsp_ret;
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
}
|
|
|
|
}
|
2006-06-05 23:34:19 +00:00
|
|
|
|
2015-09-17 19:40:12 +00:00
|
|
|
/* Must be within 5 minutes of the server (or in range +/-2h
|
|
|
|
* in case of Mac OS X), so simply carry over server timestamp
|
|
|
|
* (as Windows 7 does)
|
|
|
|
*/
|
|
|
|
rsp_timestamp = find_timestamp(ses);
|
|
|
|
|
2010-10-21 11:42:55 +00:00
|
|
|
baselen = CIFS_SESS_KEY_SIZE + sizeof(struct ntlmv2_resp);
|
2010-10-28 14:53:07 +00:00
|
|
|
tilen = ses->auth_key.len;
|
|
|
|
tiblob = ses->auth_key.response;
|
|
|
|
|
|
|
|
ses->auth_key.response = kmalloc(baselen + tilen, GFP_KERNEL);
|
2010-10-21 11:42:55 +00:00
|
|
|
if (!ses->auth_key.response) {
|
2016-02-10 17:50:21 +00:00
|
|
|
rc = -ENOMEM;
|
2010-10-28 14:53:07 +00:00
|
|
|
ses->auth_key.len = 0;
|
2010-10-21 11:42:55 +00:00
|
|
|
goto setup_ntlmv2_rsp_ret;
|
|
|
|
}
|
2010-10-28 14:53:07 +00:00
|
|
|
ses->auth_key.len += baselen;
|
2010-10-21 11:42:55 +00:00
|
|
|
|
2013-11-07 23:40:57 +00:00
|
|
|
ntlmv2 = (struct ntlmv2_resp *)
|
2010-10-21 11:42:55 +00:00
|
|
|
(ses->auth_key.response + CIFS_SESS_KEY_SIZE);
|
2013-11-07 23:40:57 +00:00
|
|
|
ntlmv2->blob_signature = cpu_to_le32(0x00000101);
|
|
|
|
ntlmv2->reserved = 0;
|
2015-09-17 19:40:12 +00:00
|
|
|
ntlmv2->time = rsp_timestamp;
|
|
|
|
|
2013-11-07 23:40:57 +00:00
|
|
|
get_random_bytes(&ntlmv2->client_chal, sizeof(ntlmv2->client_chal));
|
|
|
|
ntlmv2->reserved2 = 0;
|
2010-10-21 11:42:55 +00:00
|
|
|
|
2010-10-28 14:53:07 +00:00
|
|
|
memcpy(ses->auth_key.response + baselen, tiblob, tilen);
|
2010-10-21 11:42:55 +00:00
|
|
|
|
2016-07-19 07:26:21 +00:00
|
|
|
mutex_lock(&ses->server->srv_mutex);
|
|
|
|
|
2018-02-16 18:19:27 +00:00
|
|
|
rc = cifs_alloc_hash("hmac(md5)",
|
|
|
|
&ses->server->secmech.hmacmd5,
|
|
|
|
&ses->server->secmech.sdeschmacmd5);
|
2013-07-04 15:35:21 +00:00
|
|
|
if (rc) {
|
2016-07-19 07:26:21 +00:00
|
|
|
goto unlock;
|
2013-07-04 15:35:21 +00:00
|
|
|
}
|
|
|
|
|
2010-10-26 23:10:24 +00:00
|
|
|
/* calculate ntlmv2_hash */
|
2010-10-28 14:53:07 +00:00
|
|
|
rc = calc_ntlmv2_hash(ses, ntlmv2_hash, nls_cp);
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
if (rc) {
|
2020-04-15 05:42:53 +00:00
|
|
|
cifs_dbg(VFS, "Could not get v2 hash rc %d\n", rc);
|
2016-07-19 07:26:21 +00:00
|
|
|
goto unlock;
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
}
|
2010-10-26 23:10:24 +00:00
|
|
|
|
|
|
|
/* calculate first part of the client response (CR1) */
|
2010-10-28 14:53:07 +00:00
|
|
|
rc = CalcNTLMv2_response(ses, ntlmv2_hash);
|
2010-10-21 19:25:17 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "Could not calculate CR1 rc: %d\n", rc);
|
2016-07-19 07:26:21 +00:00
|
|
|
goto unlock;
|
2010-10-21 19:25:17 +00:00
|
|
|
}
|
2007-07-09 07:55:14 +00:00
|
|
|
|
2010-10-13 23:15:00 +00:00
|
|
|
/* now calculate the session key for NTLMv2 */
|
2011-06-20 21:14:03 +00:00
|
|
|
rc = crypto_shash_setkey(ses->server->secmech.hmacmd5,
|
2010-10-28 14:53:07 +00:00
|
|
|
ntlmv2_hash, CIFS_HMAC_MD5_HASH_SIZE);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not set NTLMV2 Hash as a key\n",
|
|
|
|
__func__);
|
2016-07-19 07:26:21 +00:00
|
|
|
goto unlock;
|
2011-06-20 21:14:03 +00:00
|
|
|
}
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_init(&ses->server->secmech.sdeschmacmd5->shash);
|
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not init hmacmd5\n", __func__);
|
2016-07-19 07:26:21 +00:00
|
|
|
goto unlock;
|
2010-10-21 19:25:17 +00:00
|
|
|
}
|
|
|
|
|
2011-06-20 21:14:03 +00:00
|
|
|
rc = crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
2013-11-07 23:40:57 +00:00
|
|
|
ntlmv2->ntlmv2_hash,
|
2010-10-21 19:25:17 +00:00
|
|
|
CIFS_HMAC_MD5_HASH_SIZE);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc) {
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
|
2016-07-19 07:26:21 +00:00
|
|
|
goto unlock;
|
2011-06-20 21:14:03 +00:00
|
|
|
}
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
ses->auth_key.response);
|
2011-06-20 21:14:03 +00:00
|
|
|
if (rc)
|
2013-05-05 03:12:25 +00:00
|
|
|
cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
|
2016-07-19 07:26:21 +00:00
|
|
|
unlock:
|
|
|
|
mutex_unlock(&ses->server->srv_mutex);
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
setup_ntlmv2_rsp_ret:
|
2010-10-28 14:53:07 +00:00
|
|
|
kfree(tiblob);
|
cifs NTLMv2/NTLMSSP ntlmv2 within ntlmssp autentication code
Attribue Value (AV) pairs or Target Info (TI) pairs are part of
ntlmv2 authentication.
Structure ntlmv2_resp had only definition for two av pairs.
So removed it, and now allocation of av pairs is dynamic.
For servers like Windows 7/2008, av pairs sent by server in
challege packet (type 2 in the ntlmssp exchange/negotiation) can
vary.
Server sends them during ntlmssp negotiation. So when ntlmssp is used
as an authentication mechanism, type 2 challenge packet from server
has this information. Pluck it and use the entire blob for
authenticaiton purpose. If user has not specified, extract
(netbios) domain name from the av pairs which is used to calculate
ntlmv2 hash. Servers like Windows 7 are particular about the AV pair
blob.
Servers like Windows 2003, are not very strict about the contents
of av pair blob used during ntlmv2 authentication.
So when security mechanism such as ntlmv2 is used (not ntlmv2 in ntlmssp),
there is no negotiation and so genereate a minimal blob that gets
used in ntlmv2 authentication as well as gets sent.
Fields tilen and tilbob are session specific. AV pair values are defined.
To calculate ntlmv2 response we need ti/av pair blob.
For sec mech like ntlmssp, the blob is plucked from type 2 response from
the server. From this blob, netbios name of the domain is retrieved,
if user has not already provided, to be included in the Target String
as part of ntlmv2 hash calculations.
For sec mech like ntlmv2, create a minimal, two av pair blob.
The allocated blob is freed in case of error. In case there is no error,
this blob is used in calculating ntlmv2 response (in CalcNTLMv2_response)
and is also copied on the response to the server, and then freed.
The type 3 ntlmssp response is prepared on a buffer,
5 * sizeof of struct _AUTHENTICATE_MESSAGE, an empirical value large
enough to hold _AUTHENTICATE_MESSAGE plus a blob with max possible
10 values as part of ntlmv2 response and lmv2 keys and domain, user,
workstation names etc.
Also, kerberos gets selected as a default mechanism if server supports it,
over the other security mechanisms.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2010-09-19 03:02:18 +00:00
|
|
|
|
|
|
|
return rc;
|
2006-06-05 16:26:05 +00:00
|
|
|
}
|
|
|
|
|
2010-10-21 19:25:08 +00:00
|
|
|
int
|
2011-05-27 04:34:02 +00:00
|
|
|
calc_seckey(struct cifs_ses *ses)
|
2010-10-21 19:25:08 +00:00
|
|
|
{
|
2019-06-12 16:19:59 +00:00
|
|
|
unsigned char sec_key[CIFS_SESS_KEY_SIZE]; /* a nonce */
|
|
|
|
struct arc4_ctx *ctx_arc4;
|
2016-10-17 20:40:22 +00:00
|
|
|
|
2019-06-12 16:19:59 +00:00
|
|
|
if (fips_enabled)
|
|
|
|
return -ENODEV;
|
2010-10-21 19:25:08 +00:00
|
|
|
|
|
|
|
get_random_bytes(sec_key, CIFS_SESS_KEY_SIZE);
|
|
|
|
|
2019-06-12 16:19:59 +00:00
|
|
|
ctx_arc4 = kmalloc(sizeof(*ctx_arc4), GFP_KERNEL);
|
|
|
|
if (!ctx_arc4) {
|
2020-04-15 05:42:53 +00:00
|
|
|
cifs_dbg(VFS, "Could not allocate arc4 context\n");
|
2019-06-12 16:19:59 +00:00
|
|
|
return -ENOMEM;
|
2011-06-20 21:14:03 +00:00
|
|
|
}
|
2010-10-21 19:25:08 +00:00
|
|
|
|
2021-08-19 10:34:59 +00:00
|
|
|
cifs_arc4_setkey(ctx_arc4, ses->auth_key.response, CIFS_SESS_KEY_SIZE);
|
|
|
|
cifs_arc4_crypt(ctx_arc4, ses->ntlmssp->ciphertext, sec_key,
|
|
|
|
CIFS_CPHTXT_SIZE);
|
2010-10-21 19:25:08 +00:00
|
|
|
|
|
|
|
/* make secondary_key/nonce as session key */
|
|
|
|
memcpy(ses->auth_key.response, sec_key, CIFS_SESS_KEY_SIZE);
|
|
|
|
/* and make len as that of session key only */
|
|
|
|
ses->auth_key.len = CIFS_SESS_KEY_SIZE;
|
|
|
|
|
2019-06-12 16:19:59 +00:00
|
|
|
memzero_explicit(sec_key, CIFS_SESS_KEY_SIZE);
|
2020-08-07 06:18:13 +00:00
|
|
|
kfree_sensitive(ctx_arc4);
|
2019-06-12 16:19:59 +00:00
|
|
|
return 0;
|
2010-10-21 19:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2016-11-03 23:47:37 +00:00
|
|
|
cifs_crypto_secmech_release(struct TCP_Server_Info *server)
|
2010-10-21 19:25:08 +00:00
|
|
|
{
|
2013-07-04 15:35:21 +00:00
|
|
|
if (server->secmech.cmacaes) {
|
2013-06-27 04:45:05 +00:00
|
|
|
crypto_free_shash(server->secmech.cmacaes);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.cmacaes = NULL;
|
|
|
|
}
|
2013-06-27 04:45:05 +00:00
|
|
|
|
2013-07-04 15:35:21 +00:00
|
|
|
if (server->secmech.hmacsha256) {
|
2012-09-18 23:20:30 +00:00
|
|
|
crypto_free_shash(server->secmech.hmacsha256);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.hmacsha256 = NULL;
|
|
|
|
}
|
2012-09-18 23:20:30 +00:00
|
|
|
|
2013-07-04 15:35:21 +00:00
|
|
|
if (server->secmech.md5) {
|
2010-10-21 19:25:08 +00:00
|
|
|
crypto_free_shash(server->secmech.md5);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.md5 = NULL;
|
|
|
|
}
|
2010-10-21 19:25:08 +00:00
|
|
|
|
2018-02-19 17:11:13 +00:00
|
|
|
if (server->secmech.sha512) {
|
2018-02-16 18:19:28 +00:00
|
|
|
crypto_free_shash(server->secmech.sha512);
|
|
|
|
server->secmech.sha512 = NULL;
|
|
|
|
}
|
|
|
|
|
2013-07-04 15:35:21 +00:00
|
|
|
if (server->secmech.hmacmd5) {
|
2010-10-21 19:25:08 +00:00
|
|
|
crypto_free_shash(server->secmech.hmacmd5);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.hmacmd5 = NULL;
|
|
|
|
}
|
2010-10-21 19:25:08 +00:00
|
|
|
|
2016-11-03 23:47:37 +00:00
|
|
|
if (server->secmech.ccmaesencrypt) {
|
|
|
|
crypto_free_aead(server->secmech.ccmaesencrypt);
|
|
|
|
server->secmech.ccmaesencrypt = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (server->secmech.ccmaesdecrypt) {
|
|
|
|
crypto_free_aead(server->secmech.ccmaesdecrypt);
|
|
|
|
server->secmech.ccmaesdecrypt = NULL;
|
|
|
|
}
|
|
|
|
|
2013-06-27 04:45:05 +00:00
|
|
|
kfree(server->secmech.sdesccmacaes);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.sdesccmacaes = NULL;
|
2012-09-18 23:20:30 +00:00
|
|
|
kfree(server->secmech.sdeschmacsha256);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.sdeschmacsha256 = NULL;
|
2010-10-21 19:25:08 +00:00
|
|
|
kfree(server->secmech.sdeschmacmd5);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.sdeschmacmd5 = NULL;
|
2010-10-21 19:25:08 +00:00
|
|
|
kfree(server->secmech.sdescmd5);
|
2013-07-04 15:35:21 +00:00
|
|
|
server->secmech.sdescmd5 = NULL;
|
2018-02-16 18:19:28 +00:00
|
|
|
kfree(server->secmech.sdescsha512);
|
|
|
|
server->secmech.sdescsha512 = NULL;
|
2010-10-21 19:25:08 +00:00
|
|
|
}
|