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 attachment 44595 [details, diff] < 2.4.25 Patch
Created attachment 44596 [details, diff] 2.4 (2.4.25+) Patch
Created attachment 44597 [details, diff] <= 2.6.8.1 Patch
Created attachment 44598 [details, diff] 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 :-]
