Bugzilla – Bug 61204
VUL-0: CVE-2004-0949: remote DoS in kernel SMB code
Last modified: 2021-10-04 10:13:05 UTC
Via vendor-sec: Date: Mon, 27 Sep 2004 10:35:04 +0200 From: Stefan Esser <s.esser@e-matters.de> To: vendor-sec@lst.de Subject: [vendor-sec] Samba 3.x Remote Heap Overflow and Linux smbfs remote overflows On request of redhat and suse here are extracts of my mails to security@samba.org and linus/marcelo/urban ...Linux Kernel Bugs ----------------- 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 15001 - 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 15002 - 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...
<!-- SBZ_reproduce --> ...
What kernel versions does this apply to? In 2.6 we recommend using the cifs module rather than smbfs (which is marked unsupported in sles9). It makes sense to check the cifs client as well.
And does anybody already have fixes for our various kernels?
From the posting it wasnt clear to which version it applies. Neither whether there are any fixes. I will ask them.
Date: Mon, 27 Sep 2004 14:12:19 +0200 From: Stefan Esser <s.esser@e-matters.de> To: Sebastian Krahmer <krahmer@suse.de> Cc: vendor-sec@lst.de Subject: Re: [vendor-sec] Samba 3.x Remote Heap Overflow and Linux smbfs remote overflows Hi, > To which version does the Kernel-bug apply? > (The mail reads as this was already discussed with Linux, > but theres no detail on it) And, are there any fixes? > > Sebastian The kernel bugs are for 2.4 2.6 has partly the same problem in the trans2 reconstruction but there the memcpy is eliminated and the only thing one can achieve is returning to high data counters from the function. At the moment these counters are only checked against minimum values and it is not possible to overflow anything with too high values. (Well it would be possible if the counter would still be signed ints and one would send 2 gb of data) It was not really discussed with Linus and co. I just mailed them the same stuff I sent to the list and they started working on it. I only know by one mail that went CC to me that they are obviously sending around mails about this within their circles. Greetings, Stefan Esser
Created attachment 24025 [details] Patch from Urban Widmark via Stefan Esser via vendor-sec Seems like the tabs are expanded. But it came this way via mail. :(
CAN-2004-0883 Multiple buffer overflows in linux kernel smbfs
BTW, shouldnt the printk() be protected by netrate_limit()?
Created attachment 24687 [details] smbfs for 2.4 patch fixed whitespace damage in patch
okir to review and apply to sles8
Patch submitted to 2.4 HEAD branch. Should this go to UL1 SP4 as well?
yes, please.
Done. Assigning back to security-team for further tracking
2.6 smbfs looks clean (uses smb_request_ok wrappper), trans2 is not there anymore.
2.6 cifs CIFSSMBWrite and CIFSSMBRead look good too.
looks like there is a third bug in the smbfs code
Created attachment 25202 [details] mail from stefan esser
Do you want me to commit this to SP1 and SL92?
yes please.
Hm... SP1 is visible via ftp://ftp.suse.com/pub/people/mantel/kotd Is this really public yet?
I added the patch to SL9.2. Please let me know what to do with SP1.
The discussions on vendor-sec are not clear. Any questions about a date didn't yield any answer. Marcelo Tosatti seems to have the impression that the issue is not public yet.
From: Stefan Esser <s.esser@e-matters.de> Hello, because the list of bugs got confusing in the meanwhile. Here is a short overview over the bugs Aff. Patch Bug 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 missing fragment information leak 2.4 - smb_recveive_trans2 malicious parm/data offset information leak/DOS 2.4 + smb_recveive_trans2 defragmentation overflow 2.6 - smb_proc_readX_data malicious data offset DOS (-=hdrlen underflow) 2.6 - smb_recv_trans2 malicious parm/data offset information leak/DOS(???) +(+possible underflow) 2.6 C smb_recv_trans2 missing fragment information leak 2.6 C smb_recv_trans2 fragment resending leads to invalid counters + means patch exists - means patch does not yet exist C means patch was already commited (BTW the last 2.6 bug is more or less same bug as smb_recveive_trans2 +defragmentation overflow but without the overflow) Stefan
Created attachment 25459 [details] linux-2.4.27-smbfs-fixes.diff patch from Stefan Esser for all 2.4.27 smbfs issues
Created attachment 25460 [details] linux-2.6.9-smbfs-fixes.diff patch from stefan esser for 2.6.9 smbfs fixes
Olaf, can you integrate those patches please?
From: Stefan Esser <s.esser@e-matters.de> Hi, attached are patches for all bugs found. The only test performed is that it all compiles. (some bugs are fixed by rearranging the if condition order) Greetings Stefan Esser ... perhaps take with grain of salt.
Do we now have a complete set of patches? Shouldn't we wait for a complete set rather than pushing small bits and pieces every week?
I don't know. My feeling is we do not have the complete set yet, so waiting is advisable.
Adding Andi Siegert <afx@atsec.com> to various kernel bugs for making sure that the kernel bugs are being tracked in the context of the currently ongoing Common Criteria CAPP/EAL4 evaluation, to run into the final phase End of 11/2004 Beginning of 12/2004.
I compared the 2.6 patch set we have to the list of problems in comment #23, and it seems to be complete. The patches are in all 2.6 trees but disabled until official release.
The 2.4 patch also seems to be complete; I updated the SLES8SP4 branch. Any other SLES8 branches that need updating as well?
That should have read "the HEAD and SLES8SP4 branches".
From: Mark J Cox <mjc@redhat.com> 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
swamp_id: 32
updates released.
<!-- SBZ_reopen -->Reopened by meissner@suse.de at Tue Dec 21 16:13:36 2004, took initial reporter krahmer@suse.de to cc
we got customer reports that smbfs is broken on 9.1 (2.6.5 based) and 9.2 (2.6.8 based), so the 2.6 fix is likely bad.
http://bugzilla.suse.de/show_bug.cgi?id=49453
Your latest comments only point to each another; but I need a fix for the fix...
yes. there is no fix yet. mls and I had a look at it and perhaps there is a magic data_count = 0 , data_offset = 0 which triggers an early if () branch or similar. needs input from kernel hackers.
Created attachment 27379 [details] patch for SL 9.1, please try For testing.
Created attachment 27397 [details] smbfs-security-fix update, now working, smbfs-security-fix
Created attachment 27398 [details] smbfs-security-fix-incremental same, but incremental against old fix.
olaf, can you review and apply to the 2.6 branches please?
Created attachment 27616 [details] smbfs-2.6-ac security fix from 2.6.10-ac8.
last patch lacks some parts we need for 2.6.8 / 2.6.5
Created attachment 27619 [details] smbfs-fix-full This is the smbfs-2.6.10-ac8 patch merged with the parts that were already in bitkeeper from s.esser. I tested this patch on 9.2, the write problem is fixed with this patch too.
Hubert, please replace the old patches.fixes/smbfs-security-fix by the last patch I have added in the 2.6 kernel trees.
*** Bug 64453 has been marked as a duplicate of this bug. ***
Done. Kernels have been submitted for checkin.
(just for completeness) mainline has the same patch now: http://linux.bkbits.net:8080/linux-2.6/cset%4041e9a86bi4MvUzMJ8Ru62gdkFgHKtg?nav=index.html| ChangeSet@-3d
still needed or SP1 branch update.
most SP1 packages already released. closing (just s390 will follow)
CVE-2004-0949: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N)