Hi Jakob,
I do agree with you that a NULL SecAttrib will get you a default
descriptor. After sending the post (before you jumped on it), I wanted
to preface the statement with "some hand waiving." What constitutes a
default descriptor is somewhat of a moving target when over the
Windows OS's and its usually easiest to explain it as "Everyone, Full
Control" though it might be weakened to "Current User, Full Control".
Unless, of course, two processes are engaged in IPC/Synchronization,
and one process is a "Local Service" and the other is a desktop
program running under "Current User". In this case, a NULL SecAtrrib
on a named securable object acts like "Everyone, Full Control".
Confer: What did the analysis Paget's Shatter Attack reveal? How did
Microsoft remediate it?
I suppose I should bounce it back at you: why is it appropriate that
either "Administrators", Local Service", or "SYSTEM" (any one of whom
might show up due to a default descriptor) have access to my mutex,
when all that is required is a single ACE of {Current User,
STANDARD_RIGHTS_READ|SYNCHRONIZE}?
Jeff
On Fri, Jun 25, 2010 at 5:24 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> Read my post again,
>
> I did not say that NULL DACLs are not obviously dangerous (they are
> and have been deprecated since the mid 1990s). I said that a
> NULL SECURITY_ATTRIBUTES does not result in a NULL DACL but something
> much less dangerous.
>
> If you found a way to make the SRM assign a NULL DACL in response to
> a NULL lpSecurityDescriptor, then you found yet another security bug in the
> SRM itself (congratulations).
>
> PS: One small correction to my post: For at least some APIs, Windows 9x
> will not object to a non-NULL lpSecurityDescriptor anyway.
>
>
> On 25-06-2010 21:08, Jeffrey Walton wrote:
>>
>> Hi Jakob,
>>
>> Boy this is an argumentative list at times....
>>
>> As a Win32 guy, I understand your the finer points you are making.
>> Unfortunately, there are implicit assumptions that are being made
>> which are undermining your arguments. Put another way, its the attacks
>> which you *don't* know about which will burn you with these NULL
>> DACLs.
>>
>> In the discussion with Patrick Eisenacher [2], I claimed a wilcard
>> cert violated principle of least privilege. Patrick pressed me for the
>> next attack using wildcard certs, which I did not have. In this case,
>> I have the next attacks. We have not released the paper yet, though
>> its been shared with those affected, including Microsoft.
>>
>> The response to "This is plain wrong" is inlined. I did not claim a
>> NULL DACL violates Principle of Least Privilige this time around (I'm
>> trying to learn from my mistakes). I cited the guys who wrote the
>> proverbial security book at Microsoft. Hopefully their opinion will be
>> weighed more appropriately.
>>
>> I could also cite Richter, but he usually offers Win32 best practices
>> (Richter will also tell you not to use NULL DACLs). But its fairly
>> obvious (to me) if one is going to discard a security related best
>> practice and the SDLC, one is probably not going to follow Win32 best
>> practices (is this 'too much' of a leap?).
>>
>> On Fri, Jun 25, 2010 at 5:01 AM, Jakob Bohm<jb-open...@wisemo.com> wrote:
>>>
>>> On 24-06-2010 23:31, Jeffrey Walton wrote:
>>>>
>>>> [SNIP]
>>>>
>>>> Critical sections have the added benefit that you don't have to supply
>>>> a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
>>>> folks leave unspecified (NULL) so the net effect is "Everyone, Full
>>>> Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
>>>> security audit.
>>>>
>>>
>>> This is plain wrong, and I certainly hope nobody uses this
>>> misunderstanding
>>> in security audits.
>>>
>>
>> NULL DALCS and other Dangerous ACE Types: "A NULL DACL is a way of
>> granting all accessd to all users of an object, including attackers. I
>> sometimes quip that NULL DACL == No Defense. And its absolutely true.
>> If you don't care that anyone can do anything to your object -
>> including read from it, write to it, delete existing data, modify
>> existing data, and deny others access to the object - a NULL DACL is
>> fine. However, I have yet to see a product for which such a
>> requirement is of benefit, which, of course, completely rules out the
>> use of NULL DACLs in your product". [1]
>>
>>>
>>> [SNIP]
>>>
>>
>> Jeff
>>
>> [1] Howard and LeBlanc, 'Writing Secure Code', ISBN 0-7356-1722-8, p 195.
>> [2] http://www.mail-archive.com/openssl-users@openssl.org/msg61152.html
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-us...@openssl.org
> Automated List Manager majord...@openssl.org
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
