Slashdot Mirror
Bind 4 and 8 Vulnerabilities
eecue writes "The world's most popular DNS package is once again vulnerable. Even the advisory says it's only a matter of time before worms are written.... just like a couple years ago. I guess this is why i run tinydns."
Escape your binds, use djbdns.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Does TinyDNS support internal and external views? By this I mean, can it return a different IP for the host "foo.my.com" based on what subnet a client is connecting from (e.g., return 192.168.10.11 for all clients in 192.168.* and return 4.3.17.45 for all clients outside of that)? If so, I will switch. If not, I need that function of Bind 9.
MORTAR COMBAT!
All hail djbdns! ... now if we could only convinve djb to loosen some licensing issues.
Use BIND 9. It works, it's secure, it supports DNSSEC, and doesn't have the bizantine architecture (read: clusterfuck) of tinydns.
Alternatively, you could update to the latest version of BIND.
From the advisory:
"BIND 9 was not affected by any of the vulnerabilities described in this advisory."
linx pro has more information on the exploit, including patches to fix it.
Does MS fix their vulnerabilities that fast? Judging by the number of klez variants in my inbox, I'd say "no".
And I guess this is why I run BIND 9...
Yeah don't most people run Bind 9 these days? My Redhat 7.1 and 7.3 servers are both at bind-9.2.1.
This is why I run MaraDNS.
:wq
http://www.isc.org/products/BIND does NOT have the updated versions (4.9.11, 8.2.7, 8.3.4) that addresses these security issues posted yet (as of 1:16 CST). Perhaps slashdot should update the story once the tarballs become available.
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d? s: a-- C++++ UL++++ P++ L+++ E- W++ N o-- K- w--- O- M+ V PS+ P
Come on, Bind 9 has been out for some time, so don't flip out!
It was pointed out on the nylug-talk list that the advisory doesn't seem to include any info about whether nominum, paul vixie, or the ISC was notified about the bug.
Does anyone know if ISS did the right thing, or are they being big doo-doo-heads?
-Peter
== Just my opinion(s)
uhm. you know there's more to do for a DNS server? Like reverse lookups? MX lookups? ......?
Not that easy as you might think! But - why didn't you write a fast, secure, simply ideal DNS server?
[] Most smaller networks don't need a large (and dare I say buggy) installation of BIND.
[] May I suggest djbdns rather than BIND? Its creator says "every step of the design and implementation has been carefully evaluated from a security perspective. The djbdns package has been structured to minimize the complexity of security-critical code. dnscache is immune to cache poisoning. It is advisable to use the package as a secure alternative to BIND."
[] May I suggest Dnsmasq , which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".
If you celebrate Xmas, befriend me (538
Frankly, anyone still using BIND 4 deserves to get rooted.
Anyone still running BIND 8 should be given a good slap and told to upgrade.
Anyone running BIND 9, well done.
It's not surprising that bind 4 and 8 have the same vulnerabilities - they're based on the same code base, after all. Bind 9 was 100% rewritten, is modular, and actually *checks its inputs*, avoiding buffer overruns and such.
It uses RFC-specified zone file format, it's extremely functional (internal/external views of DNS based on query source, TSIG authenticated DNS transactions, DNSSEC authenticated DNS records).
In the couple of years the bind 9 code has been out there, the only vulnerabilities it's had caused the server to shut itself down immediately, as it realised something was wrong with its input. That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.
The potential for a passive worm is actually fairly high, given that the exploit needs to come in response to a DNS query: The worm infects a DNS server, and waits for queries. It responds to those queries from other DNS servers by attempting to infect them.
The nasty parts: Enough people dual-use their DNS servers (serving as both authoritative master for outside and for their own lookups) that you could get lots of authoritative masters. It also does NOT scan.
It could be made even stealtier if the exploit, on failure, would still function. On success, it of course functions normally. This might be harder, but, if so, it would be really REALLY hard to detect such a worm.
It would take a bit of writing to get right, so there is a good window in which to patch your machines. So patch SOON.
Test your net with Netalyzr
BIND 8.3.3 is the latest version of ISC BIND 8. We strongly recommend that you upgrade to BIND 9.2.1 or, if that is not immediately possible, to BIND 8.3.2 due to certain security vulnerabilities in previous versions. 8.3.3 contains a security fix in libbind. If you have BIND 8.x you need to upgrade.
"I guess this is why i run tinydns."
BIND 9 has been available for TWO YEARS, Troll.
- Free
- Secure
Choose one.
If you celebrate Xmas, befriend me (538
...sun rises in the East.
Just old versions of bind,
Bind 4.x and 8.x are vulnerable to this.
Version 9, which is a complete rewrite from scratch
and the version that everyone running bind should be using,
does not suffer this security flaw.
Slashdot editors should take an extra care when posting
news like this to avoid FUD and unnecessary panic.
Answer: OpenBSD See subsection 6.8.3.1
and read this for why
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
According to the article, exploiting these bugs will terminate the DNS. There's no mention of being able to infect the server. I'm not sure why the article mentions worms, other than the possibility of h4x0red Win boxes pounding on the bug.
One line blog. I hear that they're called Twitters now.
For me, it is not really an option to use a tinydns or any other DNS solution other than BIND. Upgrading to BIND9 is not really an option for me either. I work for a large multinational, and we have a lot of UNIX servers (Sun, IBM, and HP in terms of numbers). I get hardware and software support direct from the manufacturer, and if I install an application, or a version of an application that my vendor does not support, I am on my own. These 24-7 support contracts are important to us in being able to sell our services and maintaining our SLA's and availability targets. Those issues aside, I do not want to have to explain to the PHBs that we cannot get support on a particular problem because the application in question is not supported by Sun, or that IBM only supports version 3.4 and we run version 4.0.
So, it is all well and good if someone out there has the choice to install some other software, but keep in mind that it is not necessarily an option for everyone...
*** Where are we going? And what's with this handbasket?
anyone else find the djbdns user community arrogant and unhelpful in the extreme? they use djbdns because they don't know better, but soon the licensing issues they care so little about will come and bite them in the ass
Another vulnerability has been found in Microsoft Windows 98...
I take that comment to imply: "Windows 98 Second Edition is too old to be supported; all users of Windows 98 Second Edition should upgrade to Windows XP Home Edition." The problem with upgrading from one major version of a product to the next just to fix a bug is that newer major versions will often drop useful features that an older version had. For instance, Windows XP Home Edition loses Windows 98's competent support for running proprietary applications designed for MS-DOS. In addition, XP Home loses the ability to run acceptably on a 133 MHz machine with 32 MB of RAM.
Does BIND 9 drop major features or require more hardware for a given level of service vs. BIND 8?
Will I retire or break 10K?
like many things posted here about security is actually about advertising? Right now, I have a feeling that this is not about talking about old versions of bind, but about pushing tinydns. After looking at the notice, that felt like ads for ISS. More so, since readint what the moron from ISS said in australia.
edit: damn.
Bind 9.2.1 has been out for a while. If you haven't upgraded yet consider letting someone who does know run your nameservers...
Most important of all, involve someone higher up at management, preferably puting them on the cc: of the mail you send. If you are responsible for the box, it is your ass on the line if things go wrong. By involving them, you put more pressure on the vendor. Be proactive, pass the problem to your vendor, rather than try to justify yourself when the inevitable happens.
Mother is the best bet and don't let Satan draw you too fast.
http://developers.slashdot.org/comments.pl?sid=424 88&cid=4465167
AIRLACE claims to have maintained the BIND code base for a year. I bet she did it.
http://www.nimh.org/code/ldapdns/
http://developers.slashdot.org/comments.pl?sid=424 88&cid=4465167
The DJBDNS community gives excellent help. There policy is that you don't mung files. If you do then they will be grasping at straws and that doesn't do anybody any good.
Well?
Two of the attacks are DoS: You crash the server, end of story. One, the buffer overflow, can potentially execute code.
The only "gotcha" in that exploit is that an attacker needs to control a DNS server which the victim DNS server queries. Thus it is a passive attack, the victim must query you, not the other way around.
That is why the attacker uses a passive worm: The worm infects a DNS server, which in addition to being the local DNS server, serves as the authoritative master DNS server for some domains. When another DNS server queries the infected authoritative master, the authoritative master's response is designed to compromise the requesting server.
This compromise is followed by a transfer of the worm code itself, and now the victimized server is now infected as well.
As I said, this doesn't scan, which makes it particularly nice and stealthy.
You could also make an active scanning worm as follow: There are 2 kinds of nodes, authoritative DNS servers and other DNS servers. If you infect an authoritative DNS server, the worm knows it. Otherwise, it knows the authoritative DNS server it was infected from.
The worm "scans" by sending DNS queries (ideally with forged from addresses) which will trigger a lookup from the known corrupted authoritative server. This can then go through the net, rather noisily, and infect all servers which accept remote queries. This process can be sped up considerably by looking through the local cache for a list of all DNS servers that the corrupted machine knows about. Rough guess? Less than an hour to infect everything which can listen to the net, and you still have the passive attack to get DNS machines behind firewalls etc.
The fortunate thing: Although the possible worms are either very fast (lots of vulnerable machines, topological speedup from using the cache) or very stealthy (no scanning at all, a contageon strategy), both techniques require a fair amount of BIND specific programming to develop and release: You need to not only craft the exploit, but keep bind running and transmit the exploit.
So no kiddiot can simply drop exploit code into scalper.c and get it to work, instead there is a considerable amount of programming needed. So we do have a significant time window to patch machines, but they do need to be patched because it is a very "worm friendly" exploit pattern.
Test your net with Netalyzr
BIND - serving remote shells since 1986 ;)
Knowing that this might be a vulnerability issue, I immediately logged into my main servers and typed, in each, "up2date -du --tmpdir=/home/tmpdir".
Before I even realized that this doesn't apply to me, (I'm using Bind 9) all the updates had been downloaded and applied.
And, I guess, in a week or so, I'll get an email from Red Hat letting me know that I should be running up2date again...
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
http://developers.slashdot.org/comments.pl?sid=424 88&cid=4465167
Used to run Bind9, but BIND seems to be suffering from the Microsoft bloat phenomenon. How many megs do you need for serving up DNS?? The BIND 9 decompressed tar file comes out to 2100+ files at 21MB. If I recall the installation process, it took forever to compile and then loaded the system with a bunch of superfluous directories and files. For more complicated installations with more exotic requirements than I have, maybe I can see using BIND9, but for my wimpy little web server that has maybe two or three A records to its name, there's no point, so I use djbdns.
-R
Well, he is actually very smart, however, his licensing schemes are questionable. Someone has said it before and I will say it again:
"Change the BIND license to something non-BSD and wait for the OpenBSD crew to yank it from their source and write something more secure"
BIND 9 is slower than BIND 8, because it does a more correct job, but it's not significantly slower for most applications. If you are running a root name server, you will have to buy bigger iron. If you are running a corporate nameserver, you probably won't. For home use, BIND 9 will perform nicely on a 486 (I run it on a Soekris board, for example).
BIND 9 is also not bug-for-bug compatible with BIND 8, so there are some things you can do in BIND 8 that are broken, that you can't do in BIND 9. So upgrading can require some rework if you happen to have unwittingly tripped over those bugs.
On the other hand, BIND 9 is a complete, ground-up rewrite of BIND. It works better, is easier to use, and because of the strict practices that were followed in implementation, is much more reliable.
BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.
(I used to work for the ISC, so you might think I'm biased, but I wasn't involved with the ISC BIND project, so it's more that I got to look on while they did it, and was there to see some of the design work they did to make it more reliable, I know the engineers who did it, and I really think they did a great job.)
With all of the security news lately, I am too scared to run Apache, IIS, Exchange, lpr, lprng, mySQL, PostgreSQL, Outlook, Outlook Express, map Netware drives to Win 9x clients, X11, use any program that requires glibc, or use BIND 4 or 8 or any DNS for that matter. My computer sits in a locked closet, lacks input devices, and runs only the OpenBSD kernel and nothing else.
The BIND maintainers are ISC. ISS notified ISC a long time ago. ISC chose when it would notify WHICH vendors WHEN.
I like MyDNS - http://mydns.bboy.net/ - serves records directly from a MySQL database, and easy to set up and manage.
;)
0.9.5 (development copy at http://mydns.bboy.net/beta/) also supports PostgreSQL.
Of course, I am biased.
66.35.250.150 slashdot
However, he is also QUITE clear. Source patches are fine. Of any sort.
Has Bernstein put permission to redistribute any patches against djbdns in writing? If so, then the license becomes roughly equivalent to the Trolltech QPL.
if something works like this, why do you need to be able to redistribute anything more than patches?
What about for porting the program to operating systems that don't fit Bernstein's idea of how the directory structure should be laid out, such as Windows 2000 Server or Windows .NET Enterprise Server?
Install buggy BIND
Buggy? At least the vulnerability mentioned in the article does not affect most recent version of BIND 9.x.
Will I retire or break 10K?
Besides, the project has not been updated because there is no need. djbdns just works. If you need more functionality than the stock package provides, there are several patches. I know because I wrote (and publish) one.
The rest of your "arguments" I will not go into because they rely on flawed assumptions.
I was running tinydns on my home computers and the servers I maintain at work, but I was getting frustrated with the locations of the files and the use of non standards services. Note that this is my opinion and I understand that other people may want to continue using it.
/package /command /service /etc/dnscachex /var/spool/djbdns /var/spool/mail/dnsc* /etc/dnsroots.global
/etc/inittab
/usr/local/bin
But in case your installed it on your system in the "standard" location (/usr/local) (Note: I used dnscache and dnsclog as the users to create), here is a little script to "wipe" it (remember to have bind ready to take over after you kill the sv processes remaining).
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -f
rm -f
perl -pi.old -e 's%^(SV:123456:respawn:/command/svscanboot)%#$1%'
userdel dnscache
userdel dnsclog
cd
foreach i (fghack pgrphack readproctitle supervise svc svok svs* envdir envuidgi
d multilog setlock setuidgid softlimit tai64n* axfr* dns* pickdns* random-ip rbl
dns* tinydns* walldns*)
rm -f $i
end
Hope this helps,
-- M
-- Martial MICHEL
Is it just me or there have beemr ecently a flood of people whoring Gentoo. Seems suspicios since noone I know perosnally or proffesionally runs it. And no I dojnt run Gentoo coz I'm located in Russia and d/l every package in source form over 33.6 is not much fun.
US-UK-Israel: The real Axis of Evil
Another option, if one does not need recursive caching is posadis. There is also pdnsd, which only provides recursive DNS service.
Security history of various DNS servers:
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
You're messed up. Read this
"Just wanted to let you guys know that the review will be back up soon. We recently went through a new formatting standard, and work is being done to get the review to conform to that standard."
I wasn't messed up, I referred to that particular passage.
I'll have to set this up and try it. Thanks for the info.
MORTAR COMBAT!
This package is full of crap and you need daemontools installed. And as always, all crap made by D. J. Bernstein is unmaintained and can't be modified.
Note: I'm not making any claims about how the djbdns license is written; merely that since it doesn't include the right to modify and re-distribute, it is not completely free. In practice Bernstein may be good about accepting patches and incorporating them into the main trunk of the code.
Unlimited growth == Cancer.
Way to go IIS!! You keep on releasing SECURITY WARNINGS without notify the package maintainers! This shows the absoulute non-thinking-mentality that runs that company. I guess this is why people point and laugh at you guys and use more reliable sources such as BugTraq / SecurityFocus.
I have to ask... You already put one foot in your grave.. Could this be the other foot??
And honestly.. How much is Microsoft paying you guys to do this?? You must be getting some really big kick backs for pulling stunts like this?
Nite Nite IIS.. I'll be sleeping a lot better than you will tonight.
Actually, it's more the other way 'round. People like to blame things on Sendmail. Usually people who haven't looked at it years, if it all. Would you blame the 2.[45] Linux kernels for 1.0's lack of support for fireware or USB.
Neither Sendmail.org nor Sendmail, Inc has a long history of being vulnerable. Commercial OSes have a history of running old Sendmail5.65 distros. Sendmail.org, on the other hand, has a history of being blamed for vulnerabilities it neither caused nor can be responsible for fixing.
It has a history of Slashdolts making ignorant critiques like yours: Sendmail doesn't complain problem about group-readable /usr; it complains about group-WRITABLE /usr. It does complain about group-readable authentication databases.
Show us an option that Sendmail should code around. One that actually exists, I mean! You'll find that (a) satisfying Sendmail without DontBlameSendmail will be more secure and (b) the circumstances are the choice of the OS distro or the installation's Sys Admin (and likely an oversight).
One of the least appreciated strengths of the internet is its diversity. MS Office (macro viruses) and MS Outlook (all the other viruses) are great examples of how dangerous a homgenous environment can be - and so is BIND.
The logical conclusion is that we should all actively explore and support alternative solutions, and luckily the internet community seems to enjoy doing this anyway. I use MaraDNS - a simple, secure, open-source, well supported, low overhead authoritative and caching name server that does zone transfers (with a crap website, unfortunately).
So if you aren't hogtied by corporate policy, try an alternative - increase diversity - strengthen the internet. Just don't all switch to MaraDNS...
Brian: You don't need to follow me! You're all individuals!
Crowd (together): Yes! We're all individuals!
Individual: I'm not.
if your named was running in a chroot jail to begin with. Like, say, OpenBSD's. The more vulnerabilities I see published, the more I see the truth in what Bruce Schneier was talking about when he noted that total security can not be achieved, and the the goal of developers should instead be software and systems that fail gracefully.
Running your daemons with restricted privs, in a chroot jail, is a great example of software that fails gracefully.
illum oportet crescere me autem minui
...who runs BIND as "root" and doesn't jail it.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
First: There are probably still thousands of people are still running oder versions so this announcement is vitally important to some.
/. editors stop spreading FUD and panic about Windows software problems too. But if they're going to do it for one, it had better be for both!
Second: When any flaw in any version of any Windows software older that the latest and greatest has a flaw, it is flailed mercelessly on this very site. And now you're saying we should just ignore the same situation with Unix?
I dream of a day that
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
djb's license leaves a lot to be desired See the linuxmafia djb FAQ for details.
That site goes into much more extensive detail and says it better than I can here.
It is as if djb thinks white space is a non-renewable resource.
HINT: Strange code style makes it harder to review for correctness.
PROBLEM: Bind is no great pile of wonderful code either.
If you ever have the unfortunate situation of disagreeing with djb, you know what I mean. Find a flaw and djb will argue with you until you give up in disgust.
Yes: tinydns has flaws, but djb will argue that his code is the way things should work and it is the other hosts that have problems.
HINT: What good is it to offer a reward for finding a bug when all you get is an argument in return?
I'll refer you back to his distribution controlling licenses for another example.
And if you EVER invent an algorithm, implement an idea, distribute code that djb things was his original idea
HINT: If you are not willing to be an djb-acolyte, then you might as well forget it.
It seems that ever since his US DoJ lawsuit, djb feels free to wield his lawyer stick to anyone who dares editorialize on his activity. I see that the linuxmafia folks have encounters his legalistic zeal as well.
dbj: You demonstrate that you have the ability to contribute to others very well. I only wish you were less controlling, open to constructive comments and easier to collaborate with ... you
and others would benefit from a more
gentle and less caustic approach to
dealing with others.
"in the first place, sendmail should be
secure regardless of the filesystem permissions"
Did you?
In the free world the media isn't government run; the government is media run.
I would love to upgrade our internal DNSs to BIND9, but we use the "rrset-order" option quite heavily. BIND9 doco says this is still not supported...
ln -s
You say the djbdns "license" is "more restrictive" than Microsoft's "shared source license".
You don't know what you're talking about. Dan Bernstein does not allow you to redistribute FORKS of djbdns. You are very explicitly allowed, in perpetuity, regardless of what Dan says next year, to redistribute djbdns source tarballs with a specific MD5 checksum. Obviously, you are also allowed to publish patches and detailed vulnerability reports. You're simply not allowed to distribute adulterated source code or your own "fixed" binaries.
This is of course a moot point. There has never been a published vulnerability in the qmail or djbdns codebase. qmail is one of the most widely used MTAs on the Internet. The incentive to find vulnerabilities is huge. Bernstein's methodology is correct and his understanding of the Unix secure coding problem is complete.
You say that there hasn't been a djbdns release since last year and offer that as evidence that djbdns is going "stale".
You don't know what you're talking about. There hasn't been a new qmail release in years. qmail remains one of the most popular MTAs on the Internet, contending seriously only with the diminishing Sendmail hegemony and Microsoft's products. There are no new qmail releases because qmail is complete, hasn't had any security problems, and does virtually everything anyone wants an MTA to do. There hasn't been a new djbdns release because djbdns is complete, hasn't had any security problems, and does virtually everything anyone wants a DNS server to do.
see subject
Comment removed based on user account deletion
You really, really suck, Eric Krout.
Unless they changed the headline between the time you posted and the time I read it, they did take care in posting. The headline as I read it is "Bind 4 and 8 Vulnerabilities"
The asstalkers are an ancient indian tribe who helped us win the Vietnam War by speaking their sacred language, asstalkian. The Vietnamese could not crack the asstalk code, so that is how we one the war. There is a movie coming out to tell the story of the indians' struggle. It is called "The Asstalkers."
So patch SOON.
First we need a patch, and one that still loads our zone files, please.
Some BIND 8 security updates tightend some security-unrelated consistency checks, too, making upgrades suprisingly hard. After such experiences, nobody rushes to make updates, unless absolutely forced to.
Though, do you like to use a not-maintained package? When was the last date it was updated? How are you going to stay in touch with current technologies if the package is not being maintained ?
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
Comment removed based on user account deletion
Just like the Apache vulnerability release the ISS team failed to contact the maintainers about the vulnerability to get a proper patch released. This is horrible behaviour and it endangers everyone. Most say this recent behavior is due to the fact that M$ is in bed with ISS and their 'x-force'. They seem to target open source projects and then issue statements denying that there are 'responsible contacts' since it's not an actual firm or corporation. Just another tool to cause fear and uncertainty in the open source world in the name of security. While ISS didn't release the full details of the exploit they released enough. Anyone with half a brain can figure out how to turn this exploit into a deadly worm. I'd give it a few weeks before we see the first few attempts.
You are my hero.
Afterthought: The right to fork is such a fundamental assumption of the open-source model that it's easy to forget other vital reasons for it, beyond just the code being maintainable after its owner decides to quit. I posted before thinking of those.
When we say something is "open source", we're also implying the right to create derivative works descended from that codebase. E.g., the most important long-term fact about the Berkeley NET2, 4.4BSD, 4.4BSD-Lite, and 4.4BSD-Lite2 releases is that we got 386BSD, and then {Free|Net|Open}BSD from them. Had the U.C. Berkeley Computer Science Research Group used a Bernstein-style no-forking-allowed licence, there would have been none of those things: Their creation would have been illegal.
So, I think if you mull over your assertion that you "don't think that [a right to fork] is necessary for something to be free (as in GNU free)", you'll see that this right actually is absolutely vital and essential to the very concept.
Rick Moen
rick@linuxmafia.com
"The world's most popular DNS package is once again vulnerable."
This is the scariest part of the security mentality. Whenever a flaw is discovered everyone freaks and says 'oh, now I'm vulnerable!' until a patch is distributed and 'Phew! Now I'm safe again."
This is not the right way to look at it. The flaw was there for years, and you were vulnerable to everyone who found it before a whitehat did. What's more, you're *still* vulnerable to every flaw that hasn't yet made it to slashdot's pages, but will in coming months and years.
Choosing a platform that reacts quickly to patch discovered flaws means only that you're safer from attacks from those people who read the same sources you do, and quickly move to exploit the published vulnerabilities before you can patch them.
The fact is that it's rarely known how many people discovered a vulnerability before it was made public, and so if you rely on a system that requires frequent hotfixes, however quickly the vendor may react, you are still succeptable to the countless holes that have already been discovered, but not by the good guys.
The morals of this argument are that it's better to use a system that doesn't have as many holes, to one that patches them 'instantly,' and that unless another vulnerability is never discovered in your platform, you're vulnerable to attack today, and always have been.
Kevin Fox
So write RFC complient zone files.
While stile quite alpha, the latest snapshot of BIND 9.3.0 (in ftp://ftp.isc.org/isc/bind9/snapshots) does contain _partial_ support for rrset-order (cyclic and random orders).
Probably best not to run it in a production environment, though.
-Frysco!
We don't like spammers, troll, and krapflooders here. Go to hell and die, E r i c.
I read that submission and thought "Oh My God! Time to upgrade BIND to 8.3.whatsit! I'll quick pop over to CERT and see what's up..." No mention of anything at CERT. Then I re-read ISS's stuff more carefully and see that ISS just lost all credibility with me. They're talking about a vulnerability in an ANCIENT version of BIND! I've been on BIND 9 since late 2001, and they mention this archaic falderol about BIND 8.3.3 in an urgent-sounding November 12th 2002 press release. Wankers. Fool me once, shame on me uh, er, we won't be fooled again! Someone please hack their site and post some twisted porn on their front page.
Comment removed based on user account deletion
``How many root nameservers run DJBDNS?'' None at the moment. Of course, none of them run BIND 9 either.
Funny how the BIND proponents say that BIND 8 and BIND 9 are completely different products when we're talking about security, but then suddenly forget the version number when we're talking about deployment.
NSD is a good alternative,
an authoratative only, high performance, simple and open source name server.
http://www.nlnetlabs.nl/nsd/
Of course, we have already proved that tinydns contains exactly zero vulnerabilities..... :p
Like any other large product, it has evolved and continues to this day with its latest version. Like it or not, BIND has proven itself reliable enough for the likes of government, military, mega corporations to stake their electronic presence on. My point is simply that DJBDNS has not.
Most of the comments I'm reading in this thread seem to have a decided lack of sight of 'the big picture'. It seems as if most of the proponants of your product(s) are the weekend cowboy type; running a personal DNS server for their home or SOHO LAN. Then again, what should I expect from an online forum, right?
So, considering 'the big picture' (ie; hundreds of hosted domains, secure zone updates for a plethora of alternate name servers, scalability (the ability to double or triple in size without a major restructuring), and standards compliance) - convince me. Which part of your website and/or documentation shows me why I should reccomend DJBDNS over BIND for an enterprise client.
BD Phone Home!
Shameless plug. Like you weren't expecting it.
The site www.lycos.com is running Microsoft-IIS/5.0 on Windows 2000.
It would seem that not every enterprise is able to pick the right tool for the right job.
This is unfortunate, as it would otherwise render your attempt at culling a tacit endorsement from these organisations in terms of their use of your software legitimate.
// -- http://www.BRAD-X.com/ --
www.lycos.com is the web server. The DNS servers are running djbdns. You're also wrong when you claim that this endorsement was ``tacit''; the administrator sent a testimonial to the mailing list three months ago.
When DJB's qmail and djbdns products are distributed in compiled and working form with major Linux distributions, I might look at them again. However, I haven't seen that.
qmail in particular, in my opinion, suffers from the need to apply over a dozen "unofficial" patches to make it do the wonderful things people associate with it.
DJB's refusal to allow distribution of anything but unpatched source tarballs keeps his tools out of the hands of a lot of people, pushing them to use BIND, Sendmail, postfix, and all these other "less secure" or "less perfect" options. I can see where djbdns would be the perfect default DNS for Linux distributions... if the license allowed it.
Maybe the solution would be for someone to develop RPMs that include the official DJB source tarballs, all the best patches, and a script to apply the patches, then compile and install the result? B-)
Use of BIND 4 and BIND 8 is deprecated. BIND 9 was rewritten from scratch because the BIND 4/8 code is so badly written, and is therefore full of undiscovered vulnerabilities.
Would it be news if a vulnerability were discovered in sendmail 2 or 4? Or in Linux 1.2? Everyone running BIND 4 or 8 should upgrade to 9, unless (like OpenBSD) they have performed their own security audit and code rewrite.
You're missing the point - it's fixed fairly quickly, but the main problem is it wasn't detected quickly.
The stupid OSS fallacy that many eyes finds bugs is especially false for security bugs.
If it were true, just get a bunch of insects to look at the code.
A single skilled eye beats a billion dumb ones.
Closed source can be just as secure.
The only trouble is when the skilled eyes aren't given enough time to to look at stuff or write stuff securely in the first place.
This could still happen to opensource software.
Actually, that was part of the point I was trying to make, you just put it into words properly. :-)
Or support zone transfers rather than telling to go away and rsync your gibberish-zone-files behind the scenes.
Tim, to clarify, Prof. Bernstein talks about rsync/ssh or scp just as examples of alternate approaches that can be used to mirror zonefiles, without use of outgoing AXFR, not to mention TSIG and IXFR. And I suppose that, in fairness, that's worth considering (when you don't want/need to interoperate with other people's nameservers that do the standard zone-transfer protocols). You might be able to efficiently and reliably do pull-distribution of zonefiles in one of the ways Bernstein speaks of. It's worth trying, in some circumstances. (On the other hand, I don't see offhand how you could do push-distribution that way, without creating a security hazard.)
But Prof. Bernstein didn't merely content himself with issuing a nameserver that doesn't fully support zone-transfer protocols he deprecates and say "Hey, that's how it is. Use it if you like the design, or don't." No, he had to justify that using one of the most wacko Web pages I've ever seen, where he argues against the very notion of backup nameservers (which in DJBware jargon are termed "third-party DNS service"). That just floors me, but, yes, the man actually does say that.
On that page, you'll find a great deal of logic-chopping that presents facts that seem to support the conclusion he desires while omitting crucial ones that don't. Example: Bernstein says you needn't worry about inbound SMTP mail bouncing when your on-site DNS becomes unreachable (with no backup DNS elsewhere) because "Mail transfer agents defer delivery attempts when DNS servers are unreachable". Well, yes, but not past the expiration of any cached DNS values -- which is exactly the problem that offsite backup nameservers address.
Example #2: Bernstein says having offsite backup nameservers won't stop the mail from bouncing during an extended outage because "the SMTP servers aren't reachable either". That is, of course, a non-sequitur: You would of course have offsite backup MX hosts, in addition to your offsite backup nameservice, to ensure that "the SMTP servers are reachable".
Building up that sort of wacko justification for why offsite backup nameservers aren't useful (when clearly they are essential), just because his software supports that functionality in only a partial and eccentric fashion, is certainly the most bizarre move I've seen from the DJB camp, to date.
The pity of it is that Bernstein has a number of excellent points he's made, that people really should heed, e.g., modular design, attention to trust relationships, eschewing featuritis, careful coding to prevent buffer overflows, and not mindlessly enshrining protocols into RFCs for little reason other than BIND already doing them. If not for his unexcelled talent at pissing people off, and for wacko post-hoc rationalising like the foregoing, those important lessons would surely be more widely understood.
Rick Moen
rick@linuxmafia.com
If the author of the above comment was not djb but someone else who was defending him: I would not consider such a comparison with djb's style of argument as a complement.
Only a sycophant of djb would be dumb enough to feed a troll.
I'm sorry to hear that you learned from djb's code. While I have nothing to do with the troll to whom you replied (i.e., I'm not the author of the "why I avoid djb code"), I could not but help respond to your comment about learning to program from reading djb's code.
... qlog.c. OK, it is a small file:
e of buffer_2
... for obfuscated C. Could have been less cleaver. And if speed were a real concern a simple table lookup would have done nicely.
/. filter, I will stop this post now and continue with part 2.
Lets pull up MR djb's djbdns v1.05 code shall we? This code has 208 *.[ch] files. These 208 files contain 11731 lines of text. How many opening comments can one count? Only 124 comments. Of those, 114 comments are single line comments, and only 10 are multi-line comments that total 73 lines for a grand total of 187 lines of comments.
So a puny 1.59% of the source lines in djbdns are comments!!! I hope you document your own source code better than that!
Now you may say that well commented code is no guarantee of quality. Very True. Some might even go as far as to try and argue that good code should self document. But a balance must be struck somewhere.
Lets pick a file at random
#include "buffer.h"
#include "qlog.h"
static void put(char c)
{
buffer_put(buffer_2,&c,1);
}
There is no indication of what buffer_2 is. One has to go to buffer_2.c to find these gems:
#include "buffer.h"
char buffer_2_space[256];
static buffer it = BUFFER_INIT(buffer_unixwrite,2,buffer_2_space,siz
_space);
buffer *buffer_2 =
And that BUFFER_INIT magic being:
#define BUFFER_INIT(op,fd,buf,len) { (buf), 0, (len), (fd), (op) }
So we character array of buffer_2_space fixed in size and declared with the magic constant of 256?!
I'm not very impressed so far! But lets continue back in qlog.c where we left off:
static void hex(unsigned char c)
{
put("0123456789abcdef"[(c >> 4) & 15]);
put("0123456789abcdef"[c & 15]);
}
Cute
Continuing:
static void octal(unsigned char c)
{
put('\\');
put('0' + ((c >> 6) & 7));
put('0' + ((c >> 3) & 7));
put('0' + (c & 7));
}
OK, here the author assumes ASCII and continues to be cute. Now we reach the heart of the qlog file, the qlog function itself:
void qlog(const char ip[4],uint16 port,const char id[2],const char *q,const char
qtype[2],const char *result)
{
char ch;
char ch2;
BTW: All of the indentation is that of the author. I have not omitted any comments in this file because there are none. Between these code sections are single empty lines.
So we see function with 6 arguments, none of them documented. Let us hope that qlog is always called with a non-NULL q and result pointers.
To avoid the "too few chars per line"
Next we see the reason for those hex() and octal() functions:
... but gee wiz folks!
/. filter).
hex(ip[0]);
hex(ip[1]);
hex(ip[2]);
hex(ip[3]);
put(':');
hex(port >> 8);
hex(port & 255);
put(':');
hex(id[0]);
hex(id[1]);
buffer_puts(buffer_2,result);
hex(qtype[0]);
hex(qtype[1]);
put(' ');
Gee, those first 4 hex() calls look a a lot like an attempt to output a value of an IP address. I sure hope this code never encounters non-IPv4 addresses! No attempt to use the standard declaration types for IPv4 addresses, just 4 signed chars? And what about endian/host/net order? Oh, I'm sure it all works
I'll move to part 3 where the "quality" begins!
(Sorry, must break this into parts because of
the "too few chars per line
For the final gem we see the following code from that same function. Here we see more examples of why you should not code like djb codes.
if (!*q)
put('.');
else
for (;;) {
ch = *q++;
while (ch--) {
ch2 = *q++;
if ((ch2 >= 'A') && (ch2 <= 'Z'))
ch2 += 32;
if (((ch2 >= 'a') && (ch2 <= 'z')) || ((ch2 >= '0') && (ch2 <= '9')) || (ch2 == '-') || (ch2 == '_'))
put(ch2);
else
octal(ch2);
}
if (!*q) break;
put('.');
}
I am not making this code up folks! Did the author every heard of ctype macros? What about non-ASCII character sets? Can you be sure that the *q pointer will stop on a NUL character and terminate the above loop? How about those magic 32 constants? Hopefully the 1st octet that *q points at will cause the while(ch--) loop to terminate before *q++ runs off the end of the string!
Just for completeness here are the final lines of this qlog.c file:
put('\n');
buffer_flush(buffer_2);
}
I am far from impressed with just this little sample.
Poorly commented code. Frequent use of magic constants. Places where standard types and macros could have been used. Excess cleverness where sample straight forward coding would work just as well. Sorry, all that makes for poor code quality!
Qmail sucks. no smtp auth. real fuckin good. dont give me that its good until you try to scale. Say postfix, or some other real MTA. But qmail?
and DJB, fucking sucks. Try reading his sources. Its unreadable.
Shows what you know, fuck head.
DJB. I think you are such a fucking cunt. Your code sucks. your software sucks. and you FUCKING LIE about your 500 dollar bet - people complain about nailing your ass and you not paying up.
You make fun of software with real circulation. if as many people who use bind and sendmail used Q-homo-mail or DickJerkDNS we would find your shit fuck software fullm of holes.
You are probably a ass philandering pedophillic fuckstick motherfucker. I hate you your software and you existence.
mister tiny program piece wise speaks! hey arent you the guy who makes 9000 little binaries to do the job of one binary? so you create a fucking mess in /services/, and its filled with 900 fucking files, and you talk about how forward and reverse tables being in sep. files is gay?
FUCK YOU
LYCOS:[Terra Networks now] Per-Share Data
Book Value (mrq) $9.02 -- Earnings (ttm) -$18.95 -- Earnings (mrq) -$14.69 -- Sales (ttm) $1.22 -- Cash (mrq) $3.55
Management Effectiveness -- Return on Assets (ttm) -4.77% -- Return on Equity (ttm) -100.83%
Profitability -- Profit Margin (ttm) -81.9%
So here you Papa bear Berenstain, telling all the cubs how it is. But instead of being good, I'm going to piss on your fucking leg like an angry cat. Lycos sucks shit, fool. Google rules it so hard. And the same degree which Google owns so hard over Lycos is about the same disparity between that Michael Jackson-esque piece of shit code base fairytale you refer to as DJBDNS and Qmail. Or should I call it quake mail, since the average Gaymer would produce better code than that. You taking the endorsement of that piece of shit company as anything more than insult is as laughable as you are, cuntcasket. Its dumbassed zealot professors such as yourself that leads me to believet hat scientists in skunk work projects are the road to technological salvation, not evangelical assholes hiding out in Universities so they don't actually have to prove themselves. You are the epitome of a tenured loser asshole. I hate you, and whatever titiion the kids have to pay to goto your rat infested dump of a school is too much if they hire idiots like you.
All I have to Say, Berenstain, is GET A FUCKING JOB. You fucking cartoon character.
All Research Reports for Terra Networks, S.A. (ADR$ 14.69Sales(ttm)$1.22Cash(mrq)$3.55 Valuation RatiosPrice/Book(mrq)0.51Price/EarningsN/A Price/Sales(ttm)3.73 Income StatementsSales(ttm)$699.1MEBITDA(ttm)-$262.1MInco me available to common(ttm)-$11.5B ProfitabilityProfit Margin(ttm)-81.9%Operating MarginN/A Fiscal YearFiscal Year EndsDec
31Most recent quarter31-Dec-2001Management EffectivenessReturn on Assets(ttm)-4.77%Return on Equity(ttm)-100.83% Financial StrengthCurrent Ratio(mrq)5.59Debt/Equity(mrq)0.00Total Cash(mrq)$2.21B Short Interest
Statistics at a Glance -- NasdaqNM:TRLYAs of 13-Nov-2002Price and Volume52-Week Low
on 8-Oct-2002$3.60Recent Price$4.55152-Week High
on 27-Nov-2001$9.27Beta1.67Daily Volume(3-monthavg)123.8KDaily Volume(10-dayavg)231.0K Stock Performance
big chart [1d | 5d | 3m | 6m | 1y | 2y | 5y]52-Week Change-39.4%52-Week Change
relative to S&P500-21.6% Share-Related ItemsMarket Capitalization$2.83BShares Outstanding621.3MFloat379.0M Dividends & SplitsAnnual DividendnoneLast SplitnonePer-Share DataBook Value(mrq)$9.02Earnings(ttm)-$18.95Earnings(mrq)-
As of 8-Oct-2002Shares Short4.73MPercent of Float1.2%Shares Short
(Prior Month)6.17MShort Ratio39.07Daily Volume121.0K ADR InformationShares/ADR1See Profile Help