-
Notifications
You must be signed in to change notification settings - Fork 829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3.7.1: memory leak: getname() #13
Comments
Submitted by guy_harris Logged In: YES What happens if you run with the "-S" flag? The IP dissector allocates no memory except for, when The TCP dissector, however, allocates, when printing "-S" causes absolute sequence numbers to be displayed; the |
Submitted by nobody Logged In: NO hi, i was running it like tcpdump -nvvvei eth0 and now i'm i also tried a simple modification that limits the total i bet there is no possibility for recursion that would eat -tom |
Submitted by nobody Logged In: NO hi, i'm beginning to feel that this is not really tcpdump's also it might be that the key is not 'broken packets' but libpcap is version 0.7.1 to be more precise. -tom |
Submitted by tom_soderlund Logged In: YES hi, observing now the HEAD version of both tcpdump and libpcap. i think i found it. the key was not only the number of i verified this by making getname() in addrtoname.c return maybe the cache should be limited in size somehow? sorry for my rather misleading information and assumptions -tom |
TCPDUMP Denial-of-Service vulnerability Hello, Before proceeding, please note that we are not regular contributors of the tcpdump project, so we are not experts about the rest of the codebase, and before submitting the patch and notify the vulnerability we would like to have your feedback. From what we understood by analyzing the code of “addrtoname.c”, the program, in order to cache the IP Address – Hostname resolution, maintains an hashtable (hnametable), which holds lists of type “hnamemem”. Each “hnamemem” element holds:
The function “getname” in “addrtoname.c” is responsible for populating and maintaining such data structure, however we noticed that new elements are added to the “cache” even if the hostname resolution is turned off (by using the “-n” flag); in that case, the hostname field of hnamemem is populated with the string representation of the IP address (xxx.xxx.xxx.xxx). This leads to a performance degradation and increasing memory occupation in case tcpdump is deployed in an environment where it “sees” many different IP addresses (i.e.: on a LAN with few hundreds or thousands of hosts, it is difficult to notice any performance degradation or anomalous memory usage). In addition, since this function is called each time an IP has to be printed (i.e.: it is triggered also in “non-verbose” mode), an attacker could easily exploit for a DoS-type attack it by sending packets that sweep the entire IP address space. Please note that since this function is used almost everywhere, the attacker is not limited to crafting source and/or destination IP, but he can play also with addresses embedded inside the packet (i.e.: RADIUS packets). In this way, he would obtain the following results:
We also did a quick check on the “getname6” function, and it also seems to be vulnerable (and in that case, with IPv6, only the sky is the limit for possible memory occupation :) ). We have also successfully developed a shell script (quick&dirty) that exploits the vulnerability: it simply sweeps the IPv4 address space by sending “arping” requests, causing tcpdump to steadily increase the memory usage, and thus CPU usage too. What we suggest in order to fix this vulnerability is:
We propose the following patch, that according to our tests resolves the issue (obviously, it has been developed in a quick&dirty way, so we may have missed something, and it has to be polished before submitting it to the repository). We look forward to receiving your feedback. Antonio Trapanese
|
I acknowledge this long-standing issue, it needs to be fixed eventually (whether in the suggested way or not). |
Converted from SourceForge issue 604464, submitted by nobody
hi,
while observing millions of mostly broken udp, tcp and
icmp payloads inside mostly broken ipv4 packets,
tcpdump-3.7.1 kept allocating more and more memory
until it had occupied a huge 244MB memory space.
my analysis is that there is some memory forgotten to
free in case of broken packets.
libpcap version 0.7.
regards,
-tom
The text was updated successfully, but these errors were encountered: