full-disclosure - question regarding CAN-2004-0930

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <72EF783FF480DC3C2E424B63@utd49554.utdallas.edu>
From: pauls at utdallas.edu (Paul Schmehl)
Subject: question regarding CAN-2004-0930

--On Wednesday, November 17, 2004 12:13:52 AM +0100 Christian 
<evilninja@....net> 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 (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu