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] [day] [month] [year] [list]
Message-ID: <649694840.20070816165324@SECURITY.NNOV.RU>
Date: Thu, 16 Aug 2007 16:53:24 +0400
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: "Joey Mengele" <joey.mengele@...hmail.com>
Cc: sebastian@...fgarten.com, full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com
Subject: Re: McAfee Virus Scan for Linux and Unix v5.10.0
	Local Buffer Overflow

Dear Joey Mengele,

Of cause, it's mitigating factor. But:

default  PATH_MAX  under  Linux  is  4096,  and  it's not hard to create
file/folder   with   longer   path,   it's  impossible to access it,

E.g. folder with path longer than PATH_MAX:

bash$ pwd
pwd: could not get current directory: getcwd: cannot access parent directories: Result too large
bash$ ls
job-working-directory: could not get current directory: getcwd: cannot access parent directories: Result too large

Access   is  not  required  in  this  case.  It's  possible  to  create
_searchable_ files with  the  length  up  to  approximately  MAX_PATH  +
NAME_MAX. It's more than required to exploit (4128).

--Wednesday, August 15, 2007, 9:34:50 PM, you wrote to joey.mengele@...hmail.com:

JM> You are playing handpuppet of the jackass, actually. Check PATH_MAX 
JM> in the Linux Kernel.

JM> J

JM> On Wed, 15 Aug 2007 12:53:18 -0400 monikerd <monikerd@...il.com> 
JM> wrote:
>>Joey Mengele wrote:
>>> Where does security come into play here? This is a local crash 
>>in a 
>>> non setuid binary. I would like to hear your remote exploitation 
>>
>>> scenario. Or perhaps your local privilege escalation scenario?
>>>
>>> J
>>>
>>>   
>>I'll play advocate of the devil then. Imagine a wiki running on a 
>>webserver,
>>
>>that allows anybody to create new topics which end up in
>>/articles/[Topic].txt
>>with sufficient .htaccess stuff in /articles to twart most usual 
>>attacks ..
>>
>>
>>If you could create an arbitrary long topic, then you *might*
>>be able to execute some code, when some cronjob would scan the 
>>drive
>>and come across the file?
>>
>>creating files is a different privilege than  running code. Hence 
>>imho
>>it's not a bogus advisory.
>>
>>
>>another possibility would be to create an archive that extracts an
>>incredibly
>>long filename perhaps? scanning an archive before/after it's 
>>extracted
>>is a pretty common event i guess.

JM> --
JM> Click for free information on accounting careers, $150 hour potential.
JM> http://tagline.hushmail.com/fc/Ioyw6h4dCaNyraR2kkZ8KcMCiTJDWZokEDbswig9iZ5cvsPFFYamWc/

JM> _______________________________________________
JM> Full-Disclosure - We believe in it.
JM> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
JM> Hosted and sponsored by Secunia - http://secunia.com/


-- 
~/ZARAZA http://securityvulns.com/
...без дубинки никогда не принимался он за программирование. (Лем)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