Emplace vs closures

[cym13 via Digitalmars-d]

On Tuesday, 20 September 2016 at 08:23:04 UTC, John Colvin wrote:
> On Tuesday, 20 September 2016 at 08:08:16 UTC, 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.
>>>
>>> -Steve
>>
>> I beg to defer,
>
> You mean differ, right?

Hmm... yes, sorry.

>> 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.
>>
>> 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.
>>
>> That being said I don't think it should be the burden of the 
>> library or language to deal with this for the reasons you 
>> exposed.
>>
>> [1] http://www.trapkit.de/advisories/TKADV2008-015.txt
>> [2] http://www.trapkit.de/advisories/TKADV2009-004.txt
>
> Interesting, hadn't seen this stuff before. There is also the 
> matter of large offsets taking you to accessible memory, such 
> as you might get with a null pointer to a very large struct.

Another interesting case is the Firefox debug offset. On x86 the 
address space was scarce so nothing could be mapped in userspace 
above 0xe0000000 IIRC. Firefox devs decided to use the address 
0xefefefef to cause a clear segfault easy to hook in order to 
ease debugging. When Firefox was ported to x86_64 this range 
became available, so an attack was to setup that address and 
cause an error leading to a debug segfault and code execution. I 
think the fix was to used 0xfefefefe instead but I'm not sure.

Anyway segfaults aren't safe, they should be avoided and 
controlled when possible. It's always better to manage the error.