DLL - shared memory - sometimes not shared?

NTDEV
1

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?

2

what did you do to share your data ? Each process gets a separate copy of your DLL and data sections. Global data in a DLL is not shared between processes unless you take special measures such as writing it to a memory mapped file.

//Daniel

3

Hello Daniel,

mainly it is looking like this:

#pragma data_seg(“SHARED”)
unsigned long ctr = 10000;
#pragma data_seg()
#pragma comment(linker, “/section:SHARED,RWS”)

It is working in general between applications using the DLL,
but not when app is using a DLL to use DLL with shared area.

BTW:
Could it perhaps be a problem, because DLL between is using LoadLibrary?
But no, in other apps i also use LoadLibrary and there it is working…

Best regards,

Martin

4

What filename the DLL uses to call LoadLibrary? Does it load the same copy of DLL or from a different path?

5

xxxxx@clibb.de wrote:

mainly it is looking like this:

#pragma data_seg(“SHARED”)
unsigned long ctr = 10000;
#pragma data_seg()
#pragma comment(linker, “/section:SHARED,RWS”)

It is working in general between applications using the DLL,
but not when app is using a DLL to use DLL with shared area.

Please remember that nothing in the system APIs can tell the difference
between code in an EXE and code in a DLL. It’s all just executable
instructions that are part of the process address space.

BTW:
Could it perhaps be a problem, because DLL between is using LoadLibrary?
But no, in other apps i also use LoadLibrary and there it is working…

Is the LoadLibrary loading a different instance? That is, is it
possibly getting a different copy of the DLL? If the application is
using implicit loading, then it’s following the default DLL load path.
The rules for LoadLibrary can be slightly different, and if you have a
fully qualified path, that could be different again.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

The rules for LoadLibrary differ with various releases of the OS and with
various settings in the Registry. So my first guess is that this analysis
is correct, you are loading different instances of the DLL. This means
that if you have a copy of the DLL in app A’s directory, and a copy in app
B’s directory, as far as the loader is concerned these are completely
different DLLs, even if they are bitwise copies of each other.
joe

xxxxx@clibb.de wrote:
> mainly it is looking like this:
>
> #pragma data_seg(“SHARED”)
> unsigned long ctr = 10000;
> #pragma data_seg()
> #pragma comment(linker, “/section:SHARED,RWS”)
>
> It is working in general between applications using the DLL,
> but not when app is using a DLL to use DLL with shared area.

Please remember that nothing in the system APIs can tell the difference
between code in an EXE and code in a DLL. It’s all just executable
instructions that are part of the process address space.

> BTW:
> Could it perhaps be a problem, because DLL between is using LoadLibrary?
> But no, in other apps i also use LoadLibrary and there it is working…

Is the LoadLibrary loading a different instance? That is, is it
possibly getting a different copy of the DLL? If the application is
using implicit loading, then it’s following the default DLL load path.
The rules for LoadLibrary can be slightly different, and if you have a
fully qualified path, that could be different again.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

7

Yes, use a memory mapped file. This gives you full control over the
shared memory. The DLL with a shared section is a half-supported hack
which is bristle, as you’ve just seen.
– pa

On 03-Oct-2012 11:23, xxxxx@clibb.de wrote:

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?

8

And when the DLL is loaded by another logon session, it will be yet another copy of the shared section.

9

Please do not use the /section:SHARED support. This will nearly always create serious security vulnerabilities as anybody who can load the DLL can overwrite that memory in all other processes loading the DLL.

That support is there only for very, very special and specific uses. You need to use a securable file mapping object instead.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@clibb.de
Sent: Wednesday, October 03, 2012 5:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

Hello Daniel,

mainly it is looking like this:

#pragma data_seg(“SHARED”)
unsigned long ctr = 10000;
#pragma data_seg()
#pragma comment(linker, “/section:SHARED,RWS”)

It is working in general between applications using the DLL, but not when app is using a DLL to use DLL with shared area.

BTW:
Could it perhaps be a problem, because DLL between is using LoadLibrary?
But no, in other apps i also use LoadLibrary and there it is working…

Best regards,

Martin

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

10

I fail to see how this “nearly always” creates security issues. If you never make any security decisions based on the shared region, and treat is as POD with no pointers, say for a small debug use, I can see absolutely no security issue.

Please don’t spread FUD. Of course I’m willing to hear how a shared data region, which is non-executable, can cause an issue.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, October 03, 2012 2:26 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

Please do not use the /section:SHARED support. This will nearly always create serious security vulnerabilities as anybody who can load the DLL can overwrite that memory in all other processes loading the DLL.

That support is there only for very, very special and specific uses. You need to use a securable file mapping object instead.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@clibb.de
Sent: Wednesday, October 03, 2012 5:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

Hello Daniel,

mainly it is looking like this:

#pragma data_seg(“SHARED”)
unsigned long ctr = 10000;
#pragma data_seg()
#pragma comment(linker, “/section:SHARED,RWS”)

It is working in general between applications using the DLL, but not when app is using a DLL to use DLL with shared area.

BTW:
Could it perhaps be a problem, because DLL between is using LoadLibrary?
But no, in other apps i also use LoadLibrary and there it is working…

Best regards,

Martin

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

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

11

Jeffrey Curless wrote:

I fail to see how this “nearly always” creates security issues. If you never make any security decisions based on the shared region, and treat is as POD with no pointers, say for a small debug use, I can see absolutely no security issue.

Yes, but your scenario is a tiny fraction of the things people use such
regions for. Put another way, you’ve described the “nearly” scenarios.
You are the 1%. :wink:

This is the kind of “rule” that we come across fairly often in this
list. In experienced hands, with care, a DLL shared data sections can
be useful. The problem is they are easy, so inexperienced developers
reach for them first, when there are better and more secure alternatives
available.

Please don’t spread FUD.

Skywing knows what he’s talking about. You ignore him at your peril.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

Oh I know he does, I read his blog and everything he posts on here, but I’m getting tired of these blanket statements from people.

The reality is if you use things properly, with care, then you will be ok. I’d rather have someone explain WHY you need to be careful than make a generalization. Explaining lets those inexperienced people learn, whereas his answer does not.

I do respect his knowledge though.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, October 03, 2012 3:18 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DLL - shared memory - sometimes not shared?

Jeffrey Curless wrote:

I fail to see how this “nearly always” creates security issues. If you never make any security decisions based on the shared region, and treat is as POD with no pointers, say for a small debug use, I can see absolutely no security issue.

Yes, but your scenario is a tiny fraction of the things people use such regions for. Put another way, you’ve described the “nearly” scenarios.
You are the 1%. :wink:

This is the kind of “rule” that we come across fairly often in this list. In experienced hands, with care, a DLL shared data sections can be useful. The problem is they are easy, so inexperienced developers reach for them first, when there are better and more secure alternatives available.

Please don’t spread FUD.

Skywing knows what he’s talking about. You ignore him at your peril.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

13

I’m not sure what more needs to be explained other than “anybody who can load the DLL can overwrite that memory in all other processes loading the DLL”. I certainly don’t consider pointing this out to be “spreading FUD”.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Curless
Sent: Wednesday, October 03, 2012 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DLL - shared memory - sometimes not shared?

Oh I know he does, I read his blog and everything he posts on here, but I’m getting tired of these blanket statements from people.

The reality is if you use things properly, with care, then you will be ok. I’d rather have someone explain WHY you need to be careful than make a generalization. Explaining lets those inexperienced people learn, whereas his answer does not.

I do respect his knowledge though.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, October 03, 2012 3:18 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DLL - shared memory - sometimes not shared?

Jeffrey Curless wrote:

I fail to see how this “nearly always” creates security issues. If you never make any security decisions based on the shared region, and treat is as POD with no pointers, say for a small debug use, I can see absolutely no security issue.

Yes, but your scenario is a tiny fraction of the things people use such regions for. Put another way, you’ve described the “nearly” scenarios.
You are the 1%. :wink:

This is the kind of “rule” that we come across fairly often in this list. In experienced hands, with care, a DLL shared data sections can be useful. The problem is they are easy, so inexperienced developers reach for them first, when there are better and more secure alternatives available.

Please don’t spread FUD.

Skywing knows what he’s talking about. You ignore him at your peril.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

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

14

A DLL’s shared section can be shared across all processes in the same security context (logon session). A shared memory session can also be opened by any process in the same security context. Unless it’s unnamed and communicated across processes by some private means, but then someone can duplicate its handle (by sheer luck?) and get access to it.

If you’re in the same logon session, you’re already on this side of the hatch, as Mr. R Chen likes to say.

15

Also, a shared data section is nothing else as a specially named mapped memory section.

16

This is exactly correct. In order to have the shared section, you must trick the program into loading your dll. If they load your dll, well, you are already in their security context so… you win.

That is exactly why I said FUD, and I stand beside it.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Wednesday, October 03, 2012 4:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

A DLL’s shared section can be shared across all processes in the same security context (logon session). A shared memory session can also be opened by any process in the same security context. Unless it’s unnamed and communicated across processes by some private means, but then someone can duplicate its handle (by sheer luck?) and get access to it.

