DLL - shared memory - sometimes not shared?

NTDEV
41

> I would certainly rather that this particular very dangerous tool had never been created, but the time

for that debate has come and gone decades ago.

A couple of observations:

  1. There is nothing particularly dangerous about SHARED section per se. Dangers arise only when you are allowed to share it across the logon boundaries

  2. There is no need to debate - the only thing that is needed is just to fix this vulnerability at the OS level transparently to applications.

All that the OS to do is to prohibit sharing temporary RW data across logon boundaries, i.e. every logon session should be allocated its own dedicated set of slots in a pagefile, while kernel should have its own set of slots that is the same for all users. If you do it this way, a SHARED section will be shared only among processes that run in the same user context, i.e there will be multiple instances of this section - one instance of a section per user.Simple, ugh…

Anton Bassov

42

>I think that the sharing of DLLs is more restrictive than a logon session;
it is actually desktop-specific.

Desktop can be set per thread and switched at runtime. Thus, it’s normally not appropriate for process-wide things.

43

I’m not missing the point. I got what he said, I was just also looking at it from the other direction also.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, October 04, 2012 1:28 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

In order to have the shared section, you must trick the program into loading your dll.

You seem to be missing the point…

In order for the attack to take place there is no need to “trick” the target process into loading a DLL. This DLL may be very-well known and used, for example, by several well-known known programs written by some well-known vendor - they may want to cooperate with one another, and, hence, use a DLL for this purpose. The only thing needed for launching an attack here is some rogue process who loads this DLL into its address space and modifies its SHARED section. At this point all these well-known programs may get compromised (at least theoretically - it depends on how exactly this section is used by them). This is what Ken speaks about…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

44

>I think that the sharing of DLLs is more restrictive than a logon session; it is actually desktop-specific.

IIRC, desktop is a security boundary only as far as GUI is concerned. Therefore, the above statement, apparently, applies only in context of loading a DLL because of invocation of a window hook procedure…

Anton Bassov

45

>> I would certainly rather that this particular very dangerous tool had

> never been created, but the time
> for that debate has come and gone decades ago.

A couple of observations:

  1. There is nothing particularly dangerous about SHARED section per se.
    Dangers arise only when you are allowed to share it across the logon
    boundaries

  2. There is no need to debate - the only thing that is needed is just to
    fix this vulnerability at the OS level transparently to applications.

All that the OS to do is to prohibit sharing temporary RW data across
logon boundaries, i.e. every logon session should be allocated its own
dedicated set of slots in a pagefile, while kernel should have its own set
of slots that is the same for all users. If you do it this way, a SHARED
section will be shared only among processes that run in the same user
context, i.e there will be multiple instances of this section - one
instance of a section per user.Simple, ugh…

And how does this suggestion differ from what is currently implemented?

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

46

> Just a small question, where i have not yet found a solution:

I have a DLL with a shared area. This shared area contains a simple
initialized integer,
which is set e.g. to a value of 10.000. Every time the DllMain is called,
i print the value and increase it by one.
(It is only a test, part of a bigger implementation).

I can use the DLL from an exe, call the same exe a second time in parallel
and i see the counter increasing.
I can also renaming the exe to another name and call it,
again i see the counter increasing.

Of course when it is not used anymore, it is unloaded and next time
the counter restarts at initial value (10.000).

Now the question / problem:
When i use an exe, which uses a different dll, which inside the dll calls
my test dll
(with the shared memory), then i get a new counter (new “shared” memory)
instead of the existing one. So sharing of the integer variable is not
more working.

Why is this the case? Is it just a bug somewhere in my implementation
or is this a valid / known behavior? Is there perhaps a workaround?

I think i saw somewhere the use of a memory mapped file
instead of the shared memory. Is it the way to go?

What you have not yet confirmed with anyone is what you mean by “uses the
DLL”?

Is it literally the SAME DLL, loaded from the exactly same path? Or is it
a copy of the DLL, loaded from the executable directory, and each
executable is in its own directory? If you have a file which is a
bitwise identical copy of DLL A, call it DLL A’, as far as the OS is
concerned A’ != A, because it is loaded from a different path. Until you
can confirm that it is EXACTLY the same DLL file being loaded, there’s
nothing more can be said on this.
joe

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer