DLL - shared memory - sometimes not shared?

OSR_Community_User · October 3, 2012, 4:59pm

That’s not what I said at all…

-Jeff

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

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.

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

Ken_Johnson · October 3, 2012, 5:00pm

Any usage of a shared section in a DLL is *inherently* cross-security-domain by default.

In you use a shared section in a DLL, you must by default be prepared (at any and all times) for there to be complete garbage in the shared section within the DLL.

And if you are prepared (and must assume that) all of the data in that shared section in garbage, what are you actually going to usefully place in the shared section ?

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:54 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

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”.

-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

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

OSR_Community_User · October 3, 2012, 5:11pm

I could see it used to monitor client programs from a main logging program perhaps, where if the programs crash they write a bit of data into the shared section in their exception handlers.

“Could be bad” doesn’t mean “is always bad”. You are taking things far too extremely. That’s just like saying well, files that notepad can open could be corrupted, so better not ever open files!

Or, man, that shared memory region could be bad! I better never look at it!

If everything that could be bad were, and we had no protection from it, we’d never be able to do anything. Usermode to kernelmode IO works this way, think about it. I pass a pointer to a buffer, you map and lock it, and protect yourself with a _try/_except. I could pass junk data in my buffer, so you also need to verify the data in the buffer matches what you expect before going off and doing anything. Could the data in the buffer change after you verify it? Yes. Well then you better make a copy I can’t touch and verify that and work from it.

Easy peasy lemon squeezy.

The real lesson is, anytime you share data across security contexts you must protect and verify based upon the usage pattern.

-Jeff

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

Any usage of a shared section in a DLL is *inherently* cross-security-domain by default.

In you use a shared section in a DLL, you must by default be prepared (at any and all times) for there to be complete garbage in the shared section within the DLL.

And if you are prepared (and must assume that) all of the data in that shared section in garbage, what are you actually going to usefully place in the shared section ?

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:54 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

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”.

-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

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

Pavel_A1 · October 3, 2012, 5:27pm

Well. Is there any API, PE header flag, appcompat shim etc. that will
opt out of this auto-creation of shared sections by DLLs in a process?

Thanks,
– pa

On 03-Oct-2012 22:59, Skywing wrote:

Any usage of a shared section in a DLL is *inherently* cross-security-domain by default.

In you use a shared section in a DLL, you must by default be prepared (at any and all times) for there to be complete garbage in the shared section within the DLL.

And if you are prepared (and must assume that) all of the data in that shared section in garbage, what are you actually going to usefully place in the shared section ?

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:54 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

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”.

-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.

raj_r · October 3, 2012, 6:02pm

i was wondering where i read about this shared section being a
security hole and finally located it in google

its raymond chen oldnewthing and it is as old as old rum btw

http://blogs.msdn.com/b/oldnewthing/archive/2004/08/04/208003.aspx

On 10/4/12, Pavel A wrote:
> Well. Is there any API, PE header flag, appcompat shim etc. that will
> opt out of this auto-creation of shared sections by DLLs in a process?
>
> Thanks,
> – pa
>
> On 03-Oct-2012 22:59, Skywing wrote:
>> Any usage of a shared section in a DLL is inherently
>> cross-security-domain by default.
>>
>> In you use a shared section in a DLL, you must by default be prepared (at
>> any and all times) for there to be complete garbage in the shared section
>> within the DLL.
>>
>> And if you are prepared (and must assume that) all of the data in that
>> shared section in garbage, what are you actually going to usefully place
>> in the shared section ?
>>
>> - 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:54 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?
>>
>> 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”.
>>
>>
>>
>> -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
>

Ken_Johnson · October 3, 2012, 6:16pm

No. Shared sections are so rare (and so far deprecated) that nobody added such a capability. The flag would likely just as well fail to load the DLL as who knows what it would do when its shared data wasn’t really shared, anyway, even if it did hypothetically exist.

S (Msft)

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

Well. Is there any API, PE header flag, appcompat shim etc. that will opt out of this auto-creation of shared sections by DLLs in a process?

Thanks,
– pa

On 03-Oct-2012 22:59, Skywing wrote:

Any usage of a shared section in a DLL is *inherently* cross-security-domain by default.

In you use a shared section in a DLL, you must by default be prepared (at any and all times) for there to be complete garbage in the shared section within the DLL.

And if you are prepared (and must assume that) all of the data in that shared section in garbage, what are you actually going to usefully place in the shared section ?

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:54 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?

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”.

-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

OSR_Community_User · October 3, 2012, 6:18pm

> i was wondering where i read about this shared section being a

security hole and finally located it in google

its raymond chen oldnewthing and it is as old as old rum btw

http://blogs.msdn.com/b/oldnewthing/archive/2004/08/04/208003.aspx

On 10/4/12, Pavel A wrote:
>> Well. Is there any API, PE header flag, appcompat shim etc. that will
>> opt out of this auto-creation of shared sections by DLLs in a process?
>>

