2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* fs/cifs/cifsencrypt.c
|
|
|
|
*
|
2006-02-09 21:12:47 +00:00
|
|
|
* Copyright (C) International Business Machines Corp., 2005,2006
|
2005-04-16 22:20:36 +00:00
|
|
|
* Author(s): Steve French (sfrench@us.ibm.com)
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU Lesser General Public License as published
|
|
|
|
* by the Free Software Foundation; either version 2.1 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
|
|
|
|
* the GNU Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public License
|
|
|
|
* along with this library; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
*/
|
|
|
|
|
|
|
|
#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>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-04-02 11:34:30 +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.
|
|
|
|
*/
|
2007-06-24 21:15:44 +00:00
|
|
|
static int cifs_calculate_signature(const struct smb_hdr *cifs_pdu,
|
2010-10-21 11:42:55 +00:00
|
|
|
struct TCP_Server_Info *server, char *signature)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-10-21 19:25:17 +00:00
|
|
|
int rc;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-10-21 11:42:55 +00:00
|
|
|
if (cifs_pdu == NULL || signature == NULL || server == NULL)
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-10-21 19:25:17 +00:00
|
|
|
if (!server->secmech.sdescmd5) {
|
|
|
|
cERROR(1, "%s: Can't generate signature\n", __func__);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = crypto_shash_init(&server->secmech.sdescmd5->shash);
|
|
|
|
if (rc) {
|
|
|
|
cERROR(1, "%s: Oould not init md5\n", __func__);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
crypto_shash_update(&server->secmech.sdescmd5->shash,
|
|
|
|
server->session_key.response, server->session_key.len);
|
|
|
|
|
|
|
|
crypto_shash_update(&server->secmech.sdescmd5->shash,
|
2011-04-29 05:40:20 +00:00
|
|
|
cifs_pdu->Protocol, be32_to_cpu(cifs_pdu->smb_buf_length));
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_final(&server->secmech.sdescmd5->shash, signature);
|
2007-07-09 07:55:14 +00:00
|
|
|
|
2010-09-08 20:57:05 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2011-01-07 16:30:28 +00:00
|
|
|
/* must be called with server->srv_mutex held */
|
2007-06-24 21:15:44 +00:00
|
|
|
int cifs_sign_smb(struct smb_hdr *cifs_pdu, struct TCP_Server_Info *server,
|
|
|
|
__u32 *pexpected_response_sequence_number)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
char smb_signature[20];
|
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
if ((cifs_pdu == NULL) || (server == NULL))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
if ((cifs_pdu->Flags2 & SMBFLG2_SECURITY_SIGNATURE) == 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
return rc;
|
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
cifs_pdu->Signature.Sequence.SequenceNumber =
|
|
|
|
cpu_to_le32(server->sequence_number);
|
2005-04-16 22:20:36 +00:00
|
|
|
cifs_pdu->Signature.Sequence.Reserved = 0;
|
2007-07-13 00:33:32 +00:00
|
|
|
|
2005-04-29 05:41:05 +00:00
|
|
|
*pexpected_response_sequence_number = server->sequence_number++;
|
|
|
|
server->sequence_number++;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-10-21 11:42:55 +00:00
|
|
|
rc = cifs_calculate_signature(cifs_pdu, server, smb_signature);
|
2007-06-24 21:15:44 +00:00
|
|
|
if (rc)
|
2005-04-16 22:20:36 +00:00
|
|
|
memset(cifs_pdu->Signature.SecuritySignature, 0, 8);
|
|
|
|
else
|
|
|
|
memcpy(cifs_pdu->Signature.SecuritySignature, smb_signature, 8);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
static int cifs_calc_signature2(const struct kvec *iov, int n_vec,
|
2010-10-21 11:42:55 +00:00
|
|
|
struct TCP_Server_Info *server, char *signature)
|
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;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2010-10-21 11:42:55 +00:00
|
|
|
if (iov == NULL || signature == NULL || server == NULL)
|
2006-03-31 21:22:00 +00:00
|
|
|
return -EINVAL;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2010-10-21 19:25:17 +00:00
|
|
|
if (!server->secmech.sdescmd5) {
|
|
|
|
cERROR(1, "%s: Can't generate signature\n", __func__);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = crypto_shash_init(&server->secmech.sdescmd5->shash);
|
|
|
|
if (rc) {
|
|
|
|
cERROR(1, "%s: Oould not init md5\n", __func__);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
crypto_shash_update(&server->secmech.sdescmd5->shash,
|
|
|
|
server->session_key.response, server->session_key.len);
|
|
|
|
|
2007-07-13 00:33:32 +00:00
|
|
|
for (i = 0; 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) {
|
2010-09-08 20:57:05 +00:00
|
|
|
cERROR(1, "null iovec entry");
|
2006-03-31 21:22:00 +00:00
|
|
|
return -EIO;
|
2007-11-03 04:34:04 +00:00
|
|
|
}
|
2007-06-24 21:15:44 +00:00
|
|
|
/* The first entry includes a length field (which does not get
|
2006-03-31 21:22:00 +00:00
|
|
|
signed that occupies the first 4 bytes before the header */
|
2007-06-24 21:15:44 +00:00
|
|
|
if (i == 0) {
|
2007-11-05 21:46:10 +00:00
|
|
|
if (iov[0].iov_len <= 8) /* cmd field at offset 9 */
|
2006-03-31 21:22:00 +00:00
|
|
|
break; /* nothing to sign or corrupt header */
|
2010-10-21 19:25:17 +00:00
|
|
|
crypto_shash_update(&server->secmech.sdescmd5->shash,
|
|
|
|
iov[i].iov_base + 4, iov[i].iov_len - 4);
|
2006-03-31 21:22:00 +00:00
|
|
|
} else
|
2010-10-21 19:25:17 +00:00
|
|
|
crypto_shash_update(&server->secmech.sdescmd5->shash,
|
|
|
|
iov[i].iov_base, iov[i].iov_len);
|
2006-03-31 21:22:00 +00:00
|
|
|
}
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2010-10-21 19:25:17 +00:00
|
|
|
rc = crypto_shash_final(&server->secmech.sdescmd5->shash, signature);
|
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
|
|
|
}
|
|
|
|
|
2011-01-07 16:30:28 +00:00
|
|
|
/* must be called with server->srv_mutex held */
|
2007-06-24 21:15:44 +00:00
|
|
|
int cifs_sign_smb2(struct kvec *iov, int n_vec, 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];
|
2007-06-24 21:15:44 +00:00
|
|
|
struct smb_hdr *cifs_pdu = iov[0].iov_base;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
if ((cifs_pdu == NULL) || (server == NULL))
|
2005-12-02 21:32:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
if ((cifs_pdu->Flags2 & SMBFLG2_SECURITY_SIGNATURE) == 0)
|
2005-12-02 21:32:45 +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
|
|
|
|
2007-06-24 21:15:44 +00:00
|
|
|
*pexpected_response_sequence_number = server->sequence_number++;
|
|
|
|
server->sequence_number++;
|
2005-12-02 21:32:45 +00:00
|
|
|
|
2010-10-21 11:42:55 +00:00
|
|
|
rc = cifs_calc_signature2(iov, n_vec, 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
|
|
|
}
|
|
|
|
|
2007-07-09 07:55:14 +00:00
|
|
|
int cifs_verify_signature(struct smb_hdr *cifs_pdu,
|
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];
|
|
|
|
|
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;
|
|
|
|
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)
|
2010-04-21 03:50:45 +00:00
|
|
|
cFYI(1, "dummy signature received for smb command 0x%x",
|
|
|
|
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);
|
2010-10-21 11:42:55 +00:00
|
|
|
rc = cifs_calculate_signature(cifs_pdu, server,
|
2005-04-16 22:20:36 +00:00
|
|
|
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-21 11:42:55 +00:00
|
|
|
/* first calculate 24 bytes ntlm response and then 16 byte session key */
|
2011-05-27 04:34:02 +00:00
|
|
|
int setup_ntlm_response(struct cifs_ses *ses)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2011-01-27 15:58:04 +00:00
|
|
|
int rc = 0;
|
2010-10-21 11:42:55 +00:00
|
|
|
unsigned int temp_len = CIFS_SESS_KEY_SIZE + CIFS_AUTH_RESP_SIZE;
|
|
|
|
char temp_key[CIFS_SESS_KEY_SIZE];
|
|
|
|
|
|
|
|
if (!ses)
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-10-21 11:42:55 +00:00
|
|
|
ses->auth_key.response = kmalloc(temp_len, GFP_KERNEL);
|
|
|
|
if (!ses->auth_key.response) {
|
|
|
|
cERROR(1, "NTLM can't allocate (%u bytes) memory", temp_len);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
ses->auth_key.len = temp_len;
|
|
|
|
|
2011-01-27 15:58:04 +00:00
|
|
|
rc = SMBNTencrypt(ses->password, ses->server->cryptkey,
|
2010-10-21 11:42:55 +00:00
|
|
|
ses->auth_key.response + CIFS_SESS_KEY_SIZE);
|
2011-01-27 15:58:04 +00:00
|
|
|
if (rc) {
|
|
|
|
cFYI(1, "%s Can't generate NTLM response, error: %d",
|
|
|
|
__func__, rc);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = E_md4hash(ses->password, temp_key);
|
|
|
|
if (rc) {
|
|
|
|
cFYI(1, "%s Can't generate NT hash, error: %d", __func__, rc);
|
|
|
|
return rc;
|
|
|
|
}
|
2010-10-21 11:42:55 +00:00
|
|
|
|
2011-01-27 15:58:04 +00:00
|
|
|
rc = mdfour(ses->auth_key.response, temp_key, CIFS_SESS_KEY_SIZE);
|
|
|
|
if (rc)
|
|
|
|
cFYI(1, "%s Can't generate NTLM session key, error: %d",
|
|
|
|
__func__, rc);
|
2010-10-21 11:42:55 +00:00
|
|
|
|
2011-01-27 15:58:04 +00:00
|
|
|
return rc;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2006-06-01 19:20:10 +00:00
|
|
|
#ifdef CONFIG_CIFS_WEAK_PW_HASH
|
2011-04-19 18:23:31 +00:00
|
|
|
int calc_lanman_hash(const char *password, const char *cryptkey, bool encrypt,
|
2008-12-06 01:41:21 +00:00
|
|
|
char *lnm_session_key)
|
2006-06-01 19:20:10 +00:00
|
|
|
{
|
|
|
|
int i;
|
2011-04-19 18:23:31 +00:00
|
|
|
int rc;
|
2006-06-01 19:20:10 +00:00
|
|
|
char password_with_pad[CIFS_ENCPWD_SIZE];
|
|
|
|
|
|
|
|
memset(password_with_pad, 0, CIFS_ENCPWD_SIZE);
|
2008-12-06 01:41:21 +00:00
|
|
|
if (password)
|
|
|
|
strncpy(password_with_pad, password, CIFS_ENCPWD_SIZE);
|
|
|
|
|
2010-04-24 11:57:45 +00:00
|
|
|
if (!encrypt && global_secflags & CIFSSEC_MAY_PLNTXT) {
|
2008-12-06 01:41:21 +00:00
|
|
|
memset(lnm_session_key, 0, CIFS_SESS_KEY_SIZE);
|
|
|
|
memcpy(lnm_session_key, password_with_pad,
|
|
|
|
CIFS_ENCPWD_SIZE);
|
2011-04-19 18:23:31 +00:00
|
|
|
return 0;
|
2008-12-06 01:41:21 +00:00
|
|
|
}
|
2006-06-02 22:57:13 +00:00
|
|
|
|
2006-06-01 19:20:10 +00:00
|
|
|
/* calculate old style session key */
|
|
|
|
/* calling toupper is less broken than repeatedly
|
|
|
|
calling nls_toupper would be since that will never
|
|
|
|
work for UTF8, but neither handles multibyte code pages
|
|
|
|
but the only alternative would be converting to UCS-16 (Unicode)
|
|
|
|
(using a routine something like UniStrupr) then
|
|
|
|
uppercasing and then converting back from Unicode - which
|
|
|
|
would only worth doing it if we knew it were utf8. Basically
|
|
|
|
utf8 and other multibyte codepages each need their own strupper
|
|
|
|
function since a byte at a time will ont work. */
|
|
|
|
|
2008-07-24 15:56:05 +00:00
|
|
|
for (i = 0; i < CIFS_ENCPWD_SIZE; i++)
|
2006-06-01 19:20:10 +00:00
|
|
|
password_with_pad[i] = toupper(password_with_pad[i]);
|
|
|
|
|
2011-04-19 18:23:31 +00:00
|
|
|
rc = SMBencrypt(password_with_pad, cryptkey, lnm_session_key);
|
2008-12-06 01:41:21 +00:00
|
|
|
|
2011-04-19 18:23:31 +00:00
|
|
|
return rc;
|
2006-06-01 19:20:10 +00:00
|
|
|
}
|
|
|
|
#endif /* CIFS_WEAK_PW_HASH */
|
|
|
|
|
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;
|
|
|
|
unsigned int wlen;
|
|
|
|
unsigned int size = 6 * sizeof(struct ntlmssp2_name);
|
|
|
|
__le64 curtime;
|
|
|
|
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);
|
|
|
|
wlen = strlen(ses->server->hostname);
|
|
|
|
|
|
|
|
/* The length of this blob is a size which is
|
|
|
|
* six times the size of a structure which holds name/size +
|
|
|
|
* two times the unicode length of a domain name +
|
|
|
|
* two times the unicode length of a server name +
|
|
|
|
* size of a timestamp (which is 8 bytes).
|
|
|
|
*/
|
2010-10-28 14:53:07 +00:00
|
|
|
ses->auth_key.len = size + 2 * (2 * dlen) + 2 * (2 * wlen) + 8;
|
|
|
|
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
|
|
|
cERROR(1, "Challenge target info allocation failure");
|
|
|
|
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;
|
|
|
|
|
|
|
|
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);
|
|
|
|
cifs_strtoUCS((__le16 *)blobptr, ses->domainName, dlen, nls_cp);
|
|
|
|
|
|
|
|
blobptr += 2 * dlen;
|
|
|
|
attrptr = (struct ntlmssp2_name *) blobptr;
|
|
|
|
|
|
|
|
attrptr->type = cpu_to_le16(NTLMSSP_AV_NB_COMPUTER_NAME);
|
|
|
|
attrptr->length = cpu_to_le16(2 * wlen);
|
|
|
|
blobptr = (unsigned char *)attrptr + sizeof(struct ntlmssp2_name);
|
|
|
|
cifs_strtoUCS((__le16 *)blobptr, ses->server->hostname, wlen, nls_cp);
|
|
|
|
|
|
|
|
blobptr += 2 * wlen;
|
|
|
|
attrptr = (struct ntlmssp2_name *) blobptr;
|
|
|
|
|
|
|
|
attrptr->type = cpu_to_le16(NTLMSSP_AV_DNS_DOMAIN_NAME);
|
|
|
|
attrptr->length = cpu_to_le16(2 * dlen);
|
|
|
|
blobptr = (unsigned char *)attrptr + sizeof(struct ntlmssp2_name);
|
|
|
|
cifs_strtoUCS((__le16 *)blobptr, ses->domainName, dlen, nls_cp);
|
|
|
|
|
|
|
|
blobptr += 2 * dlen;
|
|
|
|
attrptr = (struct ntlmssp2_name *) blobptr;
|
|
|
|
|
|
|
|
attrptr->type = cpu_to_le16(NTLMSSP_AV_DNS_COMPUTER_NAME);
|
|
|
|
attrptr->length = cpu_to_le16(2 * wlen);
|
|
|
|
blobptr = (unsigned char *)attrptr + sizeof(struct ntlmssp2_name);
|
|
|
|
cifs_strtoUCS((__le16 *)blobptr, ses->server->hostname, wlen, nls_cp);
|
|
|
|
|
|
|
|
blobptr += 2 * wlen;
|
|
|
|
attrptr = (struct ntlmssp2_name *) blobptr;
|
|
|
|
|
|
|
|
attrptr->type = cpu_to_le16(NTLMSSP_AV_TIMESTAMP);
|
|
|
|
attrptr->length = cpu_to_le16(sizeof(__le64));
|
|
|
|
blobptr = (unsigned char *)attrptr + sizeof(struct ntlmssp2_name);
|
|
|
|
curtime = cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
|
|
|
|
memcpy(blobptr, &curtime, sizeof(__le64));
|
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) {
|
|
|
|
if (!attrsize)
|
|
|
|
break;
|
|
|
|
if (!ses->domainName) {
|
|
|
|
ses->domainName =
|
|
|
|
kmalloc(attrsize + 1, GFP_KERNEL);
|
|
|
|
if (!ses->domainName)
|
|
|
|
return -ENOMEM;
|
|
|
|
cifs_from_ucs2(ses->domainName,
|
|
|
|
(__le16 *)blobptr, attrsize, attrsize,
|
2010-10-26 23:10:24 +00:00
|
|
|
nls_cp, false);
|
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;
|
|
|
|
}
|
|
|
|
|
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];
|
2007-07-13 00:33:32 +00:00
|
|
|
wchar_t *user;
|
|
|
|
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) {
|
|
|
|
cERROR(1, "calc_ntlmv2_hash: can't generate ntlmv2 hash\n");
|
|
|
|
return -1;
|
|
|
|
}
|
2010-09-08 20:57:05 +00:00
|
|
|
|
2010-09-08 21:10:58 +00:00
|
|
|
/* calculate md4 hash of password */
|
|
|
|
E_md4hash(ses->password, nt_hash);
|
2010-08-20 20:42:26 +00:00
|
|
|
|
2010-10-21 19:25:17 +00:00
|
|
|
crypto_shash_setkey(ses->server->secmech.hmacmd5, nt_hash,
|
|
|
|
CIFS_NTHASH_SIZE);
|
|
|
|
|
|
|
|
rc = crypto_shash_init(&ses->server->secmech.sdeschmacmd5->shash);
|
|
|
|
if (rc) {
|
|
|
|
cERROR(1, "calc_ntlmv2_hash: could not init hmacmd5\n");
|
|
|
|
return rc;
|
|
|
|
}
|
2006-06-05 23:34:19 +00:00
|
|
|
|
2011-02-25 07:11:56 +00:00
|
|
|
/* convert ses->user_name to unicode and uppercase */
|
|
|
|
len = strlen(ses->user_name);
|
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) {
|
|
|
|
cERROR(1, "calc_ntlmv2_hash: user mem alloc failure\n");
|
|
|
|
rc = -ENOMEM;
|
2006-06-08 05:41:32 +00:00
|
|
|
goto calc_exit_2;
|
2010-10-21 19:25:17 +00:00
|
|
|
}
|
2011-02-25 07:11:56 +00:00
|
|
|
len = cifs_strtoUCS((__le16 *)user, ses->user_name, len, nls_cp);
|
2006-06-08 05:41:32 +00:00
|
|
|
UniStrupr(user);
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
(char *)user, 2 * len);
|
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) {
|
|
|
|
cERROR(1, "calc_ntlmv2_hash: domain mem alloc failure");
|
|
|
|
rc = -ENOMEM;
|
2006-06-08 05:41:32 +00:00
|
|
|
goto calc_exit_1;
|
2010-10-21 19:25:17 +00:00
|
|
|
}
|
2007-10-14 17:58:43 +00:00
|
|
|
len = cifs_strtoUCS((__le16 *)domain, ses->domainName, len,
|
|
|
|
nls_cp);
|
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);
|
2010-10-21 19:25:17 +00:00
|
|
|
} else if (ses->serverName) {
|
|
|
|
len = strlen(ses->serverName);
|
|
|
|
|
|
|
|
server = kmalloc(2 + (len * 2), GFP_KERNEL);
|
|
|
|
if (server == NULL) {
|
|
|
|
cERROR(1, "calc_ntlmv2_hash: server mem alloc failure");
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto calc_exit_1;
|
|
|
|
}
|
|
|
|
len = cifs_strtoUCS((__le16 *)server, ses->serverName, len,
|
|
|
|
nls_cp);
|
|
|
|
crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
(char *)server, 2 * len);
|
|
|
|
kfree(server);
|
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);
|
2010-10-21 19:25:17 +00:00
|
|
|
|
2006-06-08 05:41:32 +00:00
|
|
|
calc_exit_1:
|
|
|
|
kfree(user);
|
|
|
|
calc_exit_2:
|
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;
|
|
|
|
unsigned int offset = CIFS_SESS_KEY_SIZE + 8;
|
|
|
|
|
|
|
|
if (!ses->server->secmech.sdeschmacmd5) {
|
|
|
|
cERROR(1, "calc_ntlmv2_hash: can't generate ntlmv2 hash\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
crypto_shash_setkey(ses->server->secmech.hmacmd5,
|
2010-10-28 14:53:07 +00:00
|
|
|
ntlmv2_hash, CIFS_HMAC_MD5_HASH_SIZE);
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_init(&ses->server->secmech.sdeschmacmd5->shash);
|
|
|
|
if (rc) {
|
|
|
|
cERROR(1, "CalcNTLMv2_response: could not init hmacmd5");
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2010-10-27 20:20:36 +00:00
|
|
|
if (ses->server->secType == RawNTLMSSP)
|
|
|
|
memcpy(ses->auth_key.response + offset,
|
2010-10-28 14:53:07 +00:00
|
|
|
ses->ntlmssp->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
|
2010-10-27 20:20:36 +00:00
|
|
|
else
|
|
|
|
memcpy(ses->auth_key.response + offset,
|
|
|
|
ses->server->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
|
2010-10-21 19:25:17 +00:00
|
|
|
crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
ses->auth_key.response + offset, ses->auth_key.len - offset);
|
|
|
|
|
|
|
|
rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
ses->auth_key.response + CIFS_SESS_KEY_SIZE);
|
2010-08-20 20:42:26 +00:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2010-10-21 19:25:17 +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
|
|
|
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;
|
2010-10-21 11:42:55 +00:00
|
|
|
struct ntlmv2_resp *buf;
|
2010-10-28 14:53:07 +00:00
|
|
|
char ntlmv2_hash[16];
|
|
|
|
unsigned char *tiblob = NULL; /* target info blob */
|
2006-06-05 16:26: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
|
|
|
if (ses->server->secType == RawNTLMSSP) {
|
|
|
|
if (!ses->domainName) {
|
2010-10-26 23:10:24 +00:00
|
|
|
rc = find_domain_name(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) {
|
|
|
|
cERROR(1, "error %d finding domain name", rc);
|
|
|
|
goto setup_ntlmv2_rsp_ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} 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) {
|
|
|
|
cERROR(1, "error %d building av pair blob", 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
|
|
|
|
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) {
|
|
|
|
rc = ENOMEM;
|
2010-10-28 14:53:07 +00:00
|
|
|
ses->auth_key.len = 0;
|
2010-10-21 11:42:55 +00:00
|
|
|
cERROR(1, "%s: Can't allocate auth blob", __func__);
|
|
|
|
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
|
|
|
|
|
|
|
buf = (struct ntlmv2_resp *)
|
|
|
|
(ses->auth_key.response + CIFS_SESS_KEY_SIZE);
|
|
|
|
buf->blob_signature = cpu_to_le32(0x00000101);
|
|
|
|
buf->reserved = 0;
|
|
|
|
buf->time = cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
|
|
|
|
get_random_bytes(&buf->client_chal, sizeof(buf->client_chal));
|
|
|
|
buf->reserved2 = 0;
|
|
|
|
|
2010-10-28 14:53:07 +00:00
|
|
|
memcpy(ses->auth_key.response + baselen, tiblob, tilen);
|
2010-10-21 11:42:55 +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) {
|
2010-04-21 03:50:45 +00:00
|
|
|
cERROR(1, "could not get v2 hash rc %d", 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
|
|
|
goto setup_ntlmv2_rsp_ret;
|
|
|
|
}
|
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) {
|
|
|
|
cERROR(1, "Could not calculate CR1 rc: %d", rc);
|
|
|
|
goto setup_ntlmv2_rsp_ret;
|
|
|
|
}
|
2007-07-09 07:55:14 +00:00
|
|
|
|
2010-10-13 23:15:00 +00:00
|
|
|
/* now calculate the session key for NTLMv2 */
|
2010-10-21 19:25:17 +00:00
|
|
|
crypto_shash_setkey(ses->server->secmech.hmacmd5,
|
2010-10-28 14:53:07 +00:00
|
|
|
ntlmv2_hash, CIFS_HMAC_MD5_HASH_SIZE);
|
2010-10-21 19:25:17 +00:00
|
|
|
|
|
|
|
rc = crypto_shash_init(&ses->server->secmech.sdeschmacmd5->shash);
|
|
|
|
if (rc) {
|
|
|
|
cERROR(1, "%s: Could not init hmacmd5\n", __func__);
|
|
|
|
goto setup_ntlmv2_rsp_ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
ses->auth_key.response + CIFS_SESS_KEY_SIZE,
|
|
|
|
CIFS_HMAC_MD5_HASH_SIZE);
|
|
|
|
|
|
|
|
rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
|
|
|
|
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
|
|
|
|
|
|
|
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
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
struct crypto_blkcipher *tfm_arc4;
|
|
|
|
struct scatterlist sgin, sgout;
|
|
|
|
struct blkcipher_desc desc;
|
|
|
|
unsigned char sec_key[CIFS_SESS_KEY_SIZE]; /* a nonce */
|
|
|
|
|
|
|
|
get_random_bytes(sec_key, CIFS_SESS_KEY_SIZE);
|
|
|
|
|
|
|
|
tfm_arc4 = crypto_alloc_blkcipher("ecb(arc4)", 0, CRYPTO_ALG_ASYNC);
|
2011-01-29 19:54:58 +00:00
|
|
|
if (IS_ERR(tfm_arc4)) {
|
|
|
|
rc = PTR_ERR(tfm_arc4);
|
2010-10-21 19:25:08 +00:00
|
|
|
cERROR(1, "could not allocate crypto API arc4\n");
|
2011-01-29 19:54:58 +00:00
|
|
|
return rc;
|
2010-10-21 19:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
desc.tfm = tfm_arc4;
|
|
|
|
|
|
|
|
crypto_blkcipher_setkey(tfm_arc4, ses->auth_key.response,
|
|
|
|
CIFS_SESS_KEY_SIZE);
|
|
|
|
|
|
|
|
sg_init_one(&sgin, sec_key, CIFS_SESS_KEY_SIZE);
|
2010-10-28 14:53:07 +00:00
|
|
|
sg_init_one(&sgout, ses->ntlmssp->ciphertext, CIFS_CPHTXT_SIZE);
|
2010-10-21 19:25:08 +00:00
|
|
|
|
|
|
|
rc = crypto_blkcipher_encrypt(&desc, &sgout, &sgin, CIFS_CPHTXT_SIZE);
|
|
|
|
if (rc) {
|
|
|
|
cERROR(1, "could not encrypt session key rc: %d\n", rc);
|
|
|
|
crypto_free_blkcipher(tfm_arc4);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
|
|
|
|
crypto_free_blkcipher(tfm_arc4);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
cifs_crypto_shash_release(struct TCP_Server_Info *server)
|
|
|
|
{
|
|
|
|
if (server->secmech.md5)
|
|
|
|
crypto_free_shash(server->secmech.md5);
|
|
|
|
|
|
|
|
if (server->secmech.hmacmd5)
|
|
|
|
crypto_free_shash(server->secmech.hmacmd5);
|
|
|
|
|
|
|
|
kfree(server->secmech.sdeschmacmd5);
|
|
|
|
|
|
|
|
kfree(server->secmech.sdescmd5);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
cifs_crypto_shash_allocate(struct TCP_Server_Info *server)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
unsigned int size;
|
|
|
|
|
|
|
|
server->secmech.hmacmd5 = crypto_alloc_shash("hmac(md5)", 0, 0);
|
2011-01-27 15:58:04 +00:00
|
|
|
if (IS_ERR(server->secmech.hmacmd5)) {
|
2010-10-21 19:25:08 +00:00
|
|
|
cERROR(1, "could not allocate crypto hmacmd5\n");
|
|
|
|
return PTR_ERR(server->secmech.hmacmd5);
|
|
|
|
}
|
|
|
|
|
|
|
|
server->secmech.md5 = crypto_alloc_shash("md5", 0, 0);
|
2011-01-27 15:58:04 +00:00
|
|
|
if (IS_ERR(server->secmech.md5)) {
|
2010-10-21 19:25:08 +00:00
|
|
|
cERROR(1, "could not allocate crypto md5\n");
|
|
|
|
rc = PTR_ERR(server->secmech.md5);
|
|
|
|
goto crypto_allocate_md5_fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
size = sizeof(struct shash_desc) +
|
|
|
|
crypto_shash_descsize(server->secmech.hmacmd5);
|
|
|
|
server->secmech.sdeschmacmd5 = kmalloc(size, GFP_KERNEL);
|
|
|
|
if (!server->secmech.sdeschmacmd5) {
|
|
|
|
cERROR(1, "cifs_crypto_shash_allocate: can't alloc hmacmd5\n");
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto crypto_allocate_hmacmd5_sdesc_fail;
|
|
|
|
}
|
|
|
|
server->secmech.sdeschmacmd5->shash.tfm = server->secmech.hmacmd5;
|
|
|
|
server->secmech.sdeschmacmd5->shash.flags = 0x0;
|
|
|
|
|
|
|
|
|
|
|
|
size = sizeof(struct shash_desc) +
|
|
|
|
crypto_shash_descsize(server->secmech.md5);
|
|
|
|
server->secmech.sdescmd5 = kmalloc(size, GFP_KERNEL);
|
|
|
|
if (!server->secmech.sdescmd5) {
|
|
|
|
cERROR(1, "cifs_crypto_shash_allocate: can't alloc md5\n");
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto crypto_allocate_md5_sdesc_fail;
|
|
|
|
}
|
|
|
|
server->secmech.sdescmd5->shash.tfm = server->secmech.md5;
|
|
|
|
server->secmech.sdescmd5->shash.flags = 0x0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
crypto_allocate_md5_sdesc_fail:
|
|
|
|
kfree(server->secmech.sdeschmacmd5);
|
|
|
|
|
|
|
|
crypto_allocate_hmacmd5_sdesc_fail:
|
|
|
|
crypto_free_shash(server->secmech.md5);
|
|
|
|
|
|
|
|
crypto_allocate_md5_fail:
|
|
|
|
crypto_free_shash(server->secmech.hmacmd5);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|