CreateProcess and error 740 (requires elevation)
in [Win32 Kernel]
|
From: Remy Lebeau on 6 Jan 2010 13:14 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eFsJx2pjKHA.4048(a)TK2MSFTNGP06.phx.gbl... > No? Just adding SetProcessDEPPolicy(0) to your code is not a > simple circumvention? To circumvent UAC? I doubt that. UAC and DEP are separate and unrelated technologies. UAC protects API functions from performing unauthorized tasks. DEP protects memory blocks from executing unauthorized code. Besides that, SetProcessDEPPolicy() requires the system admin to have configured DEP to allow apps to Opt in/out of DEP protection, which is not always the case. > So is that why the ATL virtual class thunking framework borrowed from > the old OWL framework is and was bad code? Dynamically allocating a thunk is not bad code. There are plenty of valid usages for it (Borland's VCL uses it for its window procedues, for instance). Allocating a memory block that is specicially intended for running executable code (has PAGE_EXECUTE_... flags applied to it) is not disallowed by either UAC or DEP. DEP prevents non-executable memory from running executable code. It does not block intentionally-executable memory. -- Remy Lebeau (TeamB)
From: Hector Santos on 6 Jan 2010 16:30 Thanks for your input Phil. I think a possible solution for MS is to offer an automatic "exempt" or white list scan for pre-installed applications during any security hot fix related to DEP, UAC or whatever it is that concerns MS own products or OS features but the solution may affect other applications. Do you wish to automatically exempt trusted installed applications from any security elevation? The point is that most customers will have established setups and trusted installed applications AT the moment of an OS upgrade or security hotfix and that any new OS security measures can hurt some of the trusted installed applications. From the USER or ADMIN standpoint, the OS security upgrade process SHOULD exempt these established installations. Failure of the established installed application is *not* expected. When that happens, it is usually the application vendor that gets the support incident first. I think this is a reasonable QA compromise to help reduce support cost on both ends - MS and her tertiary market of vendors. Thanks -- HLS Wilson, Phil wrote: > 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.
From: m on 8 Jan 2010 21:07 IMHO, well designed and written software has been immune to these issues; beyond the obvious interference of security popups. In my own case, having recently certified our APPs for Windows 7 / Server 2008 R2, there were no code changes necessary and we have not manifests etc. at all. The principal code base was originally targeted at NT 4, and except for the change to an MSI installer, has functioned correctly in every version of Windows since without changes. Now many pieces have changed since then, but if I want to I can still install and run my circa 1997 version 1.2 (first stable release) on my multi-core Windows 7 desktop. "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OxDLUexjKHA.1652(a)TK2MSFTNGP05.phx.gbl... > Thanks for your input Phil. > > I think a possible solution for MS is to offer an automatic "exempt" or > white list scan for pre-installed applications during any security hot fix > related to DEP, UAC or whatever it is that concerns MS own products or OS > features but the solution may affect other applications. > > Do you wish to automatically exempt trusted > installed applications from any security elevation? > > The point is that most customers will have established setups and trusted > installed applications AT the moment of an OS upgrade or security hotfix > and that any new OS security measures can hurt some of the trusted > installed applications. > > From the USER or ADMIN standpoint, the OS security upgrade process SHOULD > exempt these established installations. Failure of the established > installed application is *not* expected. When that happens, it is usually > the application vendor that gets the support incident first. > > I think this is a reasonable QA compromise to help reduce support cost on > both ends - MS and her tertiary market of vendors. > > Thanks > > -- > HLS > > Wilson, Phil wrote: > >> 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. > >
From: Jochen Kalmbach [MVP] on 9 Jan 2010 03:11 Hi m! > pieces have changed since then, but if I want to I can still install and > run my circa 1997 version 1.2 (first stable release) on my multi-core > Windows 7 desktop. Yes, you can! But: IF you read registry keys from HKLM, it will sometimes not read the "correct" value, if you previously wrote to HKLM without a manifest (or some other programm). The same is true for files under "Program Files"... You should at least use a Vista-Manifest to avoid these problems... and also a manifest is the *only* way to overcome filename-conflicts with the Shim database... -- Greetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/
From: Paul Baker [MVP, Windows Desktop Experience] on 13 Jan 2010 08:59
Agreed. What everyone else is talking about are defects and hacks :) Paul "m" <m(a)b.c> wrote in message news:eli1HCNkKHA.1536(a)TK2MSFTNGP06.phx.gbl... > IMHO, well designed and written software has been immune to these issues; > beyond the obvious interference of security popups. |