4 ms·
If the memory had the value of a password and was then unallocated, the value would still be there. Then when allocating the memory again, the value would be th
by londgine 4y ago
If the memory had the value of a password and was then unallocated, the value would still be there. Then when allocating the memory again, the value would be there. If you initialize it to something and then print it, there is no security issue. but if you print it before, then you just printed a password.
- stingraycharles 4y agoWouldn’t clearing the memory upon free() be a more reliable way to deal with this, though?
- Denvercoder9 4y agoNo, as not all memory is free()'d, think e.g. of crashes and buffer overflows.
- moffkalast 4y agoYou could try having the OS guarantee zero initialized memory for all blocks that your program gets, but that's hard to enforce as a standard I imagine.
- stingraycharles 4y agoSo if it’s hard to enforce, what’s the reason we go through the effort of zeroing anyway? Isn’t this one of those things that either need to be 100% reliable to be useful? Or is this more about preventing escalation in case someone finds an exploit in your code?
- wolletd 4y agoZeroing is just a form of initialization. If you initialize the memory right away (and completely!) with actual data, there's no need for additional zeroing. Zeroing is something one should do if the allocated memory isn't completely initialized right away. In my experience, that's not only about someone finding exploits, but also about stability. When people write code, most of the time they simply work with the assumption that an `int` contains a 0 by default and that code usually fails in unpredictable ways if it does not. Accessing uninitalized memory is just always an error and having uninitalized memory laying around in your application has rarely any benefit. Either assign a value or zero it. Not doing either of those suggests the allocation isn't needed right there in the first place.
- 3836293648 4y agoI think we do this in practice. The issue is that malloc doesn' t ask the OS for memory, it calls the system allocator which in turn asks the OS for memory. But once you've freed something, that allocator can give you that memory back without talking to the kernel
- justsomehnguy 4y ago> be a more reliable way to deal with this, Only if you can guarantee what free_and_zero() would succeed every time. But you can't.
- perryizgr8 4y agoWhat if the program never called free? Or if it crashed? A bad actor could intentionally crash a program, and then allocate lots of memory, then search for the password in the memory.
- Findecanor 4y agoAll modern operating systems will clear the physical memory before handing it from one process (crashed or not) to another.
- perryizgr8 4y agoIf that's true, then the entire premise of calloc is invalid, isn't it? Newly allocated memory would always be zeroed anyway by the OS. Then what are we even discussing?
- rightbyte 4y agoThere is a process local object pool in some implementations.
- butlerm 4y agomalloc is not a system call, it is a C library function. Modern operating systems clear memory when providing it to a process, but malloc implementations reuse the same memory locations previously used an arbitrary number of times within the process and normally do not clear memory when it is reused (within the process) for performance reasons.
- sys_64738 4y agoThis is why even with garbage collected languages that you should always manually bzero the password field or other important fields.