Yes there is. It’s called “don’t do that”. A DLL which has a shared
segment will depend on the sharing for proper functionality; if you don’t
want shared segments, don’t mark it as such. If the original programmer
went through all the effort to create a shared segment, then it is clearly
important and expected functionality, and the DLL probably will not work
as expected if the sharing were defeated.

>> Thanks,
>> – pa
>>
>> On 03-Oct-2012 22:59, Skywing wrote:
>>> Any usage of a shared section in a DLL is inherently
>>> cross-security-domain by default.
>>>
>>> In you use a shared section in a DLL, you must by default be prepared
>>> (at
>>> any and all times) for there to be complete garbage in the shared
>>> section
>>> within the DLL.
>>>
>>> And if you are prepared (and must assume that) all of the data in that
>>> shared section in garbage, what are you actually going to usefully
>>> place
>>> in the shared section ?
>>>
>>> - 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:54 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: RE: RE:[ntdev] DLL - shared memory - sometimes not shared?
>>>
>>> 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”.
>>>
>>>
>>>
>>> -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
>

OSR_Community_User · October 3, 2012, 6:32pm

> 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”.

-Jeff
****
In the Great Wide World of Security, getting a trusted (or sandboxed)
process to share information with a non-trusted process or a process
outside the sandbox is clearly a security violation.

Now, one of the ways you can “trick” a process into loading a DLL is to
use it as a system-wide hook. That’s why in Vista+, the “integrity level”
is used to avoid some of these issues. Ultimately, anything you (the
owner of the logged-in session) can do is legitimate. Note that someone
else logged into a different session does NOT share the shared segment;
you can only use it to “leak” information to your own process context,
which means you already have access to it!

The problem comes up when someone can get a piece of malware to run that
uses a DLL with shared data, and uses it to send information out, say,
over the Internet. This can usually be handled in a more straightforward
fashion, such as blocking outgoing TCP/IP connections to unvetted
locations or to unvetted ports.

But ultimately, as I indicated in an earlier reply, a DLL that has a
shared segment has it because that sharing defines an integral part of its
functionality. You can choose to not allow any DLLs on your system that
have shared segments (you can parse the PE file looking for sharing, and
if I know you’re doing it, I can circumvent it fairly trivially). And it
is no more “dangerous” than opening a memory-mapped file and sharing it
among multiple processes. I think the concerns are missing the point: why
is there sharing? If you don’t know why there is a shared segment, you
have no idea of the implications of disabling it, and the phrase
“undefined behavior” pops to mind.
joe

-----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

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

Pavel_A1 · October 3, 2012, 6:37pm

On 04-Oct-2012 00:15, Skywing wrote:

No. Shared sections are so rare (and so far deprecated) that nobody added such a capability. The flag would likely just as well fail to load the DLL as who knows what it would do when its shared data wasn’t really shared, anyway, even if it did hypothetically exist.

S (Msft)

Failing to load such DLLs would be fine. Is it too late for Win7 SP2?
– pa

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

Well. Is there any API, PE header flag, appcompat shim etc. that will opt out of this auto-creation of shared sections by DLLs in a process?

Thanks,
– pa

OSR_Community_User · October 3, 2012, 6:40pm

Duplicate *what* handle? The handle from LoadLibrary cannot be duplicated
or inherited; it is completely process-local. So if you have the handle,
there’s nothing you can do with it except use it to load resources from
the DLL’s resource segment.

I hadn’t seen the several other replies that said what I said: there’s no
security leak because you are already in that security context. Malware
is excepted, but that would require you did fairly irresponsible site
maintenance, as well as poor security policies.
joe

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

OSR_Community_User · October 3, 2012, 6:45pm

> 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.
****
Actually, one of my assignments in my Systems Programming course was using
a shared segment WITH POINTERS, shared between two processes. You have to
use _based pointers, a Microsoft extension to the C language.

If you pass pointers, you don’t generate any security holes, because
either the pointer is into the shared segment, which makes it useless in
another process, or it is pointing to a nonshared segment, which makes it
useless in another process. Based pointers are always segment-relative,
so they can’t “leak” anything.

If I wanted to attack your machine effectively, shared data segments are
not a particularly interesting tool.

You have no more nor less access than you would have to a shared file,
which you can feel free to scribble on, no matter how much damage this may
represent. You are thinking about the problem incorrectly.
joe

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

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

OSR_Community_User · October 3, 2012, 7:50pm

No I’m not thinking about it incorrectly. I understand it perfectly, I just chose the wrong argument to explain why it wasn’t a real security issue all the time.

-Jeff

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

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.
****
Actually, one of my assignments in my Systems Programming course was using a shared segment WITH POINTERS, shared between two processes. You have to use _based pointers, a Microsoft extension to the C language.

If you pass pointers, you don’t generate any security holes, because either the pointer is into the shared segment, which makes it useless in another process, or it is pointing to a nonshared segment, which makes it useless in another process. Based pointers are always segment-relative, so they can’t “leak” anything.

If I wanted to attack your machine effectively, shared data segments are not a particularly interesting tool.

