Slashdot Mirror

Qmail.. djbdns... daemontools... ucspi-tcp... all good, quality--and at the risk of jinxing it--secure software.

http://cr.yp.to/

Errr, hangon, you're telling me that I'm subsidising companies posting me junk mail? 'cos without some statistics to back this up, I'd suggest that actually their postage costs are paid entirely by them. I believe actually my postgage costs are subsidised by the bulk mailers...

You're right though, the real problem is the standards. What we really need is sender validation, and enforced AUPs You send spam, you get cut off. If your ISP doesn't cut you off, their upstream provider does. At the moment, tracking down whose fault e-mail is, is somewhat time consuming.

Being able to work out where e-mail actually originated from would help, too. For example, e-mails to any of my support addresses (for students at the university where I work), from homes in America, can be assumed to be spam :) I need to talk to work about not allowing inbound e-mail that claims to be from our domain - if I can pre-sort anything from @ into a non-spam folder, it would make things a lot quicker, too.

IM 2000 would be another good way of solving this. It would at least cut down on the impact of spam to non-existant addresses, as each takes up less bandwidth, and should help with the zombie problem, as users with infected machines are likely to notice their send-queue full of spam (especially when they run out of quota for e-mail storage).

Anyone else got any good ideas, while I'm at it?

The "primegen" program listed where the Xeon beats the Athlon slightly does not do any floating point.

I looked at the code and played with it a little (I got it from http://cr.yp.to/primegen.html and it seems the benchmark is mostly limited by the implementation of putchar().

My system was an dual AMD Opteron 1.8GHz running Win XP pro with Cygwin. I modified the benchmark to not use putchar() but instead just write the characters to a 1MB buffer, and it got 16 times faster! To be specific, "primes 1 100000000 > file" went from 24.2 seconds to 1.497. Note that it's generating 51MB of output for primes under 100 million. I didn't bother running it for the 100 billion max, but would expect it to be around 50GB.

This is a very poor benchmark since it's just measuring your stdc implementation of putchar and your system's ability to sink data to /dev/null, not anything useful.

People wouldn't be reimplementing DJB's tools under less restrictive licensing (BSD in the case of ipsvd and runit, GPL in the case of libowfat) if he used a reasonable license in the first place, instead of giving out his software with no license to redistribute whatsoever.

I'm using runit rather than daemontools at work because we can't comply with DJB's non-license. Please be a bit more careful before calling bullshit.

It is not GPL'd, it has a BSD lic. But it's source is freely avail. And it is FREE.

Have you actually read the qmail licence? Indeed, can you even find the licence for qmail? The closest thing I can find for a qmail licence is:

http://cr.yp.to/qmail/dist.html

Very restrictive licence. Noone is allowed to distribute qmail modified in *any* way, you cant even change the install paths, you *must* accept DJB's unrelated-to-SMTP ideas on where software should be installed. You cant add patches, etc..

Qmail is not Free Software, and a maintainance nightmare because of the licence.

TeX's bounty is for all bugs, not just security holes.

mozilla.org's bounty is more similar to djb's bounties for security holes in his server software, djbdns and qmail. The major differences between mozilla.org's bounty and djb's are that mozilla.org produces client software rather than server software, and we expect our bounty to be won (multiple times).

TeX's bounty is for all bugs, not just security holes.

mozilla.org's bounty is more similar to djb's bounties for security holes in his server software, djbdns and qmail. The major differences between mozilla.org's bounty and djb's are that mozilla.org produces client software rather than server software, and we expect our bounty to be won (multiple times).

BIND9... don't get your hopes up. The BIND company sells paches for their software. Meaning that if you don't pay them money then you're going to be running an errornouse DNS server. [original emphasis]

Still most people use BIND for two reasons: no one wants to learn the crusty details of DNS and 2) Linux comes with BIND as it's default name library.

Alternative like djbdns should be used.

I wish it was so simple. There are two most important problems with djbdns, though. Namely:

1. unlike BIND, djbdns does not follow RFCs 1034/1035
2. unlike BIND, djbdns is not free software

