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.


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.

Reply via email to