When a binary is running and there is some memory/info leak are there areas of program (or OS?) memory which are more prone to leak and is a leak in one segment worse than in another segment?
1 Answer
Generally, programs running in userspace don't have access to kernel space memory. As a result, it is overwhelmingly unlikely that a program would be able to leak kernel memory.
The memory being leaked depends heavily on the program running. A famous example is Heartbleed, which leaked all sorts of information regarding the TLS process and contents of communications of other users. Concretely, this means:
- Private Keys
- Passwords
- Sensitive Personal Data
- etc.
This, of course, would be the worst case. Some internal states of your program, such as "how many more bytes need to be sent to this user", are of very little relevance to an attacker. Depending on the specific memory leak, it may be possible for an attacker to determine what sort of data is being leaked, or it might be completely random. In the latter case, an attacker would need some form of analysis to determine what the data being leaked means.
For example, if I gave you 01bf7621 6dd8317f 820c5ab1, then you really wouldn't know what that means unless you had some sort of context.
-
Any region where a leak would be more prevalent (code,stack,heap...)? I'd expect that leaks somewhere where the programs interacts with the external world would occur more often? Not sure if true. Commented Jan 15, 2022 at 10:16
-
@larsmitsars You can't really tell which one is more prevalent, it depends entirely on the vulnerability. If you insist on an answer, then as a completely unsourced gut feeling, I'd say the heap tends to be more affected in practice.– user163495Commented Jan 15, 2022 at 11:57