[cifs-protocol] [EXTERNAL] Re: [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details - TrackingID#2309080040007879
Andrew Bartlett
abartlet at samba.org
Wed Sep 20 18:57:28 UTC 2023
Thanks so much for your time and investigation Jeff,
Please do continue to investigate, yes, this is the correct area we
need described.
We know that windows will fail if step 14 does not get the 'correct
(for a server that does not implement level 2)' error code from <197>
step 2. But if it does get the 'correct' fault/error code, what is the
correct way to know that the negotiation was still fit to continue
against a down-level server. That is, we are missing a step 16 for
the client behaviour in the failure case on 14/15.
We need more than initial assumptions as this is a security behaviour
we need to get right, while maintaining service against both patched
and unpatched (Samba is not yet patched on the server side) servers.
Thanks,
Andrew Bartlett
On Wed, 2023-09-20 at 18:37 +0000, Jeff McCashland (He/him) via cifs-
protocol wrote:
> Hi Andrew,
> Just to be clear, are you referring to this behavior note for section
> 3.5.4.4.10 NetrLogonGetCapabilities (Opnum 21)?:
> <197> Section 3.5.4.4.10: Windows RPC layer may return its
> own error code instead of STATUS_INVALID_LEVEL. The error code that a
> client gets depends on where the calling application is getting the
> error from: 1. If the client is running on Windows and
> calling Windows RPC APIs, they may get the Win32 error code
> RPC_S_INVALID_TAG ([MS-ERREF] section 2.2). 2. If the
> client is running on third-party operating systems or getting the
> error code from the wire, they may get nca_s_fault_invalid_tag
> (0x1C000006). ([C706-RSCP]). 3. The conversion between
> the on-the-wire nca_s_fault_invalid_tag and Win32 error code
> RPC_S_INVALID_TAG is specified in [MS-RPCE] section 3.1.1.5.5.
> Since the original question cited section 3.1.4.1 Session-Key
> Negotiation, I gather you're asking how the Client should proceed if
> an error is returned from NetrLogonGetCapabilities in Session-Key
> Negotiation steps 11 and/or 14, and if the behavior is different
> based on the different possible errors returned.
> 3.1.4.1 Session-Key Negotiation Session-key
> negotiation between a client and a server is performed over an
> unprotected RPC channel. The following diagram illustrates the
> negotiation flow.[...] 11. The client calls the
> NetrLogonGetCapabilities method to get Negotiaged flags by setting
> QueryLevel to 1 (section 3.4.5.2.10). 12. The server
> SHOULD<72> return the negotiated flags for the current
> exchange. 13. The client SHOULD<73> compare the received
> ServerCapabilities (section 3.5.4.4.10) with the negotiated
> NegotiateFlags (section 3.5.4.4.2), and if there is a difference, the
> session key negotiation is aborted. 14. The client calls
> the NetrLogonGetCapabilities method to get Requested flags by setting
> QueryLevel to 2 (section 3.4.5.2.10). 15. The server
> SHOULD<74> return the client capabilities received during a
> negotiation request from client.
> Since returning the results is stated as SHOULD, my initial
> assumption is that if an error is returned, the client simply does
> not return results.
> Best regards,Jeff McCashland (He/him) | Senior Escalation Engineer |
> Microsoft Protocol Open Specifications TeamPhone: +1 (425) 703-8300
> x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and
> Canada)Local country phone number found here:
> http://support.microsoft.com/globalenglish | Extension 1138300
> -----Original Message-----From: Andrew Bartlett <abartlet at samba.org>S
> ent: Monday, September 18, 2023 3:04 PMTo: Jeff McCashland (He/him) <
> jeffm at microsoft.com>; metze <metze at samba.org>; Ralph Böhme <
> slow at samba.org>Cc: cifs-protocol at lists.samba.org; Microsoft Support <
> supportmail at microsoft.com>Subject: [EXTERNAL] Re: [cifs-protocol]
> [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details -
> TrackingID#2309080040007879
> So, what metze is getting as is that the details of what to do if the
> behaviour in note <197> is triggered. If the correct fault (mapped
> to an error code) is received by the client, due to noticing an older
> unpatched server (or Samba), what is the secure and correct
> behaviour?
> Andrew Bartlett
> On Mon, 2023-09-18 at 15:55 +0000, Jeff McCashland (He/him) via cifs-
> protocol wrote:
> > Hi Metze,
> > I haven't seen any response to my request below.
> > Could you give me an idea of when you may be able to provide
> > moreinformation on your [MS-NRPC] concern?
> > Best regards,Jeff McCashland (He/him) | Senior Escalation Engineer
> > | MicrosoftProtocol Open Specifications TeamPhone: +1 (425) 703-
> > 8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time
> > (US and Canada)Local country phone number found here:http://suppo/
> > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.c
> > om%7C0c04f797e40e47e482ff08dbb8931c2c%7C72f988bf86f141af91ab2d7cd01
> > 1db47%7C1%7C0%7C638306714208453677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > C%7C%7C&sdata=4gRUKI2XhxFHCTSs0ELokyBuTZ700fJgxsJ2n5AJmB0%3D&reserv
> > ed=0 | Extension 1138300
> > -----Original Message-----From: Jeff McCashland (He/him)Sent:
> > Tuesday, September 12, 2023 3:49 PMTo: Stefan Metzmacher <
> > metze at samba.org
> > > ; Ralph Böhme <
> > slow at samba.org
> > Cc:cifs-protocol at lists.samba.org
> > ; Microsoft Support <supportmail at microsoft.com
> > Subject: RE: [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking
> > details- TrackingID#2309080040007879
> > Hi Metze,
> > I have reviewed [MS-NRPC] section 3.1.4.1 Session-Key negotiation,
> > andI don't seen any mention of downgrade at all. I admit this is
> > adocument I'm not deeply familiar with.
> > Could you specify which steps you are referring to, what you mean
> > by adowngrade, and specifically where you feel more detail is
> > needed?
> > Best regards,Jeff McCashland (He/him) | Senior Escalation Engineer
> > | MicrosoftProtocol Open Specifications TeamPhone: +1 (425) 703-
> > 8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time
> > (US and Canada) Local country phone number foundhere:http://suppo/
> > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.c
> > om%7C0c04f797e40e47e482ff08dbb8931c2c%7C72f988bf86f141af91ab2d7cd01
> > 1db47%7C1%7C0%7C638306714208453677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > C%7C%7C&sdata=4gRUKI2XhxFHCTSs0ELokyBuTZ700fJgxsJ2n5AJmB0%3D&reserv
> > ed=0 | Extension 1138300
> > -----Original Message-----From: Jeff McCashland (He/him)Sent:
> > Friday, September 8, 2023 1:46 PMTo: Stefan Metzmacher <
> > metze at samba.org
> > > ; Ralph Böhme <
> > slow at samba.org
> > Cc:cifs-protocol at lists.samba.org
> > ; Microsoft Support <supportmail at microsoft.com
> > Subject: [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details
> > -TrackingID#2309080040007879
> > [support on CC, updated Subject with new SR ID]
> > Hi Metze,
> > We have created SR 2309080040007879 to track this issue. I will
> > lookinto it and get back to you.
> > Best regards,Jeff McCashland (He/him) | Senior Escalation Engineer
> > | MicrosoftProtocol Open Specifications TeamPhone: +1 (425) 703-
> > 8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time
> > (US and Canada) Local country phone number foundhere:http://suppo/
> > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.c
> > om%7C0c04f797e40e47e482ff08dbb8931c2c%7C72f988bf86f141af91ab2d7cd01
> > 1db47%7C1%7C0%7C638306714208453677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > C%7C%7C&sdata=4gRUKI2XhxFHCTSs0ELokyBuTZ700fJgxsJ2n5AJmB0%3D&reserv
> > ed=0 | Extension 1138300
> > -----Original Message-----From: Stefan Metzmacher <metze at samba.org
> > Sent: Thursday, September 7, 2023 11:27 PMTo: Jeff McCashland
> > (He/him) <jeffm at microsoft.com
> > > ; Ralph Böhme <
> > slow at samba.org
> > Cc:cifs-protocol at lists.samba.org
> >
> > Subject: [EXTERNAL] Re: [MS-NRPC]
> > DCERPC_NCA_S_FAULT_INVALID_TAGreturned instead of
> > STATUS_INVALID_LEVEL -TrackingID#2307200040007944
> > Hi Jeff,
> > > We have updated [MS-NRPC] for the next release to address
> > > thisissue. We have added the following Behavior Note to
> > > section3.5.4.4.10:
> > > <197> Section 3.5.4.4.10: Windows RPC layer may return its own
> > > errorcode instead of STATUS_INVALID_LEVEL. The error code that a
> > > clientgets depends on where the calling application is getting
> > > the errorfrom:1. If the client is running on Windows and calling
> > > Windows RPC APIs,they may get the Win32 error code
> > > RPC_S_INVALID_TAG ([MS- ERREF]section 2.2).2. If the client is
> > > running on third-party operating systems orgetting the error code
> > > from the wire, they may getnca_s_fault_invalid_tag (0x1C000006).
> > > ([C706-RSCP] DCE 1.1: RemoteProcedure Call - Reject Status Codes
> > > and Parameters).3. The conversion between the on-the-wire
> > > nca_s_fault_invalid_tagand Win32 error code RPC_S_INVALID_TAG is
> > > specified in [MS-RPCE]Section 3.1.1.5.5.
> > > I hope that helps.
> >
> > Yes, thanks!
> > In addition I think 3.1.4.1 Session-Key Negotiation could be much
> > moreverbose in a way that it would describe how safe downgrade is
> > possibleand how an unsafe downgrade is detected.
> > metze_______________________________________________cifs-protocol
> > mailing listcifs-protocol at lists.samba.org
> >
> > https://list/
> > s.samba.org%2Fmailman%2Flistinfo%2Fcifs-
> > protocol&data=05%7C01%7Cjeffm%40microsoft.com%7C0c04f797e40e47e482f
> > f08dbb8931c2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63830671
> > 4208453677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RhwUpKut09
> > WPrb1%2FkCcelIzwPXoG0g4u8%2B8K%2BRAKbY8%3D&reserved=0
> --Andrew Bartlett (he/him) https://samba.org/~abartlet/
> Samba Team Member (since 2001) https://samba.org/
> Samba Team Lead https://catalyst.net.nz/services/samba
> Catalyst.Net Ltd
> Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
> company
> Samba Development and Support: https://catalyst.net.nz/services/samba
>
> Catalyst IT - Expert Open Source Solutions
>
>
> _______________________________________________cifs-protocol mailing
> listcifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
--
Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd
Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company
Samba Development and Support: https://catalyst.net.nz/services/samba
Catalyst IT - Expert Open Source Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20230921/c710a44b/attachment.htm>
More information about the cifs-protocol
mailing list