If you’re in the same logon session, you’re already on this side of the hatch, as Mr. R Chen likes to say.

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

17

This is incorrect. /shared sections within an image are NOT instanced per LSA logon session. They are instanced per TS session. You will be poking a hole in anything that does isolation within a TS session.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Wednesday, October 03, 2012 1:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

A DLL’s shared section can be shared across all processes in the same security context (logon session). A shared memory session can also be opened by any process in the same security context. Unless it’s unnamed and communicated across processes by some private means, but then someone can duplicate its handle (by sheer luck?) and get access to it.

If you’re in the same logon session, you’re already on this side of the hatch, as Mr. R Chen likes to say.

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

18

No. The vulnerability has nothing to do with tricking someone into loading the DLL unexpectedly. This is not the issue.

Consider an isolation system A running unprivileged, untrusted program P in a TS session S. Unprivileged program P is not trusted and has been stripped down to run in a very limited security context by the isolation system A.

Program running outside of the isolation system, Q, executes in TS session S and makes use of a DLL D with a shared section (because it shipped with the DLL). Q already loads DLL D as a normal course of its operation, so there is no tricking the program to load DLL D; it does so normally.

The vulnerability is that now unprivileged program P can load the DLL D and start overwriting anything in the shared section within that DLL. These changes will be visible to the non-isolated/non-sandboxed program Q, subverting the capability of the isolation system A to effectively isolate untrusted code under its control within TS session S.

Isolation system A may be some in-box component or it may be some application that sandboxes code which a user separately installs.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Curless
Sent: Wednesday, October 03, 2012 1:15 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

This is exactly correct. In order to have the shared section, you must trick the program into loading your dll. If they load your dll, well, you are already in their security context so… you win.

That is exactly why I said FUD, and I stand beside it.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Wednesday, October 03, 2012 4:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

A DLL’s shared section can be shared across all processes in the same security context (logon session). A shared memory session can also be opened by any process in the same security context. Unless it’s unnamed and communicated across processes by some private means, but then someone can duplicate its handle (by sheer luck?) and get access to it.

If you’re in the same logon session, you’re already on this side of the hatch, as Mr. R Chen likes to say.

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

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

19

I would argue that you didn’t do a good job vetting your security. You shouldn’t be using a DLL with a shared region across security domains, if action can occur based upon the shared region.
Of course just because changes “can be seen” doesn’t mean there is a security hole. Action must be taken based upon these changes.

But see, we just did a much better job of explaining than, “O-M-G don’t do that”.

:slight_smile:

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, October 03, 2012 4:43 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

No. The vulnerability has nothing to do with tricking someone into loading the DLL unexpectedly. This is not the issue.

Consider an isolation system A running unprivileged, untrusted program P in a TS session S. Unprivileged program P is not trusted and has been stripped down to run in a very limited security context by the isolation system A.

Program running outside of the isolation system, Q, executes in TS session S and makes use of a DLL D with a shared section (because it shipped with the DLL). Q already loads DLL D as a normal course of its operation, so there is no tricking the program to load DLL D; it does so normally.

The vulnerability is that now unprivileged program P can load the DLL D and start overwriting anything in the shared section within that DLL. These changes will be visible to the non-isolated/non-sandboxed program Q, subverting the capability of the isolation system A to effectively isolate untrusted code under its control within TS session S.

Isolation system A may be some in-box component or it may be some application that sandboxes code which a user separately installs.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Curless
Sent: Wednesday, October 03, 2012 1:15 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

This is exactly correct. In order to have the shared section, you must trick the program into loading your dll. If they load your dll, well, you are already in their security context so… you win.

That is exactly why I said FUD, and I stand beside it.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Wednesday, October 03, 2012 4:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

A DLL’s shared section can be shared across all processes in the same security context (logon session). A shared memory session can also be opened by any process in the same security context. Unless it’s unnamed and communicated across processes by some private means, but then someone can duplicate its handle (by sheer luck?) and get access to it.

If you’re in the same logon session, you’re already on this side of the hatch, as Mr. R Chen likes to say.

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

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

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

20

Great! You have just proven that security bugs in DLLs do not exist. After all, in order to be affected by a bug you must first trick the program into loading your dll…

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Curless
Sent: Wednesday, October 3, 2012 1:15 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

This is exactly correct. In order to have the shared section, you must trick the program into loading your dll. If they load your dll, well, you are already in their security context so… you win.

That is exactly why I said FUD, and I stand beside it.