Running BIND 4 or 8? Upgrade! 237
The Dev
was the first of several zillion to point out that security holes were found
in BIND. The
detailed table
of known vulnerabilities will help clarify (and it has tarball links too), but the short version is, if you're running BIND 4 or BIND 8, set aside some time today to upgrade to 4.9.8 or 8.2.3 (not beta, betas of 8.2.3 are vulnerable). And now's a good time to reconsider version 9, too.
SecurityFocus warns
that the last time a BIND hole of this magnitude was found, it was followed by a "cyber-crime wave." Exploits for these holes were successfully created by
COVERT Labs,
but nobody seems to know whether they're in the wild yet. Obviously, they soon will be. Post your questions and answers about upgrading below.
Re:I am amazed... (Score:2)
sprintf(buf, "...%80s...", badstr)
will happily pull more than 80 characters from badstr. You really want to use snprintf, though it isn't supported identically on various platforms -- check the manpage.
Read this if you want to learn considerably more about safe usage of strncpy/cat/etc:
http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/ [usenix.org]
Re:Avoiding This Altogether (Score:2)
The biggest problem with security problems is that they don't show up during ANY part of the standard software development cycle (your testers generally don't have the source code to try and exploit the code with, and certainly don't have the expertise to do so anyway), so they go unnoticed for years until someone on the outside finds the hole and exploits it.
Re:Who needs BIND? (Score:2)
I'd say that dubious distinction falls to wu-ftpd, but BIND is a close second.
Anyway, BIND 9 is a complete rewrite.
--
OpenBSD Immune (Score:2)
SoupIsGood Food
Re:Avoiding This Altogether (Score:2)
Sure, they should mention what buffer overruns are. But they shouldn't be teaching you how to use a particular tool - but how that class of tools work in general.
Unless of course it is a C/C++ course
Re:What's it take to go from BIND 8.2.x to 9.1 ?? (Score:2)
Much MUCH easier than 4->8
Re:djbdns is the way to go! (Score:2)
Re:I am amazed... (Score:2)
Re:I am amazed... (Score:2)
Re:yeah... (Score:2)
Because all software is buggy crap to begin with.
Programmers of open source software are no different than programmers of closed sourc -- both code to their level of skill and pride. The only difference is pay, and money does nothing to make someone write better code. It's not like a programmer gets paid more for writing more elegant, secure code. Nope, it only has to work not too long after their scheduled release date.
The fact is that all code of sufficient size and complexity will have bugs in it. I leave it to the reader to decide whether they want the buggy programs they depend upon to be open or closed.
Re:yeah... (Score:2)
A very good point. There are fundamental protocol flaws that can render code vulnerable even if there are no buffer overflows or other standard bugs.
However, looking at the list of vulnerabilities for BIND, they appear to almost exclusively be of the buffer overflow and 'improper handling' vein, which falls into the category of buggy code, not bad underlying design.
Then again, your idea would apply if the code was written without concern for preventing things like buffer exploits.
maybe we should take a pointer from the *BSD camp; they fix how the code functions and then they evaluate why the code does something in that manner so design flaws can be addressed.
Who's "we"? BSD uses bind just like Linux does.
But I agree, if you mean specifically OpenBSD and their thorough audit process. It reminds me of the processor industry, when years are spent validating a design.
Then again, processors ship with bugs in them as well. You can never be assured that you are 100% bug free in any sufficiently complex (ie not provably correct) design. It's worse with software than with hardware, because in software there are more uncontrollable variables.
BIND 9.x is on the right track. They've completely rewritten nearly all aspects of the underlying architecture to address the design problems inherent in BIND 4 & 8.
Which CERT advisories refer to underlying architectural flaws?
Not to say a re-write is bad... I think developers are too afraid of starting over. Especially in the open source world, where release schedules are not a concern, but code quality is.
A How-To On This (Score:2)
-Waldo
New Kernel (Score:2)
-Waldo
In the wild (Score:2)
So upgrade.
this was on MSNBC, ZDNN (Score:2)
Re:Avoiding This Altogether (Score:2)
Re:Who needs BIND? (Score:2)
Let look at the track record of BIND.
1) explot every few months (followed by apologies like, "well, BIND has been out so long, it has to be secure NOW".
2) New BIND, where the authors seem to indicate that security was not part of the design critieria.
But you see, djbdns has the wrong license. It's not GPL. And people will rather be rooted than run a non-GPL software. Especially if running it would mean that one had to admit that there is actually a non-GPL software that is (Oh nooo) *better* than the GPL alternative.
If you want to see the same additude for another piece of "software", check out any discussion on Sendmail (same arguments, same security holes).
Re:How about ... (Score:2)
Note that djbdns is a suite of dns utilities that together gives the same functionality of BIND.
dnscache *only* do caching (great if you are on a dialup. Because, do you really need a fullblown dnsserver if you only what to do caching?).
tinydns *only* only server dns request (no caching).
If you want a dnsserver, you only need those two. They run in with their own userid, in chroot'ed into their own directories owned by them.
AND, it's a snap to set up (took my half a day to figure out everything).
Re:djbdns is the way to go! (Score:2)
GPL limits the distribution, in the sense that if you distribute it, you have to give the source code. AND YES THIS IS A LIMITIATION.
Bernstein's license is that you can't distribute it and changing the author's (his) original wish on how the software should work. That means you cqan't arbitrary change the code, or the location of where the software is installed, and distribute and still call it qmail/djbdns.
You can distribute binaries, AS LONG AS IT INSTALL EXACTLY LIKE IT WOULD IF THE USER COMPILED AND DID A MAKE INSTALL FROM PRISTINE SOURCES.
Heck, like the GPL, if you don't like it, you can always negotiate with the author the change the license terms.
If you want talk about true freedom, talk about the BSD license.
Re:I fucking hate it! (Score:2)
So why don't you just turn on the telnet service or download the free SSHD for NT/2000 [criadvantage.com]? It's really not that difficult...
I still can't understand how in this day and age someone can waste their time complaining and not be able to figure this stuff out.
Cheers,
huh? (Score:2)
Granted I'm not a DNS wizard but I don't think this is the case. In the worst case you could say that djbdns requires separate IP addresses for everything. Except that really isn't the case anymore, as I understand it.
For all of the complaints about the Outlook/Exchange monoculture and its susceptibility to exploits that you see on slashdot, I'd really expect more people to be using things like djbdns and fixing the holes in it rather than complaining. I'd rather patch djbdns to add minimal functionality than patch BIND to fix major security problems.
Granted Berstein isn't the most affable character in the world, but I don't pick my software based on the personality of the people who write it.
Re:Who needs BIND? (Score:2)
However, it is misleading to suggest that that is the only, or even the most important, criterion. Quantity of scrutiny has nothing to do with quality of scrutiny...as many open source software projects find out. Having millions of naive users who never look at the source code does you very little good from a security standpoint. Having ten knowledgeable people audit the source code does a tremendous amount of good. Also, djbdns has a little more than 10,000 lines of code. BIND has well over 120,000. It is much easy to verify simple software than complex software. That, combined with the relative track records of the authors of djbdns and BIND make the comparison much more difficult than simply looking at how widely deployed something is.
Re:OpenBSD Immune (Score:2)
it's quite a nice OS..
mirrors of bind 8.2.3 in australia (Score:2)
bind is mirrored in australia at:
PlanetMirror:
ftp://ftp.planetmirror.com/pub/bind/src/8.2.3/
AARNet:
ftp://mirror.aarnet.edu.au/pub/bind/src/8.2.3/
please try to use one of them before hitting
the ISC server.
-jason
The Microsoft connection... (Score:2)
Re:I am amazed... (Score:2)
I didn't start about Java
My whole point is that the technology exists today to prevent this kind of situations. There's no kind of excuse for this kind of bugs anymore.
I strongly oppose your suggestion that you can make programmers work harder and code better (if you know how, you're going to be rich). It hasn't happened in the past and I guarantee you it won't happen in the future. It's the technology that's fundamentally flawed and not the programmer.
Re:I am amazed... (Score:2)
C should only be used in those parts of a system that are really critical (critical as in a profiler shows that we need more performance here and there's no way to do it the language we're currently using). Using C when it's not needed costs you in terms of lines of code, development time, bugs (direct correlation with lines of code) and maintenance cost (same correlation again). Some might argue against LOC, but the other things have been shown to be true in very extensive and convincing casestudies (I could look up some references if you'd like to have them).
Re:I am amazed... (Score:2)
Of course it is possible to create good programs if you don't make any errors, duh. The problem is that humans do make errors. And since C provides little or no protection against these errors it is unsafe.
As long as we will use C for implementing these kind of things, there will be memory leaks. Of course C is a very performance efficient language, however, things like this make it unsuitable for security critical apps because you can never be 100% sure it doesn't have memory leaks.
Re:I am amazed... (Score:2)
C++, with some proper string class would have probably prevented the problem. I suspect a Java implementation would perform acceptably too. However, there are several procedural languages that would be suitable as well. There's plenty of alternatives to C. C may have been a nice language for this kind of programs in the seventies but its 2001 now. C had technical flaws, many of which were addressed in languages that came after it.
BTW. I disagree that this is a low level application. Device drivers are lowlevel applications. You typically find them at the bottom layer of the OSI model. Bind would classify for the application layer (almost at the top).
Then, you hammer down the fact that it is possible to create safe programs in C. But then my simple question is: why the hell do we have all these security leaks? Bind isn't an incident, it's just the latest leak to be found. Probably a solution will be provided in the form of a patch. However, this patch won't fix the fundamental problem, it will just fix the symptom and in the future more bugs will be found.
Debian users (Score:2)
deb http://security.debian.org/ stable/updates main contrib non-free
Re:attn slashdot editors: (Score:2)
Re:openbsd NOT immune.. (Score:2)
As to timely updates, there was a patch for bind4 yesterday, even though it looks like the buffer overruns were defanged back in 1997 in a general sweep for sprintf()s.
Re:djbdns is the way to go! (Score:2)
Ok if you are working from scratch. But more tricky if you want a replacement for an existing set up.
Re:yeah... (Score:2)
Though the router was only "mission-critical" because of the DNS servers being misconfigured.
Microsoft is hardly unique in not complying with rfc 2182 though...
Re:The Microsoft connection... (Score:2)
Their "own" version of DNS could easily be an old version of BIND hacked to work with a Windows GUI, however...
Anyway RFC 2182 is software agnostic.
Re:yeah... (Score:2)
If Cisco's network were to go down, that would say a lot more about their products than if the same thing happened to MS.
More to the point whoever set up Cisco's nameservers appears to understand the basics and know what they are doing. Something which is self evidently not the case with Microsoft.
Re:Chroot jail with bind 9? (Score:2)
eye opener (Score:2)
For those who feel safe and comfortable with their home box, especially those hooked up to DSL or cabel, I strongly recommend checking out that list. It's scary and it's only bind! To keep the balance, the fix list for Win2K SP1 is even longer... and scarier..
I run a box at home that is connected to the net 24/7 on a dynamic IP without an easy-to-guess hostname and I get about 10 probes a day.. FTP, ping, SSH, telnet, http.. you name it.. I assume most boxes get the same amount.. If you have an open door, it WILL be exploited!
Re:eye opener (Score:2)
"but there's a lot of rhetoric on Slashdot about how Microsoft OS's are *UN*safe."
Re:eye opener (Score:2)
Re:Who needs BIND? (Score:2)
DJB is willing to bet [cr.yp.to] that there won't be and even though djbdns is not in wide use, his other project, Qmail, which carries a similar guarantee is widespread even in high-profile high-risk locations like Hotmail. No security related bug has ever been found AFAIK.
Regards,
Xenna (who bets his servers on it)
Re:yeah... (Score:2)
Re:The Microsoft connection... (Score:2)
M$ uses their own DNS software. Hopefully because of their recent DNS borking on their own software/systems they won't try to convince people their DNS software is superior because /their/ DNS isn't vulnerable to the BIND holes.
But they probably will anyways... Oh well.
Re:I am amazed... (Score:2)
I'm not really interested in an argument that it's possible to write bounds checking code by hand -- obviously it is (and I'm sure you do!) -- but equally obviously, many, possibly most, people do not.
I can see two fixes to this problem:
These vulnerabilities cost huge amounts every time they happen, not just in terms of security breaches but in all the hidden cost of time spent upgrading systems. How many DNS servers are there running vulnerable versions of BIND right now? How long will it take to fix them, assuming they get fixed? This is really a lot of money...
I kind of wish education could solve this problem, but I'm cynical, so I place more faith in systems which prevent it happening.
Re: (Score:2)
Quick patch for promiscuous installs. (Score:2)
Which is truly annoying.
A quick way to give yourself some protection is to configure ipchains first thing to block all inbound everything except responses to things (like TCP sessions) originating inside. Then selectively expose anything you want to be reachable from outside. This limits the (initial) vulnerabilities to the servers you expose and the TCP/IP stack itself.
Even if a server like BIND is running they can't exploit it unless they can get a message to it.
(Of course once they get through a hole in one of the things you DO expose they can open up any others they want. Then all bets are off.)
When installing on a new machine you might want to go out onto the net and get any security tools and patches I might need, roll them onto a floppy, then pull your network connections and reinstall from scratch (reformatting the disk), just in case some kiddie got to the box while the initial wide-open install was running.
Of course you don't want it running open on a home network, either, since it could be used to sniff and attack other machines while it's open. But if you have any other machines you can write that floppy on one of 'em and run both the install and door-locking while the machine is connected to nothing but the power grid and sneakernet. B-)
The problem isn't really C... (Score:2)
That's because C is an "enough rope" language. Others do some checking, but it costs execution speed, and they still can't block all the holes. C does JUST what you tell it, without waisting cycles on trying to save you from yourself (and giving you a false sense of security). It's up to you to tell it to do whatever checking you want done.
The problem isn't really the language. It's the standard library, which contains some input routines with buffer overflows built in. The biggest culprit is gets(). It was a mistake to put it there, and the manual page now warns you not to use it and what to use to replace it (fgets()). But now it's there, and a bunch of stuff will break if it goes away.
(Of course anything that will break is already broken. So you might want to cut it out of your own library and see what won't link. B-) )
And So It Begins... (Score:2)
"And so it begins."
"There is a hole in your BIND."
"What do you want?"
I tried BIND9 - it was worse. Using DJBDNS now. (Score:2)
I upgraded to BIND 9 and had problems right off the bat, to say nothing of the fact it's 10X the size of BIND8. DJBDNS is one Slick package. It rawks. Very, very elegant. http://cr.yp.to/djbdns.html [cr.yp.to]
BIND 9 is supposed to have been written by a "team of professionals". From where? Microsoft? Guys that were "let go" because they wrote code too buggy and bloated for M$? DJBDNS shows once again one guy with a major clue beats a "team of professionals" every time.
Thanks for getting us this far, Vix and Co., but you can sit down now.
Windows NT Server, stable, on a heap of junk! (Score:2)
It's currently at 42 Days, it was past 150 when I took thinks down because I tweaked IP addresses for our network. (Yeah... NT needs to be reboot to work right... it's not perfect).
The point is that NT is stable, you just have to treat it like a server instead of a workstation.
--Mike--
Re:djbdns is the way to go! (Score:2)
You don't know what you're talking about. The latest djbdns has load balancing built into tinydns, the iterating resolver. Dnscache, tinydns, and axfrdns can all run on the same machine, e.g., to replicate the usual BIND installation. And please explain to me how software can "rot." Oh yes, there's a new release of qmail in the works, you got that wrong, too. Qmail is doing fine, are you a shill for ISC?
The bottom line is that if you are running BIND you're more vulnerable than with djbdns. Everyone runs bind and sendmail for the same reason that windows is installed on so many desktops, it's the default install.
Re:I am amazed... (Score:2)
What a strange statement. It is perfectly safe to program in C as long as you are paying attention. In my experience, the security leaks occur by a) oversight of the programmer (probably about 3am) b) code contributed by an amateur who lack formal training thus wouldn't know the basics we do or c) rush jobs that were only meant for test purposes but then got incorporated into final code.
The first can be checked for by code review, which is where Open Source is supposed to excel. The second tends to occur where people have never studied CompSci, yet have dabbled in Javascript hence consider themselves a programmer (ok, slight exageration). The only solution to this is use software where the team has a good reputation. The last is poor software engineering. Harangue the author(s) to go back and do a proper job.
Personally I think C is an excellent language for writing core OS apps in. Fast, flexible and efficient. Java is a good server-side language for application server development but I wouldn't write my core server apps in it (not fast or lean enough). What alternative language would you suggest?
Phillip.
Re:Chroot jail with bind 9? (Score:2)
Before you run ./configure, do a "export CFLAGS=--static"
Then ./configure --enable-chroot.
make
Then go in and copy the binaries to your chroot jail.
Then go make sure your chrooted /var/run can be written as the user that named runs as.
Then go edit your zone files and add "$TTL 84000" to the top of each one.
Then start named as you did previously.
Bind and Sendmail (Score:2)
TinyDNS/DNSCache (Score:2)
This comes in two parts- 'tinydns', which only handles serving authoritative data, and 'dnscache' which only handles providing caching DNS services.
Installation is somewhat complex, but the software works like a charm once you get past that.
Re:Debian update instructions (Score:2)
Never trust anyone who tells you not to trust people. 0
bind - Bug Infested Network Daemon (Score:2)
The folks who wrote and/or maintain bind had the best of intentions. Bind code filled the need when Arpanet/Internet sites were copying around large host files. I don't wish to denigrate / attack those who helped create and maintain bind, but one cannot ignore the fact that bind is one of the larger infrastructure vulnerabilities we face today. The track record of bind v8 and previous version cast doubt on the wisdom trust bind v9.
Bind's track record clearly shows it for what it is: a bug infested and many flawed chunk of code that has lasted way past its prime. Bind is to name service as sendmail is to EMail.
Bind has and very likely continues to suffer from:
But all is not lost in the name service front. A few alternatives to bind exist now. Several more efforts are in the works as well. Time and experience will show which efforts will succeed.
For those cannot become a bind-free site now or in the near term future, there are some things you can do to minimize the damage bind code can cause. Consider the following ideas. These idea are not for everyone. This list is by no means exhaustive. You might want to:
If you treat bind with caution, you will be more likely to survive intact until a bind-free solution with a good track record presents itself.
Things Qmail Needs (Score:2)
Qmail works great if your a programmer, or if you have LOTS of time. Some people do not. Qmail works out of the box for 90% of what we do. The other ten percent could be made easier if some of the extremely common "add ons" were merged into the source.
Re:djbdns is the way to go! (Score:2)
From an ISP point of view, you really want to do this. Servers which customers use to lookup names should not be the servers which you use to store customer zone files. This ensures that when domains get redelegated away from your nameservers, that your own customers always see the correct (i.e. as delegated) zone contents.
Qmail appears abandoned.
What a pity. I use qmail in several places and it really works well. But I won't stop using it even if it is abandoned because I have the source, and ICHI (I Can Hack It).
Re:OpenBSD Immune (Score:2)
Re:I am amazed... (Score:2)
Because only very few of those eyes are looking at the code. Most of them are just looking at a list of programs running on their system with BIND in it. They never bother (nor have time) to look at the actual code.
DNS Stories ... Re:Ok (Score:2)
(Sorry, bad pun, couldn't resist :-) )
--
Fuck Censorship.
Re:yeah... (Score:2)
What's it take to go from BIND 8.2.x to 9.1 ?? (Score:2)
Does anyone here know about what (if any) compatibility issues there are going from 8.2.x (installed on most machines today) to 9.1 ?? Did they change stuff in the config file format, again?
Assuming... (Score:2)
Cheers...
--
"No se rinde el gallo rojo, sólo cuando ya está muerto."
Chroot jail with bind 9? (Score:2)
SealBeater
Come on (Score:2)
You just have to wonder what recently means, 90 days? Time to cancel the LAN party and have an Update party
________
Re:yeah... (Score:2)
Except that Microsoft were running their own Microsoft-based DNS servers, and were thus not affected by these latest announcements.
Microsofts mistake was to put all their servers on one subnet, and allow a change to be performed on a mission-critical router without proper approval, as far as I can work out.
The interesting this is that their marketing machine managed to hush this up so well: if it had been Cisco, they would have been toast.
Re:Higher Level Languages are Unpredictable (Score:2)
[sigh] I note that you've been moderated down as Flamebait. Apparently, someone is moderating based on emotion, not rational discussion, again.
And so've I. Despite the fact that my point was rational, intelligent, on topic and clearly posted.
Yup, we've got some wonderfully intelligent moderators these days.
It's okay. I'll just go back to the home page, hit refresh until I get moderator access (it'll only take two or three times), and then I'll fix the stupid moderation going on (in other discussions, of course).
Read the moderator guidelines, you cheese-eating dweebs.
Re:Windows NT Server, stable, on a heap of junk! (Score:2)
At work I've got a Windows NT Server I slapped together from parts left over from a workstation that was too decrepid for use as a workstation. It's got a number of handicaps working against it, including:
486 DX/2 - 50 Mhz processor
Only 32 MB of DRAM
BIOS patch drivers running in real mode
Runs a Telnet server, DNS, and web server
Goofy BIOS/Video card combination that dies after a warm boot
Windows NT 4.0 Server
That *is* impressive with all those handicaps. Oops, especially with that last one. [grin]
Yeah, I've got a friend who has a small ISP up in Maine, and he was running the whole damned thing off 486s and Windows NT Server. Except for the uptime-limiting Windows-esque reboots, it was stable.
Then, when Microsoft came a-knockin' to do a software audit, they screwed him.
I'd propose that, in a business situation, you really have to keep away from the pirated software, and the overheads involved in making sure that you have that license handy for the copy of Windows NT Server on that machine may negate the savings of using an OS that you just had kicking around (and therefore didn't have to purchase again).
Even with that stability, I'll stick with my Linux. Aside from BIND (!), it's secure and stable. I'm running DNS, web (Apache), SMTP (sendmail), POP, telnet, Windows file and printer sharing (SAMBA), DHCP, NAT gateway to my LAN, and PPPoE to connect to my DSL provider. And the damned thing (a Pentium 100) still spends most of its CPU cycles on SETI@Home.
This would rule it out as a candidate for real use, right? Wrong! It NEVER dies, (it can't, won't reboot except for a power cycle). I take it down for the odd service pack, otherwise it's always there.[grin] Yeah, I know. I hate those. That's the kind of computer that you simply can't throw out, even though it's of marginal usefulness.
I've got a great 486 motherboard. Sure, it's only VLB, but it's a 486DX4-100 with a load of cache RAM soldered to the board. It's stable, it's fast (for a 486!), and I have a VESA video, IO and network card for it. And it's narrow.
And despite all those good things, it's also got a really annoying problem: the CMOS memory doesn't stay. So, I tried connecting an external battery. No better. I tried desoldering the CMOS battery from the board and replacing it, figuring that the battery external battery connections were bad. Still didn't work. Something is obviously fried. So, every time I have a power failure (not very often), I have to manually intervene, tell it that it the size of the hard disk attached to it, etc. Pain in the ass, but it's too good a board otherwise. You know what I mean - I've got a nice Socket-7 board kicking around; it's clockable to 233MHz and will take an MMX processor. It's got PCI slots, integrated I/O, much nicer board by specs than that 486. And yet, for anything mission critical, I'd still take that 486 any day.
That Socket-7 board feels like it's got static damage, but I'll be damned if I know how. I bought it new, unsealed the factory box, and have always used a wrist strap, static baggies and a good anti-stat workmat underneath it. The 486, on the other hand, came from a crappy clone builder, where you know they carried it across a carpet on a dry winter day.
It's currently at 42 Days, it was past 150 when I took thinks down because I tweaked IP addresses for our network. (Yeah... NT needs to be reboot to work right... it's not perfect).No, but that *is* impressive.
My alltime uptime record for Windows is 66 days for Windows 95B. Of course, that's only possible when you're running Windows 95 under laboratory conditions, and only then with the 49.7 day crash memory leak bug fixed.
The point is that NT is stable, you just have to treat it like a server instead of a workstation.Servers don't waste resources on GUIs.
Linux Losers? Uhhh... Yeah, dude. Right. (Score:2)
But do you really think linux losers spend their time trying to find buffer overflows in software? Nah, they spend their time downloading exploits written by others, writing WinAMP skins (or whatever it is called on linux), and playing quake.
I like what the Linux losers seem to do best. They write stuff. Stuff that lets me do kewl things that impress my boss and save my IT budgets for grander things.
Like really blowing away the MCSE idiots at the office by setting up and running a domain server, web server with caching proxy, mail server, SAMBA printer server, DHCP server and NAT firewall - with an uptime that blows away the best that they've done so far with Windows 2000 - for the 17 user LAN in a division of a Fortune 500 company - for under $200.
Fine, our website only gets about 50-60 distinct hits/day. But, the server processes about 300 e-mails a day, including large AutoCAD DXF attachments. The printer attached to it is always running. And we've saturated our T1 a few times now, though the server's NAT.
Yup. <$200. Old but tough-as-nails Compaq Pentium 100 with 48 megs of mismatched SIMMs kicking around - free. 4.3 gig Maxtor IDE hard disk drive - left over from an upgrade. Operating system and ISP-on-a-disk - Red Hat 6.2, free download, $0.50 blank CD-R, ~$0.12 for bandwidth. Couple of el-cheapo PCI network cards with gold "MADE IN TAIWAN, R.O.C." stickers on them? ~$30. Time to set it up? A few hours of my time, ~$150.
Stats? Check 'em out yourself. I've cut out lines that I didn't deem necessary to judging the performance of this server.
[lwade@wwwprocessor : 0
vendor_id : GenuineIntel
model name : Pentium 75 - 200
cpu MHz : 99.717487
bogomips : 39.73
[lwade@www
1:37pm up 75 days, 19:29, 1 user, load average: 1.04, 1.05, 1.01
52 processes: 50 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 1.1% user, 2.1% system, 96.6% nice, 0.0% idle
Mem: 46848K av, 45524K used, 1324K free, 6212K shrd, 1588K buff
Swap: 153176K av, 15632K used, 137544K free 19232K cached
The nice CPU usage there is represented entirely by SETI@Home's UNIX/Linux client. If not for that, the little old Compaq wouldn't have much to do with most of its CPU cycles.
I think that the people who contribute to, and are the most ardent advocates of an operating system with that capability, can't possibly be accurately described as losers.
When you can do that with Windows (any version), with that kind of uptime, on a Pentium 100, lemme know.
Higher Level Languages are Unpredictable (Score:2)
Most security leaks are a direct consequence of using languages like C. People claim it is possible to program safely in C, however, incidents like this prove them wrong.
[sigh] I note that you've been moderated down as Flamebait. Apparently, someone is moderating based on emotion, not rational discussion, again.
Years ago, I used to be a very fluent assembly language programmer. I haven't done it in years, and I kind of lost interest in programming when I saw that the higher-level languages were taking over.
For anything that has to be rock-solid-stable and predictable, like core operating system components and security, relying on higher-level programming where your code is being mangled by a compiler and linked to potentially faulty libraries, scares the hell out of me.
Look at Windows 9x as a perfect example of why this is a problem. You install a new application. It swaps all the DLLs for its own versions. Because the DLLs are changed, anything which had a dependency on those DLLs will be affected.
What will happen?
Well, to quote Ren Hoek from the legendary History Eraser Button episode, "Maybe something bad, maybe something good. We just don't know."
Eudora has caused a fatal exception error in CTL3D.DLLFor security, the vulnerabilities are even more subtle, and I believe that they're unavoidable.
The only way to ensure that you have complete control over what is actually running is to write it all yourself. Assembled from mneumonics, not compiled from a high-level code. All your own subroutines, written in your hand, not packaged libraries and other cop-outs.
High level programming languages are great for community college programming students. But I think the 'Net would be a lot more secure if we kept them out of our operating system core components.
And yes, writing in lower level languages can take a very long time. And, during development, some of the crashes are absolutely spectacular. But if you think about how much a bug that crashes an operating system like Windows 2000 costs to productivity worldwide - especially in an economy where every hiccup of a webserver slams NASDAQ into the guardrail like a Honda Civic being edged off the road by a Plymouth TrailDuster - spending a little more time to avoid the ambiguity of compilers and linked libraries is well worthwhile.
It's in the wild (Score:2)
The problem with capped Karma is it only goes down...
Re:Ok (Score:2)
Re:Come on (Score:2)
Suppose your fairy godmother appeared.... (Score:2)
As part of the way the magic works, in order to remove all buffer overflows and memory leaks and the like, it will cause all your programs to use twice as much cpu horsepower.
Would you take her up on the offer? Is it worth sacrificing some horsepower for security and safety?
You can program completely safely in assembly langage -- heck, even directly in binary using a hex editor. It's just not productive to do so. The high level C does so much of the bookkeeping for you. Similarly, using even higher level languages to achieve type safety, bounds checkinging, automatic memory management, etc. is just an extension of getting the computer to automate more of the tedious bookkeeping of programming. Isn't it worth it? For *most* applications (esp. bind) is the efficiency of C *so* inmportant?
Not trying to start a flamewar. Just some thoughtless remarks to piss off people who hate high level languages.
Re:yeah... (Score:2)
Re:Bind and Sendmail (Score:2)
That's exactly why they rewrote BIND 9 from scratch.
The scary thing... (Score:2)
Fortunately I can ssh into my server at home, so I had it upgraded within an hour.
Another scary thing is the CERT graph [cert.org] showing the exploit reports for the NXT bug. I definitely don't want to have an un-upgraded BIND in the peak of that curve.
Re:Who needs BIND? (Score:3)
Or rather, track record of having known security related bugs, because it is so widely used and hence so widely scrutinized. Whatever it is that you think has less bugs because of less known security issues, ask yourself if it is as widely deployed and as widely scrutinized as bind.
Maybe we should be more forgiving to Microsoft security issues then?
As long as the patch is released in a timely fashion (which means a day or two tops), and they don't attempt to cover up the "issue", then yes we should be. Unfortunately, neither of these things describes Microsoft behavior in most cases.
Debian update instructions (Score:3)
deb http://security.debian.org/ potato/updates main
Then do a:
apt-get update
followed by a:
apt-get upgrade
DONE.
Who needs BIND? (Score:3)
---------------------------
"The people. Could you patent the sun?"
A couple of important points (Score:3)
Second, and more importantly, DO NOT RUN A NAMESERVER AS ROOT. There are -u and -g flags when starting named that allow you to set which user the nameserver will run as, much in the same way that IRC servers are run as unpriveleged users. Then if the server is compromised, you've only lost an account and not the whole system, assuming no one will be able to hit you with a local exploit.
Ok (Score:3)
--
Re:aka "named" (Score:3)
Bind 9 not related to bind 8/BSD nto safe if..... (Score:3)
BSD users are still screwed if they downloaded the source and compiled from source. The changes to BSD's BIND 4 are only for those people that used open BSD's implementation of BIND4.
There are severl alternatives, and having used them all, we had to switch back to bind because of interoperative problems or performance issues. Some solutions are.....
Maybe one of these solutions will work for you.
Re:djbdns is the way to go! (Score:3)
Qmail appears abandoned. Many people are making patches, but what a pain in the ass, get the source then apply the 3 patches you need and hope they work together. Qmail is a great program, BUT if the author isn't going to keep improving it, then he should turn it loose to those that are.
aka "named" (Score:3)
It's probably worth mentioning that the program "named" (as seen in the service control activity panel of LinuxConf) is "bind".
djbdns is the way to go! (Score:4)
http://cr.yp.to/djbdns.html [cr.yp.to]
Re:Chroot jail with bind 9? - answer (Score:4)
I built bind 9 it barfed a little, but all I
really needed to do was make the
under the chroot directory world writable. And
bind 9 complained about not having a $TTL
directive in my zone files. Once I fixed those
things, I was up and running without having to
change named.conf.
I found the following things helpful:
named -g -u <user> -t <chroot_dir>
this runs named in the foreground without
writing to log files and lets you see what's
going on with it for troubleshooting. I
also used ktrace to good effect: use truss
on Solaris, strace on Linux and ktrace on
BSDs and you'll see what named is trying to
do (in particular, which files it's trying to
open).
I'm running OpenBSD and (now) BIND 9.1
Red Hat Releases updated RPMs (Score:4)
Re:OpenBSD Immune (Score:4)
OpenBSD 2.8 http://www.openbsd.org/errata.html [openbsd.org]
OpenBSD 2.7 http://www.openbsd.org/errata27.html [openbsd.org]
The rebuild and install is trivial.
--
Re:What's it take to go from BIND 8.2.x to 9.1 ?? (Score:4)
It's all in the docs/misc/migrating file in the 9.1.0 tarball...
Re:In the wild (Score:4)
Because this announcement is on slashdot does NOT imply there are exploits available in the wild for these security holes.
An exploit "in the wild" implies it is generally available to any script k1d that wants to download it, and as yet there are no "known" attack exploits available on the popular crack download sites.
This does not mean there are no exploits available. A very skilled cracker (or hacker doing it on a theoretical basis) may already have worked out what code he can get by the BIND signiture parser buffer overflow, and thus what he can get the CPU to run.
I hasten to add though that because of the way BIND parses it's input to this buffer, the attacker cannot actually run arbitrary code, but only use code containing characters which can get through the parsing routine.
Excellent description at The Register [theregister.co.uk].
Re:In the wild (Score:5)
The BIND 4 hole(s) is/are going to be a BITCH to exploit, certainly not impossible; but hard enough that it won't be suprising if such never sees wide distribution. Quoth the original advisory [pgp.com]:
Re:Who needs BIND? (Score:5)
Re:Debian update instructions (Score:5)
When making security updates, verify first the debs really are the ones announced on:
http://lists.debian.org/debian-security-announc
A mailing list you should be subscribed to, if you run public services with debian. Relying on
Re:Avoiding This Altogether (Score:5)
The other is accepting unchecked amounts of input from untrusted users. Remember that C (unlike, for example, Pascal, Java or LISP) does no bounds checking, so you have to implement bounds checking yourself.
If you do the equivalent of:
char buffer[ BUFFLEN];int i = 0;
while( ! feof( stdin))
{
buffer[ i++] = getchar();
}
buffer[ i] = '\0';
That's going to lead to a buffer overrun which someone can exploit. If you do the equivalent of:
char buffer[ BUFFLEN];int i = 0;
int maxinput = BUFFLEN - 1;
while( ! feof( stdin) && i < maxinput)
{
buffer[ i++] = getchar();
}
buffer[ i] = '\0';
Then you're reasonably safe. But to be safer still, don't use C to write daemons which take input from untrusted third parties, and don't run daemons as root - give each it's own separate role account.
A quote seems appropriate... (Score:5)
One Ring to find them,
One Ring to bring them all
and in the darkness BIND them.
Hmmm... Interesting.
Re:Avoiding This Altogether (Score:5)
Sure. There is a mailing list over at SecurityFocus called SECPROG that discusses secure programming practises. The idea is to produce a white paper that describes how to write secure code. The draft can be seen here [securityfocus.com] and is probably the definitive how-to in existence at the moment.
Hope that helps.