DLL Hijacking vulnerability

[NewVersionTester]

Hi,

please have a look at this vulnerability: https://packetstormsecurity.com/files/137077/AutoIT-3-DLL-Hijacking.html

 

You have not replied for months, so it is already public now.

[JohnOne]

I looked.

Now what?

[spudw2k]

I'm sure this is an issue with a galaxy of software applications; nothing unique to AutoIt.

[orbs]

16 hours ago, spudw2k said:

I'm sure this is an issue with a galaxy of software applications; nothing unique to AutoIt.

true; but the fact that everyone's a fool doesn't mean you should be one too.

when you run your AutoIt compiled software in production environment, where security is an issue (especially when you have a pedant CISSO on your back), this issue requires at least minor attention. luckily, if you develop a software with AutoIt and deploy it, you can mitigate the issue quite easily - even if only in a formal manner - like this:

regarding compiled AutoIt scripts: if they are part of an installed program (i.e. they reside in a protected folder, like Program Files) you need do nothing.

if designed to run as portable, just issue a warning in your website/documentation/EULA or wherever users are bound to see it: "do not launch app.exe directly from the download location; instead, create a new folder, copy or move app.exe to that folder. and launch it from there."

as for the AutoIt & SciTE installers - similar notice can be placed on the download page.

now, all these are formal means of mitigation; they work by putting the responsibility of security in the users' hands. surprisingly, this is actually acceptable by common security norms.

however, if the AutoIt dev team wishes to provide a technical solution, it should not be that hard - make autoit3.exe load DLL's in non-default path order, i.e. first use the ones located in Windows installation path, and than use the ones in the exe path. this link has relevant info.

anyways, as for the AutoIt & SciTE installers - i think the mentioned notice is sufficient. you install AutoIt very rarely (compared to running a script, native or compiled), so i don't think messing with it is worthwhile.

[spudw2k]

3 hours ago, orbs said:

now, all these are formal means of mitigation; they work by putting the responsibility of security in the users' hands. surprisingly, this is actually acceptable by common security norms.

Of course it is.  Certainly a company must take measures when are where they can without inhibiting the user, but the best way to protect your users is to educate them how to protect themselves.  Now a disclaimer that no one reads when they login to a system...that's not what I'm talking about.  That's just for legal purposes; i'm talking about actual user awareness training.  Much in the same way, a disclaimer on a website only has the value of CYA measure for the software dev.