-1

how to use the malloc() function effeciently for different OS.

Tinni
  • 17
  • 2
  • 7
    malloc itself doesn't really have vunerabilities, you need to be a bit more specific – nos Mar 01 '12 at 19:47
  • 1
    -1 for "we all know..." followed by false statement. If you don't know something, don't assert is as fact as part of your question, but instead ask a question. – R.. GitHub STOP HELPING ICE Mar 01 '12 at 20:28
  • To provide more clearity, I meant the malloc() has to be used more carefully otherwise it would result in open vulnerabilites.. – Tinni Mar 01 '12 at 22:06
  • Specifically, the question is that what points should be taken care-off while using malloc() for different OS(like windows, linux etc) respectively to avoid any vulnerability ? – Tinni Mar 01 '12 at 22:08
  • The best way to *"to avoid **any** vulnerability"* while using `malloc()` is probably not to use it at all, isn't it? – thkala Mar 01 '12 at 23:25
  • @thkala: That's like saying the best way not to die while wearing a clown suit is not to wear a clown suit. It might be true, but it won't keep you from dying... – R.. GitHub STOP HELPING ICE Mar 02 '12 at 03:12

4 Answers4

1

I find the claim that malloc is a source of vulnerabilities extremely dubious. Whoever told you this was probably thinking either of:

  • arithmetic overflows computing the size argument to pass to malloc, or
  • out-of-bound array accesses when accessing an array obtained by malloc.

Neither of these is in any way specific to malloc, and really the first only becomes an issue because of the second, which stems from the fact that out-of-bound array access in C produced undefined behavior rather than a trappable error condition.

There's nothing the OS or library implementation needs to do to "avoid vulnerabilities in malloc" because such vulnerabilities are not in malloc. They're in broken application code that's violating the contract of the C language.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
0

The book, "The Art of Software Security Assessment" does a good job describing the various problems you can encounter when using malloc().

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
atk
  • 9,244
  • 3
  • 32
  • 32
0

First of all, on most modern operating systems, malloc() is implemented by the runtime library. Not the operating system. See the source code of the GNU implementation here.

Secondly, security between processes is assured by providing only cleared RAM for process space growth. The C runtime malloc() library function may ask the operating system for additional memory when malloc's memory pool is exhausted.

wallyk
  • 56,922
  • 16
  • 83
  • 148
0

There are a couple of major vulnerabilities that can be caused by the insecure use of malloc, for example:

  • If malloc fails, the result can be NULL. Failure to check and handle this condition can lead to null-dereferences which in certain circumstances are exploitable.
  • If the size passed to malloc is too small - most often caused by an arithmetic operation that overflowed - then malloc may succeed but return a buffer that is smaller than the original developer intended. Use of this buffer may then lead to a heap-overflow.
  • If you fail to release the memory eventually via a call to free() then a memory leak may occur which could be used to exhaust memory, for instance as part of a denial-of-service attack.

Malloc is a standard library function. It is not guarranteed to be handled by the OS (it is part of the CRT for each platform), and apart from the rules above there is no commonality that can be relied upon between different implementations. Malloc is not inherently insecure. People's use of it can be.

SecurityMatt
  • 6,593
  • 1
  • 22
  • 28