Re: [Full-Disclosure] question regarding CAN-2004-0930
On Wed, 17 Nov 2004 17:49:12 -0600, Paul Schmehl wrote > > When you do an "ls", you are making a call that the *os* has > to respond to. The os is *not* vulnerable, so it (properly) > rejects the request as malformed. i think i get it now. as someone else explained is "wildcard expansion" also an issue here. so the (linux) os responds, before the smbd could even notice the call. > Hopefully that makes more sense to you. yes, thank you. Christian. -- BOFH excuse #433: error: one bad user found in front of screen ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] question regarding CAN-2004-0930
--On Wednesday, November 17, 2004 12:13:52 AM +0100 Christian <[EMAIL PROTECTED]> wrote: hm, i still don't get it: the daemon has to answer to "dir" too, doesn't he? the sole reason that "ls is a unix utility" does not make sense in this context. "ls" and "dir" are not vulnerable here, sure, but this still does not explain why smbd acts different here. i've played around with tcpdump and strace here. the tcpdump looks very similiar, the smbd's answer to "ls" is much shorter, as "strace" reveals. I've obviously done a poor job of explaining the problem then. When you do a "dir", you are making a call that the daemon has to respond to. The daemon is vulnerable, so when you make a "dir" request with the specific parameters that overflow the buffer in the daemon, it crashes. When you do an "ls", you are making a call that the *os* has to respond to. The os is *not* vulnerable, so it (properly) rejects the request as malformed. Hopefully that makes more sense to you. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] question regarding CAN-2004-0930
Rob klein Gunnewiek wrote: Not completely so. Issuing the command using the client causes that the wildcards are sent to the server where globbing is handled.. there's also where the error occurs. When you mount it first and you do the 'ls' command, your local BASH (not 'ls') handles the globbing (wildcards) so it doesn't even arrive at the smb server. ah, now that makes sense, yes. thanks for the explanation. Christian. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] question regarding CAN-2004-0930
On Tue, 16 Nov 2004 11:34:59 -0500, Castigliola, Angelo <[EMAIL PROTECTED]> wrote: > > The reason is that when you run the "dir" command Samba does the > processing and chokes. When you try the latter command "ls" Linux\Unix > processes the command and has no problems. > Not completely so. Issuing the command using the client causes that the wildcards are sent to the server where globbing is handled.. there's also where the error occurs. When you mount it first and you do the 'ls' command, your local BASH (not 'ls') handles the globbing (wildcards) so it doesn't even arrive at the smb server. -- Rob klein Gunnewiek ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] question regarding CAN-2004-0930
Blah, the difference is that the linux shell does * expansion i think. > hm, i still don't get it: the daemon has to answer to "dir" too, doesn't > he? the sole reason that "ls is a unix utility" does not make sense in > this context. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] question regarding CAN-2004-0930
Paul Schmehl wrote: Because in the former case you were attempting to access a file through the daemon. In the latter, you were attempting to access a file through a unix utility. The former (smbd) is vulnerable. The latter (ls) apparently is not. hm, i still don't get it: the daemon has to answer to "dir" too, doesn't he? the sole reason that "ls is a unix utility" does not make sense in this context. "ls" and "dir" are not vulnerable here, sure, but this still does not explain why smbd acts different here. i've played around with tcpdump and strace here. the tcpdump looks very similiar, the smbd's answer to "ls" is much shorter, as "strace" reveals. so i just assume that "dir" _triggers_ the bug, while "ls" does not and since i lack C expertise (and the souce of "dir"), i'll never find out why ;) and no, i am not digging deeper here, i was just curious. thank you (both) for comments, Christian. -- BOFH excuse #170: popper unable to process jumbo kernel ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] question regarding CAN-2004-0930
--On Tuesday, November 16, 2004 03:16:44 PM +0100 Christian Kujau <[EMAIL PROTECTED]> wrote: "ls" returned *instantly* with "No such file or directory" and smbd did not go crazy. now i ask myself: how comes? Because in the former case you were attempting to access a file through the daemon. In the latter, you were attempting to access a file through a unix utility. The former (smbd) is vulnerable. The latter (ls) apparently is not. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] question regarding CAN-2004-0930
The reason is that when you run the "dir" command Samba does the processing and chokes. When you try the latter command "ls" Linux\Unix processes the command and has no problems. Angelo Castigliola III Enterprise Security Architecture UnumProvident Telephone: 207-575-3820 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of evilninja Sent: Tuesday, November 16, 2004 9:17 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Full-Disclosure] question regarding CAN-2004-0930 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, don't know if this is the right place to ask, but here it goes: i was notified by one of my users (!) about the recent samba vulnerability (CAN-2004-0930 [1]) that this is indeed easily "exploitable" by just issuing commands with long wildcard-patterns in the filename part, just as: :\> dir **.exe ok, my smbd went crazy and the "dir" command was waiting for the result. but: when i mounted the smb-share under linux (mount -t smbfs ) and issuing $ ls /mnt/smb-share/***.exe "ls" returned *instantly* with "No such file or directory" and smbd did not go crazy. now i ask myself: how comes? thank you for comments, Christian. [1] http://samba.iasi.roedu.net/samba/security/CAN-2004-0930.html - -- BOFH excuse #120: we just switched to FDDI. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmgveC/PVm5+NVoYRAkOFAJ9SdPk1yskCAwAId+wOfCY3n4rR0ACfVB3K mObYXTZxboxpcLnV4vaov9Q= =J3hN -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] question regarding CAN-2004-0930
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, don't know if this is the right place to ask, but here it goes: i was notified by one of my users (!) about the recent samba vulnerability (CAN-2004-0930 [1]) that this is indeed easily "exploitable" by just issuing commands with long wildcard-patterns in the filename part, just as: :\> dir **.exe ok, my smbd went crazy and the "dir" command was waiting for the result. but: when i mounted the smb-share under linux (mount -t smbfs ) and issuing $ ls /mnt/smb-share/***.exe "ls" returned *instantly* with "No such file or directory" and smbd did not go crazy. now i ask myself: how comes? thank you for comments, Christian. [1] http://samba.iasi.roedu.net/samba/security/CAN-2004-0930.html - -- BOFH excuse #120: we just switched to FDDI. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmgveC/PVm5+NVoYRAkOFAJ9SdPk1yskCAwAId+wOfCY3n4rR0ACfVB3K mObYXTZxboxpcLnV4vaov9Q= =J3hN -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] question regarding CAN-2004-0930
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, don't know if this is the right place to ask, but here it goes: i was notified by one of my users (!) about the recent samba vulnerability (CAN-2004-0930 [1]) that this is indeed easily "exploitable" by just issuing commands with long wildcard-patterns in the filename part, just as: :\> dir **.exe ok, my smbd went crazy and the "dir" command was waiting for the result. but: when i mounted the smb-share under linux (mount -t smbfs ) and issuing $ ls /mnt/smb-share/***.exe "ls" returned *instantly* with "No such file or directory" and smbd did not go crazy. now i ask myself: how comes? thank you for comments, Christian. [1] http://samba.iasi.roedu.net/samba/security/CAN-2004-0930.html - -- BOFH excuse #120: we just switched to FDDI. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmgvL+A7rjkF8z0wRAjCwAJ90xxcrTOj9h0OIT5SQO+C9skSUzgCfYlK4 EqkXTwEDJHaQi6ItZShdYWI= =xvPA -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
