[cifs-protocol] [REG:111101553031054] SystemLibraryDTC

[Jay Simmons]

Please let me know if there are any other questions - otherwise I'll be resolving the issue as resolved from our side.  Thanks!  - Jay

-----Original Message-----
From: Jay Simmons 
Sent: Wednesday, June 20, 2012 8:35 AM
To: 'Andrew Bartlett'; Bryan Burgin
Cc: 'cifs-protocol at cifs.org'; MSSolve Case Email; Tarun Chopra
Subject: RE: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC

* So, does this mean that the 'new' behaviour of NT_STATUS_NO_USER_SESSION_KEY is due to the stack being co-incidentally zero at this point, but that this might not always be the case?

Yes that is mostly correct.  To be completely accurate:   the stack buffer in question on WS08 and later is not explicitly or implicitly zero’d – it’s actually an uninitialized buffer filled with semi-random stuff from previous stack call frames.   (The buffer contents might still be semi-predictable for some OS versions\architectures, so it doesn't change the discussion that much.)

* If windows ever creates a privileged, unsigned lsa connection over TCP, you could hijack it and use this to call querysecret to extract a secret value from the DC 'unencrypted'. 
* I guess it's a long shot (lots of other avenues for attack), but it's one that might be possible. 

Yes anything is possible but this also seem likes a long shot to me.  The Windows client-side code is hard-coded to always use SMB not TCP - so it would be hard to subvert a Windows client machine into using TCP in such a situation unless the client machine was already compromised.    And the client still needs to be authorized to perform the operation in the first place, so a compromised client doesn't need to resort to such trickery - it could just call the DC in the normal fashion and unencrypt the results.    

* The annoying thing is that this issue *prevents* the use of RPC transport layer security for the most sensitive operations.  I wanted to sign certain privileged connections setting up trusts (to prevent hijacking), but I can't as it means I have to use SystemLibraryDTC (and expose the secret) and some servers may reject it anyway.  I also can't seal because some servers will reject it as NT_STATUS_NO_USER_SESSION_KEY.
* It would actually be better if SystemLibraryDTC was abolished, and replaced by the session key as used in DRSUAPI.  This would then allow these calls to be made over secure RPC.

I understand the annoyance factor and the appeal of being able to securely call these methods over TCP – but these protocols were designed and written to be used only over SMB, so calling them over TCP is basically non-tested and non-supported.    “SystemLibraryDTC” really just an artifact of the local LRPC implementation that was never intended to be externally visible (and would not be except for a Windows bug).    To be honest, we are not investing much time in MS-SAMR;  my recommendation would be to use LDAP which is a much more modern and flexible protocol, and does not suffer from such historical MS-SAMR\SMB limitations.    

Do you have any other questions around this issue?

Thx,
Jay Simmons

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Friday, June 15, 2012 5:33 AM
To: Bryan Burgin
Cc: Jay Simmons; 'cifs-protocol at cifs.org'; MSSolve Case Email; Tarun Chopra
Subject: RE: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC

On Tue, 2012-06-12 at 15:56 +0000, Bryan Burgin wrote:
> [+Jay Simmons]
> 
> Hi Andrew.  We made some progress on this issue.  Below is the response from Jay Simmons who researched this for you.  Jay agreed to join this thread.
> 
> "Thanks for your extreme patience on this issue.    Your findings were correct – Windows servers up through Windows Server 2003 will attempt to use the well-known key “SystemLibraryDTC” to decrypt data, if no SMB session has been established for the incoming client (which is usually the case when invoking RPC calls over TCP).    Windows servers after WS03 behave only slightly better – for those OS versions, a “random” key will be used whose contents depend on memory\stack contents at the time the call is made.    While the server-side behavior is not ideal, the client must still first be authenticated and authorized for the operation (eg, password set) to be allowed.   Therefore the security vulnerability lies in the fact that the client chose to expose sensitive data to a potential wire-sniffing attack, by using an insecure means of making the call in the first place (this assumes that RPC-level transport security was not leveraged to protect the data).   Note that we explicitly document in MS-SAMR (see section 2.1) which calls must be made using RPC-over-SMB, at least in part for preventing exactly this problem.    No Windows client will ever invoke such a call (ie, one with SMB-session-key encrypted parameters) without an SMB session.    
> 
> "This probably goes without saying, but please do not attempt to rely on this behavior as it will likely be blocked at some point in the future.  
> 
> "Feedback welcomed, especially if you think we have misunderstood the security implications of the issue."

So, does this mean that the 'new' behaviour of NT_STATUS_NO_USER_SESSION_KEY is due to the stack being co-incidentally zero at this point, but that this might not always be the case?

If windows ever creates a privileged, unsigned lsa connection over TCP, you could hijack it and use this to call querysecret to extract a secret value from the DC 'unencrypted'. 

I guess it's a long shot (lots of other avenues for attack), but it's one that might be possible. 

The annoying thing is that this issue *prevents* the use of RPC transport layer security for the most sensitive operations.  I wanted to sign certain privileged connections setting up trusts (to prevent hijacking), but I can't as it means I have to use SystemLibraryDTC (and expose the secret) and some servers may reject it anyway.  I also can't seal because some servers will reject it as NT_STATUS_NO_USER_SESSION_KEY.

It would actually be better if SystemLibraryDTC was abolished, and replaced by the session key as used in DRSUAPI.  This would then allow these calls to be made over secure RPC. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org