Don't get me wrong, it is quite a solid piece of software (the laughable cracking contest notwithstanding) but it is not a complete DNS implementation (zone transfers, anyone?) which wouldn'd be such a big deal if it was free software, because anyone (myself included) could make it RFC compatible in few weeks (months at most) but unfortunately it is not.

Also, you should learn about BIND9 (and even BIND8) in the context of cache poisoning. It is not as big of a problem as you seem to believe.

Most people use BIND for two reasons indeed, but those reasons are:

1. BIND is the most complete DNS implementation
2. BIND is free software
3. ("permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted..." etc.) contrary to what you are trying to imply with your patches-selling remark

I am sure many--if not all--GNU/Linux distos will come with djbdns as soon as it is released as free software, for--as I have already said--it is quite a good piece of software, for a one man project.

this page, problems remained up until (at least) BIND 8.2.2-P5. Pretty sad since this attack has been known for ages (especially since it's so easy to prevent).

>ufortunately, djbdns is not open-source.

Incorrect, it is open source.

It isn't GPL.

There's a big difference.

>Until a true open source alternative to BIND appears, we're stuck with it.

By "true alternative" do you mean it has to be GPLable?

Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review. He'll even give you $500 as a reward for your hard work. Find me a GPL program that makes an offer like that.

Now, if he doesn't like your patch, you can post the patch on the internet. You can even put it alongside the source. You can even make an autopatch program that will patch djbdns during make so that dumb users can handle the process

For the disbelievers, here's the source code.

Here's bernstein's statement about the freedom of his software. Feel free to print it out and sign it if you're insane on the idea he can revoke your license.

>ufortunately, djbdns is not open-source.

Incorrect, it is open source.

It isn't GPL.

There's a big difference.

>Until a true open source alternative to BIND appears, we're stuck with it.

By "true alternative" do you mean it has to be GPLable?

Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review. He'll even give you $500 as a reward for your hard work. Find me a GPL program that makes an offer like that.

Now, if he doesn't like your patch, you can post the patch on the internet. You can even put it alongside the source. You can even make an autopatch program that will patch djbdns during make so that dumb users can handle the process

For the disbelievers, here's the source code.

Here's bernstein's statement about the freedom of his software. Feel free to print it out and sign it if you're insane on the idea he can revoke your license.

>ufortunately, djbdns is not open-source.

Incorrect, it is open source.

It isn't GPL.

There's a big difference.

>Until a true open source alternative to BIND appears, we're stuck with it.

By "true alternative" do you mean it has to be GPLable?

Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review. He'll even give you $500 as a reward for your hard work. Find me a GPL program that makes an offer like that.

Now, if he doesn't like your patch, you can post the patch on the internet. You can even put it alongside the source. You can even make an autopatch program that will patch djbdns during make so that dumb users can handle the process

For the disbelievers, here's the source code.

Here's bernstein's statement about the freedom of his software. Feel free to print it out and sign it if you're insane on the idea he can revoke your license.

It's covered with a shiny $500 security guarantee. That's better then the nothingness BIND offers me...

BIND is open source, but that doesn't make it safe and secure. it's probobly more insecure just because of that.

to somthing called DNS poison. Why? Because system administrators are anal and fail to realize that software like BIND is not written to be secure. Hell, DNS was not even designed for such a large internet. The original DNS implementors were bad programmers and designers.

BIND9... don't get your hopes up. The BIND company sells paches for their software. Meaning that if you don't pay them money then you're going to be running an errornouse DNS server.

Still most people use BIND for two reasons: no one wants to learn the crusty details of DNS and 2) Linux comes with BIND as it's default name library.

Alternative like djbdns should be used.

First of all I don't know if you actually need to run certain tasks at certain specific times. If so, you will need to use cron after all. But here's some ideas:

I had a app server that ran a number of critical tasks, and they had a somewhat arbitrary and complex dependency graph. A good analogy would be eBay's indexing cycle: a bunch of stuff has to happen as often as possible, but it's not really important if it takes 30 minutes or 35 minutes or 1 hour to do each cycle.

Also it needed to be easy to extend: a programmer should be able to write the code and "stick it somewhere" to extend the system.

The previous admin had set some tasks to run in cron every 5 minutes, not realizing that after a while some of the jobs actually took 6-7 minutes and growing (you can imagine what the process table looked like after a while, and some of these were not locking resources properly.....)

I came up with a system using Makefiles (takes care of interdependencies and the -j flag will run indepent processes in parallel) and djb's daemontools package.

If you're not familar with daemontools, it is an incredibly tight little set of tools that lets you *atomically* and *reliably* start, stop, and configure daemons, and it lets you turn ANY script into a daemon. It just runs a "run" script you supply, and when the script dies for any reason, it restarts it. So you can create a script like this:

#!/bin/sh
make -C /foo/bar/baz update
sleep 60

and it will run it over and over again. Combine this with resource limits and multilog logging and you have a bulletproof way to keep things going in the background.

So I set up the dependencies in the Makefile, threw in a couple scripts to run all the scripts in a couple "drop box" directories that programmers can use, and documented everything and made a web interface for checking the results. Now it doesn't really matter if the cycle takes 5 minutes or 10 minutes or 30 minutes, the makefiles are run over and over again in a loop, keeping things up to date.

Again, I don't know the specifics of your needs but this is definitely something to consider. Especially if your crontab has grown into a huge confusing mess, and you don't actually care what exact time things are running.

This is not agreed-on "DNS behaviour", it's a flawed feature of BIND designed to try to prevent cache poisoning. See Dan Berstein's notes on BIND's credibility mechanism . We don't need any encouragement to make DNS less secure!

So for all secure DNS resolvers, TTL will still be 48 hours until Verisign works out a way to let people update it themselves.

First, the root servers have different dns server software and OSes, not because Vixie thought of it, but because it is policy codified in the BCP RFC for root servers best practices. In fact, I think he was unhappy about other root servers using non-BIND software in the beginning.

Second, he is being disingenuous about his comments about patents, his company owns at least one patent related to the Verisign "Site Finder" service methodology. Nominum Patent I didn't see any statements by him disparaging his company when they applied for that patent. So it isn't that he doesn't like patents, it is that he doesn't like that Akamai is making money doing third party DNS without paying him money or homage. Note: His commercial, for profit dns server software company has a white paper enumerating the scalability and other problems with BIND, and they use an architecture more similar to DJBDNS than to BIND 9 - separate auth and resolving dns server packages, most modern dns server software uses this architecture to reduce code complexity and improve security and performance.

Third, if he wanted to be the pillar of dns server software that he supposedly is, he could have sent a few goons from Nominum over to Akamai and set up some boxes with his commercial, for profit, "scalable" dns server software and Akamai would have been able to see if his software was able to stand up to the ddos attack better than what they have. If it did, he probably could have gotten a sweet, lucrative contract out of it and been a hero for helping thwart the attack, rather than a hypocritical, self serving competitor hiding behind Open Source to appear credible.

Fourth, Akamai is a single point of failure because that is what they do - offload dns and content load from the biggest companies on the net life MS, google and ebay. No, I don't work there, but I would venture a guess that they carry more traffic than (maybe) any other company. So I am sure it is easy to armchair quarterback and say they should do this and that, but when the attacks are probably at 10's or 100's of GiB/s I am not sure what I would do.

Nominum is also involved in RFID stuff, so I will be interested to see what happens with him and his companies as that ramps up. And who knows what deals have already been made - "the future of DNS is right."

Some DNS software links:
nsd - high performance, uses BIND style files and authoritative only
They have an interesting testing procedure where they run nsd and BIND, have them build responses to the same queries and then analyze any differences: diff analysis
maradns
Powerdns, mysql and a pretty website
djbdns he's grouchy and the no license license thing freaks people out and pisses them off, but people become attached to the quirky but rock solid software.
nstx, ip over dns, yeah...

DJB seems to favor the consumer in the EULA debate.