You have no more nor less access than you would have to a shared file, which you can feel free to scribble on, no matter how much damage this may represent. You are thinking about the problem incorrectly.
joe

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

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

OSR_Community_User · October 3, 2012, 9:56pm

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

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

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

OSR_Community_User · October 3, 2012, 11:25pm

Why would you want the ability to fail a DLL load? I fail to see how
shared segments create any problem. In fact, many DLLs critically depend
upon the ability to share, for example, any global hook DLL. And there is
already a mechanism to avoid letting a global hook do DLL injection:
integrity level. So what does blocking a DLL load because of shared
segments actually accomplish, other than annoying people who need shared
segment DLLs?
joe

On 04-Oct-2012 00:15, Skywing wrote:
> No. Shared sections are so rare (and so far deprecated) that nobody
> added such a capability. The flag would likely just as well fail to
> load the DLL as who knows what it would do when its shared data wasn’t
> really shared, anyway, even if it did hypothetically exist.
>
> - S (Msft)

Failing to load such DLLs would be fine. Is it too late for Win7 SP2?
– pa

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A
> Sent: Wednesday, October 03, 2012 2:26 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DLL - shared memory - sometimes not shared?
>
> Well. Is there any API, PE header flag, appcompat shim etc. that will
> opt out of this auto-creation of shared sections by DLLs in a process?
>
> Thanks,
> – pa
>

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

OSR_Community_User · October 3, 2012, 11:32pm

> 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.

No, the example of shared data segments was already posted. One thing
that was not emphasized was that if there is no initializer, the data goes
in the default data segment no matter what the preceding #pragma data_seg
suggests. This makes it difficult to put C++ structures in a shared data
segment, even if you write your own allocator (which you have to). I used
to get a lot of questions about why std::vector could not be used in a
shared data segment/memory-mapped file. It can be, but only with a lot of
work, usually not justified.
joe

//Daniel

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

Ken_Johnson · October 3, 2012, 11:36pm

Globals without an initializer go into the segment set by #pragma bss_seg(), excluding __declspec(thread) variables which go to .tls without regard to whether there was an initializer or not.

S (Msft)

From: xxxxx@flounder.com
Sent: 10/3/2012 20:32
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

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.

No, the example of shared data segments was already posted. One thing
that was not emphasized was that if there is no initializer, the data goes
in the default data segment no matter what the preceding #pragma data_seg
suggests. This makes it difficult to put C++ structures in a shared data
segment, even if you write your own allocator (which you have to). I used
to get a lot of questions about why std::vector could not be used in a
shared data segment/memory-mapped file. It can be, but only with a lot of
work, usually not justified.
joe

//Daniel

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

OSR_Community_User · October 3, 2012, 11:39pm

Thank you. That’s useful information.
joe

Globals without an initializer go into the segment set by #pragma
bss_seg(), excluding __declspec(thread) variables which go to .tls without
regard to whether there was an initializer or not.

S (Msft)

From: xxxxx@flounder.com
Sent: 10/3/2012 20:32
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL - shared memory - sometimes not shared?

> 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.

No, the example of shared data segments was already posted. One thing
that was not emphasized was that if there is no initializer, the data goes
in the default data segment no matter what the preceding #pragma data_seg
suggests. This makes it difficult to put C++ structures in a shared data
segment, even if you write your own allocator (which you have to). I used
to get a lot of questions about why std::vector could not be used in a
shared data segment/memory-mapped file. It can be, but only with a lot of
work, usually not justified.
joe
>
> //Daniel
>
> —
> 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

anton_bassov · October 4, 2012, 12:46am

> 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.

Sorry, Ken, but if what you have said on this thread is correct and SHARED section of DLL is, indeed, shared across the logon boundary…well, then it is not the DLL developer who creates security issues - it is OS designer. Vulnerabilities of this type firmly belong, IMHO, in “due to the fallacy of the OS design” class of problems…

Anton Bassov

anton_bassov · October 4, 2012, 1:24am

> 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

Ken_Johnson · October 4, 2012, 2:20am

Shared sections within an image are a very dangerous tool and not something that I would at all recommend for general purpose use (or nearly any use). They are not amenable to being used securely if you are depending on the OS’s built-in security model.

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.

That being said, it is still a choice of the developer to elect to use such a piece of functionality and they need to understand the consequences and responsibilities in doing so. If a developer uses shared sections within an image incorrectly (and there are vanishingly few good use cases for them compared to the myriad of very bad use cases for them), then they will create a vulnerability in their application. A developer can’t use a piece of functionality without understanding what it does and then say that is not their responsibility of they create a vulnerability with it through lack of understanding of the functionality that they used.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, October 03, 2012 9:50 PM
To: Windows System Software Devs Interest List
Subject: 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.

Sorry, Ken, but if what you have said on this thread is correct and SHARED section of DLL is, indeed, shared across the logon boundary…well, then it is not the DLL developer who creates security issues - it is OS designer. Vulnerabilities of this type firmly belong, IMHO, in “due to the fallacy of the OS design” class of problems…

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