On Thu, 19 Sep 2002, Rick Moen wrote: > Quoting Ian C. Sison ([EMAIL PROTECTED]): > > > Maybe the vulnerabilities of the old codebase do not apply to 9.x due > > to the redesign/rewrite, but the principle of monolith design is > > generally asking_for_an_exploit(tm), and as expected, there has > > already been 1 security problem in 9.x (which counts) and another in > > the resolver library (which i think does not count..) > > Hmm, the only recent resolver libs problem I've found (a buffer > overflow) was around July of this year and was in the BIND v. _8.x_ > libbind. But please note that, ironically, this vulnerability could not > be exploited if the query passed through a BIND v. _9.x_ cache. ;-> > > (Many -- most? -- Linux systems use the glibc resolver library, rather > than any BIND lib. That doesn't affect your point; I just thought I'd > mention the fact.)
Yup, which is why i said this problem does not count.. \8) > After searching the CERT database, the only vulnerability in BIND9 > itself that I can find is CERT Advisory #CA-2002-15, last June -- but > the hole was not exploitable in any way other than a DoS. > Specifically: Sending a specific DNS packet to the daemon triggered > that instance going into some sort of test mode where it performed an > internal consistency check. Somebody at Nominum obviously screwed up, > but it's (1) not what we (mostly) mean when we say "security problem" > and (2) not attributable to monolithic architecture. 1) i believe whether its a local/remote root compromise or an IP packet which brings down a service, it is a legitimate security issue. That particular problem could cause bind to assert and dump core, which could bring chaos to a network that depends on it. Its been done to me some time ago... Sometimes these DoSs are actually more harmful to service providers than actual remote roots, as there are those cases wherein an intruder gains super user access, and uses it to install an IRC bot or something, and keeps the system online.. 8) My point? These DoS problems are equally as disruptive remote roots and provide yet another way by which unauthorized intrusions bring down legitimate services. 2) i could be so bold (not to generalize) but to give light to the possibility that programs developed to be atomic in nature, having limited well defined interfaces, as well as having defined behaviour patterns tend to have less oversights like the abovementioned issue. Keeping the interface and algorithm simple makes it simpler to review, and critique, and makes it easier to identify bugs. Again i am not concluding anything. I am stating a theoretical possibility based on the different books i have read and from personal experience. There are simply too many factors that are involved in software development that could skew the resultant product towards the extreme opposite of what i said. > > I am unsure about MaraDNS, but i believe the little proglets of djbdns > > are clearly the way to go, if one has a little more time to develop, > > and debug such a design.. > > I tend to strongly agree with the general sentiment -- with the caveat > that, ultimately, the only suitable criterion for successful designs is > results (the "Proof is in the pudding" rule). I offer Exim as a modest > example: It's not been perfect, but author Philip Hazel, is very on top > of things. It had one local-only root exploit in 1997, patched > immediately. In 2001, there was a format-string weakness, but only > against obsolete versions. (Hazel had already patched it.) In late > 2001, Hazel fixed a input-validation weakness that theoretically might > have permitted remote attacks using pipes, for which there never were > any known exploits. I believe that's pretty much its entire security > history, since the initial version in 1995. Admittedly i have very little experience with Exim, so i would like to reserve comment until the time that i do. For now, i'll take your word for it \8) > > That's arguably good enough, given (1) competent system maintenance and > (2) the major win Exim gives in simplicity of operation and > configuration. It even has some advantages available only to monolithic > designs: Postfix and Qmail can't be configured to eliminate dupe copies > when you are mailed directly plus via an alias; Exim (and presumably > Sendmail) can. Cyrus imap has done a some work on that, in that it's delivery agent has a database of already sent items, to avoid actual dups being delivered. True, its not related to your point where the MTA actually supports it, but at least it makes it less important feature if other software layers can support it. ;). UUCP support is available in Postfix, and there are references in the documentation on how to integrate it. http://www.postfix.org/rewrite.html _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
