Bug 6100 - Function needs to return "status not implemented"
Summary: Function needs to return "status not implemented"
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.2.7
Hardware: All Windows NT
: P3 normal
Target Milestone: ---
Assignee: Stefan Metzmacher
QA Contact: Samba QA Contact
Depends on:
Reported: 2009-02-10 17:51 UTC by Nick Meier
Modified: 2009-03-05 15:23 UTC (History)
1 user (show)

See Also:

Network capture file (14.41 KB, application/octet-stream)
2009-02-23 19:12 UTC, Nick Meier
no flags Details
Network capture with the correct error code (13.72 KB, application/octet-stream)
2009-02-24 03:06 UTC, Stefan Metzmacher
no flags Details
smbd log output (161.98 KB, application/octet-stream)
2009-02-25 14:29 UTC, Nick Meier
no flags Details
patch (517 bytes, patch)
2009-03-05 14:42 UTC, Volker Lendecke
no flags Details
Network capture of netlogon starting (11.61 KB, application/octet-stream)
2009-03-05 14:44 UTC, Nick Meier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Meier 2009-02-10 17:51:44 UTC
The following issue was identified during a Samba/Microsoft conference call.

Microsoft Open Protocol Document MS-NRPC
    NetrLogonDummyRoutine1, section
    For win7 this function is renamed to NetrLogonGetCapabilities –  opnum 21,
    see section

- 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.
Comment 1 Stefan Metzmacher 2009-02-16 04:45:00 UTC
Should be fixed with commit fe417b29bd23b7b935669993e0f01de4c7de2378
Comment 2 Nick Meier 2009-02-23 19:12:30 UTC
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.
Comment 3 Stefan Metzmacher 2009-02-24 03:04:29 UTC
Hi Nick,

Are you sure you used the correct version?

I was able to take a capture with the the correct error.

Comment 4 Stefan Metzmacher 2009-02-24 03:06:39 UTC
Created attachment 3953 [details]
Network capture with the correct error code

See frames 61-64
Comment 5 Nick Meier 2009-02-24 09:06:15 UTC
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.


I'll get a fresh copy and retest.
Comment 6 Nick Meier 2009-02-24 11:01:30 UTC
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.


Comment 7 Nick Meier 2009-02-25 14:29:11 UTC
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.
Comment 8 Nick Meier 2009-03-05 10:48:13 UTC
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

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)));
                setup_fault_pdu(p, NT_STATUS(DCERPC_FAULT_OP_RNG_ERROR));   <--- Line 648
        } else {
                 * Reset the lengths. We're ready for a new pdu.
                p->in_data.pdu_needed_len = 0;
                p->in_data.pdu_received_len = 0;

Comment 9 Volker Lendecke 2009-03-05 13:34:52 UTC
Ok, Windows 7 seems to do a different flavor of schannel. Let me take a look at the docs...

Comment 10 Volker Lendecke 2009-03-05 14:24:34 UTC
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 




just making sure that we get enough bytes for the auth footer.

Comment 11 Volker Lendecke 2009-03-05 14:42:23 UTC
Created attachment 3977 [details]

Can you try the attached patch (not checked in yet)?


Comment 12 Nick Meier 2009-03-05 14:44:56 UTC
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.
Comment 13 Volker Lendecke 2009-03-05 14:56:35 UTC
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 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.... :-)

Comment 14 Nick Meier 2009-03-05 15:05:31 UTC
Your change worked.  I successfully logged in using Samba domain credentials.

Also, thanks for the doc reference!

Comment 15 Volker Lendecke 2009-03-05 15:06:52 UTC

Thanks for testing, checking that in now :-))

Comment 16 Volker Lendecke 2009-03-05 15:23:25 UTC
Pushed the patches to v3-3-test and master. Closing.