I’m writing a program. The input is a complex data structure in memory. The output is an HTML report that contains: (1) a representation of the structure; (2) textual annotations that refer to objects in the structure.

In order to link the annotations to parts of the structure, I use the objects’ memory addresses as anchors. Thus, memory addresses end up directly in the generated HTML code.

Could this be in any way dangerous?

The reports are mostly for personal use, but sometimes they might be shared.

The program can be used as a library, inside another process’s memory space. However, the input objects are constructed specially for this purpose, and will normally be garbage-collected once the report is finished.

I was thinking about obfuscating the addresses with MD5—would that be somehow better?

  • There are only a limited number of addresses which a program will be able to use. Brute forcing them would not be difficult, so hashing them is pretty useless. It's the same problem with trying to hash an IP address. The keyspace is just too small. Generate a random index number, as others have already pointed out, rather than a deterministic, and easily reversible hash.
    – forest
    Commented Apr 24, 2016 at 2:35
  • 1
    @forest Oh. I feel stupid now. Of course I can simply map memory addresses to anything, even sequential indices, thus preserving the linkage but erasing all trace of the original addresses. Thank you for helping me see. Commented Apr 24, 2016 at 11:50

3 Answers 3


Purely from a programming point of view, instead of using an objects memory address to link these two pieces of data, you really should be generating an index number and using that to refer between the structure and your annotation.

I can't see any reason why it would be dangerous though to include the addresses in the report, since as soon as your program terminates the address space is freed by the OS. While it may not be zeroed out (data may remain in memory until overwritten), you probably aren't at risk of exploitation.

  • Why do you think this approach is bad from a programming point of view? I really like its simplicity and elegance. (I’m using Python’s id function which is specifically documented as “unique and constant for this object during its lifetime.”) Commented Apr 23, 2016 at 8:20
  • 1
    @VasiliyFaronov - because the memory addresses disappear, and change between subsequent runs. They're meaningless outside of the linking performed internal to your program. You should be outputting something that does have meaning to your user (and preferably stable, although this may not be possible in all situations). Commented Apr 23, 2016 at 16:43
  • @Clockwork-Muse I don’t show the addresses to the user. They are only used by JavaScript code to add highlights on mouse hover. It’s just a neat visual hint, it doesn’t need any more meaning. Commented Apr 23, 2016 at 19:51
  • @Daisetsu Wait, you mean that I should reduce addresses to arbitrary indices at the time of report generation, right? Of course, that’s the solution. It was stupid of me not to see it. Commented Apr 24, 2016 at 11:54
  • Yes. That's what I'm saying. If you choose the indices in a repeatable way, the program will return the same output every time, which can be invaluable in debugging problems. If the indices change every time and you're trying to track down an issue in the program that can make it more difficult to dupicate the bug.
    – Daisetsu
    Commented Apr 24, 2016 at 16:31

It may be dangerous. If your program manipulates confidential data that doesn't end up in the report, then the memory addresses may reveal information about the confidential data. Exploiting this data is likely to be difficult; the attacker would have to have a good working knowledge of what the program does, and they'd only obtain partial information, mostly about the size and number of some data elements.

For example, condider this pseudocode which analyzes a patient's record to determine whether they are fit for work:

struct patient_record_entry entries* = malloc(entry_count * sizeof(struct patient_record_entry));
char *employer_name = malloc(employer_name_length);
// read patient data from file
// analyze patient record to determine fitness for work
bool is_patient_fit = …;
       patient.name, employer_name, is_patient_fit);

Revealing the addresses of employer_name and entries reveals the number of entries in the patient's record (employer_name - entries minus a constant related to memory management) in the not so unlikely case where the two memory blocks are consecutive. This leaks more information about the patient than what is supposed to be in the output.


First, what would you lose by hashing those values? I suspect the code isn't particularly performance critical and the speed impact would be relatively minor. If there isn't a big downside it is probably worth doing.

As to what the security impact may be - many operating systems use address space layout randomisation (ASLR) to help mitigate against certain types of attacks. In the case that your program produces this output and exits it's probably not a big deal as the leaked addresses are for a now dead process, but as you mention a library that could leak addresses for a process that continues running there may be an issue there. Leaking the info doesn't directly create a vulnerability, but may make it easier to exploit one that does exist.

  • “First, what would you lose by hashing those values?” — sure, nothing. I just don’t want to be a “cargo cultist” when it comes to security. I’d like to understand what I’m doing and why. Commented Apr 23, 2016 at 11:51
  • “may make it easier to exploit one that does exist” — can you give some examples? Commented Apr 23, 2016 at 11:51
  • The simplest example would be a stack based overflow - the attacker overwrites the return address of a stack frame with the address of a piece of data they control. By placing shellcode at that address they can then control execution. ASLR helps prevent this by making it hard for the attacker to determine such an address. Printing out addresses, particularly those containing data derived from input the attacker controls negates some of this protection. It's not a big problem as a modern OS has several other protections, but probably best to avoid. Commented Apr 24, 2016 at 9:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .