CWE-462 concerns associative lists, or alists, that allow the same key more than once. Duplicate keys can lead to non-unique keys being mistaken for an error.
MITRE lists C, C++, Java and C# as affected languages. It is a data structure design problem more than a classic exploit.
How it happens
A properly designed alist could use a duplicate key entry as a constant time replace. But duplicates can also be inserted by mistake, and code cannot tell which case it is looking at. Because of that ambiguity, MITRE says duplicate key entries in an association list are not recommended and should not be allowed.
MITRE's example, in Python, adds data to a list and then sorts it:
alist = []
while (foo()):
# now assume there is a string data with a key basename
queue.append(basename, data)
queue.sort()
Since basename is not necessarily unique, the result may not sort the way the author intended.
What an attacker gains
MITRE lists quality degradation, varying by context. The security effect depends on what the list controls. If it holds settings, permissions or routing, a duplicate entry can change which value wins.
How to find it
The record lists no detection methods and no observed CVEs. Review code that builds lists of key and value pairs from external input or merged sources. Test with repeated keys and check which entry is used.
How to fix it
From the record, both at the architecture and design phase:
- Use a hash table instead of an alist.
- Use an alist that checks the uniqueness of keys on every insert, before adding the entry.
A small Python version of the second option:
def put(alist, key, value):
if any(k == key for k, _ in alist):
raise KeyError("duplicate key: " + key)
alist.append((key, value))
Quick check
Why not simply allow duplicates as a replace operation?
Because accidental duplicates look identical to intended ones. Code reading the list cannot tell which was meant.
