Emplace vs closures

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 20 07:00:00 PDT 2016


On 9/20/16 4:08 AM, cym13 wrote:
> On Monday, 19 September 2016 at 14:22:16 UTC, Steven Schveighoffer wrote:
>> On 9/19/16 7:27 AM, Lodovico Giaretta wrote:
>>
>>> What I'd like to know: is this usage widespread? Should we forbid it for
>>> the sake of security?
>>
>> No. There is no security concern here. You are dereferencing a null
>> pointer, which is perfectly safe.
>>
>
> I beg to defer, null pointer dereference is certainly not safe in the
> general case. In many cases it lead to code execution or privilege
> escalation. See for example CVE-2008-568 [1] for an example in kernel
> space or CVE-2009-0385 [2] in user space.

In kernel space, yes. So don't do this in your D kernel :)

In user space, the chance is very unlikely. It requires a function 
context to be larger than the reserved page space, and accessing a 
function context variable outside that space.

Not impossible, but very very unlikely. And beyond the control of the 
exploiter.

> The idea is that you are really trying to call a function in a part of
> memory that is not mapped, but if you are able to map the zero page and
> control what function pointer is present there then it is exploitable.
> I'd like people to get away from the idea that null pointer dereference
> is safe, it's not. In most cases it's not exploitable but that's
> definitely not a safe spot.

Dereferencing a null pointer is perfectly safe in user space (where you 
can't map the zero page). Indexing a null pointer is not. In this case, 
we are indexing a null pointer, so there is the potential for abuse, but 
very very small.

I'm still not sure that emplace on an inner struct is a thing we need to 
allow, especially when it's known that the context pointer will be 
invalid. Maybe we should only allow if called via a different name, to 
prevent unwitting uses.

-Steve


More information about the Digitalmars-d mailing list