Bug 15465 - rpcd_lsad/netlogon/LogonControl2Ex can dereference a client-supplied pointer
Summary: rpcd_lsad/netlogon/LogonControl2Ex can dereference a client-supplied pointer
Status: ASSIGNED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DCE-RPCs and pipes (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Noel Power
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-03 10:50 UTC by Robert Morris
Modified: 2024-06-04 09:40 UTC (History)
4 users (show)

See Also:


Attachments
demonstrate a bug in LogonControl2Ex (134.94 KB, text/x-csrc)
2023-09-21 10:04 UTC, Robert Morris
no flags Details
patch (for master) (5.02 KB, patch)
2023-09-25 10:06 UTC, Noel Power
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Morris 2023-09-03 10:50:44 UTC
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
Comment 1 Andrew Bartlett 2023-09-03 20:12:22 UTC
Adding embargo pending analysis.
Comment 2 Andrew Bartlett 2023-09-21 06:58:43 UTC
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!
Comment 3 Robert Morris 2023-09-21 10:04:16 UTC
Created attachment 18116 [details]
demonstrate a bug in LogonControl2Ex
Comment 4 Robert Morris 2023-09-21 10:06:14 UTC
(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;
Comment 5 Noel Power 2023-09-25 10:06:54 UTC
Created attachment 18122 [details]
patch (for master)
Comment 6 Andrew Bartlett 2023-09-26 03:32:37 UTC
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).
Comment 7 Andrew Bartlett 2023-12-05 02:25:17 UTC
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'.
Comment 8 Samba QA Contact 2024-06-04 09:40:04 UTC
This bug was referenced in samba master:

1297c7ca65ba485febee4eabe32a8e1c793b187c
a27525e555c2c88f3b3bbef17d6e803a3a231d2b
0418b9fa929736a404b9ff976ff034009b913089
8adbdbe50f7ac69cb815794d1c3d214bbac7c848
747a7fec01d39453093ed48b167fa1d5d80aead4