A recent Slashdot article (or maybe it was one of the comments attached to the article) pointed out an easy cache-poisoning DoS attack on djbdns.

Wrong. dnscache (from the djbdns package) is not vulnerable to poison and never has been. You are probably thinking of previous versions of BIND.

Other plans include replacing BIND with djbdns, and integrating SPF+ with sendmail.

dnscache keeps copious logs as well. You'll want to filter out most stuff on production machines, but it's handy for troubleshooting.

That's an interesting approach, but it's unnecessary. Computers, whether connected to a network or not, only do what they're programmed to do. It just so happens that. today, a lot of computers are programmed (accidentally or otherwise) to execute arbitrary code from unauthorized third parties. There are ways to avoid this, but many programmers are too lazy or inexperienced to care.

Other DNS software

Management tools

twa lets authorized browsers edit the tinydns data file.

ldap2dns converts an LDAP DNS database to a tinydns data file. tinyadmin is a graphical interface to the LDAP DNS database used by ldap2dns.

mkdns converts a MySQL DNS database to a tinydns data file. It lets authorized browsers edit the MySQL DNS database.

sql2tinydns is similar to mkdns.

dhcp_dns watches dhcpd for new DHCP address assignments, and publishes those addresses through tinydns.

tinydyndns publishes dynamic IP addresses authenticated through POP connections.

Servers

ldapdns publishes DNS information from an LDAP database.

MyDNS publishes DNS information from a MySQL database.

Posadis publishes DNS information from BIND-style zone files. Security history: Buffer overflow, allowing attackers around the Internet to take control of the server; fixed in m5pre2 (2002.03.30). Someone announced an exploitable buffer overflow in m5pre2 a few weeks later; the history here isn't clear from the Posadis web pages.

NSD publishes DNS information from BIND-style zone files. Security history: Unclear. The NSD documentation includes bugs like ``Very strange coredump in hash_destroy() that happens sometimes'' without any analysis of their security impact. Is that an exploitable buffer overflow?

PowerDNS publishes DNS information from MySQL databases, PostgreSQL databases, Oracle databases, IBM databases, LDAP databases, or BIND-style zone files. Security history: Unclear, like the NSD security history.

MaraDNS is a general-purpose DNS server.

lbnamed is a load-balancing DNS server.

lbdns is another load-balancing DNS server.

Oak DNS Server is a good example of why novices shouldn't try to write DNS software. The digitallumber.net domain, served by Oak DNS Server 1.0, is inaccessible to a huge number of clients that try AAAA lookups before A lookups: the server incorrectly returns NXDOMAIN for AAAA, effectively wiping out its own A record.

Caches

pdnsd is a DNS cache. Security history: Remotely exploitable buffer overflow; fixed in 1.1.7a (2002.01.18).

MaraDNS can act as a cache.

I don't know why anyone would want to use these caches in place of dnscache .

DNS clients

adns is a DNS client library.

ares is a DNS client library.

perldns is a DNS client library for Perl.

The Buggy Internet Name Daemon [how very professional... *sigh*]

BIND is a monolithic server/cache; it also includes a client library, libresolv. Security history: IQUERY buffer overflow in BIND before 8.1.2-T3B (1998); NXT buffer overflow in BIND before 8.2.2-P4 (1999); nslookupcompla

Why not use djbdns then?

I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns.

If you go to the tinydns site, you can read quite a lot of ranting about the brokenness of BIND and how it doesn't conform to various RFC's. DJB hates BIND with a fiery passion, and his rants make for interesting reading if you have nothing better to do.

Personally, I use one called djbdns. It's extremely small and basically bug free! The author actually will pay $50,000 to whoever finds the first exploit in it or something.

You might want to read the first line of the djbdns security guarantee:

"I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns."

$500 is hardly $50,000 but even if it was $50,000, please keep in mind that a hypothetical non-public exploit of tinydns would be worth much more than $50,000 for anyone who would want to use it seriously. Please remember that by compromising DNS server you can effectively control mail and websites, even without compromising the mail and web servers themselves. I have already seen web traffic for compromised domains routed through proxy servers controlled by attackers (or smtp traffic redirected via external relays, for that matter). This might be very powerful and can be quite hard to detect, especially when you provide correct dns info to internal network.

