2 ms·
> I wonder how long it will take until someone finds a security exploit of this "feature" I'm not sure what exactly crafting a 16-bit installer file to exploit
by SEMW 13y ago
> I wonder how long it will take until someone finds a security exploit of this "feature"
I'm not sure what exactly crafting a 16-bit installer file to exploit some bug in the bundled installshield to get it to execute code of your choosing (when the user tries to run your installer) would achieve.
You've got the user to run an installer that you've made. They've just double-clicked on your program. Forget crafting dodgy installer data files, you can run whatever code you like just by... running it.
Moreover, given the user is trying to install your program, they'll be happy to elevate its privileges, too (through UAC). So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you? (And if the user doesn't think your program's an installer, they're not going to be any less confused by the appcompat installshield's UAC prompt than if your program just tries to elevate by UAC by itself. It's not like the bundled one is setuid root (or the windows equivalent)).
See also: http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...
- doug11235 13y ago> So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you? In the days of Antivirus products and executable whitelists, the "elevation of privilege" may be getting arbitrary execution as any user. Of course trustedinstaller.exe or whatever that has a valid Microsoft signature can run, why shouldn't it? No need to ship that file back home either for further analysis (as AV products like to do with unknown files), its a standard OS thing. Therefore my rootkit isn't burned either.