Bug 134721 - 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 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
2.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jim Paradis
Brian Brock
impact=moderate,public=20041115
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-05 15:03 EDT by Josh Bressers
Modified: 2013-08-05 21:08 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-13 15:06:38 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)

  None (edit)
Description Josh Bressers 2004-10-05 15:03:52 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 Mark J. Cox (Product Security) 2004-11-17 04:52:16 EST
See bug 134720 for an updated patch and description of the CVE names
Comment 2 Mark J. Cox (Product Security) 2004-12-01 06:24:01 EST
removing embargo
Comment 3 John Flanagan 2004-12-13 15:06:38 EST
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2004-505.html

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