Bugzilla Bug 65877

CAN-2004-0882 Samba 3.x unicode filename buffer overflow
CAN-2004-0883 Multiple buffer overflows in linux kernel smbfs

This is what CERT was contacting us about.

The Samba Team will be releasing Samba 2.2.12 to address
this bug in the 2.2.x series.  Since this issue has already
been fixed in Samba 3.0.6 and later, we will only be releasing
a patch (the one attached to this email) for earlier
3.0.x versions.  The public announcement is planned for 16:00
CEST (GMT+2) on Thursday, September 30.


-----Forwarded Message-----
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
Date: Mon, 27 Sep 2004 10:35:04 +0200

On request of redhat and suse here are extracts of my mails to
security@samba.org and linus/marcelo/urban

Samba Bug
---------

> Hi,
>
> I just wanted to make the first contact concerning a remote vulnerability
> in Samba 3.x  Please notify me about arrival of this message as soon
> as possible.
>
> the bug:
>
> trans2.c - static int call_trans2qfilepathinfo(connection_struct *conn,
>
>  data_size = max_data_bytes + 1024;
>  pdata = Realloc(*ppdata, data_size);
>
> max_data_bytes from client is trusted. Can f.e. be 0
> In 2.x this was no problem because only the dos8name was
> copied into the packet. (which was wrong)
>
> In 3.x the unicode complete filename is copied into the
> packet. This will overflow the allocated memory on longer
> filenames.
>
> f.e. in
> case SMB_QUERY_FILE_NAME_INFO:
> and
> case SMB_QUERY_FILE_ALL_INFO:
> case SMB_FILE_ALL_INFORMATION:


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 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...

From: 	Stefan Esser <s.esser@e-matters.de>
To: 	Josh Bressers <bressers@redhat.com>
Cc: 	vendor-sec@lst.de
Subject: 	Re: [vendor-sec] Samba 3.x Remote Heap Overflow and Linux smbfs remote overflows
Date: 	Thu, 30 Sep 2004 08:36:01 +0200	
Morning vendor-sec,

> Anyhow, the issues you speak of were reported by Stefan Esser, which puts
> him in the drivers seat for this one.
> 
> Stefan, any ideas on an embargo date?

Well the thing is that security@samba.org said: 
Uhh we believe this is hard to exploit and therefore lets call it a DOS
(and btw... how can overwriting glibc malloc control structures
result in code execution?)

Now I am in the situation that I have not completed a POC for this one
because I wasted on the one hand a lot of time on trying to exploit the
more interesting (linux kernel remote) one and on the other hand my
time for doing this stuff is limited to parts of the weekend at the
moment.  

This means I will create the POC at the weekend, to convince samba
security of the existence of malloc exploits and after that I am ready
to release. I seriously doubt that they will release anything until
I proofed it to them.

If I recall correctly linux kernel bugs are usually fixed in the
distributions long time before the next stable kernel reaches the street
and therefore just tell me how long you need to build your kernels and
test them. In the meantime I will simply try to get an answer from
Marcelo about his plans to handle this. (Maybe one day he will answer
one of my emails)


Stefan Esser

We already require >=samba-3.0.7 as per GLSA 200409-16 so CAN-2004-0882 is
covered here.

That leaves us with CAN-2004-0883 kernel smbfs issue.

These issues don't seem to have been touched upon upstream yet, adding on
gregkh to this bug in case he knows more.

This may of been addressed in 2.6.9rc3. But we are not supposed to patch it yet
or make a big deal. This is simply a tracker bug for internal awareness. 
This bug should never be opened to the public either. When it's time file a new
bug.

As a general usage note : you don't need to remove "Gentoo Security" group to
open the bug to non-Security members. Adding someone to Cc: will make them see
the bug (unless you uncheck the "Users in the Cc List can always view this bug"
checkbox).

Security test comment -- please ignore.

Moving to newly-created kernel-specific category

Created an attachment (id=44595) [edit]
< 2.4.25 Patch

Created an attachment (id=44596) [edit]
2.4 (2.4.25+) Patch

Created an attachment (id=44597) [edit]
<= 2.6.8.1 Patch

Created an attachment (id=44598) [edit]
2.6.9 Patch

Changing status, this is now public.

All done, the following externally maintained sources need fixing:

gentoo-dev-sources - Adding dsd...
grsec-sources - Solar's already on...
hardened(-dev)-sources - Adding hardened herd...
hardened-sources - Adding hardened herd...
hppa(-dev)-sources - Adding GMSoft...
mips-sources - Adding Kumba...
pegasos-dev-sources - Adding dholm...
openmosix-sources - Adding cluster herd.
rsbac(-dev)-sources - Adding kang...
selinux-sources - There are masked, taking no action...
sparc-sources - Adding joker...

gentoo-dev-sources fixed, both 2.6.9 for normal users and 2.6.7 for sparcs

hppa-(dev-)sources done.

oM-sources done.

sparc-sources-2.4.28 stable

mips-sources patched.

pegasos-dev-sources fixed

hardened-sources bumped to 2.4.28

Note: hardened-sources are only ~arch; the maintainer scox needs to declare
them stable or the hardened team can after it gets a little feedback from the
users.

rsbac-dev-sources: done

rsba-sources bumped to 2.4.28 (~x86)

Hardened herd: Only hardened-dev-sources is left for this bug. Some swift
action would be appreciated since this is blocking the GLSA. We may need to
mask if this issue is not dealt with quickly. Thanks!

Fixed in stable hardened-dev-sources-r16

Mitre has assigned the following CVE id's to this issue:

CAN-2004-0949
CAN-2004-0882
CAN-2004-0883

This can be closed?

Hi
it seems, this patch cause some special behavior of mounted smb-shares.
When I write to a mounted share "echo abcdefg > test.txt" it blocks for about 30s but then the file is written correctly. 
dmesg shows: 
smb_trans2: invalid data, disp=0, cnt=0, tot=0, ofs=0
smb_add_request: request [0000010035e29e00, mid=15] timed out!

I use gentoo-dev-soures and since r6 I have this problem, and since then this patch is added to the ebuild. With every other kernel I don't have this problem.
(Server is samba-3.0.9-r1)

theres a bug open for this (bug 72968) http://bugs.gentoo.org/show_bug.cgi?id=72968#c7 
but it is assigned to the samba team and I think it's a problem of this patch and not a problem on the server side (that's why i post here).

Frank Meier

All kernels fixed, closing bug; notifications are being migrated away from
GLSAs for kernels, more news coming soon so stay tuned :-]