|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2005-0877: dnsmasq cache poisoning&DoS | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Ludwig Nussel <lnussel> |
| Component: | Incidents | Assignee: | Security Team bot <security-team> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | CVE-2005-0877: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N) | ||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Ludwig Nussel
2005-04-04 12:12:08 UTC
The Buffer overflow does not exist in SUSE Linux 9.2 and I'll fix it for 9.3 The poisoning bug is very theoretical because you have to guess a 16Bit value in a very short time frame and the fix would make this a 48Bit value which is just harder to guess. I talked to the Author of dnsmasq about this and he has the same opinion, that this bug is not too important to fix for older versions (quote: "My opinion is that this is not a security hole that that needs a backport") So after talking to Ludwig, I'll fix the buffer overflow for 9.3 only. SM-Tracker-833 package for 9.3 submitted Can this bug actually be triggered? According to the patch you made it's a wrong length in fscanf (257 instead of 256). The file that is read is written by the daemon itself. AFAICS the same buffer of 257 chars is used also for creating the records that are later written to disk so the string read from the file can never be longer than 256 characters. I did not look too close to the fix but I got it directly from the author. The buffer overflow is documented as "The buffer overflows might allow an attacker on the local network to crash Dnsmasq upon restart." so I think it can be triggered somehow but I don't have an exploit at hand. The cache poisoning attack can be executed very easily and the time-window can be increased by the attacker by stopping the queried DNS to answer. The poisoning can be done from remote, right? I would suggest to include this patch as part of our distributed package. (Even if the new solution is not perfect but the best for the environment and purpose of dnsmasq.) > The cache poisoning attack can be executed very easily and the time-window
> can be increased by the attacker by stopping the queried DNS to answer.
how can an attacker stop the queried DNS to answer?
And without sniffing the network, how can the poisoning be done very easily?
I don't see this but maybe I overlooked something.
You can stop or slow down the queried DNS server by overloading it with lots of recursive queries or by using one of the various ordinary denial-of-service techniques. The attacker only needs to send a continues stream of packets (2^15 on average) till he hits the right transaction ID. There is not much effort needed. Just a bit of time and luck. If I assume a target bandwidth of 100 KByte/s and a DNS response package size of about 300 bytes the attacker needs less then 100 seconds to send all 2^15 packages. The bar for making this attack happen is too low in versions prior 2.22 to make me feel comfortable. okay, I saw that scenario too but I did not think it has a practical relevance for an environment where dnsmasq is used. Just out of curiosity. Don't we have a problem with nearly all nameservers then? Including the resolver of the glibc? AFAIK at least bind 9.2.1 uses 16Bit query IDs to protect himself against spoofed answers. But I don't know if they changed it after 9.2.1 16bit is the standardized size for the transaction ID. If other solutions only make use of the ID they have the same problem. They should use a random port which doubles the bits to guess. so: 100 sec * 2^15 about 38 days. :) AFAIK BIND does so. oh.. * 2^16 I think. 76 days therefore. can't one scan for an open UDP port instead of sending all packages to all ports? An UDP package to a closed port should send an ICMP package doesn't it? Anyway. I think for the version on 9.3 (2.20) it's possible to port the poisoning fix but for 2.13 on the 9.2 it might be a little bit too much what do you think? But I still have the opinion, that the fix is not necessary for the environment where dnsmasq is used (answers queries only to a small local network and the ISP dns has to be knocked down to poison the cache) but I'm not a security guy as you can see :) - scanning may be more expensive because:
+ sending a 300 byte DNS package with poisoning data to an port seems
faster then just sending an arbitrary UDP packet, waiting for an response,
evaluate it, an then send the DNS poisoning package
Every query gets its own random port. dnsmasq seems to use a fixed port for
this (32851/UDP).
- I do not know if it is much work to backport the patch. Please ask the PM
for a version upgrade if you think it's too much.
- The attack is too easy to accomplish and is therefore even dangerous for
home users. Think about all the man-in-the-middle attacks possible with
SSL and SSH. :(
Scanning: If you limit the attack to just open UDP ports it may be faster. That is right. aj already said ok to the version update so lets just do it. version update for 9.2 and 9.3 in /work/src/done/... Thank you Uwe. I'll handle the patchinfo files and a like. /work/src/done/PATCHINFO/dnsmasq.patch.box CAN-2005-0876 CAN-2005-0877 packages released CVE-2005-0877: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N) |