With all due respect to D. J. Bernstein, even though I do believe that his name server is probably the most secure one in use today, his cracking contest is hardly meaningful. There is an interesting article, The Fallacy of Cracking Contests by Bruce Schneier, published in the December 1998 issue of The Crypto-Gram Newsletter:

You see them all the time: "Company X offers $1,000,000 to anyone who can break through their firewall/crack their algorithm/make a fraudulent transaction using their protocol/do whatever." These are cracking contests, and they're supposed to show how strong and secure the target of the contests are. The logic goes something like this: We offered a prize to break the target, and no one did. This means that the target is secure.

It doesn't.

Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so.

1. The contests are generally unfair.

Cryptanalysis assumes that the attacker knows everything except the secret. He has access to the algorithms and protocols, the source code, everything. He knows the ciphertext and the plaintext. He may even know something about the key.

And a cryptanalytic result can be anything. It can be a complete break: a result that breaks the security in a reasonable amount of time. It can be a theoretical break: a result that doesn't work "operationally," but still shows that the security isn't as good as advertised. It can be anything in between.

Most cryptanalysis contests have arbitrary rules. They define what the attacker has to work with, and how a successful break looks. Jaws Technologies provided a ciphertext file and, without explaining how their algorithm worked, offered a prize to anyone who could recover the plaintext. This isn't how real cryptanalysis works; if no one wins the contest, it means nothing.

Most contests don't disclose the algorithm. And since most cryptanalysts don't have the skills for reverse-engineering (I find it tedious and boring), they never bother analyzing the systems. This is why COMP128, CMEA, ORYX, the Firewire cipher, the DVD cipher, and the Netscape PRNG were all broken within months of their disclosure (despite the fact that some of them have been widely deployed for many years); once the algorithm is revealed, it's easy to see the flaw, but it might take years before someone bothers to reverse-engineer the algorithm and publish it. Contests

The answers it generates are often excessively verbose (e.g. redundant NS records).

This only occurs if you specify redundant name servers in the database. tinydns serves exactly what you tell it to serve.

Third-party documentation suggests a configuration that violates recommendations of TLD operators and most ISPs, which means that you have to redo parts of it once you receive your first delegation.

That is because you should avoid RFC 2317 style delegation. RFC 2317 was written by the authors of BIND:

"If you were running BIND, you'd find it only a little bit painful to receive a classless reverse delegation (setting up one zone file), while you'd find it much more painful to receive separate reverse delegations (setting up many zone files)." (source)

Not flamebait, just ill-informed.

1) djbdns uses separate IP addresses for caching and content-serving for security. Google on BIND and cache poisoning.

2) The timestamps are in machine-readable form for good reason--they are easier to parse in, e.g., a statistics package. If you want to see what your system "is doing" right now, why do you need a human-readable timestamp? If you need to see what your system "is doing" over time, what better way than a statistics package? You "don't have time" to pipe "tail -f /var/log/dnscache/current" through tai64nlocal to get a human-readable timestamp... yet you have time to post silly arguments to /.?

Besides, if you were all that hot and bothered about it, why not just switch from multilog (the logging daemon, which is NOT a part of djbdns) to splogger and send your log messages to syslog (or into oblivion, same difference sometimes)?

3) I've never had this problem. Of course, if everyone else used djbdns instead of the Buggy Internet Name Daemon, axfrdns would be obsolete. rsync+ssh is the way to go. ;-) But honestly, I find your comment to be unmoving: "I did something wrong, and axfrdns broke. Therefore, axfrdns sucks." Whatever.

4a) Of course BIND's zone files are more readable. Like the timestamps in the log files, the zone files are meant to be machine-readable to encourage web or script frontends.

4b) You are NOT forced to name your authoritative servers anything. You obviously did not read the Fine Manual. (Hint: it's right here.)

5) What's wrong with daemontools? Unlike inetd, I've NEVER had exhaustion attacks with programs managed by daemontools. I find it all quite elegant.

