[OpenAFS-devel] Multi-User Windows 2000 Token security
Shyh-Wei Luan
luan@almaden.ibm.com
Tue, 2 Oct 2001 18:09:12 -0700
--0__=07BBE04BDFFF13FE8f9e8a93df938690918c07BBE04BDFFF13FE
Content-type: text/plain; charset=US-ASCII
Here is my attempt at a brief description of the Windows 2000 client token
security problem and a proposed solution.
Let me start with a scenario of how it works in the simple case (e.g., for
Windows NT).
(1) The cache manager starts and registers itself as an SMB server with the
name \\<computer name>-afs.
(2) When a user does an AFS logon (through klog or the AFS authentication
panel), the AFS token is passed to the cache manager using a pioctl call,
which is implemented as an SMB write request to a special filename
recognized by the cache manager. The SMB write request is sent within an
SMB session. The Windows SMB client sets up the session with the AFS cache
manager, during which a user name and a new SMB session Id are presented.
By default the user name is the same as the Windows logon name of the user.
The cache manager does not perform authentication of the SMB user name and
does not ask for an SMB password. It assigns this user a "User Id" which
the Windows SMB client will use in sending the token-passing SMB write
request and all future requests for the same user. The cache manager
associates the received AFS token with the Session and User Id pair. From
now on, all SMB requests with this Session & User Id's are serviced using
the associated AFS token.
The above scheme is sufficient for Windows NT because it keeps a single SMB
session while the users is logged on. However, it is broken on Windows
2000 because Windows spontaneously starts new sessions with connected
servers which essentially invalidate established User and Session Id's.
User names are sent to the cache manager again in this process and the
cache manager (the SMB server) needs to map these users to existing AFS
tokens. This was not done in early versions of AFS Windows 2000 client,
and users experienced lost tokens.
The current Open AFS approach to this problem maps <user name, machine
name> pairs to AFS tokens. When a new AFS token is sent through the
token-passing SMB request to the cache manager, the token is tagged with
the user name and machine name of the SMB request. Subsequently, when new
Session & User Id's are generated when setting up a new SMB session, the
<user name, machine name> tuple in the SMB message is used to find the
associated AFS token(s) for this new Session & User Id's.
It might sound like the problem is solved. But it is not. This approach
has a security hole because Windows SMB client allows a user to choose any
user name when connecting to SMB shares, and the cache manager trusts the
use of the name to be legitimate without challenging the user. This allows
a user to use another's user name to get access to his tokens. Note that
this problem does not affect machines that are not shared by multiple
users.
PROPOSED SOLUTION:
One possible solution we are experimenting with is to use secret SMB user
names that are dynamically generated. Before a user's AFS token is passed
to the cache manager the first time, the AFS logon program selects a
randomly generated long string as the SMB user name. When the token is
passed to the cache manager, this token will be tagged with the secret user
name. The user does not need to know what the secret name is and never
needs to type it in. There is no reason for the user to change his SMB user
name for accessing \\<computer name>-afs. Therefore, in all new sessions
or session setups that Windows spontaneously create, the same secret user
name and machine name will be used and the correct AFS token(s) will be
mapped. Attempts to use other user's tokens will be prevented because
there will be no way to know what the dynamically generated names are.
We need to confirm that the SMB client on Windows 2000 will never reveal
the list of SMB user names that are in use (at least not to non-privileged
users). We think it would be a security exposure of the Windows 2000 OS
itself otherwise. Nevertheless we need to know. Suggestions and comments
are welcome!
Shyh-Wei Luan
Leif Johansson <leifj@it.su.se>@openafs.org on 10/01/2001 08:19:34 AM
Sent by: openafs-devel-admin@openafs.org
To: Sam Hartman <hartmans@mekinok.com>
cc: James Peterson/Almaden/IBM@IBMUS, openafs-devel@openafs.org, Marc
Dionne <dionne@cs.wisc.edu>, viklund@it.su.se, rjons@it.su.se, Shyh-
Wei Luan/Almaden/IBM@IBMUS
Subject: Re: [OpenAFS-devel] Multi-User Windows 2000 Token security
On Thu, Sep 27, 2001 at 11:15:06AM -0400, Sam Hartman wrote:
> >>>>> "Leif" == Leif Johansson <leifj@it.su.se> writes:
>
> Leif> On Wed, Sep 26, 2001 at 05:24:42PM -0700, James Peterson
> Leif> wrote:
> >> As others have mentioned there is a security problem with
> >> Windows 2000 in a multi-user environment.
> >>
> >> The only work around is, for multi-user Windows 2000 configure
> >> it so that all Logon require a restart.
> >>
>
> Leif> If we can trust the security (?) of the local filesystem we
> Leif> could presumably replace klog with kinit+afslog (I am
> Leif> temporarily ignoring the problems of getting a
> Leif> multiuser-safe kerberos on windows) and do and afslog on
> Leif> each smb session start. Would this be possible or have I
> Leif> just assumed someting unrealistic, like access to windows
> Leif> sources... ??
>
> I don't think you need to trust local filesystem. I think you could
> recompile kenh's aklog against a version of MIT Kerberos that supports
> ccapi and have a solution for at least krb5.
I thought the issue was that the session can be split over multiple
smb-sessions which each needs access to the token. If we could force
each smb-session to do the equivalent of an afslog/aklog using a normal
krb5 ccache file we could go back to having a separate token for each
smb-session.
MVH leifj
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
--0__=07BBE04BDFFF13FE8f9e8a93df938690918c07BBE04BDFFF13FE
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
<html><body><br>
<br>
Here is my attempt at a brief description of the Windows 2000 client token security problem and a proposed solution.<br>
<br>
Let me start with a scenario of how it works in the simple case (e.g., for Windows NT).<br>
<br>
(1) The cache manager starts and registers itself as an SMB server with the name \\<computer name>-afs.<br>
(2) When a user does an AFS logon (through klog or the AFS authentication panel), the AFS token is passed to the cache manager using a pioctl call, which is implemented as an SMB write request to a special filename recognized by the cache manager. The SMB write request is sent within an SMB session. The Windows SMB client sets up the session with the AFS cache manager, during which a user name and a new SMB session Id are presented. By default the user name is the same as the Windows logon name of the user. The cache manager does not perform authentication of the SMB user name and does not ask for an SMB password. It assigns this user a "User Id" which the Windows SMB client will use in sending the token-passing SMB write request and all future requests for the same user. The cache manager associates the received AFS token with the Session and User Id pair. From now on, all SMB requests with this Session & User Id's are serviced using the associated AFS tok!
en. <br>
<br>
The above scheme is sufficient for Windows NT because it keeps a single SMB session while the users is logged on. However, it is broken on Windows 2000 because Windows spontaneously starts new sessions with connected servers which essentially invalidate established User and Session Id's. User names are sent to the cache manager again in this process and the cache manager (the SMB server) needs to map these users to existing AFS tokens. This was not done in early versions of AFS Windows 2000 client, and users experienced lost tokens.<br>
<br>
The current Open AFS approach to this problem maps <user name, machine name> pairs to AFS tokens. When a new AFS token is sent through the token-passing SMB request to the cache manager, the token is tagged with the user name and machine name of the SMB request. Subsequently, when new Session & User Id's are generated when setting up a new SMB session, the <user name, machine name> tuple in the SMB message is used to find the associated AFS token(s) for this new Session & User Id's.<br>
<br>
It might sound like the problem is solved. But it is not. This approach has a security hole because Windows SMB client allows a user to choose any user name when connecting to SMB shares, and the cache manager trusts the use of the name to be legitimate without challenging the user. This allows a user to use another's user name to get access to his tokens. Note that this problem does not affect machines that are not shared by multiple users.<br>
<br>
PROPOSED SOLUTION:<br>
<br>
One possible solution we are experimenting with is to use secret SMB user names that are dynamically generated. Before a user's AFS token is passed to the cache manager the first time, the AFS logon program selects a randomly generated long string as the SMB user name. When the token is passed to the cache manager, this token will be tagged with the secret user name. The user does not need to know what the secret name is and never needs to type it in. There is no reason for the user to change his SMB user name for accessing \\<computer name>-afs. Therefore, in all new sessions or session setups that Windows spontaneously create, the same secret user name and machine name will be used and the correct AFS token(s) will be mapped. Attempts to use other user's tokens will be prevented because there will be no way to know what the dynamically generated names are.<br>
<br>
We need to confirm that the SMB client on Windows 2000 will never reveal the list of SMB user names that are in use (at least not to non-privileged users). We think it would be a security exposure of the Windows 2000 OS itself otherwise. Nevertheless we need to know. Suggestions and comments are welcome!<br>
<br>
Shyh-Wei Luan<br>
<br>
<p><font size=2 color="#800080">Sent by: openafs-devel-admin@openafs.org</font>
<p><font size=2 color="#800080">To: </font><font size=2>Sam Hartman <hartmans@mekinok.com></font><br>
<font size=2 color="#800080">cc: </font><font size=2>James Peterson/Almaden/IBM@IBMUS, openafs-devel@openafs.org, Marc Dionne <dionne@cs.wisc.edu>, viklund@it.su.se, rjons@it.su.se, Shyh-Wei Luan/Almaden/IBM@IBMUS</font><font size=2 color="#800080"> </font><br>
<font size=2 color="#800080">Subject: </font><font size=2>Re: [OpenAFS-devel] Multi-User Windows 2000 Token security</font><br>
<br>
<br>
<br>
<tt>On Thu, Sep 27, 2001 at 11:15:06AM -0400, Sam Hartman wrote:<br>
> >>>>> "Leif" == Leif Johansson <leifj@it.su.se> writes:<br>
><br>
> Leif> On Wed, Sep 26, 2001 at 05:24:42PM -0700, James Peterson<br>
> Leif> wrote:<br>
> >> As others have mentioned there is a security problem with<br>
> >> Windows 2000 in a multi-user environment.<br>
> >><br>
> >> The only work around is, for multi-user Windows 2000 configure<br>
> >> it so that all Logon require a restart.<br>
> >><br>
><br>
> Leif> If we can trust the security (?) of the local filesystem we<br>
> Leif> could presumably replace klog with kinit+afslog (I am<br>
> Leif> temporarily ignoring the problems of getting a<br>
> Leif> multiuser-safe kerberos on windows) and do and afslog on<br>
> Leif> each smb session start. Would this be possible or have I<br>
> Leif> just assumed someting unrealistic, like access to windows<br>
> Leif> sources... ??<br>
><br>
> I don't think you need to trust local filesystem. I think you could<br>
> recompile kenh's aklog against a version of MIT Kerberos that supports<br>
> ccapi and have a solution for at least krb5.<br>
</tt><br>
<tt>I thought the issue was that the session can be split over multiple<br>
smb-sessions which each needs access to the token. If we could force<br>
each smb-session to do the equivalent of an afslog/aklog using a normal<br>
krb5 ccache file we could go back to having a separate token for each<br>
smb-session.<br>
</tt><br>
<tt> MVH leifj<br>
_______________________________________________<br>
OpenAFS-devel mailing list<br>
OpenAFS-devel@openafs.org<br>
</tt><tt><a href="https://lists.openafs.org/mailman/listinfo/openafs-devel">https://lists.openafs.org/mailman/listinfo/openafs-devel</a></tt><br>
<br>
</body></html>
--0__=07BBE04BDFFF13FE8f9e8a93df938690918c07BBE04BDFFF13FE--