CreateProcess and error 740 (requires elevation)
in [Win32 Kernel]
|
From: Hector Santos on 5 Jan 2010 20:16 Remy Lebeau wrote: > "rogero" <roger.orr(a)gmail.com> wrote in message news:3652c8bf-def1-4c4c-85e7-a0f986de3986(a)l30g2000yqb.googlegroups.com... > >> After a bit of poking around this simply seems to be related to the >> *name* of the target executable. > > It can. UAC performs some heuristic analysis, called "Installer Detection" to determine if an executable might be an installer/uninstaller or updater so it can be elevated. This typically only applies to older apps that have not been updated to be UAC-aware yet. I failed or question to understand the logistics behind all this "elevation". Obviously, "bad guys" or those who just put a little sweat into it, can easily circumvent all of this. It can only be targeted at legacy applications (who those who had no need to change) and these "GOOD GUYS" are the companies or developers who are hurt. >> Does anyone know whether there is a list of *which* file names >> are affected like this? > > Not an official list, no, though a few keywords are mentioned here: > > http://msdn.microsoft.com/en-us/library/bb756960.aspx > Many moons ago when our application was among the "top 100 applications" for windows, MS had contacted us to add our software to some "installation" compatibility 'shim' or what have you. Something regarding making it the installer was NT and not 95 when it was being installed on 2000. They should of done the same thing today with this DEP stuff. Although we are not the top 100, but still an established application, the issue is not that we can update our software, the issue is that existing customers who update to newer versions of the OS all of a sudden have problems and we get the support cost to find out what has happen or to figure out how to mitigate it. Oh well, times have changed no doubt and these conservative engineering views don't seem to be important anymore - just DO IT and let the chips fall where they may. Don't get me wrong, higher elevation is "GOOD," especially in the USER world, but sometimes MS does things to resolve their own security flaws and the resolution hurts us. Like the DCOM exploit forcing MS to restrict RPC binding across the LAN. We don't use DCOM for discovery. Our solution predated MS DCOM. But it hurt us anyway. There has to be a better way then to HURT a huge base of decades of software products still active under Windows. Maybe there was no choice, but I can understand it better if it actually SOLVED or CUT DOWN on the bad guys. It doesn't and it certainly won't because they can easily circumvent all this. So it only hurts existing GOOD GUYS applications, who with no fault on there own, supported pure WIN32, did things as it was expected and now newer WIN32 OSes or supported WINS32 sub-systems are suspect to problems. Just my opinion, no need to any debate. Thanks -- HLS
From: Remy Lebeau on 5 Jan 2010 21:52 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ubW853mjKHA.5524(a)TK2MSFTNGP06.phx.gbl... > I failed or question to understand the logistics behind all this > "elevation". Obviously, "bad guys" or those who just put a > little sweat into it, can easily circumvent all of this. Not really. Not without hacking into an admin account's password, anyway. UAC really locks things down now to make sure non-admins cannot perform admin tasks anymore, which they should not have been doing in the first place. > It can only be targeted at legacy applications (who those who > had no need to change) Many legacy apps were coded using bad practices, doing things they should never have been doing without any security.administration in mind. UAC really only affects those apps that were badly programmed to begin with, forcing good practices. > Although we are not the top 100, but still an established application, > the issue is not that we can update our software, the issue is that > existing customers who update to newer versions of the OS all of a > sudden have problems and we get the support cost to find out what > has happen or to figure out how to mitigate it. Then you were likely amongst those developers who coded bad practices all along. We've all done it from time to time, and now we have to learn to code better for it. > I can understand it better if it actually SOLVED or CUT DOWN on > the bad guys. It doesn't and it certainly won't because they can easily > circumvent all this. And how do you think they actually do that? > So it only hurts existing GOOD GUYS applications, who with no fault > on there own, supported pure WIN32, did things as it was expected No, they did not do things that were expected of them, or else they would not be getting bitten by it now as things get continuously locked down. -- Remy Lebeau (TeamB)
From: Alexander Grigoriev on 5 Jan 2010 23:01 There is more than that. I've heard that Windows 2008+ (Vista, 7) x64 will detect if you're trying to run an Install Shield (16 bit) installer, and substitute a new executable. x64 is not able to run Win3 16 bit programs, so such hack is necessary. "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ubW853mjKHA.5524(a)TK2MSFTNGP06.phx.gbl... > Many moons ago when our application was among the "top 100 applications" > for windows, MS had contacted us to add our software to some > "installation" compatibility 'shim' or what have you. Something regarding > making it the installer was NT and not 95 when it was being installed on > 2000. > > They should of done the same thing today with this DEP stuff. >
From: Hector Santos on 6 Jan 2010 01:57 Remy Lebeau wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ubW853mjKHA.5524(a)TK2MSFTNGP06.phx.gbl... > >> I failed or question to understand the logistics behind all this >> "elevation". Obviously, "bad guys" or those who just put a >> little sweat into it, can easily circumvent all of this. > > Not really. No? Just adding SetProcessDEPPolicy(0) to your code is not a simple circumvention? > Not without hacking into an admin account's password, anyway. > UAC really locks things down now to make sure non-admins cannot > perform admin tasks anymore, which they should not have been doing > in the first place. Thats a different idea. "Breaking software" is another. At the very least, it should POPUP an information dialog rather than GPF. >> It can only be targeted at legacy applications (who those who >> had no need to change) > > Many legacy apps were coded using bad practices, doing things they > should never have been doing without any security.administration in > mind. Thats a generalization. This is not about "Bad Practices". Not every company has unintelligent engineering, lack of security regards or what I call "Loose" engineering. "legacy" is state of age but nonetheless time tested, engineered with quality and excellent. In fact, the better ones survive and don't need revamping - a targeted goal in lower development cost, lower support cost and reuseability. Applications don't need to change just for the sake of something "new." Its about breaking existing applications. >> Although we are not the top 100, but still an established application, >> the issue is not that we can update our software, the issue is that >> existing customers who update to newer versions of the OS all of a >> sudden have problems and we get the support cost to find out what >> has happen or to figure out how to mitigate it. > > Then you were likely amongst those developers who coded bad > practices all along. We've all done it from time to time, > and now we have to learn to code better for it. Thats not the case. The CODE was solid. It only needed SetProcessDEPPolicy(0) to resolve it. >> I can understand it better if it actually SOLVED or CUT DOWN on >> the bad guys. It doesn't and it certainly won't because they can easily >> circumvent all this. > > And how do you think they actually do that? At SetProcessDEPPolicy(0) to your code or at the DisableNXxxxxx String to the registry. >> So it only hurts existing GOOD GUYS applications, who with no fault >> on there own, supported pure WIN32, did things as it was expected > > No, they did not do things that were expected of them, or else > they would not be getting bitten by it now as things get > continuously locked down. So is that why the ATL virtual class thunking framework borrowed from the old OWL framework is and was bad code? The RULES were followed for the established Coding Practices of the Day. You can't call that "Bad Coding" or not following design expectations. They were 100% design to the well establishing coding specifications. A GPF is not expected and the fact is it all depends on the flavor of Windows and what patches or updates were done. Where is the consistency in that? Anyway my point they could of done better in dealing with established applications and not passing the buck to users and developers. Here is a good idea for Microsoft: When another major DEP Like or security change requirement is forced upon them, during the OS upgrade process, it should ask the ADMIN or USER if "SNAPSHOT" of the working system should be white listed. "Do you want to automatically white list existing safe applications already installed on the system?" [ NO ] [ YES, PLEASE DON'T BREAK MY SOFTWARE ] "NOTE: Only select YES if the machine has been certified as clean of viruses." If Yes, it will scan all installed applications and white list them and/or maybe on a prompt or suspect basis ask the user. Everyone is a winner and no freaking surprise on anyone. :) Thanks -- HLS
From: Wilson, Phil on 6 Jan 2010 12:58
The issue with installer programs is that you can't fix them. The only way a company can correct the fact that "Wonderful Software 2.0" (that you bought in 2005) won't install because of an elevation issue (in its setup.exe) is to ship you another install image or CD, and that's not realistically going to happen. The MS solutions to this include things like installer elevation, and compatibility settings so that, for example, "Wonderful Software 2.0" thinks it's installing on XP and not Vista. Security is never about just one thing that could be circumvented. The overall strategy is about defense in depth, and UAC, DEP, service session isolation, firewalls, encryption, secure DCOM, and so on are some of the pieces that help.It's also relevant that the recent Security Intelligence Report (SIR) shows that the vast majority of attacks are no longer directed at the OS or the browser, but at 3rd party apps, and that means that the good guys need to use these tools. I don't know what your app is, but I assume the that last thing any of us needs is a published security vulnerability. -- Phil Wilson The Definitive Guide to Windows Installer http://www.apress.com/book/view/1590592972 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ubW853mjKHA.5524(a)TK2MSFTNGP06.phx.gbl... > Remy Lebeau wrote: > >> "rogero" <roger.orr(a)gmail.com> wrote in message >> news:3652c8bf-def1-4c4c-85e7-a0f986de3986(a)l30g2000yqb.googlegroups.com... >> >>> After a bit of poking around this simply seems to be related to the >>> *name* of the target executable. >> >> It can. UAC performs some heuristic analysis, called "Installer >> Detection" to determine if an executable might be an >> installer/uninstaller or updater so it can be elevated. This typically >> only applies to older apps that have not been updated to be UAC-aware >> yet. > > > I failed or question to understand the logistics behind all this > "elevation". Obviously, "bad guys" or those who just put a little sweat > into it, can easily circumvent all of this. It can only be targeted at > legacy applications (who those who had no need to change) and these "GOOD > GUYS" are the companies or developers who are hurt. > > >>> Does anyone know whether there is a list of *which* file names >>> are affected like this? >> >> Not an official list, no, though a few keywords are mentioned here: >> >> http://msdn.microsoft.com/en-us/library/bb756960.aspx >> > > > Many moons ago when our application was among the "top 100 applications" > for windows, MS had contacted us to add our software to some > "installation" compatibility 'shim' or what have you. Something regarding > making it the installer was NT and not 95 when it was being installed on > 2000. > > They should of done the same thing today with this DEP stuff. > > Although we are not the top 100, but still an established application, the > issue is not that we can update our software, the issue is that existing > customers who update to newer versions of the OS all of a sudden have > problems and we get the support cost to find out what has happen or to > figure out how to mitigate it. > > Oh well, times have changed no doubt and these conservative engineering > views don't seem to be important anymore - just DO IT and let the chips > fall where they may. > > Don't get me wrong, higher elevation is "GOOD," especially in the USER > world, but sometimes MS does things to resolve their own security flaws > and the resolution hurts us. Like the DCOM exploit forcing MS to restrict > RPC binding across the LAN. We don't use DCOM for discovery. Our solution > predated MS DCOM. But it hurt us anyway. > > There has to be a better way then to HURT a huge base of decades of > software products still active under Windows. Maybe there was no choice, > but I can understand it better if it actually SOLVED or CUT DOWN on the > bad guys. It doesn't and it certainly won't because they can easily > circumvent all this. So it only hurts existing GOOD GUYS applications, who > with no fault on there own, supported pure WIN32, did things as it was > expected and now newer WIN32 OSes or supported WINS32 sub-systems are > suspect to problems. > > Just my opinion, no need to any debate. > > Thanks > > -- > HLS |