Bug 134720

Summary: CAN-2004-0883 smbfs potential DOS (CAN-2004-0949)
Product: Red Hat Enterprise Linux 3 Reporter: Josh Bressers <bressers>
Component: kernelAssignee: Alexander Viro <aviro>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: davej, jbaron, peterm, petrides, riel, security-response-team, tburke
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=20041115
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-02 11:41:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed patch for this issue.
none
Updated patch to solve all issues none

Description Josh Bressers 2004-10-05 19:02:41 UTC 
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...
Comment 1 Josh Bressers 2004-10-26 19:16:34 UTC 
Created attachment 105808 [details]
Proposed patch for this issue.
Comment 2 Josh Bressers 2004-11-02 13:36:58 UTC 
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.
Comment 3 Ernie Petrides 2004-11-02 20:51:37 UTC 
Al, could you please follow up on this?  Thanks.  -ernie
Comment 4 Alexander Viro 2004-11-04 09:55:39 UTC 
as far as I can see, both issues are real and proposed patch looks right.
IOW, ACK on both bug and proposed fix
Comment 6 Mark J. Cox 2004-11-13 23:40:08 UTC 
(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"
Comment 7 Mark J. Cox 2004-11-13 23:41:41 UTC 
Created attachment 106654 [details]
Updated patch to solve all issues
Comment 8 Mark J. Cox 2004-11-15 11:24:34 UTC 
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
Comment 9 Ernie Petrides 2004-11-25 01:30:22 UTC 
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.
Comment 10 Mark J. Cox 2004-11-30 12:14:11 UTC 
Removing embargo
Comment 11 Ernie Petrides 2004-12-02 02:54:27 UTC 
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.
Comment 12 Mark J. Cox 2004-12-02 11:41:07 UTC 
http://rhn.redhat.com/errata/RHSA-2004-549.html
Comment 13 Ernie Petrides 2004-12-10 02:51:52 UTC 
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.