| sligor |
Citation :
When you allocate a large enough region of memory (the threshold is often 1 MiB if memory serves), most allocators will get a new region of memory from the kernel using "mmap" just for that region. However, when "mmap" gives you new pages of memory, they have to be initialized to zero (when using MAP_ANONYMOUS). If they weren't, they'd be filled with all sorts of junk from other applications — and this is a serious security vulnerability. What if root was editing /etc/shadow with those pages? The same also applies if "malloc" runs out of memory for small allocations and calls "sbrk" to get more.
But it would take too long to zero all that memory. The kernel cheats. There is a page of memory already zeroed set aside. All pages in the new allocation point at this one page of physical ram, which is shared among all processes on the system, so it doesn't actually use any memory. It's marked as read-only. As soon as you write to it, the processor raises an exception. The kernel's exception handler then grabs a page of RAM (possibly swapping something else out), fills it with zeroes, and maps it into your process's address space. The "calloc" function can exploit this.
|
en gros je pense que le risque c'est de générer une exception quand on écrit dans le buffer alloué avec calloc et de rendre vulnérable donc le code à une timing-attack ( http://en.wikipedia.org/wiki/Timing_attack ).
je ne vois que ça...
masklinn a écrit :
self-reply: ah non le calloc et malloc+memset(0) sont bien équivalents, le problème c'est qu'il y a un malloc+memset(!0) qui est remplacé dans le commit:
Code :
- data->saved_message.data = malloc(inl); - memcpy(data->saved_message.data, in, inl); + data->saved_message.data = calloc(1, inl);
|
oops: http://freshbsd.org/commit/openbsd [...] 3eeccb4d63
|
OK, je suis allé trop loin dans mon analyse :D |