Elevated Privileges

[Jeff Smyrski]

Is there a way to allow a program / dll to always run
with elevated
privileges. I have a software vendor that has provided
us with programs,
one in particular that is a dll that generates htm code
for a web session.
The way that the program is supposed to work, is that the
user will make a
request to retrieve an archived/scanned document from a
database. The
interface for that function is controlled in a dll loaded
to the
Windows\System32 folder. The dll, goes fetches the
image, and then converts
the image to an HTM web page. The problem is that the
dll is doing all of
this work in the System32 folder, which unless you are a
power user locally,
or higher, you can not create in the system32 folder.
Until they fix the
bug (which by the way does not happen in windows 2000 or
NT, why I don't
know) but until they fix the bug, I need to have a
workaround for this
problem without giving all of my users Power User rights
locally. They log
into a domain, that restricts many things on the user's
workstation
including the installation of software, and by default XP
limits the
permissions for users, to only read to the system32
folder. The dll is
basically using the system32 folder as a temp folder, and
the htm document
is discarded after the inquiry has been executed. The
file names are also
random in that they are always prefaced with a 32 digit
string.htm

Is there a way to allow only that dll to execute whenever
it is called with
elevated privileges, or is there another way to make this
work, that perhaps
I have not thought of...

Thanks.

Jeff Smyrski

 

[cquirke (MVP Win9x)]

On Thu, 29 Apr 2004 06:06:49 -0700, "Jeff Smyrski"

Is there a way to allow a program / dll to always run
with elevated privileges.

Consider the malware implications of a "yes", there...

I have a software vendor that has provided
us with programs, one in particular that is a
dll that generates htm code for a web session.

The dll is basically using the system32 folder
as a temp folder

That's so dumb I'd purge the sware at this point. You don't want
incessant disk writes to this location; it's not a folder you want to
risk trashing in something goes wrong.

Can relocating the .DLL from System32 and pointing a Path to it work
around this problem? What excuses does the vendor come up with?

-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.

 

[Jeff Smyrski]

I tried un-registering the dll, and then moving the dll to a temp folder,
and re-registering it with the regsvr32. I also tried to search the
registry to manually change the registration location and neither worked.
It looks like the dll is hard coded to write to the system32 folder. The
vender said it worked just fine on windows 2000 and NT, but apparently with
tighter security on XP it no longer works.

I wish I could purge the software, the bad news is that this is a feature of
the core software that you can not get rid of, meaning the core software.
When you said malware implications...what do you mean there? By the sounds
of it, there was a security hole on W2K and NT4, in which this dll worked
just fine, but since then, new security features and hotfixes of XP have
blocked that...correct?

Thanks for the input...a MSFT post said give the users full control...if not
then there is no work around to just let one dll run with elevated
privileges.

Jeff

 

[cquirke (MVP Win9x)]

"cquirke (MVP Win9x)" <[email protected]> wrote

I tried un-registering the dll, and then moving the dll to a temp folder,
and re-registering it with the regsvr32.

I hope that wasn't "temp" as in %Temp%?

I also tried to search the registry to manually change the registration
location and neither worked.

The only hope is that it writes to . (i.e. where it is) and that the
..DLL will work if stored elsewhere (my choice would be in the app's
dir). Temp files really should go in %Temp% and thus be properly
relocatable, separated by user profile (think XP's fast user switching
feature) and so on. The coders had a bad SOP, which now matters.

It looks like the dll is hard coded to write to the system32 folder. The
vender said it worked just fine on windows 2000 and NT, but apparently with
tighter security on XP it no longer works.

Still a dof idea. You don't poo in the crucial part of the nest.

I wish I could purge the software, the bad news is that this is a feature of
the core software that you can not get rid of, meaning the core software.

Yep. Nasty, tho, and these dudes really should have fixed this by
now... I mean, *how* many years has XP been standard for? Sheesh!

When you said malware implications...what do you mean there?

Dunno; you're top posting, so context not found yet. I'll clarify
when I get there, unless it's snipped.

By the sounds of it, there was a security hole on W2K and NT4,
in which this dll worked just fine, but since then, new security
features and hotfixes of XP have blocked that...correct?

Maybe. Or more likely, MS got fed up with the number of problems
caused by apps pooing in the system's core, and decided to defend this
core accordingly. Not a bad idea, IMO.

Thanks for the input...a MSFT post said give the users full control...if not
then there is no work around to just let one dll run with elevated
privileges.

OK. Bummer, but a common real-world outcome where the whole
limited-rights account thing goes.

Oh, I see. Well, basically if that were possible, any malware could
escalate it's own priviledges, making the whole concept rather a waste
of time. Which to some extent is true, as it is - there are several
holes through which malware can escape limited rights etc.

-------------------- ----- ---- --- -- - - - -

"If I'd known it was harmless, I'd have
killed it myself" (PKD)