The following issue was identified during a Samba/Microsoft conference call. Microsoft Open Protocol Document MS-NRPC NetrLogonDummyRoutine1, section 3.5.4.9.5. For win7 this function is renamed to NetrLogonGetCapabilities – opnum 21, see section 3.5.4.3.10 - Function call to test for a man-in-the-middle attack – first implemented in win2k. - If Samba supported the end-point, but not the method, and returned “status not implemented”, then the response is secure and we would downgrade to prior behavior. - Approach that would open us up to man-in-the-middle attacks - If “RPC procnum out of range” error was returned. This is because it is not signed, thus it opens us up to man-in-the middle attacks.
Should be fixed with commit fe417b29bd23b7b935669993e0f01de4c7de2378
Created attachment 3950 [details] Network capture file Frame 78 shows the request, and frame 81 shows Samba is still returning nca_op_rng_err rather than NT_STATUS_NOT_IMPLEMENTED.
Hi Nick, Are you sure you used the correct version? I was able to take a capture with the the correct error. metze
Created attachment 3953 [details] Network capture with the correct error code See frames 61-64
About Wednesday last week, I pulled down the samba-master tree and built the source 3 branch. The command "git log --summary" shows the following: commit fe417b29bd23b7b935669993e0f01de4c7de2378 Author: Stefan Metzmacher <metze@samba.org> Date: Mon Feb 16 10:20:55 2009 +0100 s3:netlogon: implement _netr_LogonGetCapabilities() with NT_STATUS_NOT_IMPLE This hopefully fixes bug #6100. metze I'll get a fresh copy and retest.
After updating, I still see the original behavior when I test. I'm pulling down the samba-master, then cd to the samba-master/source3 tree and building. git log --summary shows the checkin. I see the new behavior in your capture file. Should I be pulling the source from somewhere else, or using a different technique to pickup the change? I also sent you an email with detail steps of what I'm doing to pick up the change and test. thanks, -Nick
Created attachment 3958 [details] smbd log output Setting a breakpoint on _netr_LogonGetCapabilities never hits. Running smbd with the debug option (-d 10) produced the attached output. Line 4387 appears to be the opnum 21 request. Line 4414 is where DCERPC_FAULT_OP_RNG_ERROR is returned. smbd never appears to dispatch to _netr_LogonGetCapabilities. this may be due to the error on line 4391 Incorrect auth_len 56.
The function api_pipe_schannel_process() fails its first test, and returns false. This false returns works its way back to the function process_complete_pdu() where it sets the error code to DCERPC_FAULT_OP_RNG_ERROR, which is returned to Win 7. See following code fragments: File: rpc_server/srv_pipe.c bool api_pipe_schannel_process(pipes_struct *p, prs_struct *rpc_in, uint32 *p_ss_padding_len) { uint32 data_len; uint32 auth_len; uint32 save_offset = prs_offset(rpc_in); RPC_HDR_AUTH auth_info; RPC_AUTH_SCHANNEL_CHK schannel_chk; auth_len = p->hdr.auth_len; if (auth_len != RPC_AUTH_SCHANNEL_SIGN_OR_SEAL_CHK_LEN) { <-- This Fails DEBUG(0,("Incorrect auth_len %u.\n", (unsigned int)auth_len )); return False; } .... auth_len = 56 from include/rpc_dce.h #define RPC_AUTH_SCHANNEL_SIGN_OR_SEAL_CHK_LEN 0x20 File: rpc_server/srv_pipe_hnd.c process_complete_pdu () .... /* Reset to little endian. Probably don't need this but it won't hurt. */ prs_set_endian_data( &p->in_data.data, RPC_LITTLE_ENDIAN); if (!reply) { DEBUG(3,("process_complete_pdu: DCE/RPC fault sent on " "pipe %s\n", get_pipe_name_from_iface(&p->syntax))); set_incoming_fault(p); setup_fault_pdu(p, NT_STATUS(DCERPC_FAULT_OP_RNG_ERROR)); <--- Line 648 prs_mem_free(&rpc_in); } else { /* * Reset the lengths. We're ready for a new pdu. */ TALLOC_FREE(p->in_data.current_in_pdu); p->in_data.pdu_needed_len = 0; p->in_data.pdu_received_len = 0; } prs_mem_free(&rpc_in); }
Ok, Windows 7 seems to do a different flavor of schannel. Let me take a look at the docs... Volker
Can you upload a sniff of that attempt? To me the following seems to be the schannel auth footer: [0090] 00 77 00 7A 00 FF FF 00 00 EB F0 9C BE E6 58 9C .w.z.... ......X. [00A0] 7F 3C E3 18 2F 80 49 65 1A 30 20 1D AA E0 31 E1 .<../.Ie .0 ...1. [00B0] DE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [00C0] 00 00 00 00 00 00 00 00 00 ........ . Samba contains a check for the auth length the client sends. It seems that you are doing HMAC-MD5 (0x77) signing and RC4 (0x7A) sealing, but you append some NULL bytes. In theory we could just change the auth_len != RPC_AUTH_SCHANNEL_SIGN_OR_SEAL_CHK_LEN to auth_len < RPC_AUTH_SCHANNEL_SIGN_OR_SEAL_CHK_LEN just making sure that we get enough bytes for the auth footer. Volker
Created attachment 3977 [details] patch Can you try the attached patch (not checked in yet)? Thanks, Volker
Created attachment 3978 [details] Network capture of netlogon starting Here you go. This was taken with netmon. If needed, I can repeat using Wireshark. Frame 55 is the opnum 21 call. Frame 58 is the response. I'll test the patch you just attached.
Ok, thanks. The sniff kindof confirms that you just send null bytes at the end of the auth footer. You see me impressed. MS-RPCE 2.2.2.11 contains ---- A client or a server that (during composing of a PDU) has allocated more space for the authentication token than the security provider fills in SHOULD fill in the rest of the allocated space with zero octets. These zero octets are still considered to belong to the authentication token part of the PDU.<36> ---- So this behaviour is even documented.... :-) Volker
Your change worked. I successfully logged in using Samba domain credentials. Also, thanks for the doc reference! -Nick
WOOT! Thanks for testing, checking that in now :-)) Volker
Pushed the patches to v3-3-test and master. Closing. Volker