If the client sends a LogonControl2Ex RPC request with function_code NETLOGON_CONTROL_SET_DBFLAG and level 4, _netr_LogonControl2Ex() executes: info4->trusted_domain_name = r->in.data->domain; r->out.query->info4 = info4; However, the r->in.data union in this case holds the client-supplied debug_level, not a domain, so info4->trusted_domain_name is now a pointer supplied by the client. Later, when replying, rpcd_lsad tries to dereference that pointer. Here's a backtrace; the illegal pointer 0x12345678 comes from the client's r->in.data->debug_level. Program received signal SIGSEGV, Segmentation fault. Address not mapped to object. 0x00003086e077e02d in strlen_m_ext_handle (ic=0x30872e528000, s=0x12345678 <error: Cannot access memory at address 0x12345678>, src_charset=CH_UNIX, dst_charset=CH_UTF16LE) at ../../lib/util/charset/util_str.c:233 233 while (*s && !(((uint8_t)*s) & 0x80)) { (gdb) where #0 0x00003086e077e02d in strlen_m_ext_handle (ic=0x30872e528000, s=0x12345678 <error: Cannot access memory at address 0x12345678>, src_charset=CH_UNIX, dst_charset=CH_UTF16LE) at ../../lib/util/charset/util_str.c:233 #1 0x00003086e077e24e in strlen_m_ext ( s=0x12345678 <error: Cannot access memory at address 0x12345678>, src_charset=CH_UNIX, dst_charset=CH_UTF16LE) at ../../lib/util/charset/util_str.c:297 #2 0x00003086e077e299 in strlen_m_ext_term ( s=0x12345678 <error: Cannot access memory at address 0x12345678>, src_charset=CH_UNIX, dst_charset=CH_UTF16LE) at ../../lib/util/charset/util_str.c:306 #3 0x00003086de0444db in ndr_charset_length (var=0x12345678, chset=CH_UTF16LE) at ../../librpc/ndr/ndr_string.c:810 #4 0x00003086f0cfe549 in ndr_push_netr_NETLOGON_INFO_4 (ndr=0x308758315420, ndr_flags=768, r=0x308758315390) at librpc/gen_ndr/ndr_netlogon.c:6176 #5 0x00003086f0cfd8b9 in ndr_push_netr_CONTROL_QUERY_INFORMATION ( ndr=0x308758315420, ndr_flags=768, r=0x308758315300) at librpc/gen_ndr/ndr_netlogon.c:6324 #6 0x00003086f0d49f87 in ndr_push_netr_LogonControl2Ex (ndr=0x308758315420, flags=32, r=0x308758314810) at librpc/gen_ndr/ndr_netlogon.c:13880 #7 0x0000308689b6eddd in netlogon__op_ndr_push (dce_call=0x308758314330, mem_ctx=0x308758314330, push=0x308758315420, r=0x308758314810) at ./librpc/gen_ndr/ndr_netlogon_scompat.c:1639 #8 0x00003086e0b1d86c in dcesrv_reply (call=0x308758314330) at ../../librpc/rpc/dcesrv_reply.c:171 #9 0x00003086e0b17f1f in dcesrv_request (call=0x308758314330) at ../../librpc/rpc/dcesrv_core.c:1994
Adding embargo pending analysis.
Robert, My reading of this code is that we can only reach this location if the user is authenticated as root or administrator. Can you reproduce this with an unprivileged user? Do you have a test script (python using our python bindings would be preferred) demonstrating this issue? Thanks!
Created attachment 18116 [details] demonstrate a bug in LogonControl2Ex
(In reply to Andrew Bartlett from comment #2) I believe you're correct that privilege is required. I've attached my test script. It won't work for you as is, but you can see in my smb_ioctl_rpc_LogonControl2Ex() how the script prepares the request: *(short*)(buf+ii) = 0x12; // opnum LogonControl2Ex ii += 2; *(int*)(buf+ii) = 16; // _ptr_server_name ii += 4; *(int*)(buf+ii) = 2; // size ii += 4; *(int*)(buf+ii) = 0; // offset ii += 4; *(int*)(buf+ii) = 2; // length ii += 4; buf[ii++] = 'x'; buf[ii++] = 0; buf[ii++] = 0; buf[ii++] = 0; *(int*)(buf+ii) = 0xfffe; // function_code NETLOGON_CONTROL_SET_DBFLAG ii += 4; *(int*)(buf+ii) = 4; // level ii += 4; *(int*)(buf+ii) = 0xfffe; // _level ii += 4; *(int*)(buf+ii) = 0x12345678; ii += 4; *(int*)(buf+ii) = 0xdeadbeef; ii += 4;
Created attachment 18122 [details] patch (for master)
Following the confirmation (which is what the code looks like) that privilege is required, that it is best if we deal with this as a public bug. The CVSS3.1 score is: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N (4.9) which is below our threshold of 5, and to me, while 'admin can read process memory' is bad, it isn't so horrible that we need a security release. We should, if easy, get a CVE however just to keep track of it. (I would like to personally double-check before finally opening up the bug, but this is to state the intention).
Removing embargo. Thanks for the patches and test, using these I can't see this being an issue without admin access, so the embargoed security process is not required. We should probably get a CVE, if Red Hat will issue one, but otherwise this is 'just a bug'.
This bug was referenced in samba master: 1297c7ca65ba485febee4eabe32a8e1c793b187c a27525e555c2c88f3b3bbef17d6e803a3a231d2b 0418b9fa929736a404b9ff976ff034009b913089 8adbdbe50f7ac69cb815794d1c3d214bbac7c848 747a7fec01d39453093ed48b167fa1d5d80aead4