[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d3t3ki7t.fsf@mid.deneb.enyo.de>
Date: Fri, 27 Aug 2010 20:45:26 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Dan Kaminsky <dan@...para.com>
Cc: Valdis.Kletnieks@...edu, full-disclosure@...ts.grok.org.uk
Subject: Re: DLL hijacking with Autorun on a USB drive
* Dan Kaminsky:
> Short version: Go see how many DLLs exist outside of c:\windows\system32.
> Look, ye mighty, and despair when you realize all those apps would be broken
> by CWD DLL blocking.
We've been discussing this issue a long time with regard to module
include paths in what used to be considered scripting languages. It's
essentially the same issue. The best fix seems to be to use the
directory the script is in to seed the include path, and not the
current directory.
It's a mostly-local issue on UNIX-like systems, for two reasons: these
days, Windows is much, much closer to the old UNIX "everything is a
file" model than the UNIX successors. Most desktops there use special
libraries to make remote resources appear local, and do not rely on
the lower layers of the operating system to provide this service.
Scripting languages and dynamic linkers are thus not as directly
exposed as they would be on Windows. Furthermore, there is a
relatively strong primary verb distinction on UNIX-like systems
because of the executable bit, which is not set by saving a download
(unless you are on FAT, which means that USB sticks can still be a
vector).
But it's curious how close these dekstops are these days, and how many
vulnerabilities have very precise equivaelents (.LNK vs. .desktop
files is yet another example).
_______________________________________________
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