Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan Kaminsky wrote: On Tue, Sep 14, 2010 at 6:07 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Dan Kaminsky wrote: 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. No, that's the too much shortened version. The correct version but is: Go see how many DLLs exist outside of the DLL search path. CWD DLL blocking does NOT break all those apps! Apps which install their DLLs into their own application directory won't notice CWD blocking at all. And apps which break can be easily fixed: [HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\application.exe] Path=... exists for more than 15 years now. An automatic patch that breaks random apps will not be an automatic patch -- and neither will the twenty patches after it. There is no automatic patch. KB2264107 just enables an Administrator to (finally) exempt CWD from the DLL search path. Nobody cares that the breakage can be fixed with some fifteen year old key. The Administrator who blocks DLL loading from CWD but cares! BTW: Windows developers and administrators should know their platform. Stefan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan Kaminsky wrote: h0h0h0. There be history, Larry. 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. No, that's the too much shortened version. The correct version but is: Go see how many DLLs exist outside of the DLL search path. CWD DLL blocking does NOT break all those apps! Apps which install their DLLs into their own application directory won't notice CWD blocking at all. And apps which break can be easily fixed: [HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\application.exe] Path=... exists for more than 15 years now. Stefan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Paul Szabo wrote: Christian Sciberras uuf6...@gmail.com wrote: ... the user has opened the bad file ... The victim views a data file, does not (directly) run an executable. The data file could be as harmless as a Word document or a plain-text file. Word (resp. MS Office) documents ain't harmless: they may contain VBA code. Plain text files can be harmfull too: any *.pl, *.js, *.vbs, *.reg which gets opened^Winterpreted by its associated application, not just viewed in the editor, can cause havoc. And it doesn't really matter whether the user double-clicks the file, or starts the resp. application first and opens the file from there. Stefan ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Wed, 15 Sep 2010 17:45:27 +0200, Stefan Kanthak said: BTW: Windows developers and administrators should know their platform. You're new here, aren't you? :) Out in the real world, if they have a McSE cert and know enough to keep the server running, they get the job even if they don't understand what some of those mystical registry keys do. The sad fact of the matter is that there are a *lot* of servers out there, and there simply aren't enough truly clued experienced admins to run them all. So most of them limp along with an unclued admin (who very well may be also acting as a secretary, or a junior designer, or a tech writer or a grad student, and who really wants to get back to their real job instead of futzing around with the server). pgplMh87SnHjO.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Tue, Sep 14, 2010 at 6:07 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Dan Kaminsky wrote: h0h0h0. There be history, Larry. 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. No, that's the too much shortened version. The correct version but is: Go see how many DLLs exist outside of the DLL search path. CWD DLL blocking does NOT break all those apps! Apps which install their DLLs into their own application directory won't notice CWD blocking at all. And apps which break can be easily fixed: [HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\application.exe] Path=... exists for more than 15 years now. Stefan An automatic patch that breaks random apps will not be an automatic patch -- and neither will the twenty patches after it. Nobody cares that the breakage can be fixed with some fifteen year old key. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
There's lots of ways for programmers to get this right, which is why you're going to see a lot of patches coming out over a long period of time. Forget the registry key, there's a SetDLLDirectory() API call (http://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspx ), although it seems to me this should take a PATH-type string with multiple directories rather than just one. But since there's nothing Microsoft can impose without breaking lots of apps, nothing systemic will be done. The fact that Microsoft is this concerned about the number of apps that will be broken also illustrates the extent of the problem, because each of those installations is likely vulnerable. -Original Message- From: Dan Kaminsky [mailto:d...@doxpara.com] Sent: Tuesday, September 14, 2010 6:54 PM To: Stefan Kanthak Cc: Larry Seltzer; full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edu Subject: Re: DLL hijacking with Autorun on a USB drive On Tue, Sep 14, 2010 at 6:07 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Dan Kaminsky wrote: h0h0h0. There be history, Larry. 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. No, that's the too much shortened version. The correct version but is: Go see how many DLLs exist outside of the DLL search path. CWD DLL blocking does NOT break all those apps! Apps which install their DLLs into their own application directory won't notice CWD blocking at all. And apps which break can be easily fixed: [HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\application.exe] Path=... exists for more than 15 years now. Stefan An automatic patch that breaks random apps will not be an automatic patch -- and neither will the twenty patches after it. Nobody cares that the breakage can be fixed with some fifteen year old key. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, 2 Sep 2010 valdis.kletni...@vt.edu wrote: Yeah, but hacking a Harvard architecture is still balls harder than hacking a von Neumann architecture. ;) It depends. Can Harvard architecture stop a careless program from loading a malicious DLL? From interpreting parts of data files as programs in some kind of script language? On Thu, 2 Sep 2010, coderman wrote: there are some useful mitigations around these inevitable failures, http://qubes-os.org/Architecture.html is an example of isolation rather than correctness i've liked since NetTop wrapped RSBAC policy around vmware guest isolation... Actually, you prove my point. Qubes OS does not try to separate code and data. It does not rely on the code (other than its own) behaving as expected. It throws everything in an isolated box and makes sure nothing leaves the box and enters another one without your explicit approval. -- Pavel Kankovsky aka Peak / Jeremiah 9:21\ For death is come up into our MS Windows(tm)... \ 21st century edition / ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Tue, 31 Aug 2010 valdis.kletni...@vt.edu wrote: Only if your OS's security model understands the fact that executable code and data belong in different security domains and thus different rules should apply about what files to trust in each category. If your OS's security model understands programs and data belong in different security domains then every instruction of code on your computer is trusted to enforce that policy. Your line of defence goes through every program and any bug can breach it. The failure is inevitable. [1] [1] P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner and J. F. Farrell, The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments, In Proceedings of the 21st National Information Systems Security Conference, 1998, pp. 303--314 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.5890 -- Pavel Kankovsky aka Peak / Jeremiah 9:21\ For death is come up into our MS Windows(tm)... \ 21st century edition / ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, 02 Sep 2010 20:47:03 +0200, Pavel Kankovsky said: On Tue, 31 Aug 2010 valdis.kletni...@vt.edu wrote: Only if your OS's security model understands the fact that executable code and data belong in different security domains and thus different rules should apply about what files to trust in each category. If your OS's security model understands programs and data belong in different security domains then every instruction of code on your computer is trusted to enforce that policy. Your line of defence goes through every program and any bug can breach it. The failure is inevitable. [1] [1] P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner and J. F. Farrell, The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments, In Proceedings of the 21st National Information Systems Security Conference, 1998, pp. 303--314 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.5890 Yeah, but hacking a Harvard architecture is still balls harder than hacking a von Neumann architecture. ;) pgpjjWUYsAbeS.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, Sep 2, 2010 at 11:47 AM, Pavel Kankovsky p...@argo.troja.mff.cuni.cz wrote: ... If your OS's security model understands programs and data belong in different security domains then every instruction of code on your computer is trusted to enforce that policy. Your line of defence goes through every program and any bug can breach it. The failure is inevitable. [1] [1] ... The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments there are some useful mitigations around these inevitable failures, http://qubes-os.org/Architecture.html is an example of isolation rather than correctness i've liked since NetTop wrapped RSBAC policy around vmware guest isolation... defense in depth loves company, so application correctness, in addition to NX / other hw protections on guest/host, in addition to virtual machine isolation, in addition to RSBAC constraints, in addition to ... are all useful and can be combined in many ways to fit various threat models and usability requirements. this is hard to design, implement, and maintain compared to the cheap and slutty coding and configuration pervasively deployed in our current reality, however. don't hold your breath; just stay ahead of all the other low hanging fruit running un-patched, un-managed Windows installs. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, Sep 2, 2010 at 1:05 PM, valdis.kletni...@vt.edu wrote: ... Yeah, but hacking a Harvard architecture is still balls harder than hacking a von Neumann architecture. ;) sir, you've got a Coyotos stuck in your mustache. what did you eat for lunch? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
I wrote: Since 1998 at least, see: Microsoft warns of DLL vulnerability in applications http://www.h-online.com/security/news/item/Microsoft-warns-of-DLL-vulnerability-in-applications-1064584.html ... the NSA warnedPDF of the problem of DLL spoofing in its Windows NT Security Guidelines 12 years ago. http://packetstormsecurity.org/NT/audit/NSAGuidePlus.PDF (Does anyone have older references?) I now noticed: An Intro to... Windows NT Security by Steve Sutton http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm mentions DLL spoofing and seems dated Oct 1997. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Tue, Aug 31, 2010 at 7:03 PM, Dan Kaminsky d...@doxpara.com wrote: On Aug 31, 2010, at 2:20 PM, Charles Morris cmor...@cs.odu.edu wrote: On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky d...@doxpara.com wrote: Again, the clicker can't differentiate word (the document) from word (the executable). The clicker also can't differentiate word (the document) from word (the code equivalent script). The security model people keep presuming exists, doesn't. Even the situation whereby a dll is dropped into a directory of documents -- the closest to a real exploit path there is -- all those docs can be repacked into executables. What? I can differentiate my coolProposal.doc from msword.exe just fine.. Uh huh. Here, let me go ahead and create 2010 Quarterly Numbers.ppt.exe with a changed icon, and see what you notice. Mr. Szabo has already slapped your wrist for such undeserved arrogance. And yeah, I find it a joke that you think that .ppt.exe isn't pretty damn obvious. I might have fell for that when I was 9, but I haven't had a problem with a windows box in years. I will admit, at 3AM when I've been working for 18 hours and awake for 36, it is possible that I may double-click such a malicious file and then immediately think OH shit and rebuild. I know what we can do, we can repackage the Hey watch out for badguys masquerading as innocent files that everybody already knows about, contact CERT and negotiate a fix between major vendors (Hey this isn't just a MS vulnerability right??), then give a talk at blackhat to establish our fame, but now that I think about it.. that would be rude to the people who have been complaining about this since 1999. If your statement is that the windows defaults should be changed, including the hide extensions default, then I wholeheartedly agree as I detailed in my first post. It's the first thing I turn off. Many people who think the same way have considered that a vulnerability in windows for years, I wouldn't consider it part of the DLL Hijacking fiasco. Imagine if the browser lock meant arbitrary code could run. I find your faith in small collections of pixels hilarious. Imagine if the keyboard LED meant arbitrary code could run!! What? I don't even understand what you are getting at. This has nothing to do with faith in icons. My statement was that windows defaults arguably represent a vulnerability in the GUI by making proposal.doc indistinguishable from proposal.doc.exe with a crafted icon, when you are encouraged to double-click the icons through the GUI, and when doc files are supposed to be innocent to open. I was also stating the fact that this vulnerability should be addressed outside of the scope of the DLL Hijacking mess. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
And yeah, I find it a joke that you think that .ppt.exe isn't pretty damn obvious. I might have fell for that when I was 9, but I haven't had a problem with a windows box in years. I will admit, at 3AM when I've been working for 18 hours and awake for 36, it is possible that I may double-click such a malicious file and then immediately think OH shit and rebuild. Thats the real threat of this, to be honest. Yes, you, me, and (hopefully) the rest of the people on this list know what to look for before clicking on something. But, do you view a .doc, or .ppt, or .mp3 as malicious and threatening as a .exe, .bat, or .vbs? Probably not. And, you cannot honestly tell me that you've never browsed to a network share and opened a Word document. And, if that Word document opens and there's legitimate data being displayed (ie - it's the document that you were expecting to open), would you ever consider that you just compromised your system? I think that's what a lot of you are missing.. there's no real trickery involved; No changing of icons, no hiding extensions, no fake files.. a DLL could be dropped into any directory containing Office documents and now each one of those Office documents are, essentially, backdoored. And, not only that, but this is affecting file formats which were previously considered benign or harmless (for the most part). - matt www.attackvector.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Charles Morris cmor...@cs.odu.edu wrote: ... complaining about this since 1999. Since 1998 at least, see: Microsoft warns of DLL vulnerability in applications http://www.h-online.com/security/news/item/Microsoft-warns-of-DLL-vulnerability-in-applications-1064584.html ... the NSA warnedPDF of the problem of DLL spoofing in its Windows NT Security Guidelines 12 years ago. http://packetstormsecurity.org/NT/audit/NSAGuidePlus.PDF (Does anyone have older references?) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
No one is saying there's no threat. It's the way people are going about it that is doing the difference. Patching the vulnerable application won't fix this whole issue. Removing the feature from Windows core will, surely break a lot of programs. Truth is, that dll shouldn't have been in that network share in the first place. And that's the whole difference between Unix-like and Windows. Once something gets into Windows, by design, you are allowing a great deal of access. Ok, as of late they did strides in securing this area, but it wasn't designed this way. The focus should be on keeping that darn dll out of your trusted zone, not what to do with it when it is inside. As the saying goes, prevention is better than cure. Cheers, Chris. On Wed, Sep 1, 2010 at 9:47 PM, matt m...@attackvector.org wrote: And yeah, I find it a joke that you think that .ppt.exe isn't pretty damn obvious. I might have fell for that when I was 9, but I haven't had a problem with a windows box in years. I will admit, at 3AM when I've been working for 18 hours and awake for 36, it is possible that I may double-click such a malicious file and then immediately think OH shit and rebuild. Thats the real threat of this, to be honest. Yes, you, me, and (hopefully) the rest of the people on this list know what to look for before clicking on something. But, do you view a .doc, or .ppt, or .mp3 as malicious and threatening as a .exe, .bat, or .vbs? Probably not. And, you cannot honestly tell me that you've never browsed to a network share and opened a Word document. And, if that Word document opens and there's legitimate data being displayed (ie - it's the document that you were expecting to open), would you ever consider that you just compromised your system? I think that's what a lot of you are missing.. there's no real trickery involved; No changing of icons, no hiding extensions, no fake files.. a DLL could be dropped into any directory containing Office documents and now each one of those Office documents are, essentially, backdoored. And, not only that, but this is affecting file formats which were previously considered benign or harmless (for the most part). - matt www.attackvector.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, Aug 27, 2010 at 11:27 AM, matt m...@attackvector.org wrote: Dan, While I agree with most of what you're saying, I do find this to be a pretty serious issue, and here's why. 1) The file doesn't have to be fake. It could be a legitimately real ppt, vcf, eml, html, whatever. The program(s) load the rogue DLL file and there doesn't seem to be any major impact on the functionality of the software, meaning that the end user wouldn't know that there was something hostile taking place. The file opens, they can view it, modify it, whatever, and all the features seem to work. Perception is reality. 2) This opens the door for more widespread attacks. In the case of PowerPoint, one could simply find a share on a network that contains a large amount of ppt files and save his/her rogue DLL file in that directory. Then, whenever anyone opens one of the files, the attacker gets immediate access to the victims PC without the victim having any idea. 3) People are getting smarter and do view .exe's as threats. Yes, because of the fact that extensions are usually hidden and that you can modify the icon to be whatever you want it to, it's trivial to trick an end user into clicking on just about anything. However.. if I pass out my Power Point presentation on a USB stick at a business meeting that has legitimate content, no one is going to have any clue that anything else took place. There's also very little risk of detection, because you don't have to worry about that one user who doesn't have extensions hidden, or someone noticing that the icon looks funny, or different. It simply makes for a more stealthy attack. To be honest, the whole DLL hijacking concept reminds me a lot of the old temp race vulnerabilities from back in the day. Is it really a vulnerability in the true sense of the word? Not really.. it's taking advantage of a series of events and being first to cross the finish line. But, I believe that because we can get the system to execute arbitrary code (OUR arbitrary code), this really does present a serious problem, just like the old temp race conditions did. Anyway, I appreciate the feedback.. and yes, ultimately I agree that invoking this through Autorun is probably, for the most part, useless, but I was asked if it was possible and I honestly wasn't sure that it would be, which is why I wrote the post after I found out that it was. - matt www.attackvector.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ I'm going to be honest here, I see this whole DLL Hijacking thing as a non-issue. It's a known behavior. Don't run applications from untrusted locations- because then you can't trust the application- not just the DLLs it loads. We aren't in the UNIX world here, yes windows may have fine-grained permissions but with the bubbly/stupid GUI from Vista onward.. I'm not even sure how to use them off-hand- so I know for a fact random-user-sixpack can't do it. You can't just casually glance at a file on a random network share and know that nobody has been manipulating it; and it's stupid to think otherwise. Do you run random executables from flashdrives you find on the floor? Even if it has a solitaire icon? No. If there was a setuid root executable that gave you a nice game of solitaire over X, while running any script at /tmp/runme.dll^H^H^Hsh - would you call this a vulnerability or a horrible design choice? Especially so when it's -clearly- documented that it runs said script? And yes, the first thing to do on a windows desktop is to disable crappy menu fades, UAC, and hide extensions; along with a slew of other garbage. I normally spend two hours in MMC as soon as it's up. It's time for others to do the same. If you want to fix this, you may of course implement signed DLLs, but then you get the issue of signed DLLs. It would just turn out to be another UAC or MS-Maintained SSL Authority List. I suppose it would be nice if an application would compare a checksum of a DLL to a hardcoded value before it loaded it, but then you get the issue of newer (but fully compatible) DLL versions having different checksums, etc, etc. It's just a mess caused by stupid design by Microsoft. Now, if there was a way to move a CWD of a more-privileged-user process to a less-privileged-adversary defined directory before loading a given DLL, that would be a real vulnerability. the old temp race vulnerabilities from back in the day. Is it really a vulnerability in the true sense of the word? Not really.. Oh, and, race conditions are real vulnerabilities. There is no question/argument on this. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia -
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
You've written exactly what I was thinkingexcept considering the big brains discussing this, I didn't deem the email worth a nickel. But now I thought, well, why not express this concern? Considering the DOS via popups (or DOS in IE6) which we've been having increasingly as of late, I really don't want myriad me too dll injection exploits. Cheers. On Tue, Aug 31, 2010 at 5:12 PM, Charles Morris cmor...@cs.odu.edu wrote: On Fri, Aug 27, 2010 at 11:27 AM, matt m...@attackvector.org wrote: Dan, While I agree with most of what you're saying, I do find this to be a pretty serious issue, and here's why. 1) The file doesn't have to be fake. It could be a legitimately real ppt, vcf, eml, html, whatever. The program(s) load the rogue DLL file and there doesn't seem to be any major impact on the functionality of the software, meaning that the end user wouldn't know that there was something hostile taking place. The file opens, they can view it, modify it, whatever, and all the features seem to work. Perception is reality. 2) This opens the door for more widespread attacks. In the case of PowerPoint, one could simply find a share on a network that contains a large amount of ppt files and save his/her rogue DLL file in that directory. Then, whenever anyone opens one of the files, the attacker gets immediate access to the victims PC without the victim having any idea. 3) People are getting smarter and do view .exe's as threats. Yes, because of the fact that extensions are usually hidden and that you can modify the icon to be whatever you want it to, it's trivial to trick an end user into clicking on just about anything. However.. if I pass out my Power Point presentation on a USB stick at a business meeting that has legitimate content, no one is going to have any clue that anything else took place. There's also very little risk of detection, because you don't have to worry about that one user who doesn't have extensions hidden, or someone noticing that the icon looks funny, or different. It simply makes for a more stealthy attack. To be honest, the whole DLL hijacking concept reminds me a lot of the old temp race vulnerabilities from back in the day. Is it really a vulnerability in the true sense of the word? Not really.. it's taking advantage of a series of events and being first to cross the finish line. But, I believe that because we can get the system to execute arbitrary code (OUR arbitrary code), this really does present a serious problem, just like the old temp race conditions did. Anyway, I appreciate the feedback.. and yes, ultimately I agree that invoking this through Autorun is probably, for the most part, useless, but I was asked if it was possible and I honestly wasn't sure that it would be, which is why I wrote the post after I found out that it was. - matt www.attackvector.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ I'm going to be honest here, I see this whole DLL Hijacking thing as a non-issue. It's a known behavior. Don't run applications from untrusted locations- because then you can't trust the application- not just the DLLs it loads. We aren't in the UNIX world here, yes windows may have fine-grained permissions but with the bubbly/stupid GUI from Vista onward.. I'm not even sure how to use them off-hand- so I know for a fact random-user-sixpack can't do it. You can't just casually glance at a file on a random network share and know that nobody has been manipulating it; and it's stupid to think otherwise. Do you run random executables from flashdrives you find on the floor? Even if it has a solitaire icon? No. If there was a setuid root executable that gave you a nice game of solitaire over X, while running any script at /tmp/runme.dll^H^H^Hsh - would you call this a vulnerability or a horrible design choice? Especially so when it's -clearly- documented that it runs said script? And yes, the first thing to do on a windows desktop is to disable crappy menu fades, UAC, and hide extensions; along with a slew of other garbage. I normally spend two hours in MMC as soon as it's up. It's time for others to do the same. If you want to fix this, you may of course implement signed DLLs, but then you get the issue of signed DLLs. It would just turn out to be another UAC or MS-Maintained SSL Authority List. I suppose it would be nice if an application would compare a checksum of a DLL to a hardcoded value before it loaded it, but then you get the issue of newer (but fully compatible) DLL versions having different checksums, etc, etc. It's just a mess caused by stupid design by Microsoft. Now, if there was a way to move a CWD of a more-privileged-user process to a less-privileged-adversary defined directory before loading a given DLL, that
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Charles Morris cmor...@cs.odu.edu wrote: ... Don't run applications from untrusted locations ... You got it wrong. Only trusted applications are run. - The attacker prepares a WORD.DOC (and a RICHED20.DLL) file in some place. The victim clicks on the WORD.DOC file, using his own installed MSWord. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
... Don't run applications from untrusted locations ... You got it wrong. Only trusted applications are run. - The attacker prepares a WORD.DOC (and a RICHED20.DLL) file in some place. The victim clicks on the WORD.DOC file, using his own installed MSWord. Aaah, well if that is the issue, it seems to me that the vulnerability here is that the application in question (MSWord) has it's CWD set to the directory of the file that it is opening through the explorer shell. It should chdir() to it's own parent directory before doing anything interesting that depends on CWD. (i.e. loading DLLs or executing ./amazingApp.sh) It's general good programming practice to be mindful of your CWD, I know that personally; a call to chdir() is almost always at the top of my script. So, I take back what I said about it being a non-issue, it IS in fact a vulnerability in the application. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Tue, 31 Aug 2010 11:12:42 EDT, Charles Morris said: Do you run random executables from flashdrives you find on the floor? Even if it has a solitaire icon? No. No, they have to be found out in the parking lot. :) pgp8tILkp5yVe.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky d...@doxpara.com wrote: Again, the clicker can't differentiate word (the document) from word (the executable). The clicker also can't differentiate word (the document) from word (the code equivalent script). The security model people keep presuming exists, doesn't. Even the situation whereby a dll is dropped into a directory of documents -- the closest to a real exploit path there is -- all those docs can be repacked into executables. What? I can differentiate my coolProposal.doc from msword.exe just fine.. If your statement is that the windows defaults should be changed, including the hide extensions default, then I wholeheartedly agree as I detailed in my first post. It's the first thing I turn off. Many people who think the same way have considered that a vulnerability in windows for years, I wouldn't consider it part of the DLL Hijacking fiasco. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Aug 31, 2010, at 2:01 PM, Charles Morris cmor...@cs.odu.edu wrote: ... Don't run applications from untrusted locations ... You got it wrong. Only trusted applications are run. - The attacker prepares a WORD.DOC (and a RICHED20.DLL) file in some place. The victim clicks on the WORD.DOC file, using his own installed MSWord. Aaah, well if that is the issue, it seems to me that the vulnerability here is that the application in question (MSWord) has it's CWD set to the directory of the file that it is opening through the explorer shell. It should chdir() to it's own parent directory before doing anything interesting that depends on CWD. (i.e. loading DLLs or executing ./ amazingApp.sh) It's general good programming practice to be mindful of your CWD, I know that personally; a call to chdir() is almost always at the top of my script. So, I take back what I said about it being a non-issue, it IS in fact a vulnerability in the application. Again, the clicker can't differentiate word (the document) from word (the executable). The clicker also can't differentiate word (the document) from word (the code equivalent script). The security model people keep presuming exists, doesn't. Even the situation whereby a dll is dropped into a directory of documents -- the closest to a real exploit path there is -- all those docs can be repacked into executables. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Adding to Charles' this dll hijacking is even less than a non-issue considering that the user has opened the bad file in the first place. I don't see it a matter of changing the cwd, but rather the user shouldn't be running stuff which he doesn't know about. It's the same analogy Charles mentioned all over again. Dan: The security model people keep presuming exists, doesn't. Dan, there was no security model, and no one assumed there was. Running dubious files, from anywhere, is always a security risk. This is more of an anti-virus fix than changing CWD: the anti-virus/ips/whatever knows that the dll-to-be-loaded is from an external source, and it should wail out a warning. I fully acknowledge a message telling me I'm about to run an executable I've just downloaded, but simply refusing to run it properly isn't something I, (or normal users, for the matter) would want. Finally, this Application X is vulnerable to dll hijcak needs to stop, right now. This whole darn thing is stupid...most if not all applications set the CWD to the target path for several reasons. Microsoft Office suite, for instance, keep backup (archives, caches and whatnot) files in the same folder the main file resides. Switching between directories is surely not an option. On Tue, Aug 31, 2010 at 11:20 PM, Charles Morris cmor...@cs.odu.edu wrote: On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky d...@doxpara.com wrote: Again, the clicker can't differentiate word (the document) from word (the executable). The clicker also can't differentiate word (the document) from word (the code equivalent script). The security model people keep presuming exists, doesn't. Even the situation whereby a dll is dropped into a directory of documents -- the closest to a real exploit path there is -- all those docs can be repacked into executables. What? I can differentiate my coolProposal.doc from msword.exe just fine.. If your statement is that the windows defaults should be changed, including the hide extensions default, then I wholeheartedly agree as I detailed in my first post. It's the first thing I turn off. Many people who think the same way have considered that a vulnerability in windows for years, I wouldn't consider it part of the DLL Hijacking fiasco. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Christian Sciberras uuf6...@gmail.com wrote: ... the user has opened the bad file ... The victim views a data file, does not (directly) run an executable. The data file could be as harmless as a Word document or a plain-text file. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
See, that's where the whole industry is failing at. There's only two kinds of files: trusted and untrusted. Why do you say harmless? Because you know a text file can't do anything at all. What if it was, for example an html page which when viewed would cause a BHO to be installed, such as in a very old version of Windows? The point of issue is not blacklisting, ie, differentiating between what is right are wrong, but siding up with what _you_know_ is right. In short, that innocent text file is (or at least should be considered) as malicious as an executable. Finally, it is not in the interest of any system to do the above differentiation (unless it was a paranoid platform we all just love). The security issue is comparable to running an executable directly from a USB drive which you founduh I'm repeating myself. Hope you get my point of view. Cheers. On Wed, Sep 1, 2010 at 12:04 AM, paul.sz...@sydney.edu.au wrote: Christian Sciberras uuf6...@gmail.com wrote: ... the user has opened the bad file ... The victim views a data file, does not (directly) run an executable. The data file could be as harmless as a Word document or a plain-text file. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Christian Sciberras uuf6...@gmail.com wrote: Why do you say harmless? Because you know a text file can't do anything at all. Exactly. The victim is attempting to view a plain text file. Surely that can be done safely? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Wed, 01 Sep 2010 08:34:47 +1000, paul.sz...@sydney.edu.au said: Christian Sciberras uuf6...@gmail.com wrote: Why do you say harmless? Because you know a text file can't do anything at all. Exactly. The victim is attempting to view a plain text file. Surely that can be done safely? Only if your OS's security model understands the fact that executable code and data belong in different security domains and thus different rules should apply about what files to trust in each category. (and yes, interpreted data like shell scripts and Java .class files and Flash are the sort of neither-fish-nor-fowl that give security models headaches, so don't bother flaming about that. ;) pgpPc5biQuzCg.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
From a user perspective, why can't someone run Solitaire.exe off a USB? (as a plain example) Consider exploits, such as BOFs caused by bad file formats, how do you know which is secure or not? The main difference between a BOF and this issue is that it is a software fault, whereas the hijack issue is nothing less than an impractical nitpick. On Wed, Sep 1, 2010 at 12:34 AM, paul.sz...@sydney.edu.au wrote: Christian Sciberras uuf6...@gmail.com wrote: Why do you say harmless? Because you know a text file can't do anything at all. Exactly. The victim is attempting to view a plain text file. Surely that can be done safely? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
(and yes, interpreted data like shell scripts and Java .class files and Flash are the sort of neither-fish-nor-fowl that give security models headaches, so don't bother flaming about that. ;) OK. Also add exploits in non-executable data as well (such as a certain gif...). What was your point again? Cheers. On Wed, Sep 1, 2010 at 12:56 AM, valdis.kletni...@vt.edu wrote: On Wed, 01 Sep 2010 08:34:47 +1000, paul.sz...@sydney.edu.au said: Christian Sciberras uuf6...@gmail.com wrote: Why do you say harmless? Because you know a text file can't do anything at all. Exactly. The victim is attempting to view a plain text file. Surely that can be done safely? Only if your OS's security model understands the fact that executable code and data belong in different security domains and thus different rules should apply about what files to trust in each category. (and yes, interpreted data like shell scripts and Java .class files and Flash are the sort of neither-fish-nor-fowl that give security models headaches, so don't bother flaming about that. ;) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Aug 31, 2010, at 2:20 PM, Charles Morris cmor...@cs.odu.edu wrote: On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky d...@doxpara.com wrote: Again, the clicker can't differentiate word (the document) from word (the executable). The clicker also can't differentiate word (the document) from word (the code equivalent script). The security model people keep presuming exists, doesn't. Even the situation whereby a dll is dropped into a directory of documents -- the closest to a real exploit path there is -- all those docs can be repacked into executables. What? I can differentiate my coolProposal.doc from msword.exe just fine.. Uh huh. Here, let me go ahead and create 2010 Quarterly Numbers.ppt.exe with a changed icon, and see what you notice. If your statement is that the windows defaults should be changed, including the hide extensions default, then I wholeheartedly agree as I detailed in my first post. It's the first thing I turn off. Many people who think the same way have considered that a vulnerability in windows for years, I wouldn't consider it part of the DLL Hijacking fiasco. Imagine if the browser lock meant arbitrary code could run. I find your faith in small collections of pixels hilarious. Cheers, Charles ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan Kaminsky d...@doxpara.com wrote: I can differentiate my coolProposal.doc from msword.exe just fine.. Uh huh. Here, let me go ahead and create 2010 Quarterly Numbers.ppt.exe with a changed icon, and see what you notice. So you (Dan) can differentiate. Why couldn't other do the same? Do you honestly think you are so much smarter than anyone else? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
valdis.kletni...@vt.edu wrote: ... The victim is attempting to view a plain text file. Surely that can be done safely? Only if your OS's security model understands the fact that executable code and data belong in different security domains and thus different rules should apply about what files to trust in each category. Hmm... an OS that cannot view plain-text in a safe manner... Shame on those who would call that an OS. Yes, even the Windows security model understands those things. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Aug 31, 2010, at 4:08 PM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com wrote: I can differentiate my coolProposal.doc from msword.exe just fine.. Uh huh. Here, let me go ahead and create 2010 Quarterly Numbers.ppt.exe with a changed icon, and see what you notice. So you (Dan) can differentiate. Why couldn't other do the same? It's not that they can't. It's that they don't, and we have huge amounts of data confirming this. Have you never been to a Moxie Marlinspike talk? His success rates on SSL Stripping a tor node were 100%. 100%!!! Do you honestly think you are so much smarter than anyone else? It's not about intelligence, it's about what you and I care about. For example, I don't care about how cars work. I want to put my key in the ignition and go. There's only so much anyone really cares about. Outside of our little club here, people want the computer to just work. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Tue, Aug 31, 2010 at 4:14 PM, Dan Kaminsky d...@doxpara.com wrote: ... It's not that they can't. It's that they don't, and we have huge amounts of data confirming this. Have you never been to a Moxie Marlinspike talk? His success rates on SSL Stripping a tor node were 100%. 100%!!! this was days into his experiment, however, and those with clue were scared away from his exit pretty quick. i believe Moxie mentioned this as a shortcoming in his presentation - it would have been nice to collect stats from the get go. then he might have shown only a 99.72% success rate. (some people *still* use IE over Tor, which is absolute insanity) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Aug 31, 2010, at 4:11 PM, paul.sz...@sydney.edu.au wrote: valdis.kletni...@vt.edu wrote: ... The victim is attempting to view a plain text file. Surely that can be done safely? Only if your OS's security model understands the fact that executable code and data belong in different security domains and thus different rules should apply about what files to trust in each category. Hmm... an OS that cannot view plain-text in a safe manner... Shame on those who would call that an OS. Yes, even the Windows security model understands those things. Notepad.exe can launch from iexplore.exe in some contexts; this open is safe (and when it isn't, it's Critical). Notepad.exe can launch from Explorer.exe in some contexts, this open is not safe. iexplore.exe has a security model. Explorer.exe doesn't (outside of standard user). That's the reality, shared by all the desktops. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Wed, 01 Sep 2010 00:59:06 +0200, Christian Sciberras said: (and yes, interpreted data like shell scripts and Java .class files and Flash are the sort of neither-fish-nor-fowl that give security models headaches, so don't bother flaming about that. ;) OK. Also add exploits in non-executable data as well (such as a certain gif...). What was your point again? Are you seriously suggesting that just because errors in implementation happen (such as malformed gifs leading to bugger overflows, etc), that it's OK to have a totally broken security model that doesn't even *try* to get it right? Since you *might* be able to find a hole using user-supplied data, we'll just assumed that you *did* find one, and we'll make it easy for you and just allow you to provide your exploit code as totally untrusted files from an untrusted source. Hmm.. where have I heard that before? Oh yes... Mr Prosser (who was arguing with a spokesman for the bulldozer drivers about whether or not Arthur Dent constituted a mental health hazard, and how much they should get paid if he did) looked around. He was surprised and slightly alarmed to find that Arthur had company. Yes? Hello? he called. Has Mr Dent come to his senses yet? Can we for the moment, called Ford, assume that he hasn't? Well? sighed Mr Prosser. And can we also assume, said Ford, that he's going to be staying here all day? So? So all your men are going to be standing around all day doing nothing? Could be, could be ... Well, if you're resigned to doing that anyway, you don't actually need him to lie here all the time do you? What? You don't, said Ford patiently, actually need him here. Mr Prosser thought about this. Well no, not as such..., he said, not exactly need... Prosser was worried. He thought that one of them wasn't making a lot of sense. Ford said, So if you would just like to take it as read that he's actually here, then he and I could slip off down to the pub for half an hour. How does that sound? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Are you seriously suggesting that just because errors in implementation happen (such as malformed gifs leading to bugger overflows, etc), that it's OK to have a totally broken security model that doesn't even *try* to get it right? No I'm suggesting to fix those implementation errors not focus on damn crippling the OS!! When I plug in a USB, I expect to run whatever I want from it, be it dll hijack exploits or not. At most, there might be a system policy for not running *any* file from removable drives, and of course there's the usual antivirus/ips. But that's a damn system policy not software lockdown. Why the hell should I, as a developer, end up fixing this shit just because some security experts think they discovered the next generation of exploits from running programs out of USB drives (network shares or what the fk there is out there). Perhaps you haven't noticed, Windows sees dlls as files, not as system libraries, unlike unix (linux/bsd/whatever). Whereas I could cripple a linux install just by removing certain non-system libraries, you can't do this in Windows, thanks to dll hell. Call it like that all you want, but I've found it convenient. If you guys can't understand a damn thing out of some crappy unix standard, it most certainly ain't my fault. Rant aside, I'll iterate my same central point, *this is not a vulnerability*. I won't consider it as such, ever. On Wed, Sep 1, 2010 at 1:43 AM, valdis.kletni...@vt.edu wrote: On Wed, 01 Sep 2010 00:59:06 +0200, Christian Sciberras said: (and yes, interpreted data like shell scripts and Java .class files and Flash are the sort of neither-fish-nor-fowl that give security models headaches, so don't bother flaming about that. ;) OK. Also add exploits in non-executable data as well (such as a certain gif...). What was your point again? Are you seriously suggesting that just because errors in implementation happen (such as malformed gifs leading to bugger overflows, etc), that it's OK to have a totally broken security model that doesn't even *try* to get it right? Since you *might* be able to find a hole using user-supplied data, we'll just assumed that you *did* find one, and we'll make it easy for you and just allow you to provide your exploit code as totally untrusted files from an untrusted source. Hmm.. where have I heard that before? Oh yes... Mr Prosser (who was arguing with a spokesman for the bulldozer drivers about whether or not Arthur Dent constituted a mental health hazard, and how much they should get paid if he did) looked around. He was surprised and slightly alarmed to find that Arthur had company. Yes? Hello? he called. Has Mr Dent come to his senses yet? Can we for the moment, called Ford, assume that he hasn't? Well? sighed Mr Prosser. And can we also assume, said Ford, that he's going to be staying here all day? So? So all your men are going to be standing around all day doing nothing? Could be, could be ... Well, if you're resigned to doing that anyway, you don't actually need him to lie here all the time do you? What? You don't, said Ford patiently, actually need him here. Mr Prosser thought about this. Well no, not as such..., he said, not exactly need... Prosser was worried. He thought that one of them wasn't making a lot of sense. Ford said, So if you would just like to take it as read that he's actually here, then he and I could slip off down to the pub for half an hour. How does that sound? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan Kaminsky d...@doxpara.com wrote: iexplore.exe has a security model. Explorer.exe doesn't ... Very dim view. So, there is no way for a Windows user to access his desktop, e.g. any data on a CD or USB stick, in a safe way? Seems so wasteful for MS to try and plug autorun viruses, then... Thankfully, you are wrong. All decent OSs have some security. (Some are more decent than others.) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Aug 31, 2010, at 6:49 PM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com wrote: iexplore.exe has a security model. Explorer.exe doesn't ... Very dim view. So, there is no way for a Windows user to access his desktop, e.g. any data on a CD or USB stick, in a safe way? Seems so wasteful for MS to try and plug autorun viruses, then... Thankfully, you are wrong. All decent OSs have some security. (Some are more decent than others.) Ok. Which desktop shell doesn't behave just like explorer? More instructively -- what would a secure desktop look like? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, 26 Aug 2010, Dan Kaminsky wrote: The question is whether they're supposed to execute code in this particular context. I think the question ought to be: what authority and privileges shall be granted to the code when it is executed? -- Pavel Kankovsky aka Peak / Jeremiah 9:21\ For death is come up into our MS Windows(tm)... \ 21st century edition / ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Mon, Aug 30, 2010 at 11:45 AM, Pavel Kankovsky p...@argo.troja.mff.cuni.cz wrote: On Thu, 26 Aug 2010, Dan Kaminsky wrote: The question is whether they're supposed to execute code in this particular context. I think the question ought to be: what authority and privileges shall be granted to the code when it is executed? Yeah, and the thing about all of the desktop shells (Explorer, Finder, etc) is that they're all just as happy to open a Word Document with winword.exe, as they are to open winword.exe (or something else with that name) itself. In other words, the security model is that authority and privileges are the expansive set that is full code execution as that user. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
summarized in one sentence: On Fri, Aug 27, 2010 at 7:08 AM, Dan Kaminsky d...@doxpara.com wrote: ... Welcome to DLL hell. and this hell hath many layers... ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
I'm not sure that I agree that there is nothing that antimalware systems can do to mitigate the risk. What about white-listing solutions in lock-down mode such as Lumension's or Bit9's or Symantec's or...well you get the idea. If the DLL is not trusted (not known) it won't run until it is trusted. The downside is the lack of something similar for the average Jane or Joe in the average home. A few come close but the average Jane or Joe is probably going to click right past prompts anyway. This is not to say that white listing is easy, just that it is a mitigating defense. From: full-disclosure-boun...@lists.grok.org.uk [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Larry Seltzer Sent: Friday, August 27, 2010 8:59 AM To: Dan Kaminsky; Christian Sciberras Cc: full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edu Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive I will admit that I don't have a *good* solution to this. It bothers me that there's no systemic solution coming for so widespread a problem. I'll add some more depressing news: there's basically nothing that anti-malware or IPS systems can do about this that they aren't already doing, i.e. scanning the DLLs before they load. Often with vulnerabilities there's a lot they can do, even if they're not a perfect solution, at least to look for specific attack code. There's nothing about the DLL loading technique that looks malicious. From: Dan Kaminsky [mailto:d...@doxpara.commailto:d...@doxpara.com] Sent: Friday, August 27, 2010 10:50 AM To: Christian Sciberras Cc: Larry Seltzer; full-disclosure@lists.grok.org.ukmailto:full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edumailto:valdis.kletni...@vt.edu Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive ...up till the moment you realize that the interface doesn't really differentiate between 2010 Quarterly Projections as an .exe or as a .ppt. Double clicking in desktop = do whatever it takes to run this, code execution or not. On Fri, Aug 27, 2010 at 10:36 AM, Christian Sciberras uuf6...@gmail.commailto:uuf6...@gmail.com wrote: while there's probably an actual vuln somewhere using this methodology, nothing's been found yet Do you really think so? Having any kind of executable load the first ntoskernel.dll it finds, such as the innocent one in it's own directory isn't really wise... On Fri, Aug 27, 2010 at 4:19 PM, Dan Kaminsky d...@doxpara.commailto:d...@doxpara.com wrote: Well, if I pull out the crystal ball, I see two possibilities: 1) Patch goes out, implementing this policy 2) 1% of customers go dark 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE 1) Patch goes out, off by default 2) 0% of customers turn it on 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE Neither look exactly appetizing, and it's not like we (yet) have a clear vulnerability that needs to be addressed. On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer la...@larryseltzer.commailto:la...@larryseltzer.com wrote: #1 in the DLL search list is the directory from which the program was loaded. How can you have a scenario where CWD is a better choice than that? Why would it be a good choice DLL sharing? Here's another possibility for a Microsoft action. Add a search location 1.5 specified by the application to Windows. If all the Office apps are sharing DLLs they can put their apps in Office/sharedDLLs and point to it. At least we could move forward from here. Microsoft's choice here dooms us to this problem for the forseeable future. From: Dan Kaminsky [mailto:d...@doxpara.commailto:d...@doxpara.com] Sent: Friday, August 27, 2010 10:08 AM To: Larry Seltzer Cc: valdis.kletni...@vt.edumailto:valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.ukmailto:full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight to package management -- something it could do, because a) there just aren't that many apps and b) they're mostly open source, so distros can legally fix things up. Windows comes from a different direction: Many, many consumer facing apps, very few of them open source, users installing for themselves, no package manager. Among other things, this introduces the concept of: Which DLLs should you load? Suppose you have ten applications, each using foo.dll. Should they all use foo.dll from c:\windows\system32? Maybe, maybe not. There are many possible versions that might be in there, and they might or might not work. You can push your version
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, Aug 27, 2010 at 1:51 AM, valdis.kletni...@vt.edu wrote: On Fri, 27 Aug 2010 01:29:32 EDT, Dan Kaminsky said: Again, let me emphasize. Really interesting vector, will probably end up attached to an unambiguous flaw. But right now, we're just seeing flaws along the lines of Double clicking an icon in Explorer might execute arbitrary code. It doesn't matter that that's true even if there's a network share, or a USB stick. That's what Explorer *does*. And as I said, a fix that starts off with First thing we do is feed Explorer to a pack of hungry dingos won't fly with Joe Sixpack. ;) Eh, no sense being so specific. I'm sure the same sort of type confusion tricks are possible in Finder, GNOME, KDE, etc. Desktops run arbitrary code. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Clearly desktops need to be able to run arbitrary code. That’s what they’re there for. Why wouldn’t eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn’t a good reason for anyone to load a DLL from the CWD, is there? I think they dropped the ball on this at Vista time. They made so many other changes for security reasons then that forced users and developers to change practice that this one wouldn’t have been such a big stink. And they’ve known about the basic problem for 10 years (and should have known earlier, since it was a UNIX attack beforehand). ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, 27 Aug 2010 07:20:22 EDT, Larry Seltzer said: Why wouldn't eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn't a good reason for anyone to load a DLL from the CWD, is there? The mentality that Our program only works with version 1.14 of the DLL so we'll ship a copy of it in the directory is too entrenched. That's why you'll see a box that has 4 or 5 different copies of the Java RTE on it. Of course, on a *sane* system you'd use a variable like LD_LIBRARY_PATH to say where to find the libraries (and maybe apply some W^X exclusion to path components). But there's just too many 3rd party packages that would have to be updated to make it palatable. Remember - Microsoft doesn't have any real committment to deliver a truly secure system to you. It has a committment to deliver just enough security and other features so it can deliver dollars to its shareholders. We all *know* what it would take to secure it - and it won't happen because the resulting paradidm shits will torpedo sales. pgpaOfON3vGq2.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
#1 in the DLL search list is the directory from which the program was loaded. How can you have a scenario where CWD is a better choice than that? Why would it be a good choice DLL sharing? Here’s another possibility for a Microsoft action. Add a search location 1.5 specified by the application to Windows. If all the Office apps are sharing DLLs they can put their apps in Office/sharedDLLs and point to it. At least we could move forward from here. Microsoft’s choice here dooms us to this problem for the forseeable future. *From:* Dan Kaminsky [mailto:d...@doxpara.com] *Sent:* Friday, August 27, 2010 10:08 AM *To:* Larry Seltzer *Cc:* valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk *Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight to package management -- something it could do, because a) there just aren't that many apps and b) they're mostly open source, so distros can legally fix things up. Windows comes from a different direction: Many, many consumer facing apps, very few of them open source, users installing for themselves, no package manager. Among other things, this introduces the concept of: Which DLLs should you load? Suppose you have ten applications, each using foo.dll. Should they all use foo.dll from c:\windows\system32? Maybe, maybe not. There are many possible versions that might be in there, and they might or might not work. You can push your version of foo.dll into c:\windows\system32. Great, you'll work fine, but there's nine other apps you might break. You can use a local foo.dll. Now you can have your lib and they can have theirs. Welcome to DLL hell. There's been a lot of work in fixing this situation, but not from the security perspective. I know we're masters of righteous indignation, but I have to emphasize -- while there's probably an actual vuln somewhere using this methodology, nothing's been found yet. Changing something with only a tenuous link to security, with such a massive impact on whether applications run or not? Yeah, not exactly surprised it's still there. On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer la...@larryseltzer.com wrote: Clearly desktops need to be able to run arbitrary code. That’s what they’re there for. Why wouldn’t eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn’t a good reason for anyone to load a DLL from the CWD, is there? I think they dropped the ball on this at Vista time. They made so many other changes for security reasons then that forced users and developers to change practice that this one wouldn’t have been such a big stink. And they’ve known about the basic problem for 10 years (and should have known earlier, since it was a UNIX attack beforehand). ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, Aug 27, 2010 at 9:10 AM, valdis.kletni...@vt.edu wrote: On Fri, 27 Aug 2010 07:20:22 EDT, Larry Seltzer said: Why wouldn't eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php ) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn't a good reason for anyone to load a DLL from the CWD, is there? The mentality that Our program only works with version 1.14 of the DLL so we'll ship a copy of it in the directory is too entrenched. That's why you'll see a box that has 4 or 5 different copies of the Java RTE on it. Of course, on a *sane* system you'd use a variable like LD_LIBRARY_PATH to say where to find the libraries (and maybe apply some W^X exclusion to path components). But there's just too many 3rd party packages that would have to be updated to make it palatable. As opposed to other platforms that, what, don't have 3rd party packages? :) Remember - Microsoft doesn't have any real committment to deliver a truly secure system to you. It has a committment to deliver just enough security and other features so it can deliver dollars to its shareholders. We all *know* what it would take to secure it - and it won't happen because the resulting paradidm shits will torpedo sales. Oh, come on. MS puts more effort into delivering a secure platform than pretty much anyone at this point. They're just not the low hanging fruit they once were. The difference between attack and defense is that we know when attack doesn't work. Unrolling this one characteristic pretty much yields security as it stands today. It's why attack research is so important -- it's our only source of ground truth! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Well, if I pull out the crystal ball, I see two possibilities: 1) Patch goes out, implementing this policy 2) 1% of customers go dark 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE 1) Patch goes out, off by default 2) 0% of customers turn it on 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE Neither look exactly appetizing, and it's not like we (yet) have a clear vulnerability that needs to be addressed. On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer la...@larryseltzer.comwrote: #1 in the DLL search list is the directory from which the program was loaded. How can you have a scenario where CWD is a better choice than that? Why would it be a good choice DLL sharing? Here’s another possibility for a Microsoft action. Add a search location 1.5 specified by the application to Windows. If all the Office apps are sharing DLLs they can put their apps in Office/sharedDLLs and point to it. At least we could move forward from here. Microsoft’s choice here dooms us to this problem for the forseeable future. *From:* Dan Kaminsky [mailto:d...@doxpara.com] *Sent:* Friday, August 27, 2010 10:08 AM *To:* Larry Seltzer *Cc:* valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk *Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight to package management -- something it could do, because a) there just aren't that many apps and b) they're mostly open source, so distros can legally fix things up. Windows comes from a different direction: Many, many consumer facing apps, very few of them open source, users installing for themselves, no package manager. Among other things, this introduces the concept of: Which DLLs should you load? Suppose you have ten applications, each using foo.dll. Should they all use foo.dll from c:\windows\system32? Maybe, maybe not. There are many possible versions that might be in there, and they might or might not work. You can push your version of foo.dll into c:\windows\system32. Great, you'll work fine, but there's nine other apps you might break. You can use a local foo.dll. Now you can have your lib and they can have theirs. Welcome to DLL hell. There's been a lot of work in fixing this situation, but not from the security perspective. I know we're masters of righteous indignation, but I have to emphasize -- while there's probably an actual vuln somewhere using this methodology, nothing's been found yet. Changing something with only a tenuous link to security, with such a massive impact on whether applications run or not? Yeah, not exactly surprised it's still there. On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer la...@larryseltzer.com wrote: Clearly desktops need to be able to run arbitrary code. That’s what they’re there for. Why wouldn’t eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn’t a good reason for anyone to load a DLL from the CWD, is there? I think they dropped the ball on this at Vista time. They made so many other changes for security reasons then that forced users and developers to change practice that this one wouldn’t have been such a big stink. And they’ve known about the basic problem for 10 years (and should have known earlier, since it was a UNIX attack beforehand). ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight to package management -- something it could do, because a) there just aren't that many apps and b) they're mostly open source, so distros can legally fix things up. Windows comes from a different direction: Many, many consumer facing apps, very few of them open source, users installing for themselves, no package manager. Among other things, this introduces the concept of: Which DLLs should you load? Suppose you have ten applications, each using foo.dll. Should they all use foo.dll from c:\windows\system32? Maybe, maybe not. There are many possible versions that might be in there, and they might or might not work. You can push your version of foo.dll into c:\windows\system32. Great, you'll work fine, but there's nine other apps you might break. You can use a local foo.dll. Now you can have your lib and they can have theirs. Welcome to DLL hell. There's been a lot of work in fixing this situation, but not from the security perspective. I know we're masters of righteous indignation, but I have to emphasize -- while there's probably an actual vuln somewhere using this methodology, nothing's been found yet. Changing something with only a tenuous link to security, with such a massive impact on whether applications run or not? Yeah, not exactly surprised it's still there. On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer la...@larryseltzer.comwrote: Clearly desktops need to be able to run arbitrary code. That’s what they’re there for. Why wouldn’t eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn’t a good reason for anyone to load a DLL from the CWD, is there? I think they dropped the ball on this at Vista time. They made so many other changes for security reasons then that forced users and developers to change practice that this one wouldn’t have been such a big stink. And they’ve known about the basic problem for 10 years (and should have known earlier, since it was a UNIX attack beforehand). ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
while there's probably an actual vuln somewhere using this methodology, nothing's been found yet Do you really think so? Having any kind of executable load the first ntoskernel.dll it finds, such as the innocent one in it's own directory isn't really wise... On Fri, Aug 27, 2010 at 4:19 PM, Dan Kaminsky d...@doxpara.com wrote: Well, if I pull out the crystal ball, I see two possibilities: 1) Patch goes out, implementing this policy 2) 1% of customers go dark 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE 1) Patch goes out, off by default 2) 0% of customers turn it on 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE Neither look exactly appetizing, and it's not like we (yet) have a clear vulnerability that needs to be addressed. On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer la...@larryseltzer.com wrote: #1 in the DLL search list is the directory from which the program was loaded. How can you have a scenario where CWD is a better choice than that? Why would it be a good choice DLL sharing? Here’s another possibility for a Microsoft action. Add a search location 1.5 specified by the application to Windows. If all the Office apps are sharing DLLs they can put their apps in Office/sharedDLLs and point to it. At least we could move forward from here. Microsoft’s choice here dooms us to this problem for the forseeable future. From: Dan Kaminsky [mailto:d...@doxpara.com] Sent: Friday, August 27, 2010 10:08 AM To: Larry Seltzer Cc: valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight to package management -- something it could do, because a) there just aren't that many apps and b) they're mostly open source, so distros can legally fix things up. Windows comes from a different direction: Many, many consumer facing apps, very few of them open source, users installing for themselves, no package manager. Among other things, this introduces the concept of: Which DLLs should you load? Suppose you have ten applications, each using foo.dll. Should they all use foo.dll from c:\windows\system32? Maybe, maybe not. There are many possible versions that might be in there, and they might or might not work. You can push your version of foo.dll into c:\windows\system32. Great, you'll work fine, but there's nine other apps you might break. You can use a local foo.dll. Now you can have your lib and they can have theirs. Welcome to DLL hell. There's been a lot of work in fixing this situation, but not from the security perspective. I know we're masters of righteous indignation, but I have to emphasize -- while there's probably an actual vuln somewhere using this methodology, nothing's been found yet. Changing something with only a tenuous link to security, with such a massive impact on whether applications run or not? Yeah, not exactly surprised it's still there. On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer la...@larryseltzer.com wrote: Clearly desktops need to be able to run arbitrary code. That’s what they’re there for. Why wouldn’t eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this (http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn’t a good reason for anyone to load a DLL from the CWD, is there? I think they dropped the ball on this at Vista time. They made so many other changes for security reasons then that forced users and developers to change practice that this one wouldn’t have been such a big stink. And they’ve known about the basic problem for 10 years (and should have known earlier, since it was a UNIX attack beforehand). ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, 27 Aug 2010 10:13:21 EDT, Dan Kaminsky said: Oh, come on. MS puts more effort into delivering a secure platform than pretty much anyone at this point. They're just not the low hanging fruit they once were. Oh, I'll grant you that, they *have* done a great job in the past few years, the biggest turn-around I've seen in 3 decades in this business. The point is that we all know that *really* fixing some of these issues will involve a *complete* re-architect of the system - and that's someplace they really don't want to go. Look at how many corporations were slow to jump on Vista - now imagine if the corporations had to wait for pretty much *every single app* to update to the New World Order. Remember that one of the big components of vendor lock-in is the cost of jumping ship. Now if the next WIndows release is as disruptive as jumping ship, you lose a lot of lock-in. (And remember what people said about the *first* release of UAC in the beta? A *lot* of people said it sucked hard enough to make them seriously consider moving to Linux... so it got toned down a whole lot before release.) pgp08bJX0wzps.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
...up till the moment you realize that the interface doesn't really differentiate between 2010 Quarterly Projections as an .exe or as a .ppt. Double clicking in desktop = do whatever it takes to run this, code execution or not. On Fri, Aug 27, 2010 at 10:36 AM, Christian Sciberras uuf6...@gmail.comwrote: while there's probably an actual vuln somewhere using this methodology, nothing's been found yet Do you really think so? Having any kind of executable load the first ntoskernel.dll it finds, such as the innocent one in it's own directory isn't really wise... On Fri, Aug 27, 2010 at 4:19 PM, Dan Kaminsky d...@doxpara.com wrote: Well, if I pull out the crystal ball, I see two possibilities: 1) Patch goes out, implementing this policy 2) 1% of customers go dark 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE 1) Patch goes out, off by default 2) 0% of customers turn it on 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE Neither look exactly appetizing, and it's not like we (yet) have a clear vulnerability that needs to be addressed. On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer la...@larryseltzer.com wrote: #1 in the DLL search list is the directory from which the program was loaded. How can you have a scenario where CWD is a better choice than that? Why would it be a good choice DLL sharing? Here’s another possibility for a Microsoft action. Add a search location 1.5 specified by the application to Windows. If all the Office apps are sharing DLLs they can put their apps in Office/sharedDLLs and point to it. At least we could move forward from here. Microsoft’s choice here dooms us to this problem for the forseeable future. From: Dan Kaminsky [mailto:d...@doxpara.com] Sent: Friday, August 27, 2010 10:08 AM To: Larry Seltzer Cc: valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight to package management -- something it could do, because a) there just aren't that many apps and b) they're mostly open source, so distros can legally fix things up. Windows comes from a different direction: Many, many consumer facing apps, very few of them open source, users installing for themselves, no package manager. Among other things, this introduces the concept of: Which DLLs should you load? Suppose you have ten applications, each using foo.dll. Should they all use foo.dll from c:\windows\system32? Maybe, maybe not. There are many possible versions that might be in there, and they might or might not work. You can push your version of foo.dll into c:\windows\system32. Great, you'll work fine, but there's nine other apps you might break. You can use a local foo.dll. Now you can have your lib and they can have theirs. Welcome to DLL hell. There's been a lot of work in fixing this situation, but not from the security perspective. I know we're masters of righteous indignation, but I have to emphasize -- while there's probably an actual vuln somewhere using this methodology, nothing's been found yet. Changing something with only a tenuous link to security, with such a massive impact on whether applications run or not? Yeah, not exactly surprised it's still there. On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer la...@larryseltzer.com wrote: Clearly desktops need to be able to run arbitrary code. That’s what they’re there for. Why wouldn’t eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php ) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn’t a good reason for anyone to load a DLL from the CWD, is there? I think they dropped the ball on this at Vista time. They made so many other changes for security reasons then that forced users and developers to change practice that this one wouldn’t have been such a big stink. And they’ve known about the basic problem for 10 years (and should have known earlier, since it was a UNIX attack beforehand). ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Valdis, that last statement of yours really didn't make any sense: (And remember what people said about the *first* release of UAC in the beta? A *lot* of people said it sucked hard enough to make them seriously consider moving to Linux... Without getting into any difference between Windows and Linux, myself, from a user perspective, would definitely prefer a UAC prompt than a File Manager which silently refuses to copy some files due to permissions. Really, comparing UAC to Linux's security measures wasn't smart. I'm no fan of UAC, and even less of SUDO. Cheerio, Chris. On Fri, Aug 27, 2010 at 4:47 PM, valdis.kletni...@vt.edu wrote: On Fri, 27 Aug 2010 10:13:21 EDT, Dan Kaminsky said: Oh, come on. MS puts more effort into delivering a secure platform than pretty much anyone at this point. They're just not the low hanging fruit they once were. Oh, I'll grant you that, they *have* done a great job in the past few years, the biggest turn-around I've seen in 3 decades in this business. The point is that we all know that *really* fixing some of these issues will involve a *complete* re-architect of the system - and that's someplace they really don't want to go. Look at how many corporations were slow to jump on Vista - now imagine if the corporations had to wait for pretty much *every single app* to update to the New World Order. Remember that one of the big components of vendor lock-in is the cost of jumping ship. Now if the next WIndows release is as disruptive as jumping ship, you lose a lot of lock-in. (And remember what people said about the *first* release of UAC in the beta? A *lot* of people said it sucked hard enough to make them seriously consider moving to Linux... so it got toned down a whole lot before release.) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, 27 Aug 2010 16:54:09 +0200, Christian Sciberras said: Valdis, that last statement of yours really didn't make any sense: (And remember what people said about the *first* release of UAC in the beta? A *lot* of people said it sucked hard enough to make them seriously consider moving to Linux... Without getting into any difference between Windows and Linux, myself, from a user perspective, would definitely prefer a UAC prompt than a File Manager which silently refuses to copy some files due to permissions. The point was that the *beta* UAC was prompting *all the frikking time*, and a lot of stuff it wouldn't allow, prompt or no prompt, so you'd have to log out entirely and log in as Administrator. It made people say Geez, if it's going to be *this* painful, I may as well move to Ubuntu and get anally raped with one species of cactus for free, rather than paying Microsoft for a different species of cactus. No, UAC did *not* make Windows act just like Linux. It just made it painful enough that other alternatives started looking raaal good. pgprv8RmmKS1m.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, Aug 27, 2010 at 5:27 PM, matt m...@attackvector.org wrote: 2) This opens the door for more widespread attacks. In the case of PowerPoint, one could simply find a share on a network that contains a large amount of ppt files and save his/her rogue DLL file in that directory. Then, whenever anyone opens one of the files, the attacker gets immediate access to the victims PC without the victim having any idea. This is not any different from what worms used to do back in 2000... http://dpnm.postech.ac.kr/research/04/nsri/papers/010919-Analysis-Nimda.pdf (See page 4) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Oh, I'll grant you that, they *have* done a great job in the past few years, the biggest turn-around I've seen in 3 decades in this business. I wonder what is the real product of that, *Nix or Mac's. My side is with FOSS, Linux etc and not Mac's but I do wonder. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan, While I agree with most of what you're saying, I do find this to be a pretty serious issue, and here's why. 1) The file doesn't have to be fake. It could be a legitimately real ppt, vcf, eml, html, whatever. The program(s) load the rogue DLL file and there doesn't seem to be any major impact on the functionality of the software, meaning that the end user wouldn't know that there was something hostile taking place. The file opens, they can view it, modify it, whatever, and all the features seem to work. Perception is reality. 2) This opens the door for more widespread attacks. In the case of PowerPoint, one could simply find a share on a network that contains a large amount of ppt files and save his/her rogue DLL file in that directory. Then, whenever anyone opens one of the files, the attacker gets immediate access to the victims PC without the victim having any idea. 3) People are getting smarter and do view .exe's as threats. Yes, because of the fact that extensions are usually hidden and that you can modify the icon to be whatever you want it to, it's trivial to trick an end user into clicking on just about anything. However.. if I pass out my Power Point presentation on a USB stick at a business meeting that has legitimate content, no one is going to have any clue that anything else took place. There's also very little risk of detection, because you don't have to worry about that one user who doesn't have extensions hidden, or someone noticing that the icon looks funny, or different. It simply makes for a more stealthy attack. To be honest, the whole DLL hijacking concept reminds me a lot of the old temp race vulnerabilities from back in the day. Is it really a vulnerability in the true sense of the word? Not really.. it's taking advantage of a series of events and being first to cross the finish line. But, I believe that because we can get the system to execute arbitrary code (OUR arbitrary code), this really does present a serious problem, just like the old temp race conditions did. Anyway, I appreciate the feedback.. and yes, ultimately I agree that invoking this through Autorun is probably, for the most part, useless, but I was asked if it was possible and I honestly wasn't sure that it would be, which is why I wrote the post after I found out that it was. - matt www.attackvector.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
I will admit that I don’t have a **good** solution to this. It bothers me that there’s no systemic solution coming for so widespread a problem. I’ll add some more depressing news: there’s basically nothing that anti-malware or IPS systems can do about this that they aren’t already doing, i.e. scanning the DLLs before they load. Often with vulnerabilities there’s a lot they can do, even if they’re not a perfect solution, at least to look for specific attack code. There’s nothing about the DLL loading technique that looks malicious. *From:* Dan Kaminsky [mailto:d...@doxpara.com] *Sent:* Friday, August 27, 2010 10:50 AM *To:* Christian Sciberras *Cc:* Larry Seltzer; full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edu *Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive ...up till the moment you realize that the interface doesn't really differentiate between 2010 Quarterly Projections as an .exe or as a .ppt. Double clicking in desktop = do whatever it takes to run this, code execution or not. On Fri, Aug 27, 2010 at 10:36 AM, Christian Sciberras uuf6...@gmail.com wrote: while there's probably an actual vuln somewhere using this methodology, nothing's been found yet Do you really think so? Having any kind of executable load the first ntoskernel.dll it finds, such as the innocent one in it's own directory isn't really wise... On Fri, Aug 27, 2010 at 4:19 PM, Dan Kaminsky d...@doxpara.com wrote: Well, if I pull out the crystal ball, I see two possibilities: 1) Patch goes out, implementing this policy 2) 1% of customers go dark 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE 1) Patch goes out, off by default 2) 0% of customers turn it on 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE Neither look exactly appetizing, and it's not like we (yet) have a clear vulnerability that needs to be addressed. On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer la...@larryseltzer.com wrote: #1 in the DLL search list is the directory from which the program was loaded. How can you have a scenario where CWD is a better choice than that? Why would it be a good choice DLL sharing? Here’s another possibility for a Microsoft action. Add a search location 1.5 specified by the application to Windows. If all the Office apps are sharing DLLs they can put their apps in Office/sharedDLLs and point to it. At least we could move forward from here. Microsoft’s choice here dooms us to this problem for the forseeable future. From: Dan Kaminsky [mailto:d...@doxpara.com] Sent: Friday, August 27, 2010 10:08 AM To: Larry Seltzer Cc: valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight to package management -- something it could do, because a) there just aren't that many apps and b) they're mostly open source, so distros can legally fix things up. Windows comes from a different direction: Many, many consumer facing apps, very few of them open source, users installing for themselves, no package manager. Among other things, this introduces the concept of: Which DLLs should you load? Suppose you have ten applications, each using foo.dll. Should they all use foo.dll from c:\windows\system32? Maybe, maybe not. There are many possible versions that might be in there, and they might or might not work. You can push your version of foo.dll into c:\windows\system32. Great, you'll work fine, but there's nine other apps you might break. You can use a local foo.dll. Now you can have your lib and they can have theirs. Welcome to DLL hell. There's been a lot of work in fixing this situation, but not from the security perspective. I know we're masters of righteous indignation, but I have to emphasize -- while there's probably an actual vuln somewhere using this methodology, nothing's been found yet. Changing something with only a tenuous link to security, with such a massive impact on whether applications run or not? Yeah, not exactly surprised it's still there. On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer la...@larryseltzer.com wrote: Clearly desktops need to be able to run arbitrary code. That’s what they’re there for. Why wouldn’t eliminating the CWD from the DLL search order fix the problem? I asked Microsoft about this ( http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php ) and they said the obvious answer, that it would break too many customer installations. And I guess it would break a bunch of them, but there really isn’t a good reason
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
You have a point. If you’re using a whitelisting system and are strict about it then you should not be vulnerable. This made me think of another issue: I just checked PowerPoint 2007, one of the apps listed as vulnerable, and both the EXEs and DLLs are digitally signed. Shouldn’t it be inherently suspicious for a signed program to load a DLL it expects to be signed but which isn’t? I know the extensibility argument would explain this, but honestly, there’s no good reason to replace most of the DLLs in Office. This is another check that could be put into LoadLibrary I guess: confirm that signatures are consistent with the EXE. *From:* Arthur Orr [mailto:a...@gci.com] *Sent:* Friday, August 27, 2010 1:52 PM *To:* Larry Seltzer; Dan Kaminsky; Christian Sciberras *Cc:* full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edu *Subject:* RE: [Full-disclosure] DLL hijacking with Autorun on a USB drive I’m not sure that I agree that there is nothing that antimalware systems can do to mitigate the risk. What about white-listing solutions in lock-down mode such as Lumension’s or Bit9’s or Symantec’s or…well you get the idea. If the DLL is not trusted (not known) it won’t run until it is trusted. The downside is the lack of something similar for the average Jane or Joe in the average home. A few come close but the average Jane or Joe is probably going to click right past prompts anyway. This is not to say that white listing is easy, just that it is a mitigating defense. *From:* full-disclosure-boun...@lists.grok.org.uk [mailto: full-disclosure-boun...@lists.grok.org.uk] *On Behalf Of *Larry Seltzer *Sent:* Friday, August 27, 2010 8:59 AM *To:* Dan Kaminsky; Christian Sciberras *Cc:* full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edu *Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive I will admit that I don’t have a **good** solution to this. It bothers me that there’s no systemic solution coming for so widespread a problem. I’ll add some more depressing news: there’s basically nothing that anti-malware or IPS systems can do about this that they aren’t already doing, i.e. scanning the DLLs before they load. Often with vulnerabilities there’s a lot they can do, even if they’re not a perfect solution, at least to look for specific attack code. There’s nothing about the DLL loading technique that looks malicious. *From:* Dan Kaminsky [mailto:d...@doxpara.com] *Sent:* Friday, August 27, 2010 10:50 AM *To:* Christian Sciberras *Cc:* Larry Seltzer; full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edu *Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive ...up till the moment you realize that the interface doesn't really differentiate between 2010 Quarterly Projections as an .exe or as a .ppt. Double clicking in desktop = do whatever it takes to run this, code execution or not. On Fri, Aug 27, 2010 at 10:36 AM, Christian Sciberras uuf6...@gmail.com wrote: while there's probably an actual vuln somewhere using this methodology, nothing's been found yet Do you really think so? Having any kind of executable load the first ntoskernel.dll it finds, such as the innocent one in it's own directory isn't really wise... On Fri, Aug 27, 2010 at 4:19 PM, Dan Kaminsky d...@doxpara.com wrote: Well, if I pull out the crystal ball, I see two possibilities: 1) Patch goes out, implementing this policy 2) 1% of customers go dark 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE 1) Patch goes out, off by default 2) 0% of customers turn it on 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE Neither look exactly appetizing, and it's not like we (yet) have a clear vulnerability that needs to be addressed. On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer la...@larryseltzer.com wrote: #1 in the DLL search list is the directory from which the program was loaded. How can you have a scenario where CWD is a better choice than that? Why would it be a good choice DLL sharing? Here’s another possibility for a Microsoft action. Add a search location 1.5 specified by the application to Windows. If all the Office apps are sharing DLLs they can put their apps in Office/sharedDLLs and point to it. At least we could move forward from here. Microsoft’s choice here dooms us to this problem for the forseeable future. From: Dan Kaminsky [mailto:d...@doxpara.com] Sent: Friday, August 27, 2010 10:08 AM To: Larry Seltzer Cc: valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive h0h0h0. There be history, Larry. 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. Longer version: Unix has always had the tradition of a system administrator. When it went consumer, it went straight
Re: [Full-disclosure] 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/
[Full-disclosure] DLL hijacking with Autorun on a USB drive
Hey guys.. Here's an example the DLL hijacking attack using a USB drive with autorun. I haven't seen this done yet, so I figured I'd post it. http://www.attackvector.org/autorun-dll-hijacker-usb-stick/ - matt ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, Aug 26, 2010 at 3:53 PM, matt m...@attackvector.org wrote: Hey guys.. Here's an example the DLL hijacking attack using a USB drive with autorun. I haven't seen this done yet, so I figured I'd post it. http://www.attackvector.org/autorun-dll-hijacker-usb-stick/ Sure, but you have the same problem most of the other DLL hijacking exploits have: There's no security boundary that says that what appears to be a .ppt, actually is one. The attacker controls both the icon and the filename. That's the case from a network share, that's the case from a USB mount, that's just the way it is. Here's the larger picture: These are unusually interesting findings. On the one hand, you have arbitrary code execution, generally the gold standard for vulnerability. On the other hand, operating systems *by definition* execute arbitrary code The question is whether they're supposed to execute code in this particular context. The answer is not actually obvious. The specific boundary at play seems to be the document boundary. There are very popular file formats that we'd like to be able to read and view, without running any embedded code inside -- powerpoint files, for instance. In the proposed scenario, the user has double clicked a file from a remote share. Calc pops up. Clearly a vuln, right? Here's the problem: How could this boundary ever be maintained? The user has no actual way of knowing that the file he's clicking on is, in fact, a PowerPoint document in the first place. It could just as easily be a .exe, faking its icon. And every major operating system has been hiding file extensions for years. Worse, even if extension weren't hidden, its not like applications have any sort of safety contract when executed from the desktop. Some formats have very clear mandates, inherited from being trafficked via email. Others are outright scripting languages and are fundamentally designed to execute arbitrary code. The web has developed a very clear security model: If you can parse it zero click from a web site, it's required to stay within the browser sandbox. The desktop has no such model -- some formats are 'safe', others aren't. There was some talk about whether PSD was vulnerable to this flaw. The complexity comes from the fact that, for all we know, opening a PSD file executes arbitrary scripts by design. Why shouldn't it? Not everything is a web browser. So, it's not that this is a weak bug or a massive bug. It's a characteristic, that has managed to make the otherwise unambiguous proof of concept -- popping calc -- ambiguously problematic. That's actually impressive, if a bit meta. We'll probably see some unambiguous attacks pop up, but they haven't yet. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
IMHO, I think its rather useless. Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. If one Thanks, Atul Agarwal Secfence Technologies www.secfence.com On Fri, Aug 27, 2010 at 1:23 AM, matt m...@attackvector.org wrote: Hey guys.. Here's an example the DLL hijacking attack using a USB drive with autorun. I haven't seen this done yet, so I figured I'd post it. http://www.attackvector.org/autorun-dll-hijacker-usb-stick/ - matt ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Matt, You have done it once again, I was just testing the last one you did using madpayload. Infolookup http://infolookup.securegossip.com www.twitter.com/infolookup -Original Message- From: matt m...@attackvector.org Sender: full-disclosure-boun...@lists.grok.org.uk Date: Thu, 26 Aug 2010 14:53:06 To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] DLL hijacking with Autorun on a USB drive ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan, So, it's not that this is a weak bug or a massive bug. It's a characteristic, that has managed to make the otherwise unambiguous proof of concept -- popping calc -- ambiguously problematic. You meant to say a feature didn't you? ;-) On Thu, Aug 26, 2010 at 10:21 PM, Sherwyn infoloo...@gmail.com wrote: Matt, You have done it once again, I was just testing the last one you did using madpayload. Infolookup http://infolookup.securegossip.com www.twitter.com/infolookup -Original Message- From: matt m...@attackvector.org Sender: full-disclosure-boun...@lists.grok.org.uk Date: Thu, 26 Aug 2010 14:53:06 To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] DLL hijacking with Autorun on a USB drive ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, 27 Aug 2010 01:42:44 +0530, Atul Agarwal said: IMHO, I think its rather useless. Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. The whole point is that launching wab.exe and opening a test file is relatively innocuous - but if you can do that, you're basically holding the user's testicles in one hand and a very sharp knife in the other. It *could* have been anything - but we'll just do something mostly harmless just to be nice. Feel free to rewrite it to do a format c:\ instead, and test on your box. Let us know which variety of PoC you prefer... pgpMmtpbCOJzw.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. Users have shown themselves very willing to open up test.vcf.exe. LJS ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
valdis.kletni...@vt.edu wrote: Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. The whole point is that launching wab.exe and opening a test file is relatively innocuous - but if you can do that, you're basically holding the user's testicles in one hand and a very sharp knife in the other. It *could* have been anything - but we'll just do something mostly harmless just to be nice. I thought that the point is that the victim does not invoke wab.exe directly, but simply double-clicks on the innocent VCF file. The attacker provides an innocent (and innocent-looking) VCF or similar file, and places some DLLs in the same folder (or in some cases in a lower-level folder). The unsafe application foolishly looks for its DLLs in (or under) the current dir. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
The reason I think you have to run wab.exe its because that's the foolish app that has the corresponding dll isssue. The cvs is just a bonus, I could be wrong. Infolookup http://infolookup.securegossip.com www.twitter.com/infolookup -Original Message- From: paul.sz...@sydney.edu.au Sender: full-disclosure-boun...@lists.grok.org.uk Date: Fri, 27 Aug 2010 13:07:54 To: a...@secfence.com; valdis.kletni...@vt.edu Cc: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive valdis.kletni...@vt.edu wrote: Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. The whole point is that launching wab.exe and opening a test file is relatively innocuous - but if you can do that, you're basically holding the user's testicles in one hand and a very sharp knife in the other. It *could* have been anything - but we'll just do something mostly harmless just to be nice. I thought that the point is that the victim does not invoke wab.exe directly, but simply double-clicks on the innocent VCF file. The attacker provides an innocent (and innocent-looking) VCF or similar file, and places some DLLs in the same folder (or in some cases in a lower-level folder). The unsafe application foolishly looks for its DLLs in (or under) the current dir. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Aug 26, 2010, at 7:53 PM, Larry Seltzer la...@larryseltzer.com wrote: Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. Users have shown themselves very willing to open up test.vcf.exe. Or for that matter, test, which is actually an exe with the icon of a vcf. Thus the problem with all this chortling about foolish applications: the desktop simply does not possess the security model of the browser or the email client. There may very well be a legitimate boundary cross from this DLL stuff, but we haven't seen it yet. All the present stuff has the indelible mark of a false boundary, in that no fix can be imagined that actually closes the vector. LJS ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.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/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan Kaminsky d...@doxpara.com wrote: Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. Users have shown themselves very willing to open up test.vcf.exe. Or for that matter, test, which is actually an exe with the icon of a vcf. Thus the problem with all this chortling about foolish applications: the desktop simply does not possess the security model of the browser or the email client. Badly setup desktops: do not hide extensions, maybe view details (or list) not icons. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Aug 26, 2010, at 9:30 PM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com wrote: Instead of it executing wab.exe (Windows Address Book) and open the file test.vcf, one can directly get any .exe file open. Users have shown themselves very willing to open up test.vcf.exe. Or for that matter, test, which is actually an exe with the icon of a vcf. Thus the problem with all this chortling about foolish applications: the desktop simply does not possess the security model of the browser or the email client. Badly setup desktops: do not hide extensions, maybe view details (or list) not icons. All that matters is defaults, and icons are way more powerful signals than a couple of letters at the end of 2010 Market Projections.ppt.exe' anyway. The web browser and the email client are not designed to launch arbitrary code. The desktop, with the slight caveat of Standard User vs. Administrator, simply is. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, 26 Aug 2010 20:39:04 PDT, Dan Kaminsky said: There may very well be a legitimate boundary cross from this DLL stuff, but we haven't seen it yet. All the present stuff has the indelible mark of a false boundary, in that no fix can be imagined that actually closes the vector. Oh you're wrong there Dan. I can imagine fixes that would close the vector (starting with fixes that impose a legitimate enforcable boundary). Fixes that will be accepted by Joe Sixpack? I think we saw where UAC ended up. :) pgpdGX3F4PQWF.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
Dan Kaminsky d...@doxpara.com wrote: Badly setup desktops: do not hide extensions, maybe view details (or list) not icons. All that matters is defaults, and icons are way more powerful ... Those defaults are wrong, change them. Anyway, icons are shown with view details. The web browser and the email client are not designed to launch arbitrary code. The desktop ... is. This attack may happen through the browser (UNC paths or somesuch). Any talk about USB sticks or desktops is bogus. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, Aug 27, 2010 at 1:06 AM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com wrote: Badly setup desktops: do not hide extensions, maybe view details (or list) not icons. All that matters is defaults, and icons are way more powerful ... Those defaults are wrong, change them. Anyway, icons are shown with view details. I think you mean application types are shown with view details. The problem is, there's a couple dozen application types that are all code execution equivalent by design. Do you know all of them? Why should a user? The web browser and the email client are not designed to launch arbitrary code. The desktop ... is. This attack may happen through the browser (UNC paths or somesuch). Any talk about USB sticks or desktops is bogus. There's no path between IE and a UNC window that doesn't either security prompt or raise an unadorned Explorer window to a remote share. I could see an argument that the latter should prompt, given that it's a (by definition) code execution context. But that's about it. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, Aug 27, 2010 at 1:05 AM, valdis.kletni...@vt.edu wrote: On Thu, 26 Aug 2010 20:39:04 PDT, Dan Kaminsky said: There may very well be a legitimate boundary cross from this DLL stuff, but we haven't seen it yet. All the present stuff has the indelible mark of a false boundary, in that no fix can be imagined that actually closes the vector. Oh you're wrong there Dan. I can imagine fixes that would close the vector (starting with fixes that impose a legitimate enforcable boundary). Fixes that will be accepted by Joe Sixpack? I think we saw where UAC ended up. :) Hehe. You start with the beginnings of imagining a fix. Here, you say 'the desktop will be aware of when it is launching content safe for viewing, vs. dangerous, and will behave differently'. Eventually you realize: 1) You have to build this database 2) You have to maintain this database, even in the face of third party apps adding handlers 3) You have to determine what the differential behavior is going to be on a safe vs. unsafe type And it's in the middle of 3) that you end up...well...where UAC ended up :) Again, let me emphasize. Really interesting vector, will probably end up attached to an unambiguous flaw. But right now, we're just seeing flaws along the lines of Double clicking an icon in Explorer might execute arbitrary code. It doesn't matter that that's true even if there's a network share, or a USB stick. That's what Explorer *does*. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Fri, 27 Aug 2010 01:29:32 EDT, Dan Kaminsky said: Again, let me emphasize. Really interesting vector, will probably end up attached to an unambiguous flaw. But right now, we're just seeing flaws along the lines of Double clicking an icon in Explorer might execute arbitrary code. It doesn't matter that that's true even if there's a network share, or a USB stick. That's what Explorer *does*. And as I said, a fix that starts off with First thing we do is feed Explorer to a pack of hungry dingos won't fly with Joe Sixpack. ;) pgp4ABteRcd6P.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
