Portsnap mirrors

As a result of the rapidly increasing usage of Portsnap, I decided a few weeks ago that it was time to add more mirrors. In addition to the original mirrors provided by Eric Anderson (portsnap1) and LayeredTech (portsnap2, which also hosts freebsd-update files and my personal websites), there is now a European mirror provided by Thomas Vogt (portsnap3).

In order to allow users to a "nearby" mirror (at least if they are in North America or Europe) some new DNS entries have been added: If you edit your /etc/portsnap.conf file to include

SERVERNAME=us.portsnap.FreeBSD.org
portsnap will try the two US mirrors before trying the European mirror; similarly, a SERVERNAME of eu.portsnap.FreeBSD.org will cause it to try the European mirror first. Either way, portsnap will only fail if none of the three mirrors are available: These two new entries only indicate an order of preference between mirrors (aren't SRV records great?).

I'd like to add a fourth mirror somewhere in the vicinity of Japan if possible; I have been offered other mirrors in North America and Europe, but it would be nice to offer systems in that part of the world a closer mirror if I'm going to add a new mirror anyway. If you can offer such a mirror, please contact me.

Posted at 2007-03-23 19:00 | Permanent link | Comments

Know your attacker

Which is more secure, a product wherein one security flaw is found each year -- but is only fixed six months later -- or a product wherein one equally serious security flaw is found every week -- but where it only takes a day before the flaw is corrected? This question underlies most attempts to compare the security records of open- and closed-source software; Microsoft's Internet Explorer and Mozilla Firefox come to mind as a good example. More security flaws are uncovered per unit time in Firefox than in Internet Explorer, but they also tend to be fixed sooner, leaving (at least by some reports) a smaller number of "days of vulnerability". Like most good questions, the answer to this one is "it depends". In this case, it depends upon whom you're worried about defending against.

I'm going to be utterly simplistic and divide attackers into two groups: Those who find vulnerabilities in software, and those who merely exploit vulnerabilities which have already been widely published. Obviously script kiddies fall into the second group, while "real" black hats fall into the first group; hereafter I'll just refer to those two representative attackers in place of the groups to which they belong.

If you're worried about being attacked by script kiddies, your job is easy: Make sure you're not affected by any published security vulnerabilities. You make sure that you're subscribed to your vendor's security announcement mailing list and that you install patches they provide promptly; you subscribe to mailing lists like Bugtraq; and in the worst case, if everybody is talking about a vulnerability for which no patch of workaround is yet available, you simply pull the plug. As long as patches are always promptly available, you have nothing to worry about.

If you're worried about being attacked by black hats, life is much harder. Your security doesn't just depend on making sure that you're not vulnerable to any known issues; your security also depends on making sure that you're not vulnerable to any unknown issues which a black hat might be able to find. At this point, you don't care how quickly known issues are addressed; instead, you should carefully audit both the code you are using and your choice of code to use, to reduce the chance that an attacker will be able to find a new vulnerability. Google got this right: Last year, having decided that they wanted to use libtiff, ImageMagick, and gzip (and almost certainly other code as well) they hired Tavis Ormandy to perform a code audit. If they hadn't, odds are that there would be some compromised GoogleBots roaming the Internet by now.

Of course, most people don't worry about black hats, for good reason: They simply don't have anything which would make them a target. A few years ago I attended a talk from the systems manager of the Oxford Supercomputing Centre, where he made the points that

After he spoke about how their security strategy is centered around making sure they have patches installed, I asked how they expected to defend against a black hat who discovered a new vulnerability; his answer (paraphrased from my memory of a two year old conversation) was "we don't defend against such attackers; we're not capable of defending against such attackers; but fortunately such attackers aren't likely to have any reason to bother us".

If, like the Oxford Supercomputing Centre, you're mainly worried about script kiddies, software with frequent but promptly fixed security issues is the most secure software for you. If, like Google, you have reason to worry about being attacked by black hats, the speed with which bugs are fixed is far less important than how many bugs there are and how easy it is for a black hat to find one. Whichever side of the fence you fall on, remember this: The software which is the most secure for you isn't necessarily the software which is the most secure for me.

Posted at 2007-03-21 02:00 | Permanent link | Comments

FreeBSD Update SMP kernel bug

In the copy of FreeBSD Update distributed with FreeBSD 6.2, there's a bug in the handling of SMP kernels. On the i386 platform, the SMP kernel (as distributed with the release) identifies itself as 'SMP-GENERIC'; consequently, if FreeBSD Update is run on a system which is running an SMP kernel installed in /boot/kernel (the default location on a multiprocessor system), FreeBSD Update will not realize that the updates it has for the SMP kernel apply to the kernel in /boot/kernel (which it thinks is a 'SMP-GENERIC' kernel). On the amd64 platform, the problem is worse: FreeBSD Update will replace the SMP kernel with a GENERIC (single processor) kernel.

I've committed a fix to -CURRENT and will be committing it to 6-STABLE and 5-STABLE early next week. Assuming no problems are found with this fix, an Errata Notice will probably go out some time around the 14th of March.

Posted at 2007-03-04 00:45 | Permanent link | Comments

Recent posts

Monthly Archives

Yearly Archives


RSS