There exist two bugs in the handling of SMB responses that result in remote kernel overflows. Due to the nature of the bugs both seem to be very hard to exploit (in the sense of remote code execution or local privilege escalation) but are trivial remote kernel crashes. 1) Bug 1 - read overflow linux/fs/smbfs/proc.c smb_proc_readX smb_proc_read data_len (returned from SMB) is not checked against count This means if the server sends more than count bytes as reply the memcpy will overflow rated: Even with local help very hard to exploit because the memory after the buffer is always in a different offset to the next tast_struct otherwise it would be trivial to overwrite the task_limit field of a task owned by yourself which could later give root permissions. (In combination with a information leak vulnerability this could otherwise be called "Potential local root with remote help") 2) Bug 2 - trans2 reconstruction overflow linux/fs/smbfs/sock.c smb_receive_trans2 data_len (and parm_len) is increased with every new packet, even if the packet contains the same data (offset, length) of an already received packet. This means the loop termination condition: if (data_len >= data_tot && parm_len >= parm_tot) break; can be used to end with f.e. a data_len far bigger than data_to and parm_len equal to parm_to inbuf = server->packet; if (buf_len >= server->packet_size) { server->packet_size = buf_len; server->packet = rcv_buf; rcv_buf = inbuf; } else { PARANOIA("copying data, old size=%d, new size=%u\n", server->packet_size, buf_len); memcpy(inbuf, rcv_buf, parm_len + data_len); } It is obvious that in such a case the memcpy will copy too much, because data_len is > data_tot. The data copied is after our buffer and therefore remote or local code exploitation exploits seem impossible, because we only have one shot or the kernel says goodbye...
Created attachment 105808 [details] Proposed patch for this issue.
Can someone take a look at this? This issue has pretty much died down on vendor-sec, and I worry that patch is not as complete as it should be.
Al, could you please follow up on this? Thanks. -ernie
as far as I can see, both issues are real and proposed patch looks right. IOW, ACK on both bug and proposed fix
(I've removed reference to 2.6 kernel in below list) CAN-2004-0883: 2.4 smb_proc_read(X) malicious data count overflow [Explained in mail Message-ID: <20040927083504.GA5287>] 2.4 smb_recveive_trans2 missing fragment information leak [Explained in mail Message-ID: <20040927083504.GA5287>] 2.4 smb_proc_readX malicious data offset information leak [Explained in Message-ID: <20041023144344.GA32227>] 2.4 smb_recveive_trans2 malicious parm/data offset information leak/DOS [Explained in Message-ID: <20041023144344.GA32227>] These issues are all of the type "user supplied data not bounds checked" (leading to DoS or info leak). Linux 2.4 CAN-2004-0949: > 2.4 + smb_recveive_trans2 defragmentation overflow [Explained in mail Message-ID: <20041019161226.GA10715>] Both are "SMB fragment reconstruction does not ensure that all data in the reconstructed packet is initialised and that a possible attacker can send always fragments with the same data in it to leave lots of the packet uninitialised, leading to DoS or leak of kernel memory"
Created attachment 106654 [details] Updated patch to solve all issues
My breakdown of which issues were in which CVE names was not correct; the following is agreed: CAN-2004-0883 "remote supplied data not bounds checked" 2.4 smb_proc_read(X) malicious data count overflow 2.4 smb_proc_readX malicious data offset information leak 2.4 smb_recveive_trans2 malicious parm/data offset information leak/DOS 2.4 smb_receive_trans2 defragmentation overflow possible overflow 2.6 smb_recv_trans2 malicious parm/data offset information leak/DOS(?? 2.6 smb_proc_readX_data malicious data offset DOS (-=hdrlen underflow) CAN-2004-0949 "failure to initialise structure/memory" (CAN-2004-0949) 2.4 smb_receive_trans2 missing fragment information leak 2.6 smb_recv_trans2 missing fragment information leak 2.6 smb_recv_trans2 fragment resending leads to invalid counters
A fix for this problem has just been committed to the RHEL3 E4 patch pool this evening (in kernel version 2.4.21-20.0.1.EL). I'm leaving this in ASSIGNED state until the fix is also propagated to the RHEL3 U4 and U5 patch pools.
Removing embargo
A fix for this problem has just been committed to the RHEL3 U4 patch pool this evening (in kernel version 2.4.21-27.EL). I'm leaving this in ASSIGNED state until the fix is also propagated to the RHEL3 U5 patch pool.
http://rhn.redhat.com/errata/RHSA-2004-549.html
A fix for this problem has just been committed to the RHEL3 U5 patch pool this evening (in kernel version 2.4.21-27.3.EL). Work on this problem has now been completed.