embargoed via samba bugzilla.

https://bugzilla.samba.org/show_bug.cgi?id=13041

Hi, Jeremy

I’m Yihan Lian, a security researcher of Qihoo 360 GearTeam.

y partner Zhibin Hu and I found a UAF of samba.

===================== target version =============================
Samba 4.6.7
===================== test command =============================
python send_reply.py <your_target_ip>

======================= crash info ===============================


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7294fdc in change_to_user (conn=0x5555557b6e80, vuid=54299) at ../source3/smbd/uid.c:371
371             int snum = SNUM(conn);

(gdb) p/x *conn                                                                          // The conn was padded and used …

$1 = {next = 0x3131313131315c5c, prev = 0x3131313131313131, sconn = 0x3131313131313131, tcon = 0x3131313131313131, cnum = 0x31313131,
  params = 0x3131313131313131, force_user = 0x31, vuid_cache = 0x3131313131313131, printer = 0x31, ipc = 0x31, read_only = 0x31,
  share_access = 0x31313131, ts_res = 0x615c3131, connectpath = 0x73756f6d, origpath = 0x0, cwd = 0x0, vfs_handles = 0x0, session_info = 0x0,
  force_group_gid = 0x0, vuid = 0x0, lastused = 0x0, lastused_count = 0x0, num_files_open = 0x0, num_smb_operations = 0x0, encrypt_level = 0x0,
  encrypted_tid = 0x0, case_sensitive = 0x0, case_preserve = 0x0, short_case_preserve = 0x0, fs_capabilities = 0x0, base_share_dev = 0x0,
  hide_list = 0x0, veto_list = 0x0, veto_oplock_list = 0x0, aio_write_behind_list = 0x0, dfree_info = 0x0, pending_trans = 0x0, spoolss_pipe = 0x0}


(gdb) bt 10
#0  0x00007ffff7294fdc in change_to_user (conn=0x5555557b6e80, vuid=54299) at ../source3/smbd/uid.c:371
#1  0x00007ffff72cad4f in switch_message (type=45 '-', req=0x5555557b8090) at ../source3/smbd/process.c:1610
#2  0x00007ffff72cb882 in smb_request_done (req=0x5555557b8090) at ../source3/smbd/process.c:1868
#3  0x00007ffff72cb637 in construct_reply_chain (xconn=0x5555557b07d0, inbuf=0x0, size=8000, seqnum=0, encrypted=false, deferred_pcd=0x0)
    at ../source3/smbd/process.c:1813
#4  0x00007ffff72cc546 in process_smb (xconn=0x5555557b07d0, inbuf=0x5555557b4df0 "", nread=8000, unread_bytes=0, seqnum=0, encrypted=false,
    deferred_pcd=0x0) at ../source3/smbd/process.c:2005
#5  0x00007ffff72cd8b1 in smbd_server_connection_read_handler (xconn=0x5555557b07d0, fd=37) at ../source3/smbd/process.c:2608
#6  0x00007ffff72cd992 in smbd_server_connection_handler (ev=0x555555795190, fde=0x5555557b1bf0, flags=1, private_data=0x5555557b07d0)
    at ../source3/smbd/process.c:2635
#7  0x00007ffff6544331 in epoll_event_loop (epoll_ev=0x5555557a6d70, tvalp=0x7fffffffdb30) at ../lib/tevent/tevent_epoll.c:728
#8  0x00007ffff6544968 in epoll_event_loop_once (ev=0x555555795190, location=0x7ffff7469a48 "../source3/smbd/process.c:4125")
    at ../lib/tevent/tevent_epoll.c:930
#9  0x00007ffff6541667 in std_event_loop_once (ev=0x555555795190, location=0x7ffff7469a48 "../source3/smbd/process.c:4125")
at ../lib/tevent/tevent_standard.c:114

============================ cause ================================

I send a request which has a chain, there are two requests in it. So they will use a same “conn”. After smbXsrv_tcon_disconnect of
+reply_tcon_and_X(), the “conn” will be freed, and create a new “conn”.

But when samba dealing the second request in the chain, it is still using the first “conn” which has been freed L.

Hope this could help you.

Attachment you could find the poc and my smb.conf.

Regards.