On Thu, 2002-07-04 at 08:49, Reckhard, Tobias wrote:
if set in resolv.conf to 127.0.0.1 and in named.conf recursion no; it should be fine ? afaik the problem is that querries on > bind8 is answered from the resolver libs and bind9 only answers from cache ?
Disclaimer: I've got all of the following from the DNS mailing list, none of it is my own (except the wording). However, the sources are pretty much experts at DNS (and coding).
The problem lies in the resolver libs. That's where it should be fixed. The current BIND resolver lib vulnerability is triggered by perfectly fine DNS datagrams. If an intermediate party between the attacker's DNS server and the target, such as a DNS proxy, reconstructs answers instead of just piping them through unmodified, then the attacker just needs to analyse that party's behaviour and modify his attack payload accordingly. This sounds a little complicated, I'll try to clarify.
The attacker knows that payload A will root the target. If the target contacts his DNS server directly, he simply sends it A and is done.
If the target accesses the DNS server through a 'constructing' DNS proxy, the attacker needs to find out how the proxy constructs packets, pick a payload B that will root the target (this may be A, but must be different, if the proxy will never construct A) and reverse the construction process to get B'.
So the use of a DNS proxy doesn't really solve the problem. Updating the buggy libraries does.
Cheers Tobias
thanks Tobias, i am still unclear as to the possibility of exploiting bind9 if recursion is limited/not allowed afaik the overflow occurs at two of the variable parsers used by the resolver libs. and also afaik bind9 answers from cache anyway. the reason i am sceptical at this stage is one of my production boxen running only (SuSE) patched apache and bind9 (80 & 53) has been r00ted. everything has been "sanitized" and i picked it up from offsite md5 hash of some binaries (eg. netstat, ps, etc.) box is offline but there's nothing much to look at, i have what i think is the originating ip and according to the isp involved there is no cli info available for the dialup (it is subbed to a third party). there was no local access to the box (ps2 keyboard connector physically removed & good security at the datacenter) therefore there are two routes into this box. throught apache & webapps or through bind9. the webapps are filtering all input and apache was patched. so i am looking at the resolver libs wich aren't used by bind9, to answer requests, yet i have some deleted logs full of DPT=53 (where i got the dialup ip from) i am redoing this box from clean media but still don't know how it was broken and essenrially it will go in with exactly the same binaries b4 the attack, suppose i could run a passive snort on the same subnet and wait for my "friend" to return... but it would be so much easier if there were another solution. ideas anyone ? tia andre