New DNS Software to Address Security Holes 80
Ben Galliart writes "The Internet Software Consortium released on Monday another patchlevel to their ever popular BIND software package. The ISC has recommended that everyone using BIND upgrade to this latest version (BIND v8.2.2 patchlevel 3) due to security holes existing in previous versions. If you are using a version previous to BIND 8.2.1 then pay special attention to the ISC configuration hints on a new required TTL setting which should be added to every zone file. More information on the TTL setting is also available in RFC 2038. On a side note, those who enjoy the bleeding edge should read the ISC future plans page which now has information on the thread-safe/multi-processor ready BIND version 9 (major rewrite) going beta in January. "
Daemon security in general (Score:4)
Each daemon is starting to add its own security (Cyrus IMAP has several options) and they aren't inter-compatible. If there were a common library they were based on, it could be improved upon by all parties involved.
Hate to point out one of the greatest benefits of open source -- shared library code that you can modify -- and also one we are bad at actually doing.
- Michael T. Babcock <homepage [linuxsupportline.com]>
Waaah! I want the alpha release, now! (Score:5)
Sure, it's not "prime time", yet! So? Give a bunch of computer phreaks the source, and they'll patch more bugs in a day than the entire BIND development team can find in a week. That's not to put the BIND team down, but a closed testbed network (typical for this kind of work) is not going to find bugs that'll crop up in the real world.
Re:Daemon security in general (Score:2)
This is going on in the OpenBSD community, but don't forget that because of stupid and worthless crypto-export laws and IP 'patents', developers and users in the US may not be able to use it.
Sucks if you're a developer or user in the US, but it doesn't seem to be holding OBSD people back any...
Your Working Boy,
NAMED-XFER has a bug in 8.2.2-P3 - fix enclosed. (Score:4)
- Strabo
The following change should correct
the problem.
Index: src/bin/named-xfer/named-xfer.c
===============================================
RCS file:
retrieving revision 8.88
retrieving revision 8.89
diff -c -r8.88 -r8.89
*** named-xfer.c 1999/11/08 23:01:39 8.88
--- named-xfer.c 1999/11/09 20:36:54 8.89
***************
*** 2195,2201 ****
zp->z_origin, zp_finish.z_serial);
}
soa_cnt++;
! if ((methode == ISIXFR) || (soa_cnt > 2)) {
return (result);
}
} else {
--- 2195,2201 ----
zp->z_origin, zp_finish.z_serial);
}
soa_cnt++;
! if ((methode == ISIXFR) || (soa_cnt >= 2)) {
return (result);
}
} else {
Negative Caching Info (Score:3)
Here's a useful chunk from the RFC:
"Negative caching" - the storage of knowledge that something does not
exist. We can store the knowledge that a record has a particular
value. We can also do the reverse, that is, to store the knowledge
that a record does not exist. It is the storage of knowledge that
something does not exist, cannot or does not give an answer that we
call negative caching.
What's now mandatory--
[RFC1034] provided a description of how to cache negative responses.
It however had a fundamental flaw in that it did not allow a name
server to hand out those cached responses to other resolvers, thereby
greatly reducing the effect of the caching. This document addresses
issues raise in the light of experience and replaces [RFC1034 Section
4.3.4].
Negative caching was an optional part of the DNS specification and
deals with the caching of the non-existence of an RRset [RFC2181] or
domain name.
Negative caching is useful as it reduces the response time for
negative answers. It also reduces the number of messages that have
to be sent between resolvers and name servers hence overall network
traffic. A large proportion of DNS traffic on the Internet could be
eliminated if all resolvers implemented negative caching. With this
in mind negative caching should no longer be seen as an optional part
of a DNS resolver.
HTH.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
What about the problems with the protocol itself? (Score:3)
If you need to point-and-click to administer a machine,
Bad, but not suprising. (Score:1)
This is very bad, but I don't think we should be suprised.
One of the *BSD project leaders said after the 4.9.? remote exploit that he doesn't trust the BIND code.
It's possible to run the name server in a chroot jail as a non-root user. That won't solve the DoS problems, but at least you won't get "owned".
Hmm... I had a URL with instructions but now I can't find it... Anyone have a link?
But is it Free? (Score:1)
Dents (Score:1)
Re:Daemon security in general (Score:2)
Now there -is- a definition for IPSec authentication, but for the machine as a whole. It doesn't work at a finer level than that.
Then, there are X.509 certificates, and SSL. Plenty of libraries, there, and certificates are easy enough to roll. Problem there is that it would require more extensive work on the part of the maintainers. It -would- be possible, though.
The question I'll ask is this - for the purpose of authentication, would it be sufficient to authenticate the machine, or would it be essential to authenticate the application?
If the former, then simply install IPSec or SKIP on all the machines that use daemons, and use IPSec/SKIP connections between those machines.
If the latter, get OpenSSL and modify the application to work through it.
No help from NSI (Score:3)
non-buggy software exports? (Score:1)
Elaboration (Score:3)
I'd like to see something along the lines of an authenticaed ident server as a necessary part of this protocol. It wouldn't be a daemon running (like ident) to identify callers, but the daemon (like BIND) connecting to the remote daemon would identify who it is (SSH2 style) and what machine it is running on (also SSH2 style).
Why identify both the machine and the daemon? Because a daemon could be loaded up by a (bad) user and run on a different port, linked against the authentication library and attempt to send bad data "out there" to other machines. In this way, the daemon itself would have identity information either created at compile-time (and linked in via header) or some other method. Of course, the daemon would have to be unreadable by anyone but root (or its own username), but that's ok, right?
Sending data over a secure connection works just fine if you don't want people snooping, but authenticating a daemon requires more than that. In the case of DNS, one of the big factors is authenticating that the DNS server you've connected to is indeed who it claims to be.
XNTP3 does this as well (in a basic form) if you want to create time peers that authenticate off each other.
RFC ideas anyone?
- Michael T. Babcock <homepage [linuxsupportline.com]>
A quick tidbit about NCACHE (Score:2)
1. The minimum TTL for that zone
2. The default TTL for records without one specified
3. The TTL of negative responses
#1 was never used, #2 is only relevant on the master server (since TTL is explicit during a zone transfer), and #3 is now the ONLY meaning for the SOA Minimum field.
What this means is that to fulfill #2 (default TTL), you will now have to add the $TTL directive to all zone files you are master of, and modify the SOA Minimum field to something more appropriate for the NCACHE TTL. Your zone file would look something like this:
; Example of $TTL and SOA
$ORIGIN whatever.org.
$TTL 86400 ; Default TTL (1 day)
@ IN SOA ns1.whatever.org. postmaster.whatever.org. (
1999111001 ; Serial
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
1800 ) ; NCACHE TTL (30 minutes)
These values are, of course, not set in stone - just an example. However, most people set their SOA Minimum field to somewhere around 1 day, give or take, to reduce load on queries to their server. This value is likely to be too high to cache NEGATIVE answers, so should probably be adjusted.
As for the $TTL directive, just add it before the SOA record, usually with whatever was the previous value for the SOA Minimum. If it is not designated, BIND will issue a warning, but will use the SOA minimum instead. Annoying to see all the warnings if you have a large number of zones, but it doesn't cause problems other than the logging:
Nov 10 12:15:12 thanatos named[14344]: Zone "whatever.org" (file whatever.org.db): No default TTL set using SOA minimum instead
This information only pertains to BIND 8.2.0 and above (including 8.2.2-P3, obviously).
- Strabo
Re:Negative Caching Info (Score:2)
This question isn't directed at you, but I'm curious...outside of posts to slashdot, or writing in general, does anyone actually use the term "grok" in conversation? I have yet to hear one person say it and I work with some serious geeks.
Re:Waaah! I want the alpha release, now! (Score:1)
Please forgive ISC for choosing a smaller, dedicated development group over a mass of chaotic hobbyist whiners. Don't take that as a flame. It's sarcasm.
Let them do the kickass job they always do and release a version when they're ready.
Re:Daemon security in general (Score:2)
"We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
Grok (Score:1)
Mishandled (Score:2)
Drop the daemon, come out with your hands up! (Score:3)
This is the FBI. We've recently gotten word of a new kind of internet protocol called 'dns'. We require that you immediately install backdoors into the protocol so we can secretly monitor all dns communication. It is not relevant that information in dns servers are publically available. This will be done at once. We will not provide assistance to you to do this. Thank you for your continued compliance.
Sorry.. given the proxmimity to the wiretapping article.. *somebody* had to do it! =)
--
Re:Negative Caching Info (Score:1)
Sure, I hear/use it all of the time. It is not a geek thing per se, but a sci-fi thing. Not all geeks are sci-fi fans, and not all sci-fi fans have read Stranger in a Strange Land, hence, the paucity of grok usage in your vicinity.
You grok?
grok is getting rare (Score:1)
Re:Negative Caching Info (Score:1)
Slashdot is great. You ask a question and it gets answered...and quickly too. I thought I was going to get flamed for asking a "stupid" question, so thanks to everyone who responded kindly.
Re:Daemon security in general (Score:2)
It's possible, but it's not trivial to do well. What you need to do is embed some kind of certificate within the application, in such a way that it is not practical for a third-party to extract it and embed it into another application.
Because the source for the application is going to be open, it will always be possible for a third-party to monitor what goes into and out from any decryption algorithm. This leaves two possibilities for protection:
Both these methods have strengths and weaknesses. They both rely on obscuring the security, by putting it in plain sight, which is great for Open Source code, but both can be defeated, so they're not perfect.
Re:Negative Caching Info (Score:2)
I'm curious...outside of posts to slashdot, or writing in general, does anyone actually use the term "grok" in conversation? I have yet to hear one person say it and I work with some serious geeks.
Oh yeah. I snarfed Win95 when it came out, and I've been glorkonzed ever since. Who could grok the sucker?
======
"Rex unto my cleeb, and thou shalt have everlasting blort." - Zorp 3:16
Re:Daemon security in general (Score:2)
That was the one of the two issues that came to mind after I thought about it.
1. With the source being open of course, someone with enough skill would be able to hack a fake daemon and replace the true one. This would still knock out most of the lil scrpt kiddies who like to play until someone came up with an easy to use root kit.
2. How do you handle authentication without making it too complicated to implement? This would certainly be easy for trusted sites but if that were the case you would use IPSEC and vpn the remote sites with you anyway.
guess it was just wishful thinking on my part
"We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
more Y2K zealots.. haha (Score:1)
Either that or they're really scamming some companys big time fixing this 'bug.'
In case people are confused about how others use dates in the serial number, it's just a little trick sys admins use so they can see when someone last updated the zone.. generally people use the YYYYMMDDR thing like it said.. the R is the number of times in the day that the zone file was updated. the only thing about doing this is that if you put '10' in R and then the next day you start at 1 again, the number will be smaller than the previous day, e.g. 1999032710 and 199903281.
I prefer the simple 'increment the number' way personally.
WILL NEVER WORK! (Score:2)
Just went to the LISA conf yesterday for a tutorial on BIND given by Vixie himself. He spent a bit on the logistical/technical issues DNSSec. Just a quick run down.
I have nameservers that can get well over a 1000 requests per second (not that they actually answer them all:). I'm not going to encrypt every response, it's just not that important. It is far more practical to use this as an internal security measure but for the internet - don't make me laugh.
Mirror (Score:1)
Re:Daemon security in general (Score:3)
You then pass the combined values over to the client, who XORs it with the same chunk of the same piece of compiled code. What's revealed is that fragment of the certificate.
This is, of course, a very trivial method. To get something more tamper-proof, you'd want to extract discontinuous pieces of the code & certificate, using some complex function to determine which bytes you wanted.
This would give you something that was sufficiently tamper-proof to resist script kiddies and novice crackers, whilst remaining very simple to implement.
The pseudo-code would look something like:
recv(client, random_gen_seed);
seed_generator(random_gen_seed);
for (i=0;i++;i offset = my_random_fn(i);
value = *(lib_ptr + offset) xor *(cert_ptr + offset);
*buffer++ = value;
}
xmit(client, buffer);
From here, you can add further complexity, to your heart's content, but this should offer you enough security to block trivial cracks.
what about microsoft dns? (Score:1)
PATCH downloadable (Score:1)
Possible to run BIND on arbitrary address/port? (Score:1)
I'd like to run two dns servers on the same machine, one for queries coming from the internet and the other for queries coming from the lan.
Yeah, I know. The "right" way to do it is to run the internal dns somewhere besides on the firewall, but I've got a scarcity of Unix boxen (read ONE).
Wondered if it was possible to configure BIND to bind to a specific address or port? Perhaps with tcpserver?
CERT informed, PATCH is out... (Score:1)
"ISC has discovered (or has been notified of) six bugs which can result in vulnerabilities of varying levels of severity in BIND as distributed by ISC. CERT has been notified of all of these issues."
Also, "In addition to fetching the bind-src tarball, you will need to fetch and apply the following patch. If you do not apply this patch, your zone transfers may fail."
- ftp://ftp.isc.org/isc/bind/src/8.2.2-P3/patch4
This is from:
http://www.isc.org/products/BIND/bind-security-
- Strabo
Re:Bad, but not suprising. (Score:1)
http://www.psionic.com/papers/dns/ [psionic.com]
Re:Daemon security in general (Score:2)
If a key is generated at compile-time, it can be stolen
./configure
make key
.oOo.oOo.oO...
src/keyfile.h completed
make all
make install
... tada
The idea I had was to have these keys actually signed by an external program (that uses the same authentication toolkit library) so that you can say, "yes, I trust these keys to be from the daemons at the root servers" and if you geet root server replies from anyone else, you ignore or negative cache that they're bad
- Michael T. Babcock <homepage [linuxsupportline.com]>
Re:Daemon security in general (Score:1)
Here is a possible protocol for an open-source program to authenticate itself.
This protocol does not work, because if you have the source code for the hashing function and a copy of the "real" binary, you can spoof the authenticator. Is there a solution?
If there is a kernel or library function that hashes the binary code of the calling process, it is possible. The hashing function could be open-source, but the compiled function would have to include an embedded constant known only to the authenticator.
I don't know how feasible that is. The idea is if you hacked the source of the hash function and recompiled, you would lose the embedded constant. Of course if you hack the original program, when you call the hash function it will return the wrong value.
Just some random thoughts.
Nathan Whitehead
Re:Daemon security in general (Score:2)
This is not a good idea in general.. as it slows inovation and really removes all the benifits of open source. The better approach is to simply desgn the protocolls so that it dose not matter if you hack the daemon. SSH is a perfect example. If I replace you sshd I can not obtain your password.. only your public key, which dose me no good and I could obtain anyway if I had access to replace the daemon.
Also, remember that the person running the blessed binary controls it's enviroment and jsut because I'm taling to a blessed binary dose not mean that it can not be tricked into doing something nasty. Example: write a fake X server and a fake libc network interface which interacts with your blessed netrek client to make it do ubernasty things, but if the protocoll had been designed with appropriate constraints this woud not matter. Generally, it is much harder or imossible to design a program to be secure in a hostile eniroment.. so just do all you sensitive stuf in a frendly enviroment.
Jeff
Re:No help from NSI (Score:2)
According to this story [cnet.com], MAPS threatened to put NSI on the RBL list because of the unsolicited email NSI was/(is?) sending to its domain registrants.
I think you've got your answer as to why NSI doesn't help with BIND. Buncha greedy bastards.
--
A host is a host from coast to coast...
Mmm... Vixie... (Score:1)
Wouldn't it be nice if... (Score:1)
Re:Mishandled (Score:2)
Re:But is it Free? (Score:1)
Re:WILL NEVER WORK! (Score:1)
Your parent zone. The root key signs the
> Meaningful encryption would push the 512 byte limit of dns udp packet to a much smaller payload, making the use of tcp for common dns activities necessary thereby tremendously reducing dns performance.
DNSSEC doesn't include encryption, only authentication. Yes, the 512 byte UDP limit is an issue, but there is a proposed solution (EDNS).
> Meaningful encryption would cause CPU load - period. Imagine the com root servers having to encrypt every answer. This would probably end up requiring an Origin 2000 and remember that 8.2.2 isn't able to take advantage of SMP.
Again, there is no encryption. Digital signatures are precomputed, so there's no additional CPU power required on root servers at runtime. Caching servers, which will verify DNSSEC signatures on incoming data, will require more CPU power.
There's no reason to encrypt DNS data - it's all public anyway. Authentication is far more important, so that connections can be made to a verifiably correct site.
Are you sure you listened to Paul Vixie's presentation?
Re:Does anyone here *actually* know anything? (Score:1)
It doesn't take a genius to look up IETF working group names.
BTW, there is only one 'Internet protocol' in the TCP/IP suite, I don't know of any 'supporting Internet protocols.' Perhaps you could enlighten us.
Recommendation: Don't be so smug. If you don't like it, move on.
Exporting bind... (Score:1)
Securing BIND/DNS (Score:1)
grok (Score:1)
#define X(x,y) x##y
Re:more Y2K zealots.. haha (Score:1)
In case people are confused about how others use dates in the serial number, it's just a little trick sys admins use so they can see when someone last updated the zone.. generally people use the YYYYMMDDR thing like it said.. the R is the number of times in the day that the zone file was updated. the only thing about doing this is that if you put '10' in R and then the next day you start at 1 again, the number will be smaller than the previous day, e.g. 1999032710 and 199903281.
Yeah, we use that scheme here, and I like it a lot. But you can actually use two digits for the increment, which gets around the problem you mention. That's what we do - YYYYMMDDRR. But then again, I've never seen RR get above 05.
Dave
Re:WILL NEVER WORK! (Score:2)
I envisioned (I thought clearly) something more along the "web of trust [linuxsupportline.com]" lines. Smaller ISPs have their keys signed by their larger ISPs (arranged somehow -- not too hard) and larger ISPs can do the same between each other for the sake of most protocols. This would be easier than what DNSSEC is going to require in some circumstances.
Since I envisioned a generic library for any type of daemon (with several options, of course, but one underlying security model), many of these systems don't have to be signed by many people at all -- security is desired, so those who want it arrange it.
I'm not sure what you're trying to say here. That if I encrypt data it grows? This isn't very true (except for the need for headers, etc.). If the stream is encrypted before being packaged (UDP, TCP), the encryption negotiation would be a packet or two every hour or so and the actual encrypted communications would be the same size, just encrypted. The only added data would be hashes for authentication.
You'd want to precompress (to a small degree) of course, seeing as compression is less CPU intensive (in some cases!) than encryption. You end up encrypting less data then and the hash is tacked on to that.
Again, I don't care if BIND can (currently) make use of SMP or not; my ideal would be it taking advantage of a library which itself could be SMP capable. I don't buy the CPU intesity argument though because with the exception of high end routers, most machines aren't processing enough data of the type discussed here for the encryption to be significant.
I may be wrong
For instance, consider a system where a new session key is negotiated by two time servers every hour. The encryption needs to be such that it can't be broken in under an hour or two (a week would be a nice goal here). Simple DES would be sufficient for most cases (although not necessarily best).
Of course, the whole point here is that I had not intended to fully flesh out how such a system would run. I do not consider myself fully capable of doing such without heavily referring to how others have already done it (ahem, patents).
Mind you, in the case of DNS and your mention of 1000 requests per second, I don't buy that convenience is more important than security in the long run. Computers are becoming much much faster every year. Put a pair of SMP Athlon 700's on a network to handle DNS and caching for a company where previously there were quad P-Pro 200's. Makes for a significant upgrade at about the same cost as the original investment but with significant head room, especially to handle the amount of encryption I'm talking about.
My concept of a good system for this would be to have multiple cyphers chosen based on the amount of data being sent to a given location (whether a "stream" can/will be held open to them) and the length of time needed for security.
I don't see a DNS packet needing to be authentic for more than an hour or so
SMTP and IMAP would need much stronger hashes to make sure E-mail was authentic (especially large companies who go to trial
I think it's "doable" and I'd love to see someone like NAI, SSH or Bruce S. fiddle with it seriously.
- Michael T. Babcock <homepage [linuxsupportline.com]>