bugtraq - Re: NOD32 Antivirus Long Path Name Stack Overflow Vulnerabilities

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: <465524FA.9000901@inkatel.com>
Date: Thu, 24 May 2007 07:39:06 +0200
From: Ismael Briones <ismak@...atel.com>
To: v9@...ehalo.us
Cc: bugtraq@...urityfocus.com
Subject: Re: NOD32 Antivirus Long Path Name Stack Overflow Vulnerabilities

You could use in your shellcode any character allowed as a directory 
character in Windows. The path name will be then converted to Unicode by 
Nod32 process.
So you have to deal with this too. I used Alpha2 
(http://www.edup.tudelft.nl/~bjwever/documentation_alpha2.html.php from 
Berend-Jan Wever) to encode an alphanumeric shellcode that will be then 
converted to Unicode:

"*
--unicode*
Make shellcode unicode-proof. This means it will only work when it gets 
converted to unicode (inserting a '0' after each byte) before it gets 
executed.
"



v9@...ehalo.us wrote:
>> Although the vulnerabilities are hard to exploit, > it's not impossible.
>> There are some restrictions to bypass:
>>
>> - The path name is formated in Unicode, so we have to find an opcode in an address with an unicode format
>> - The shellcode has to be in the path name so we have to use an Alphanumeric shellcode
>>     
>
> What's to stop someone from encoding the path(shellcode) in unicode(using both bytes of unicode/no null bytes)? Also, is there a special situation why it has to be strictly alphanumeric? Because, in general this is not the case.
>
> I've worked with these guidelines myself in the past(http://fakehalo.us/xfinder-ds.pl), and I see no specific issue with doing similar for this, unless information to the contrary isn't included.
>