Bug 134720 - CAN-2004-0883 smbfs potential DOS (CAN-2004-0949)
CAN-2004-0883 smbfs potential DOS (CAN-2004-0949)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Viro
Brian Brock
impact=moderate,public=20041115
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-05 15:02 EDT by Josh Bressers
Modified: 2007-11-30 17:07 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-02 06:41:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch for this issue. (2.25 KB, patch)
2004-10-26 15:16 EDT, Josh Bressers
no flags Details | Diff
Updated patch to solve all issues (3.03 KB, patch)
2004-11-13 18:41 EST, Mark J. Cox (Product Security)
no flags Details | Diff

  None (edit)
Description Josh Bressers 2004-10-05 15:02:41 EDT
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 15:16:34 EDT
Created attachment 105808 [details]
Proposed patch for this issue.
Comment 2 Josh Bressers 2004-11-02 08:36:58 EST
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 15:51:37 EST
Al, could you please follow up on this?  Thanks.  -ernie
Comment 4 Alexander Viro 2004-11-04 04:55:39 EST
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 (Product Security) 2004-11-13 18:40:08 EST
(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@e-matters.de>]
        2.4   smb_recveive_trans2 missing fragment information leak
        [Explained in mail Message-ID:
<20040927083504.GA5287@e-matters.de>]
        2.4   smb_proc_readX malicious data offset information leak
        [Explained in Message-ID: <20041023144344.GA32227@e-matters.de>]
        2.4   smb_recveive_trans2 malicious parm/data offset information
leak/DOS
        [Explained in Message-ID: <20041023144344.GA32227@e-matters.de>]

        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@e-matters.de>]

        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 (Product Security) 2004-11-13 18:41:41 EST
Created attachment 106654 [details]
Updated patch to solve all issues
Comment 8 Mark J. Cox (Product Security) 2004-11-15 06:24:34 EST
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-24 20:30:22 EST
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 (Product Security) 2004-11-30 07:14:11 EST
Removing embargo
Comment 11 Ernie Petrides 2004-12-01 21:54:27 EST
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 (Product Security) 2004-12-02 06:41:07 EST
http://rhn.redhat.com/errata/RHSA-2004-549.html
Comment 13 Ernie Petrides 2004-12-09 21:51:52 EST
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.

Note You need to log in before you can comment on or make changes to this bug.