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
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  for an example in
kernel space or CVE-2009-0385  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
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
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.