Bug 61204 (CVE-2004-0949)

Summary: VUL-0: CVE-2004-0949: remote DoS in kernel SMB code
Product: [Novell Products] SUSE Security Incidents Reporter: Marcus Meissner <meissner>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Major    
Priority: P3 - Medium CC: afx, krahmer, lars.vogdt, qa-bugs, security-team
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard: CVE-2004-0949: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N)
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Patch from Urban Widmark via Stefan Esser via vendor-sec
smbfs for 2.4 patch
mail from stefan esser
linux-2.4.27-smbfs-fixes.diff
linux-2.6.9-smbfs-fixes.diff
patch for SL 9.1, please try
smbfs-security-fix
smbfs-security-fix-incremental
smbfs-2.6-ac
smbfs-fix-full

Description Sebastian Krahmer 2004-09-27 16:57:23 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...
Comment 1 Sebastian Krahmer 2004-09-27 16:57:23 UTC
<!-- SBZ_reproduce  -->
...
Comment 2 Olaf Kirch 2004-09-27 17:08:59 UTC
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. 
Comment 3 Hubert Mantel 2004-09-27 18:43:00 UTC
And does anybody already have fixes for our various kernels?
Comment 4 Sebastian Krahmer 2004-09-27 19:49:35 UTC
From the posting it wasnt clear to which version it applies.
Neither whether there are any fixes.
I will ask them.
Comment 5 Sebastian Krahmer 2004-09-27 20:16:48 UTC
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
Comment 6 Sebastian Krahmer 2004-09-27 20:22:26 UTC
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. :(
Comment 7 Sebastian Krahmer 2004-09-28 16:20:33 UTC
CAN-2004-0883 Multiple buffer overflows in linux kernel smbfs
Comment 8 Sebastian Krahmer 2004-09-28 16:38:21 UTC
BTW, shouldnt the printk() be protected by netrate_limit()?
Comment 9 Marcus Meissner 2004-10-06 23:10:36 UTC
Created attachment 24687 [details]
smbfs for 2.4 patch

fixed whitespace damage in patch
Comment 10 Marcus Meissner 2004-10-07 23:28:41 UTC
okir to review and apply to sles8 
Comment 11 Olaf Kirch 2004-10-11 22:02:20 UTC
Patch submitted to 2.4 HEAD branch. Should this go to UL1 SP4 as well? 
Comment 12 Marcus Meissner 2004-10-11 22:04:04 UTC
yes, please.  
Comment 13 Olaf Kirch 2004-10-11 22:40:56 UTC
Done. Assigning back to security-team for further tracking 
Comment 14 Marcus Meissner 2004-10-18 19:41:03 UTC
2.6 smbfs looks clean (uses smb_request_ok wrappper), trans2 is not there 
anymore. 
 
 
Comment 15 Marcus Meissner 2004-10-18 19:45:25 UTC
2.6 cifs CIFSSMBWrite and CIFSSMBRead look good too. 
Comment 16 Ludwig Nussel 2004-10-20 16:09:11 UTC
looks like there is a third bug in the smbfs code 
Comment 17 Ludwig Nussel 2004-10-20 16:09:42 UTC
Created attachment 25202 [details]
mail from stefan esser
Comment 18 Olaf Kirch 2004-10-21 16:24:32 UTC
Do you want me to commit this to SP1 and SL92? 
Comment 19 Marcus Meissner 2004-10-21 16:48:06 UTC
yes please. 
Comment 20 Olaf Kirch 2004-10-21 18:17:45 UTC
Hm... SP1 is visible via ftp://ftp.suse.com/pub/people/mantel/kotd 
 
Is this really public yet? 
Comment 21 Olaf Kirch 2004-10-21 18:33:37 UTC
I added the patch to SL9.2. Please let me know what to do with SP1. 
Comment 22 Ludwig Nussel 2004-10-22 21:56:48 UTC
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. 
Comment 23 Marcus Meissner 2004-10-25 17:16:56 UTC
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                                                                           
                                                                                 
Comment 24 Marcus Meissner 2004-10-27 18:55:58 UTC
Created attachment 25459 [details]
linux-2.4.27-smbfs-fixes.diff

patch from Stefan Esser for all 2.4.27 smbfs issues
Comment 25 Marcus Meissner 2004-10-27 18:56:25 UTC
Created attachment 25460 [details]
linux-2.6.9-smbfs-fixes.diff

patch from stefan esser for 2.6.9 smbfs fixes
Comment 26 Marcus Meissner 2004-10-27 19:18:52 UTC
Olaf, can you integrate those patches please?  
Comment 27 Marcus Meissner 2004-10-27 20:18:26 UTC
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. 
Comment 28 Olaf Kirch 2004-10-28 16:45:51 UTC
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? 
Comment 29 Marcus Meissner 2004-10-28 17:08:39 UTC
I don't know. 
 
My feeling is we do not have the complete set yet, so waiting is advisable. 
 
 
Comment 30 Roman Drahtmueller 2004-11-08 23:10:52 UTC
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.
Comment 31 Olaf Kirch 2004-11-10 19:49:38 UTC
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. 
Comment 32 Olaf Kirch 2004-11-10 20:12:56 UTC
The 2.4 patch also seems to be complete; I updated the SLES8SP4 branch. 
Any other SLES8 branches that need updating as well? 
Comment 33 Olaf Kirch 2004-11-10 20:15:41 UTC
That should have read "the HEAD and SLES8SP4 branches". 
Comment 34 Marcus Meissner 2004-11-15 16:54:09 UTC
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       
                                                                                      
Comment 35 Marcus Meissner 2004-11-17 23:08:07 UTC
swamp_id: 32 
Comment 36 Marcus Meissner 2004-12-01 21:35:29 UTC
updates released. 
Comment 37 Marcus Meissner 2004-12-21 23:13:36 UTC
<!-- SBZ_reopen -->Reopened by meissner@suse.de at Tue Dec 21 16:13:36 2004, took initial reporter krahmer@suse.de to cc
Comment 38 Marcus Meissner 2004-12-21 23:13:36 UTC
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. 
Comment 39 Marcus Meissner 2004-12-21 23:19:24 UTC
http://bugzilla.suse.de/show_bug.cgi?id=49453 
 
Comment 40 Hubert Mantel 2004-12-21 23:51:00 UTC
Your latest comments only point to each another; but I need a fix for the fix...
Comment 41 Marcus Meissner 2004-12-21 23:56:01 UTC
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. 
Comment 42 Sebastian Krahmer 2005-01-04 20:59:59 UTC
Created attachment 27379 [details]
patch for SL 9.1, please try

For testing.
Comment 43 Marcus Meissner 2005-01-05 18:30:09 UTC
Created attachment 27397 [details]
smbfs-security-fix

update, now working, smbfs-security-fix
Comment 44 Marcus Meissner 2005-01-05 18:31:55 UTC
Created attachment 27398 [details]
smbfs-security-fix-incremental

same, but incremental against old fix.
Comment 45 Marcus Meissner 2005-01-10 20:44:39 UTC
olaf, can you review and apply to the 2.6 branches please? 
Comment 46 Marcus Meissner 2005-01-13 20:08:26 UTC
Created attachment 27616 [details]
smbfs-2.6-ac

security fix from 2.6.10-ac8.
Comment 47 Marcus Meissner 2005-01-13 20:14:18 UTC
last patch lacks some parts we need for 2.6.8 / 2.6.5 
Comment 48 Marcus Meissner 2005-01-13 21:02:47 UTC
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.
Comment 49 Marcus Meissner 2005-01-13 21:04:15 UTC
Hubert, please replace the old patches.fixes/smbfs-security-fix  
by the last patch I have added in the 2.6 kernel trees. 
 
 
Comment 50 Hubert Mantel 2005-01-13 23:08:33 UTC
*** Bug 64453 has been marked as a duplicate of this bug. ***
Comment 51 Hubert Mantel 2005-01-13 23:40:08 UTC
Done. Kernels have been submitted for checkin.
Comment 52 Marcus Meissner 2005-01-17 20:44:56 UTC
(just for completeness) 
 
mainline has the same patch now: 
 
http://linux.bkbits.net:8080/linux-2.6/cset%4041e9a86bi4MvUzMJ8Ru62gdkFgHKtg?nav=index.html|
ChangeSet@-3d 
Comment 53 Marcus Meissner 2005-01-24 20:28:16 UTC
still needed or SP1 branch update. 
Comment 54 Marcus Meissner 2005-02-04 23:22:41 UTC
most SP1 packages already released. closing (just s390 will follow) 
Comment 55 Thomas Biege 2009-10-13 19:51:44 UTC
CVE-2004-0949: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N)