I will NEVER go back to the monstrosity that is BIND. djbdns is so much more flexible, intelligent in its design, and it just RUNS. We're approaching 20k DNS records in our database... may not be much, but djbdns handles it all without blinking.

Simple: support for views, and licensing that allows redistribution.

I absolutely, positively require view support, which nobody but BIND that I know of supports. TinyDNS might, but I can't so much as consider it due to the license; we're distributing servers with a fairly custom software environment, and DJB's terms make that a no-no. (This is also why we're using runit rather than daemontools).

Support views in something that supports pulling info (not just zone info, but definition of what the zones are, what the views are, what the ACLs are, etc a la named.conf) directly from a database and I'll be happy as a clam. 'Till then, I run BIND.

It may come standard on 99.9%, but it's only used by 70%, vs 15% tinydns. Plus, the source is not available on 99.9% of the distributions -- it's almost always a binary. E.g, I have NEVER seen sun distribute the source to it in their distributions.

Lots of people would've eyeballed tinydns for bugs, which IIRC (and I might not), is not available in binaries. Plus, the security is guaranteed!

The djbdns security guarantee
I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns.

djbdns has not been accepted, because it's too non-standard. The main thing is the folders.

He creates and uses a folders called /service, /command and /doc, instead of following any UNIX filesystem standard. I guess he is suggesting that we abandon /usr, /bin, /lib, and just throw everything at the root level.

When you

djbdns has not been accepted, because it's too non-standard. The main thing is the folders.

He creates and uses a folders called /service, /command and /doc, instead of following any UNIX filesystem standard. I guess he is suggesting that we abandon /usr, /bin, /lib, and just throw everything at the root level.

When you

Superior.

How's postfix's security record? i.e. Can I set up a postfix server, then go on an 18-month holiday and be confident that my box will still be working when I get back (like I can with qmail)?

You can be very confident that it will be. Postfix uses privilege separation, runs as its own user account (not root), and is designed with a chroot environment in mind. It's also very componentized and designed so that a breach in one component can be isolated without a risk to the others. To the best of my knowledge, there has never been a remote code execution vulnerability in Postfix.

The last major security problem was a year ago and was just a DoS possibility. Even qmail has DoS problems. Before the DoS, in 2002 there was a problem that might allow someone to use Postfix to portscan another system (no risk to the system running Postfix). Both of these were in the older 1.1 version. The 2.x series, released in 2002, has never had a security problem bad enough to warrant an advisory for.

The only other thing I could find is djb ranting about a Postfix problem that has been fixed for over 6 years.

Yea, ok Tet. I'm a troll and that's FUD. It's not like sendmail really is a total piece of shit.

Don't give me shit about Perl either. I can write totally unreadable code in C, Perl, Python, PHP, VBScript, Vb6, C++, Java, shell scripting, and QBASIC. I can also write clean code, readable code in all of them.

It's not FUD, most Slashdotters just have their heads so far up their own asses that it just looks like they sit on top of their necks. Morons around here bemoan Microsoft for its shitty security, then they run out every other day to patch BIND or sendmail. Even assuming you're the 1 in 20 person who actually has a need that only sendmail can meet (which I doubt you are given the odds), the fact that you would suggest that saying sendmail has shit poor security is just "FUD" just serves to prove the point that you're just another one of the idealogical nutjobs that frequent this place.

Give it a rest. It's not FUD because it's true. Sendmail blows a left donkey's swollen nut when it comes to security, usability, and reliability. Just deal with it. While you're at it, ask yourself if you even really need sendmail, or if you're just too lazy to make the switch to something that actually works.

DNSSEC, sweet, doesnt do much although....
DNSSEC: theory and practice
You must be the one spilling so much tripe on his mailing lists over the years.

Well, it is open source. Perhaps you mean it's not free software. Different meaning.

