excludefile order matters if smaller range is included in bigger range #2257
Comments
Thanks for reporting this. I'm hunting down the problem, which seems to be an edge case I missed when implementing the exclusion trie merging code. Specifically, it seems that if the address part of a CIDR spec falls within a CIDR spec already in the trie, we end up doing the wrong thing, probably when we assume this means the earlier spec is the larger one. For example, if you use a different pair of specs such that the base address of the larger spec does not fall within the smaller one, the bug doesn't trigger: 192.168.1.128/25 and 192.168.1.0/24, for instance. |
Bug is in this section: if (this->mask[i] > mask[i]) {
/* broader mask, truncate this one */
this->mask[i] = mask[i];
for (; i < 4; i++) {
this->mask[i] = 0;
} We correctly take the new, broader mask for this I'm actually rewriting a few portions of this to do the work in |
Changing the order of the IP ranges inside the excludefile changes the outcome. Having a smaller IP-Range which is included in a bigger IP-Range and both defined in the excludefile, might excludes everything, if small IP-Range is in front of the big IP-Range.
This can be a single IP Address as well instead of an IP-Range.
It only happens if the smaller range is included in the bigger range.
To Reproduce
Running:
nmap --excludefile exclude.list 192.168.0.0/16
with the following two different excludefiles:Small Range in front of Big Range:
Small Range after Big Range
Expected behavior
It shouldn't matter which option the IP-Ranges are inside the excludefile.
Version info (please complete the following information):
Same behaviour with: Nmap version 7.91
The text was updated successfully, but these errors were encountered: