nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
b26077b1ae
putty-source/windows/gss.c

695 lines
23 KiB
C
Raw Normal View History

Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
#ifndef NO_GSSAPI
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
#include <limits.h>
Have wingss.c include <windows.h> by way of putty.h rather than directly. Fixes a build failure involving name clashes between winsock2.h and winsock.h, which had somehow managed to get included in succession. [originally from svn r8332]
2008-11-25 18:54:05 +00:00
#include "putty.h"
Move definition of SECURITY_WIN32 from makefiles into source. This makes it easier for people to recompile the source in other contexts or other makefiles.
2014-11-01 14:44:16 +00:00
#define SECURITY_WIN32
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
#include <security.h>
Have wingss.c include <windows.h> by way of putty.h rather than directly. Fixes a build failure involving name clashes between winsock2.h and winsock.h, which had somehow managed to get included in succession. [originally from svn r8332]
2008-11-25 18:54:05 +00:00
Move the SSH implementation into its own subdirectory. This clears up another large pile of clutter at the top level, and in the process, allows me to rename source files to things that don't all have that annoying 'ssh' prefix at the top.
2021-04-22 16:58:40 +00:00
#include "ssh/pgssapi.h"
#include "ssh/gss.h"
#include "ssh/gssc.h"
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
#include "misc.h"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
#define UNIX_EPOCH 11644473600ULL /* Seconds from Windows epoch */
#define CNS_PERSEC 10000000ULL /* # 100ns per second */
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
/*
* Note, as a special case, 0 relative to the Windows epoch (unspecified) maps
* to 0 relative to the POSIX epoch (unspecified)!
*/
#define TIME_WIN_TO_POSIX(ft, t) do { \
ULARGE_INTEGER uli; \
uli.LowPart = (ft).dwLowDateTime; \
uli.HighPart = (ft).dwHighDateTime; \
if (uli.QuadPart != 0) \
uli.QuadPart = uli.QuadPart / CNS_PERSEC - UNIX_EPOCH; \
(t) = (time_t) uli.QuadPart; \
Formatting: normalise to put a space after condition keywords. 'if (thing)' is the local style here, not 'if(thing)'. Similarly with 'for' and 'while'.
2022-12-28 15:32:24 +00:00
} while (0)
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
/* Windows code to set up the GSSAPI library list. */
Fix filename of the 64-bit MIT Kerberos DLL. 64-bit PuTTY should be loading gssapi64.dll, not gssapi32.dll. (In contrast to the Windows system API DLLs, such as secur32.dll which is also mentioned in the same source file; those keep the "32" in their name whether we're in Win32 or Win64.)
2017-08-04 18:46:21 +00:00
#ifdef _WIN64
#define MIT_KERB_SUFFIX "64"
#else
#define MIT_KERB_SUFFIX "32"
#endif
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
const int ngsslibs = 3;
const char *const gsslibnames[3] = {
Fix filename of the 64-bit MIT Kerberos DLL. 64-bit PuTTY should be loading gssapi64.dll, not gssapi32.dll. (In contrast to the Windows system API DLLs, such as secur32.dll which is also mentioned in the same source file; those keep the "32" in their name whether we're in Win32 or Win64.)
2017-08-04 18:46:21 +00:00
"MIT Kerberos GSSAPI"MIT_KERB_SUFFIX".DLL",
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
"Microsoft SSPI SECUR32.DLL",
"User-specified GSSAPI DLL",
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
};
Rewrite gprefs() in settings.c so that its input mapping includes information about where to put items that aren't mentioned in the saved configuration. So far the only nontrivial use I've made of this facility is to default to placing KEX_RSA just above KEX_WARN in the absence of any other information, which should fix 'ssh2-rsa-kex-pref'. While I'm here I've rewritten wprefs() on general principles to remove the needless length limit, since I was touching it anyway. The length limit is still in gprefs (but I've lengthened it just in case). [originally from svn r9181]
2011-06-25 17:37:31 +00:00
const struct keyvalwhere gsslibkeywords[] = {
{ "gssapi32", 0, -1, -1 },
{ "sspi", 1, -1, -1 },
{ "custom", 2, -1, -1 },
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
};
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
AcquireCredentialsHandleA,
(SEC_CHAR *, SEC_CHAR *, ULONG, PVOID,
PVOID, SEC_GET_KEY_FN, PVOID, PCredHandle, PTimeStamp));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
InitializeSecurityContextA,
(PCredHandle, PCtxtHandle, SEC_CHAR *, ULONG, ULONG,
ULONG, PSecBufferDesc, ULONG, PCtxtHandle,
PSecBufferDesc, PULONG, PTimeStamp));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
FreeContextBuffer,
(PVOID));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
FreeCredentialsHandle,
(PCredHandle));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
DeleteSecurityContext,
(PCtxtHandle));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
QueryContextAttributesA,
(PCtxtHandle, ULONG, PVOID));
Move the two existing DECL/GET_foo_FUNCTION macro sets used for dynamic linking on Windows into a single global one, which can cope with function renaming. Intended to enable eventual removal of ANSI-specific DoSomethingA references (although I've not removed any). [originally from svn r8738]
2009-11-08 18:47:41 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
MakeSignature,
(PCtxtHandle, ULONG, PSecBufferDesc, ULONG));
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
DECL_WINDOWS_FUNCTION(static, SECURITY_STATUS,
VerifySignature,
(PCtxtHandle, PSecBufferDesc, ULONG, PULONG));
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
DECL_WINDOWS_FUNCTION(static, DLL_DIRECTORY_COOKIE,
AddDllDirectory,
(PCWSTR));
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
typedef struct winSsh_gss_ctx {
unsigned long maj_stat;
unsigned long min_stat;
CredHandle cred_handle;
CtxtHandle context;
PCtxtHandle context_handle;
TimeStamp expiry;
} winSsh_gss_ctx;
const Ssh_gss_buf gss_mech_krb5={9,"\x2A\x86\x48\x86\xF7\x12\x01\x02\x02"};
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static void ssh_sspi_bind_fns(struct ssh_gss_library *lib);
Avoid crash in MIT Kerberos for Windows on session restart. A user reports that if you have MIT KfW loaded, and your PuTTY session terminates without the PuTTY process exiting, and you select 'Restart Session' from the menu, then a crash occurs inside the Kerberos library itself. Scuttlebutt on the Internet suggested this might be to do with unloading and then reloading the DLL within the process lifetime, which indeed we were doing. Now we avoid doing that for the KfW library in particular, by keeping a tree234 of module handles marked 'never unload this'. This is a workaround at best, but it seems to stop the problem happening in my own tests.
2021-07-01 17:59:44 +00:00
static tree234 *libraries_to_never_unload;
static int library_to_never_unload_cmp(void *av, void *bv)
{
uintptr_t a = (uintptr_t)av, b = (uintptr_t)bv;
return a < b ? -1 : a > b ? +1 : 0;
}
static void ensure_library_tree_exists(void)
{
if (!libraries_to_never_unload)
libraries_to_never_unload = newtree234(library_to_never_unload_cmp);
}
static bool library_is_in_never_unload_tree(HMODULE module)
{
ensure_library_tree_exists();
return find234(libraries_to_never_unload, module, NULL);
}
static void add_library_to_never_unload_tree(HMODULE module)
{
ensure_library_tree_exists();
add234(libraries_to_never_unload, module);
}
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 18:52:21 +00:00
struct ssh_gss_liblist *ssh_gss_setup(Conf *conf)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
HMODULE module;
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
struct ssh_gss_liblist *list = snew(struct ssh_gss_liblist);
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
static HMODULE kernel32_module;
if (!kernel32_module) {
kernel32_module = load_system32_dll("kernel32.dll");
}
Replace mkfiles.pl with a CMake build system. This brings various concrete advantages over the previous system: - consistent support for out-of-tree builds on all platforms - more thorough support for Visual Studio IDE project files - support for Ninja-based builds, which is particularly useful on Windows where the alternative nmake has no parallel option - a really simple set of build instructions that work the same way on all the major platforms (look how much shorter README is!) - better decoupling of the project configuration from the toolchain configuration, so that my Windows cross-building doesn't need (much) special treatment in CMakeLists.txt - configure-time tests on Windows as well as Linux, so that a lot of ad-hoc #ifdefs second-guessing a particular feature's presence from the compiler version can now be replaced by tests of the feature itself Also some longer-term software-engineering advantages: - other people have actually heard of CMake, so they'll be able to produce patches to the new build setup more easily - unlike the old mkfiles.pl, CMake is not my personal problem to maintain - most importantly, mkfiles.pl was just a horrible pile of unmaintainable cruft, which even I found it painful to make changes to or to use, and desperately needed throwing in the bin. I've already thrown away all the variants of it I had in other projects of mine, and was only delaying this one so we could make the 0.75 release branch first. This change comes with a noticeable build-level restructuring. The previous Recipe worked by compiling every object file exactly once, and then making each executable by linking a precisely specified subset of the same object files. But in CMake, that's not the natural way to work - if you write the obvious command that puts the same source file into two executable targets, CMake generates a makefile that compiles it once per target. That can be an advantage, because it gives you the freedom to compile it differently in each case (e.g. with a #define telling it which program it's part of). But in a project that has many executable targets and had carefully contrived to _never_ need to build any module more than once, all it does is bloat the build time pointlessly! To avoid slowing down the build by a large factor, I've put most of the modules of the code base into a collection of static libraries organised vaguely thematically (SSH, other backends, crypto, network, ...). That means all those modules can still be compiled just once each, because once each library is built it's reused unchanged for all the executable targets. One upside of this library-based structure is that now I don't have to manually specify exactly which objects go into which programs any more - it's enough to specify which libraries are needed, and the linker will figure out the fine detail automatically. So there's less maintenance to do in CMakeLists.txt when the source code changes. But that reorganisation also adds fragility, because of the trad Unix linker semantics of walking along the library list once each, so that cyclic references between your libraries will provoke link errors. The current setup builds successfully, but I suspect it only just manages it. (In particular, I've found that MinGW is the most finicky on this score of the Windows compilers I've tried building with. So I've included a MinGW test build in the new-look Buildscr, because otherwise I think there'd be a significant risk of introducing MinGW-only build failures due to library search order, which wasn't a risk in the previous library-free build organisation.) In the longer term I hope to be able to reduce the risk of that, via gradual reorganisation (in particular, breaking up too-monolithic modules, to reduce the risk of knock-on references when you included a module for function A and it also contains function B with an unsatisfied dependency you didn't really need). Ideally I want to reach a state in which the libraries all have sensibly described purposes, a clearly documented (partial) order in which they're permitted to depend on each other, and a specification of what stubs you have to put where if you're leaving one of them out (e.g. nocrypto) and what callbacks you have to define in your non-library objects to satisfy dependencies from things low in the stack (e.g. out_of_memory()). One thing that's gone completely missing in this migration, unfortunately, is the unfinished MacOS port linked against Quartz GTK. That's because it turned out that I can't currently build it myself, on my own Mac: my previous installation of GTK had bit-rotted as a side effect of an Xcode upgrade, and I haven't yet been able to persuade jhbuild to make me a new one. So I can't even build the MacOS port with the _old_ makefiles, and hence, I have no way of checking that the new ones also work. I hope to bring that port back to life at some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
#if !HAVE_ADDDLLDIRECTORY
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
/* Omit the type-check because older MSVCs don't have this function */
GET_WINDOWS_FUNCTION_NO_TYPECHECK(kernel32_module, AddDllDirectory);
#else
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
GET_WINDOWS_FUNCTION(kernel32_module, AddDllDirectory);
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
#endif
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
list->libraries = snewn(3, struct ssh_gss_library);
list->nlibraries = 0;
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
/* MIT Kerberos GSSAPI implementation */
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
module = NULL;
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
HKEY regkey = open_regkey_ro(HKEY_LOCAL_MACHINE,
"SOFTWARE\\MIT\\Kerberos");
if (regkey) {
char *installdir = get_reg_sz(regkey, "InstallDir");
if (installdir) {
char *bindir = dupcat(installdir, "\\bin");
Formatting: normalise to put a space after condition keywords. 'if (thing)' is the local style here, not 'if(thing)'. Similarly with 'for' and 'while'.
2022-12-28 15:32:24 +00:00
if (p_AddDllDirectory) {
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
/* Add MIT Kerberos' path to the DLL search path,
* it loads its own DLLs further down the road */
dup_mb_to_wc, dup_wc_to_mb: remove the 'flags' parameter. This parameter was undocumented, and Windows-specific: its semantics date from before PuTTY was cross-platform, and are "Pass this flags parameter straight through to the Win32 API's conversion functions". So in Windows platform code you can pass flags like MB_USEGLYPHCHARS, but in cross-platform code, you dare not pass anything nonzero at all because the Unix frontend won't recognise it (or, likely, even compile). I've kept the flag for now in the underlying mb_to_wc / wc_to_mb functions. Partly that's because there's one place in the Windows code where the parameter _is_ used; mostly, it's because I'm about to replace those functions anyway, so there's no point in editing all the call sites twice.
2024-09-24 07:46:39 +00:00
wchar_t *dllPath = dup_mb_to_wc(DEFAULT_CODEPAGE, bindir);
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
p_AddDllDirectory(dllPath);
sfree(dllPath);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
char *dllfile = dupcat(bindir, "\\gssapi"MIT_KERB_SUFFIX".dll");
module = LoadLibraryEx(dllfile, NULL,
LOAD_LIBRARY_SEARCH_SYSTEM32 |
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR |
LOAD_LIBRARY_SEARCH_USER_DIRS);
/*
* The MIT Kerberos DLL suffers an internal segfault for
* some reason if you unload and reload one within the
* same process. So, make sure that after we load this
* library, we never free it.
*
* Or rather: after we've loaded it once, if any _further_
* load returns the same module handle, we immediately
* free it again (to prevent the Windows API's internal
* reference count growing without bound). But on the
* other hand we never free it in ssh_gss_cleanup.
*/
if (library_is_in_never_unload_tree(module))
FreeLibrary(module);
add_library_to_never_unload_tree(module);
sfree(dllfile);
sfree(bindir);
sfree(installdir);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
}
Rewrite some manual char-buffer-handling code. In the course of recent refactorings I noticed a couple of cases where we were doing old-fashioned preallocation of a char array with some conservative maximum size, then writing into it via *p++ or similar and hoping we got the calculation right. Now we have strbuf and dupcat, so we shouldn't ever have to do that. Fixed as many cases as I could find by searching for allocations of the form 'snewn(foo, char)'. Particularly worth a mention was the Windows GSSAPI setup code, which was directly using the Win32 Registry API, and looks much more legible using the windows/utils/registry.c wrappers. (But that was why I had to enhance them in the previous commit so as to be able to open registry keys read-only: without that, the open operation would actually fail on this key, which is not user-writable.) Also unix/askpass.c, which was doing a careful reallocation of its buffer to avoid secrets being left behind in the vacated memory - which is now just a matter of ensuring we called strbuf_new_nm().
2022-09-13 14:00:26 +00:00
close_regkey(regkey);
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
if (module) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct ssh_gss_library *lib =
&list->libraries[list->nlibraries++];
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
lib->id = 0;
lib->gsslogmsg = "Using GSSAPI from GSSAPI"MIT_KERB_SUFFIX".DLL";
lib->handle = (void *)module;
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
#define BIND_GSS_FN(name) \
lib->u.gssapi.name = (t_gss_##name) GetProcAddress(module, "gss_" #name)
BIND_GSS_FN(delete_sec_context);
BIND_GSS_FN(display_status);
BIND_GSS_FN(get_mic);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
BIND_GSS_FN(verify_mic);
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
BIND_GSS_FN(import_name);
BIND_GSS_FN(init_sec_context);
BIND_GSS_FN(release_buffer);
BIND_GSS_FN(release_cred);
BIND_GSS_FN(release_name);
Fix for MIT KfW and user-specified GSS DLLs. Fill in all the function pointers for 3rd party Windows GSS DLLs, not just some of them. These were missed out when GSS key exchange was added in d515e4f1a3.
2019-03-19 09:18:37 +00:00
BIND_GSS_FN(acquire_cred);
BIND_GSS_FN(inquire_cred_by_mech);
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
#undef BIND_GSS_FN
ssh_gssapi_bind_fns(lib);
}
/* Microsoft SSPI Implementation */
Create, and use for all loads of system DLLs, a wrapper function called load_system32_dll() which constructs a full pathname for the DLL using GetSystemDirectory. The only DLL load not covered by this change is the one for gssapi32.dll, because that one's not in the system32 directory. [originally from svn r8993]
2010-09-13 08:29:45 +00:00
module = load_system32_dll("secur32.dll");
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
if (module) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct ssh_gss_library *lib =
&list->libraries[list->nlibraries++];
lib->id = 1;
lib->gsslogmsg = "Using SSPI from SECUR32.DLL";
lib->handle = (void *)module;
More assorted Winelib warning fixes. The previous fix on pre-0.77 was non-disruptive and just enough to get through my Coverity build (which uses winelib); but now that I look at the rest of the Winelib build output, there are some further warnings I should fix on main. Most of them are more long/LONG confusion (specific to Winelib, rather than real Windows); also, there's a multiple macro definition in jump-list.c because Winelib defines _PROPVARIANT_INIT_DEFINED_ in place of _PROPVARIANTINIT_DEFINED_ which we were testing for. (Bah.) And in windows/window.c I used wcscmp without including <wchar.h>. In spite of long vs LONG I still had to turn off one or two more DLL-loading typechecks.
2022-05-08 10:06:14 +00:00
/* No typecheck because Winelib thinks one PVOID is a PLUID */
GET_WINDOWS_FUNCTION_NO_TYPECHECK(module, AcquireCredentialsHandleA);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GET_WINDOWS_FUNCTION(module, InitializeSecurityContextA);
GET_WINDOWS_FUNCTION(module, FreeContextBuffer);
GET_WINDOWS_FUNCTION(module, FreeCredentialsHandle);
GET_WINDOWS_FUNCTION(module, DeleteSecurityContext);
GET_WINDOWS_FUNCTION(module, QueryContextAttributesA);
GET_WINDOWS_FUNCTION(module, MakeSignature);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
GET_WINDOWS_FUNCTION(module, VerifySignature);
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ssh_sspi_bind_fns(lib);
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
}
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
/*
* Custom GSSAPI DLL.
*/
module = NULL;
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
Filename *customlib = conf_get_filename(conf, CONF_ssh_gss_custom);
if (!filename_is_null(customlib)) {
const wchar_t *path = customlib->wpath;
Formatting: normalise to put a space after condition keywords. 'if (thing)' is the local style here, not 'if(thing)'. Similarly with 'for' and 'while'.
2022-12-28 15:32:24 +00:00
if (p_AddDllDirectory) {
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
/* Add the custom directory as well in case it chainloads
* some other DLLs (e.g a non-installed MIT Kerberos
* instance) */
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
int pathlen = wcslen(path);
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
while (pathlen > 0 && path[pathlen-1] != L':' &&
path[pathlen-1] != L'\\')
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
pathlen--;
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
if (pathlen > 0 && path[pathlen-1] != L'\\')
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
pathlen--;
if (pathlen > 0) {
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
wchar_t *dirpath = snewn(pathlen + 1, wchar_t);
memcpy(dirpath, path, pathlen * sizeof(wchar_t));
dirpath[pathlen] = L'\0';
p_AddDllDirectory(dirpath);
Fixed GSSAPI authentication. gssapi32.dll from MIT Kerberos as well as from Heimdal both load further DLLs from their installation directories. [SGT: I polished the original patch a bit, in particular replacing manual memory allocation with dup_mb_to_wc. This required a Recipe change to link miscucs.c and winucs.c into more of the tools.]
2017-04-03 19:30:18 +00:00
sfree(dirpath);
}
}
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
module = LoadLibraryExW(path, NULL,
LOAD_LIBRARY_SEARCH_SYSTEM32 |
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR |
LOAD_LIBRARY_SEARCH_USER_DIRS);
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
}
if (module) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
struct ssh_gss_library *lib =
&list->libraries[list->nlibraries++];
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
lib->id = 2;
lib->gsslogmsg = dupprintf("Using GSSAPI from user-specified"
Some support for wide-character filenames in Windows. The Windows version of the Filename structure now contains three versions of the pathname, in UTF-16, UTF-8 and the system code page. Callers can use whichever is most convenient. All uses of filenames for actually opening files now use the UTF-16 version, which means they can tolerate 'exotic' filenames, by which I mean those including Unicode characters outside the host system's CP_ACP default code page. Other uses of Filename structures inside the 'windows' subdirectory do something appropriate, e.g. when printing a filename inside a message box or a console message, we use the UTF-8 version of the filename with the UTF-8 version of the appropriate API. There are three remaining pieces to full Unicode filename support: One is that the cross-platform code has many calls to filename_to_str(), embodying the assumption that a file name can be reliably converted into the unspecified current character set; those will all need changing in some way. Another is that write_setting_filename(), in windows/storage.c, still saves filenames to the Registry as an ordinary REG_SZ in the system code page. So even if an exotic filename were stored in a Conf, that Conf couldn't round-trip via the Registry and back without corrupting that filename by coercing it back to a string that fits in CP_ACP and therefore doesn't represent the same file. This can't be fixed without a compatibility break in the storage format, and I don't want to make a minimal change in that area: if we're going to break compatibility, then we should break it good and hard (the Nanny Ogg principle), and devise a completely fresh storage representation that fixes as many other legacy problems as possible at the same time. So that's my plan, not yet started. The final point, much more obviously, is that we're still short of methods to _construct_ any Filename structures using a Unicode input string! It should now work to enter one in the GUI configurer (either by manual text input or via the file selector), but it won't round-trip through a save and load (as discussed above), and there's still no way to specify one on the command line (the groundwork is laid by commit 10e1ac7752de928 but not yet linked up). But this is a start.
2023-05-28 10:30:59 +00:00
" library '%s'", customlib->cpath);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
lib->handle = (void *)module;
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
#define BIND_GSS_FN(name) \
lib->u.gssapi.name = (t_gss_##name) GetProcAddress(module, "gss_" #name)
BIND_GSS_FN(delete_sec_context);
BIND_GSS_FN(display_status);
BIND_GSS_FN(get_mic);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
BIND_GSS_FN(verify_mic);
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
BIND_GSS_FN(import_name);
BIND_GSS_FN(init_sec_context);
BIND_GSS_FN(release_buffer);
BIND_GSS_FN(release_cred);
BIND_GSS_FN(release_name);
Fix for MIT KfW and user-specified GSS DLLs. Fill in all the function pointers for 3rd party Windows GSS DLLs, not just some of them. These were missed out when GSS key exchange was added in d515e4f1a3.
2019-03-19 09:18:37 +00:00
BIND_GSS_FN(acquire_cred);
BIND_GSS_FN(inquire_cred_by_mech);
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
#undef BIND_GSS_FN
ssh_gssapi_bind_fns(lib);
}
return list;
}
void ssh_gss_cleanup(struct ssh_gss_liblist *list)
{
int i;
/*
* LoadLibrary and FreeLibrary are defined to employ reference
* counting in the case where the same library is repeatedly
* loaded, so even in a multiple-sessions-per-process context
* (not that we currently expect ever to have such a thing on
* Windows) it's safe to naively FreeLibrary everything here
* without worrying about destroying it under the feet of
* another SSH instance still using it.
*/
for (i = 0; i < list->nlibraries; i++) {
Avoid crash in MIT Kerberos for Windows on session restart. A user reports that if you have MIT KfW loaded, and your PuTTY session terminates without the PuTTY process exiting, and you select 'Restart Session' from the menu, then a crash occurs inside the Kerberos library itself. Scuttlebutt on the Internet suggested this might be to do with unloading and then reloading the DLL within the process lifetime, which indeed we were doing. Now we avoid doing that for the KfW library in particular, by keeping a tree234 of module handles marked 'never unload this'. This is a workaround at best, but it seems to stop the problem happening in my own tests.
2021-07-01 17:59:44 +00:00
if (list->libraries[i].id != 0) {
HMODULE module = (HMODULE)list->libraries[i].handle;
if (!library_is_in_never_unload_tree(module))
FreeLibrary(module);
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (list->libraries[i].id == 2) {
/* The 'custom' id involves a dynamically allocated message.
* Note that we must cast away the 'const' to free it. */
sfree((char *)list->libraries[i].gsslogmsg);
}
Cleanups of the GSSAPI support. On Windows, standard GSS libraries are now loaded from standard locations (system32 for SSPI, the registry-stored MIT KfW install location for KfW) rather than using the risky default DLL search path; I've therefore also added an option to manually specify a GSS DLL we haven't heard of (which should in principle Just Work provided it supports proper GSS-API as specified in the RFC). The same option exists on Unix too, because it seemed like too useful an idea to reserve to Windows. In addition, GSSAPI is now documented, and also (unfortunately) its GUI configuration has been moved out into a sub-subpanel on the grounds that it was too big to fit in Auth. [originally from svn r9003]
2010-09-25 07:16:56 +00:00
}
sfree(list->libraries);
sfree(list);
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_indicate_mech(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_buf *mech)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
*mech = gss_mech_krb5;
return SSH_GSS_OK;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_import_name(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
char *host, Ssh_gss_name *srv_name)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
char *pStr;
/* Check hostname */
if (host == NULL) return SSH_GSS_FAILURE;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
/* copy it into form host/FQDN */
Make dupcat() into a variadic macro. Up until now, it's been a variadic _function_, whose argument list consists of 'const char *' ASCIZ strings to concatenate, terminated by one containing a null pointer. Now, that function is dupcat_fn(), and it's wrapped by a C99 variadic _macro_ called dupcat(), which automatically suffixes the null-pointer terminating argument. This has three benefits. Firstly, it's just less effort at every call site. Secondly, it protects against the risk of accidentally leaving off the NULL, causing arbitrary words of stack memory to be dereferenced as char pointers. And thirdly, it protects against the more subtle risk of writing a bare 'NULL' as the terminating argument, instead of casting it explicitly to a pointer. That last one is necessary because C permits the macro NULL to expand to an integer constant such as 0, so NULL by itself may not have pointer type, and worse, it may not be marshalled in a variadic argument list in the same way as a pointer. (For example, on a 64-bit machine it might only occupy 32 bits. And yet, on another 64-bit platform, it might work just fine, so that you don't notice the mistake!) I was inspired to do this by happening to notice one of those bare NULL terminators, and thinking I'd better check if there were any more. Turned out there were quite a few. Now there are none.
2019-10-14 18:42:37 +00:00
pStr = dupcat("host/", host);
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
*srv_name = (Ssh_gss_name) pStr;
return SSH_GSS_OK;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_acquire_cred(struct ssh_gss_library *lib,
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
Ssh_gss_ctx *ctx,
time_t *expiry)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
winSsh_gss_ctx *winctx = snew(winSsh_gss_ctx);
Patch from Iain Patterson: fix crash on Windows when GSSAPI auth is attempted but fails for some reason (such as not having a tgt for the server's realm). [originally from svn r8210]
2008-10-17 20:55:08 +00:00
memset(winctx, 0, sizeof(winSsh_gss_ctx));
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
/* prepare our "wrapper" structure */
winctx->maj_stat = winctx->min_stat = SEC_E_OK;
winctx->context_handle = NULL;
/* Specifying no principal name here means use the credentials of
the current logged-in user */
winctx->maj_stat = p_AcquireCredentialsHandleA(NULL,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
"Kerberos",
SECPKG_CRED_OUTBOUND,
NULL,
NULL,
NULL,
NULL,
&winctx->cred_handle,
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
NULL);
if (winctx->maj_stat != SEC_E_OK) {
p_FreeCredentialsHandle(&winctx->cred_handle);
sfree(winctx);
return SSH_GSS_FAILURE;
}
/* Windows does not return a valid expiration from AcquireCredentials */
if (expiry)
*expiry = GSS_NO_EXPIRATION;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
*ctx = (Ssh_gss_ctx) winctx;
return SSH_GSS_OK;
}
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
static void localexp_to_exp_lifetime(TimeStamp *localexp,
time_t *expiry, unsigned long *lifetime)
{
FILETIME nowUTC;
FILETIME expUTC;
time_t now;
time_t exp;
time_t delta;
if (!lifetime && !expiry)
return;
GetSystemTimeAsFileTime(&nowUTC);
TIME_WIN_TO_POSIX(nowUTC, now);
if (lifetime)
*lifetime = 0;
if (expiry)
*expiry = GSS_NO_EXPIRATION;
Fix a Windows warning on a strange cast. The specific thing that's strange about it is that it's _not_ an error even though the compiler is quite justified in being suspicious about it! The MS APIs define two different structures to have identical formats.
2018-06-03 13:53:29 +00:00
/*
* Type oddity: localexp is a pointer to 'TimeStamp', whereas
* LocalFileTimeToFileTime expects a pointer to FILETIME. However,
* despite having different formal type names from the compiler's
* point of view, these two structures are specified to be
* isomorphic in the MS documentation, so it's legitimate to copy
* between them:
*
* https://msdn.microsoft.com/en-us/library/windows/desktop/aa380511(v=vs.85).aspx
*/
{
FILETIME localexp_ft;
enum { vorpal_sword = 1 / (sizeof(*localexp) == sizeof(localexp_ft)) };
memcpy(&localexp_ft, localexp, sizeof(localexp_ft));
if (!LocalFileTimeToFileTime(&localexp_ft, &expUTC))
return;
}
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
TIME_WIN_TO_POSIX(expUTC, exp);
delta = exp - now;
if (exp == 0 || delta <= 0)
return;
if (expiry)
*expiry = exp;
if (lifetime) {
if (delta <= ULONG_MAX)
*lifetime = (unsigned long)delta;
else
*lifetime = ULONG_MAX;
}
}
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_init_sec_context(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_ctx *ctx,
Ssh_gss_name srv_name,
int to_deleg,
Ssh_gss_buf *recv_tok,
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
Ssh_gss_buf *send_tok,
time_t *expiry,
unsigned long *lifetime)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
winSsh_gss_ctx *winctx = (winSsh_gss_ctx *) *ctx;
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
SecBuffer wsend_tok = {send_tok->length,SECBUFFER_TOKEN,send_tok->value};
SecBuffer wrecv_tok = {recv_tok->length,SECBUFFER_TOKEN,recv_tok->value};
Formatting: fix a few mis-spaced assignments. I spotted one of those in the raw backend the other day, and now I've got round to finding a bunch more and fixing them.
2022-12-28 15:28:36 +00:00
SecBufferDesc output_desc = {SECBUFFER_VERSION,1,&wsend_tok};
SecBufferDesc input_desc = {SECBUFFER_VERSION,1,&wrecv_tok};
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
unsigned long flags=ISC_REQ_MUTUAL_AUTH|ISC_REQ_REPLAY_DETECT|
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ISC_REQ_CONFIDENTIALITY|ISC_REQ_ALLOCATE_MEMORY;
Fixes for Winelib builds. In Winelib, you have to be careful not to say 'unsigned long' where the API expects ULONG, because Winelib doesn't have the Windows LLP64 nature - its unsigned long is 64 bits, whereas ULONG is 32. Also, my local Winelib has <dwmapi.h> (used in the new demo-screenshot system), but doesn't contain some of the definitions inside it. So I've expanded the cmake test of HAVE_DWMAPI_H so that it actually checks the things we need, instead of just the existence of the containing header.
2022-05-08 07:33:53 +00:00
ULONG ret_flags=0;
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
TimeStamp localexp;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
/* check if we have to delegate ... */
if (to_deleg) flags |= ISC_REQ_DELEGATE;
winctx->maj_stat = p_InitializeSecurityContextA(&winctx->cred_handle,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
winctx->context_handle,
(char*) srv_name,
flags,
0, /* reserved */
SECURITY_NATIVE_DREP,
&input_desc,
0, /* reserved */
&winctx->context,
&output_desc,
&ret_flags,
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
&localexp);
localexp_to_exp_lifetime(&localexp, expiry, lifetime);
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
/* prepare for the next round */
winctx->context_handle = &winctx->context;
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
send_tok->value = wsend_tok.pvBuffer;
send_tok->length = wsend_tok.cbBuffer;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
/* check & return our status */
if (winctx->maj_stat==SEC_E_OK) return SSH_GSS_S_COMPLETE;
if (winctx->maj_stat==SEC_I_CONTINUE_NEEDED) return SSH_GSS_S_CONTINUE_NEEDED;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
return SSH_GSS_FAILURE;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_free_tok(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_buf *send_tok)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
/* check input */
if (send_tok == NULL) return SSH_GSS_FAILURE;
/* free Windows buffer */
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
p_FreeContextBuffer(send_tok->value);
SSH_GSS_CLEAR_BUF(send_tok);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
return SSH_GSS_OK;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_release_cred(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_ctx *ctx)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
Formatting: fix a few mis-spaced assignments. I spotted one of those in the raw backend the other day, and now I've got round to finding a bunch more and fixing them.
2022-12-28 15:28:36 +00:00
winSsh_gss_ctx *winctx = (winSsh_gss_ctx *) *ctx;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
/* check input */
if (winctx == NULL) return SSH_GSS_FAILURE;
/* free Windows data */
p_FreeCredentialsHandle(&winctx->cred_handle);
p_DeleteSecurityContext(&winctx->context);
/* delete our "wrapper" structure */
sfree(winctx);
*ctx = (Ssh_gss_ctx) NULL;
return SSH_GSS_OK;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_release_name(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_name *srv_name)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
Formatting: fix a few mis-spaced assignments. I spotted one of those in the raw backend the other day, and now I've got round to finding a bunch more and fixing them.
2022-12-28 15:28:36 +00:00
char *pStr = (char *) *srv_name;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
if (pStr == NULL) return SSH_GSS_FAILURE;
sfree(pStr);
*srv_name = (Ssh_gss_name) NULL;
return SSH_GSS_OK;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_display_status(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_ctx ctx, Ssh_gss_buf *buf)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
winSsh_gss_ctx *winctx = (winSsh_gss_ctx *) ctx;
Giant const-correctness patch of doom! Having found a lot of unfixed constness issues in recent development, I thought perhaps it was time to get proactive, so I compiled the whole codebase with -Wwrite-strings. That turned up a huge load of const problems, which I've fixed in this commit: the Unix build now goes cleanly through with -Wwrite-strings, and the Windows build is as close as I could get it (there are some lingering issues due to occasional Windows API functions like AcquireCredentialsHandle not having the right constness). Notable fallout beyond the purely mechanical changing of types: - the stuff saved by cmdline_save_param() is now explicitly dupstr()ed, and freed in cmdline_run_saved. - I couldn't make both string arguments to cmdline_process_param() const, because it intentionally writes to one of them in the case where it's the argument to -pw (in the vain hope of being at least slightly friendly to 'ps'), so elsewhere I had to temporarily dupstr() something for the sake of passing it to that function - I had to invent a silly parallel version of const_cmp() so I could pass const string literals in to lookup functions. - stripslashes() in pscp.c and psftp.c has the annoying strchr nature
2015-05-15 10:15:42 +00:00
const char *msg;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
if (winctx == NULL) return SSH_GSS_FAILURE;
/* decode the error code */
switch (winctx->maj_stat) {
case SEC_E_OK: msg="SSPI status OK"; break;
case SEC_E_INVALID_HANDLE: msg="The handle passed to the function"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" is invalid.";
break;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
case SEC_E_TARGET_UNKNOWN: msg="The target was not recognized."; break;
case SEC_E_LOGON_DENIED: msg="The logon failed."; break;
case SEC_E_INTERNAL_ERROR: msg="The Local Security Authority cannot"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" be contacted.";
break;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
case SEC_E_NO_CREDENTIALS: msg="No credentials are available in the"
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
" security package.";
break;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
case SEC_E_NO_AUTHENTICATING_AUTHORITY:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
msg="No authority could be contacted for authentication."
"The domain name of the authenticating party could be wrong,"
" the domain could be unreachable, or there might have been"
" a trust relationship failure.";
break;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
case SEC_E_INSUFFICIENT_MEMORY:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
msg="One or more of the SecBufferDesc structures passed as"
" an OUT parameter has a buffer that is too small.";
break;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
case SEC_E_INVALID_TOKEN:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
msg="The error is due to a malformed input token, such as a"
" token corrupted in transit, a token"
" of incorrect size, or a token passed into the wrong"
" security package. Passing a token to"
" the wrong package can happen if client and server did not"
" negotiate the proper security package.";
break;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
default:
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
msg = "Internal SSPI error";
break;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
}
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
buf->value = dupstr(msg);
Fix a Windows-specific GSS crash introduced in r8326, which (again) apparently triggers in failure cases. Patch by Iain Patterson. [originally from svn r8336] [r8326 == 81dafd906eb4817393fabe4d408c16de8586de8b]
2008-11-26 14:11:49 +00:00
buf->length = strlen(buf->value);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
return SSH_GSS_OK;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_get_mic(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_ctx ctx, Ssh_gss_buf *buf,
Ssh_gss_buf *hash)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
Formatting: fix a few mis-spaced assignments. I spotted one of those in the raw backend the other day, and now I've got round to finding a bunch more and fixing them.
2022-12-28 15:28:36 +00:00
winSsh_gss_ctx *winctx = (winSsh_gss_ctx *) ctx;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
SecPkgContext_Sizes ContextSizes;
SecBufferDesc InputBufferDescriptor;
SecBuffer InputSecurityToken[2];
if (winctx == NULL) return SSH_GSS_FAILURE;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
winctx->maj_stat = 0;
memset(&ContextSizes, 0, sizeof(ContextSizes));
winctx->maj_stat = p_QueryContextAttributesA(&winctx->context,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
SECPKG_ATTR_SIZES,
&ContextSizes);
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
if (winctx->maj_stat != SEC_E_OK ||
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
ContextSizes.cbMaxSignature == 0)
return winctx->maj_stat;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
InputBufferDescriptor.cBuffers = 2;
InputBufferDescriptor.pBuffers = InputSecurityToken;
InputBufferDescriptor.ulVersion = SECBUFFER_VERSION;
InputSecurityToken[0].BufferType = SECBUFFER_DATA;
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
InputSecurityToken[0].cbBuffer = buf->length;
InputSecurityToken[0].pvBuffer = buf->value;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
InputSecurityToken[1].BufferType = SECBUFFER_TOKEN;
InputSecurityToken[1].cbBuffer = ContextSizes.cbMaxSignature;
InputSecurityToken[1].pvBuffer = snewn(ContextSizes.cbMaxSignature, char);
winctx->maj_stat = p_MakeSignature(&winctx->context,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
0,
&InputBufferDescriptor,
0);
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
if (winctx->maj_stat == SEC_E_OK) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
hash->length = InputSecurityToken[1].cbBuffer;
hash->value = InputSecurityToken[1].pvBuffer;
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
}
return winctx->maj_stat;
}
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
static Ssh_gss_stat ssh_sspi_verify_mic(struct ssh_gss_library *lib,
Ssh_gss_ctx ctx,
Ssh_gss_buf *buf,
Ssh_gss_buf *mic)
{
Formatting: fix a few mis-spaced assignments. I spotted one of those in the raw backend the other day, and now I've got round to finding a bunch more and fixing them.
2022-12-28 15:28:36 +00:00
winSsh_gss_ctx *winctx = (winSsh_gss_ctx *) ctx;
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
SecBufferDesc InputBufferDescriptor;
SecBuffer InputSecurityToken[2];
ULONG qop;
if (winctx == NULL) return SSH_GSS_FAILURE;
winctx->maj_stat = 0;
InputBufferDescriptor.cBuffers = 2;
InputBufferDescriptor.pBuffers = InputSecurityToken;
InputBufferDescriptor.ulVersion = SECBUFFER_VERSION;
InputSecurityToken[0].BufferType = SECBUFFER_DATA;
InputSecurityToken[0].cbBuffer = buf->length;
InputSecurityToken[0].pvBuffer = buf->value;
InputSecurityToken[1].BufferType = SECBUFFER_TOKEN;
InputSecurityToken[1].cbBuffer = mic->length;
InputSecurityToken[1].pvBuffer = mic->value;
winctx->maj_stat = p_VerifySignature(&winctx->context,
Formatting: realign run-on parenthesised stuff. My bulk indentation check also turned up a lot of cases where a run-on function call or if statement didn't have its later lines aligned correctly relative to the open paren. I think this is quite easy to do by getting things out of sync (editing the first line of the function call and forgetting to update the rest, perhaps even because you never _saw_ the rest during a search-replace). But a few didn't quite fit into that pattern, in particular an outright misleading case in unix/askpass.c where the second line of a call was aligned neatly below the _wrong_ one of the open parens on the opening line. Restored as many alignments as I could easily find.
2022-08-03 19:48:46 +00:00
&InputBufferDescriptor,
0, &qop);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
return winctx->maj_stat;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static Ssh_gss_stat ssh_sspi_free_mic(struct ssh_gss_library *lib,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
Ssh_gss_buf *hash)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
Change how we handle the Ssh_gss_buf type. Previously, we defined it ourselves, but on Unix then assumed it was compatible with the system's gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep something similar to the existing behaviour on Windows. This requires renaming a couple of the fields in Ssh_gss_buf, and hence fixing all the references. Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal). Not tested on Windows because neither mingw32 nor winegcc worked out of the box for me. I think the Windows changes are all syntactic, though, so if this compiles it should work no worse than before. [originally from svn r8326]
2008-11-24 23:44:55 +00:00
sfree(hash->value);
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
return SSH_GSS_OK;
}
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
static void ssh_sspi_bind_fns(struct ssh_gss_library *lib)
{
lib->indicate_mech = ssh_sspi_indicate_mech;
lib->import_name = ssh_sspi_import_name;
lib->release_name = ssh_sspi_release_name;
lib->init_sec_context = ssh_sspi_init_sec_context;
lib->free_tok = ssh_sspi_free_tok;
lib->acquire_cred = ssh_sspi_acquire_cred;
lib->release_cred = ssh_sspi_release_cred;
lib->get_mic = ssh_sspi_get_mic;
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
lib->verify_mic = ssh_sspi_verify_mic;
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
lib->free_mic = ssh_sspi_free_mic;
lib->display_status = ssh_sspi_display_status;
}
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
#else
/* Dummy function so this source file defines something if NO_GSSAPI
is defined. */
Patch from Alejandro Sedeno, somewhat modified by me, which reorganises the GSSAPI support so that it handles alternative implementations of the GSS-API. In particular, this means PuTTY can now talk to MIT Kerberos for Windows instead of being limited to SSPI. I don't know for sure whether further tweaking will be needed (to the UI, most likely, or to automatic selection of credentials), but testing reports suggest it's now at least worth committing to trunk to get it more widely tested. [originally from svn r8952]
2010-05-19 18:22:17 +00:00
void ssh_gss_init(void)
Initial commit of GSSAPI Kerberos support. [originally from svn r8138]
2008-08-10 13:10:31 +00:00
{
}
#endif
Reference in New Issue Copy Permalink