while (<STDIN>) {
$line = split(':', $_);
for $line[0] {
if (/Z/) { # Zone file }
elsif (/+/) { # A Record }
elsif (/\@/) { # MX Record }
etc. etc. etc.
}
}

...since D. J. Bernstein's hasn't been updated for years...

Maybe because it hasn't needed updating.

http://cr.yp.to/djbdns/guarantee.html

You mean, $500.

We tend to blame poor programming skills but the real cause is often market pressure and bad management (no budget for secure programming training, no quality assurance process, pressure to deliver in time even if the program is buggy (e.g. Oracle 6 and Oracle E-Business Suite 11, Microsoft Windows)

Bugs in software are inevitable... its a fact of life.

I disagree!!! Dan J. Bernstein coded qmail, djbdns, and many other really secure programs. Both qmail and djbdns offers a security garantee, not much money though, but enough incentive for a hacker living in a developing country to find a security hole

Dan J. Bernstein on qmail security: (DJB is my hero!)

Why is qmail secure?

The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:

Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 41000 lines of code is a major security risk.

Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad.

As it turned out, fourteen security holes were discovered in sendmail in 1996 and 1997.

I followed seven fundamental rules in the design and implementation of qmail:

1. Programs and files are not addresses. Don't treat them as addresses.

   sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.

   In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)

   Security impact: .qmail, like .cshrc and .exrc and various other files, means that anyone who can write arbitrary files as a user can execute arbitrary programs as that user. That's it.

2. Do as little as possible in setuid programs.

   A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.

   Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.

   Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.

3. Do as little as possible as root.

   The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.

   Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.

   In fact, these programs don't even trust each other. T

We tend to blame poor programming skills but the real cause is often market pressure and bad management (no budget for secure programming training, no quality assurance process, pressure to deliver in time even if the program is buggy (e.g. Oracle 6 and Oracle E-Business Suite 11, Microsoft Windows)

Bugs in software are inevitable... its a fact of life.

I disagree!!! Dan J. Bernstein coded qmail, djbdns, and many other really secure programs. Both qmail and djbdns offers a security garantee, not much money though, but enough incentive for a hacker living in a developing country to find a security hole

Dan J. Bernstein on qmail security: (DJB is my hero!)

Why is qmail secure?

The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:

Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 41000 lines of code is a major security risk.

Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad.

As it turned out, fourteen security holes were discovered in sendmail in 1996 and 1997.

I followed seven fundamental rules in the design and implementation of qmail:

1. Programs and files are not addresses. Don't treat them as addresses.

   sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.

   In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)

   Security impact: .qmail, like .cshrc and .exrc and various other files, means that anyone who can write arbitrary files as a user can execute arbitrary programs as that user. That's it.

2. Do as little as possible in setuid programs.

   A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.

   Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.

   Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.

3. Do as little as possible as root.

   The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.

   Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.

   In fact, these programs don't even trust each other. T

We tend to blame poor programming skills but the real cause is often market pressure and bad management (no budget for secure programming training, no quality assurance process, pressure to deliver in time even if the program is buggy (e.g. Oracle 6 and Oracle E-Business Suite 11, Microsoft Windows)

Bugs in software are inevitable... its a fact of life.

I disagree!!! Dan J. Bernstein coded qmail, djbdns, and many other really secure programs. Both qmail and djbdns offers a security garantee, not much money though, but enough incentive for a hacker living in a developing country to find a security hole

Dan J. Bernstein on qmail security: (DJB is my hero!)

Why is qmail secure?

The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:

Every few months CERT announces Yet Another Security Hole In Sendmail---something that lets local or even remote users take complete control of the machine. I'm sure there are many more holes waiting to be discovered; sendmail's design means that any minor bug in 41000 lines of code is a major security risk.

Other popular mailers, such as Smail, and even mailing-list managers, such as Majordomo, seem just as bad.

As it turned out, fourteen security holes were discovered in sendmail in 1996 and 1997.

I followed seven fundamental rules in the design and implementation of qmail:

1. Programs and files are not addresses. Don't treat them as addresses.

   sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.

   In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)

   Security impact: .qmail, like .cshrc and .exrc and various other files, means that anyone who can write arbitrary files as a user can execute arbitrary programs as that user. That's it.

2. Do as little as possible in setuid programs.

   A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.

   Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.

   Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.

3. Do as little as possible as root.

   The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.

   Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.

   In fact, these programs don't even trust each other. T

Exactly. If you want to find out if your crypto implementation is secure, ask the US government. If they say yes, you've got bugs.


Depends who in the US government you ask. Groups like the US State Department, the Dept of Commerce, CSRC of the NIST and half of the NSA (who has two purposes - one to protect against foreign intelligent threats, and one to exploit against foreign intelligent adverseries.) they want to protect most of the US public (and NAFTA, G8, and NATO interests) - including US businesses - from foreign governments. These groups can give you an idea of what is likely secure as we know in the non-classified knowledge outside the cloak and dagger world of the NSA, GCHQ, CSE, etc.

Mind you, I'm not sure why anyone would need to ask permission to export a public standard like AES. I'm pretty sure there aren't any secrets happening there.

AES was selected through a very open public process, so no knowledge about AES requires export permission. The US Dept of Commerce does regulate Dual-Use items (i.e. items that have a military/dangerous/hostile use and non-military use) including information security software implementations such as toolkits, libraries, and binaries (and object code). Humanly readable source code is still somewhat in disupte, but based on some US state level court cases (Phil Karn and Bernstein) it appears that human readable source code is not regulated.

Hello Coward.

Yes, HTTP is a pretty complex protocol. However, you can write extremely simple read-only servers, such as thttpd or publicfile.

Almost all projects that publish anoncvs also publish web pages, and putting additional files on the web site is much less risky than running a whole new server.

Distribution makes untrusted input problems worse since components of your 'server' can no longer even trust each other.

The version control system doesn't trust the web server, or receive any input from the network.

Thankyou for trolling!

They'll probably have to sue ISC and these guys as well, since there are patches out there to keep Sitefinder out.

Check this one:

http://cr.yp.to/im2000.html ..."Internet Mail 2000" ... no really. :^) Basically, you (user) don't receive the email. You receive a notification: "your email is available". Now: you have to download the email from the site that notified you.

Imagine: I am a spammer. I must now host a server which has the capability to receive $millions of hits from all my wonderful spam-receiving customers. This is the first thing which begins shifting the burden of sending of email back onto the sender.

Obviously it's not perfect, if I were a spammer, I'd probably have all my malware-infected robots be the hosts for sent emails. Buuut... they'd only be active when that malware-infected computer is on. Notifications could obviously be cheaper to send (b/c it's not so bandwidth intensive, just "hey, joe@joe.com has an email available at bob@spammer.com/msgid/12345/hash-password/a1e2ff" ...but, this scheme has the potential to conserve enormous amounts of bandwidth internet wide (mail is "fetched if desired", not "sent no matter what"). If too many reports of spam are coming from a particular server, blacklist that server. Boom. There are a finite # of IP addresses on the internet, and forcing a spammer to maintain servers so their messages are successfully delivered should eventually drive them further and further out of address space.

This speaks really to "trust v. ip address", how much do you trust a residential DSL IP to deliver mail? (not much). How much do you trust Yahoo Mail's IP? (a lot, all kidding aside).

So, what's the transition? Since it is such a drastic change (rather than sending mail, sending notifications), and directly impacts $zillions of installed mail clients, I couldn't wrap my head around a valid transition path until it hit me ... use email! ;^)

Since most mailers nowadays support highlighting of http links, just send "Subject: regular", but make the body: "Internet Mail 2000 message. http://sending.server.com/msg/12345/hash/abc123" ... totally painless transition (apart from vulnerable browsers), until mail programs can be re-architected to fix it. ( if: is_im2k(): fetch( $url_from_message )

Anyway, think about it.

--Robert

Here's what DJB has to say, anyway: Software Law.

A thread on postfix and filesystems.

DJB's take.

My point is that the new filesystems (XFS and JFS, to be sure) offer reliability meeting FFS's proven reliability with better speed because they use newer, more efficient design. FFS with conservative settings is horribly slow compared to XFS or JFS with similar settings.