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]

From: evilninja at gmx.net (Christian)
Subject: 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