manual memory management

[H. S. Teoh]

On Wed, Jan 09, 2013 at 08:40:28PM +0100, Rob T wrote:
[...]
> According to my definition of memory safety, a memory leak is still a
> memory leak no matter how it happens. I can however see an alternate
> definition which is likely what you are suggesting, where so long as
> you are not accessing memory that is not allocated, you are memory
> safe. There must be more to it than that, so if you can supply a more
> correct definition, that would be welcome.
[...]

And here we finally get to the root of the problem. Walter's definition
of memory-safe (or what I understand it to be) is that you can't:
(1) Access memory that's been freed
(2) Access memory that was never allocated
(3) As a result of the above, read garbage values or other data that you
  aren't supposed to be able to access from memory.

The context of this definition, from what I understand, is security
breaches that exploit buffer overruns, stack overruns, and pointer
arithmetic to read stuff that one isn't supposed to be able to read or
write stuff into places where one shouldn't be able to write to. A good
number of security holes are caused by being able to do such things, due
to the lack of memory safety in C/C++.

Running out of memory is moot, because the OS will just kill your app
(or an exception will be thrown and the runtime will terminate), so that
presents no exploit path.

Dereferencing null is also moot, because you'll just get an exception or
a segfault, which is no help for a potential expoit.

Memory leak isn't something directly exploitable (though it *can* be
used in a DOS attack), so it doesn't fall under the definition of
"memory safety" either.

If you want to address memory leaks or dereferencing nulls, that's a
different kettle o' fish.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley