OpenBSD Journal

FreeBSD/OpenBSD Firewall comparison

Contributed by Dengue on from the courtesy-of-BSD-Today dept.

Noryungi writes : "There is an interesting article on BSD Today comparing OpenBSD and FreeBSD firewalls. The bottom line? OpenBSD is great but FreeBSD has been chosen because of its "-current" and "-stable" branches. Is it me or do I smell a flame war coming up? =) "

Jim O'Gorman's article brings up some interesting points. Upgradeability of IPFilter on OpenBSD seems to be a hot-button issue for a number of people.

(Comments are closed)

  1. By Nobody You'd Know () on

    The point: OpenBSD is released every six months. If the author of this article honestly thinks he should upgrade a production machine in any way except for patches more often than that, he has no business writing articles about computing, much less security. Especially considering that he's talking about updating to FreeBSD "-stable", in which bugs like if(a = b) vs if(a == b) are a regular occurrance. Ahem, ahem... RedHat BSD... ahem.

    Now, the proposal. We take the latest release vresions of FreeBSD and OpenBSD, respectively 4.0 and 2.7, apply known security patches (respectively, lots and none,) and if the Free guys want to, they can install their "SecureBSD" stuff too. The Free guys can modify any configuration files they want, disable whatever services they want, so long as they leave in all the services OpenBSD provides by default and don't install any third party software. The OpenBSD machine will be configured only insofar as the installation script allows.

    Then, we'll announce the IP addressses and DNS info for the machines at DefCon, and offer cool swag, a few microseconds of fame, and $50 worth of pizza to the first person who sets up a webserver on one of the machines that displays the logo of the OS on the OTHER machine. Without, of course, the benefit of an account or any passwords.

    We'll repeat the experiment a few times, letting the Free guys reinstall and patch the hole exploited in the previous round each time. We'll also test each exploit used against the other machine to see if it would have worked.

    The game will end when the FreeBSD guys tire of all the bad PR.

    1. By Jim () on

      > OpenBSD is released every six months. If the > author of this article honestly thinks he should
      > upgrade a production machine in any way except > for patches more often than that, he has no
      > business writing articles about computing, much > less security.

      Your first line makes the point for me. OpenBSD is released every six months, which is really great for a OS. The problem is that is a month after say 2.7 comes out, there is a big flaw in IPF that could lead to a exploit of the box that is a big issue. And that is what lead me to change platforms.

      When a issue like that comes up (and they will happen) there is no quick way to patch the OS to have the newest version of IPF. If it was not for that, I would not have switched.

      Really, I expected flames from this paper. But if you read it, I never say that OpenBSD is a bad OS, just that it did not fit *our* needs at the time. I do not tell people to switch at all, and I do not insult either OS. If in the future there is a easy way to upgrade IPF in OBSD then we may switch back.

      Really, I have gotten alot of flames. Most ignore the fact that I say the only services that run on the box is IPF and OpenSSH. The only real point that anyone has made yet has been about the potential for a hole in the libc in FreeBSD would affect the two services that I run.


      1. By Nobody You'd Know () on

        First off, let me note that I rewrote my original comment 4 times, removing flamage every time. I tried hard to be reasonably polite without diluting my point. I realize some people might pointlessly flame, but if I wanted to do that, I'd have been a -whole- lot crueler than I was.

        That said: I do not speak for the OpenBSD developers, but the standard policy for OpenBSD has always been to fix bugs before they are known exploitable, and if a problem is found that is even -possibly- exploitable in released code(say, the ipf shipped with 2.7, although for clarity's sake, there is no such problem known as of now,) they release a patch or replacement immediately. Note the 2.6 RSAREF issue as an example of this sort of thing. As it turned out, the uses it is put to in the default install were not exploitable, but they released a fix for it before they ever even had that knowledge - which is the right thing to do.

        For that reason, I cannot envision you having a security problem that wouldn't be fixable at least as quickly as you could fix FreeBSD. Besides, who cares how easy it is to upgrade ipf to plug holes when you have megs upon megs of essentially unaudited code linked against your network service daemons?

        Off-topic aside: wow, an actual -chain- of replies to something posted on What is the world coming to? :)

        1. By Jim () on

          > the standard policy for OpenBSD has
          > always been to fix bugs before they are known > exploitable

          Yes, but things happen. And as OpenBSD is shipped, IPF is not enabled in a default install, so if there was a exploit for it, it would not hurt OBSD's track record on default install security. I do not see how one could fault OBSD for a IPF problem. IPF is not part of the OS.

          > I cannot envision you having a security problem > that wouldn't be fixable at least as
          > quickly as you could fix FreeBSD

          I disagree with that. Based upon what I have seen on the IPF mailing list, most problems/updates are done by Darren in the core distrubition, then imported into other projects. If there was a exploit for IPF and I was running FBSD, I could take the tarball, unpack it, build it, reboot and be done. On OBSD I would have wait for it to be included in a patch for the OS, or wait for it to be included into -current (which we would not want on the firewall anyhow).

          That gives me a lack of control on OBSD. Usally OBSD is really good about giving the user complete control over everything, from the install script (which I love) to what services are enabled on first boot. IPF is one area where the end user is not in control, and that I do not like.

          On top of security problems, there are also issues of new features. If there is a newer ftp proxy in a new realese of IPF that I want to use, and it is not a security issue, simply a convience, that would not be in a OBSD security patch. I would have to do without untill the new release.

          Hopefully, before 2.8 comes out the OBSD developers will have the time to look at the way IPF is intergrated into the OS and gives users a better way to upgrade.

          > Besides, who cares how easy it is to upgrade ipf > to plug holes when you have megs upon megs of > essentially unaudited code linked against your > network service daemons?

          This is the most valid point that people keep bringing up, and one I would really like to look into. What are the chances of a FBSD box running just IPF and SSH and *nothing* else being able to be exploited by say a problem in the libc that the system shipped with? What type of attack would need to be placed against you for that to happen? If someone is that determined to break into your system, would it not be more likely for them to physically gain access to your system? Or compromise someone with access?

          My point that, from my POV, that would have to be a pretty determined attack. The type of attack that would use more then just network based attempts. To that type of attack, how well would OBSD hold up? Even if it is the best security OS around configured by a very good admin, physical access will still compromise the box.

          Is there a flaw in that thought? Is there something I am missing? I just do not see someone going through effort of exploiting a libc flaw that linked against IPF when they can just sneak into your building and spend *alot* less effort.


          1. By Theo () on


            It seems like you are totally unaware of our errata.html page. What is it about patches with detailed instructions that make them so difficult to apply? What do you do instead, re-install a new -stable release every 3 weeks when they move more stuff into it?

            That said, we do not have the man power to maintain a -stable branch.

            I think you are trying to lame the blame for an ipf bug on our shoulders, and I do not understand why that is. Even then, I have heard of no way in which this can be used to break into the firewall, as far as I understand, it can just cause a crash.

            1. By Jim () on

              Really, I am suprised that this has gained as much attention as it did. I think I am going to post to the mailling list this morning making a few of these points, but I will also place them here.

              The eratta page is nice, and I like the way the paches can be applied to the system. I have used them many time with success. Plus, I understand the limited hours that can be spend on OBSD, and I would rather them go into -current then a -stable tree. I think that that helps the project the most.

              And yes, there is no exploit for the IPF bug I referance in the article. I hope I did not make it sound as if there is one. I belive I said that there is a possiblity that one could be deleloped.

              Really what it comes down to is this: The way IPF is intergrated into the OS the control as to what versions of IPF and when they are updated lies in the hands of the OBSD devolpers. While I trust that they have everyones best interest in mind when they decide what versions to intergrate into the source tree, I like to have the ablity to make the choice (and potential mistake) for myself. I feel I have the knowledge to weigh the pros and cons for *my* faclity better then a OBSD devolper and I can therfore make a better decision as to what *we* need. If a user comes to me needed a feature that say a new real audio proxy in IPF will give them, but it is not in -current or a patch on OBSD because it is a little less stable in certian circumstances, if I decide to give it to him, I should have that ablity.

              This is not to knock the OBSD devolpers, in writing a OS they have to keep the general good in mind, not my faclity. So in keeping with the OBSD ideal it would be better not to have the potenial bugs interduced into the OS. What I say I would like to see is a way to update IPF on my own, without relying on someone else to merge anything into -current or a patch file. I want that control. Right now, OBSD does not give me that control, FBSD does.

              Which is something else I have to say. ALOT of people have said that I am OBSD bashing. PLEASE show me how. I REALLY did not have that as a intent at all. I use OBSD for a number of things, all I wanted to say in this paper is that for *our* firewall, because of these reasons, FBSD is *for now* the better solution. I *never* say it is a bad OS, or it is bad for other purposes (as a shell server for untrusted users it is *wonderfull*, as a IDS platform it is *wonferfull* etc.).

              Really, OBSD bashing was not my intent. And I am sorry if I worded something poorly that could be taken as bashing.


              1. By Intrepid| () on

                * You wrote the article so it would gain attention. You agreed to its placement on a web page that such OS users would read it. How can you say you are surprised? Correlate your actions to analgous situations in Real Life. You still want to think this wouldn't gain attention? Please.

                * OBSD bashing was achieved. You hammer an OS when you should be solving the error or leaning on the app developer to fix the error. You did neither. When this was pointed our ealier, you wrote if off as flaming. iow, you didn't consider it as valid, although it very much is, and thus your actions continue to mimic that of a basher.

                * When you write for a community, and don't consider the community well, don't be surprised when your own words come back to haunt you.

      2. By Intrepid| () on

        There was a big flaw in IPF. So you changed to a platform with known exploitable problems instead of waiting or leaning on a patch? Hmm.

        FreeBSD has a version called stable. So you went by word that it was, indeed, stable. Over a code audited OS. Hmm.

        You even claim of your switch to FreeBSD caused "no loss in security" yet someone has already pointed out a flaw in that in the Talkback under the article. And here you are still defending the switch. Hmm.

        Oh, and you ran to the platform you were most familiar with. Hmm...rather telling. Forget for a second your discussion under "Base OS" is rather flawed in not considering NetBSD. Not that I would have run a firewall on NetBSD, just that if you were honestly going for the "best solution" you need to open your eyes and evaluate everything on your own. You were unable to do that even by your own changing criteria.

        Hence your need for the subtitle of your article. Which turned it into a comparative article of a specific soluation in a speciric situation, not really a good general article on open sourced BSD based firewall solutions. That's really why you were expecting the flames--it's like saying your hand will get burned if you put it into a fire. You're doing a comparison and you don't even really understand the one OS very well. But instead of saying, "I don't know enough" you'd rather blame the OS for it's "marketing" (marketing??? gimme a break, the claims on their web page are well supported). Seems to me you got scared and ran.

        The thing that pisses me off about your article isn't that there was a problem in OBSD distribution. OBSD users know that there are a lot of areas in the OS that can be improved; that's why some people enjoy using and developing for it in the first place. What made me shake my head was that you made little distinction and rather enjoyed muddling the difference between evaluating a *secure OS* versus the *best solution*.

        You might say think that you were going for the best solution. Then why bash OpenBSD "marketing" (how did you come up with that term anyways?)? What about your inability to apply patches and code? No, I don't agree with the emails on the ipfilter group because you could have adapted code fixes to patch up the OS. Can't do that?
        Instead of leaning on the developer of ipfilter to come out with patches for an OS it supposedly ran on, you dropped the OS entirely.

        "Switching back would gain us nothing." Except a secured base OS.

        Face it--the switch was begun because you were uncomfortable in finding a better way. You feel assured in your change not because it is more secure but because it *feels* more secure according to your criteria and your familiarity with FreeBSD. Note that your criteria is to use a non-code audited OS as your base OS.

        Your have so many flaws in your reasoning and in your firewall, I could be here all day spelling it out. Then again, you were expecting that and the flames anyways.

        1. By Jim () on

          I can tell you are angry, but I really cannot tell why.

          From what I can tell, you seem to be overlooking the fact that the only services this box would have is IPF and sshd with no std user accounts. I am open minded so you are welcome to convince me other wise, but my question is this: What would the code audit gain me other then a obscure libc error. My point is a attack that would discover that sort of flaw would do more then just network based attacks and be able pentrate my physical security.

          As for everything else, really you seem very upset about something and I don't feel as if any explantion I give would be listened to by you, so I am not going to bother right now.

          Later on after you calm down a bit, please post again and explain the problems that you have with my decesion in less of a ranting manner and I will be more then happy to address them. Mr Nobody disagress with me, yet he has been able to present his ideas in a sensible way. Take a note from him.


          1. By Intrepid| () on

            First off, writing aggressively and stating one is pissed does not equate to being angry. To this day, few people can figure out when a person is angry over the Internet; indeed, many reputations are built on the perception of being angry because for others, it's just easier to write it off as such. Your loss.

            Second, if you don't feel to give an explanation, you just wrote off any future writings of yours as personal speculation and subjective, nothign more. But thanks for admitting to that.

            Third, if you cannot clearly understand the objections, mainly criticisms of your lack of objectivity and logicalness in choosing what OSs to compare and the ability to blame OBSD for an IPF failure, so be it. It just adds to your ability as a pseudo-journalist.

        2. By action () on

          You seem more pissed that he didn't include NetBSD in his article. Why stop there? Why not include minix? Mac OSX, Linux? NT? You've posted the same talkback on other sites, and you seem to have missed his message, clearly stated in the article:

          Also, in this paper I will state what worked best for us at the time. What might work best for us in a year may be different. Just like what will work best for you now may be different from what we chose. Take the information in this paper, add it to information drawn elsewhere and form your own conclusion for what will be best for you.

          I get the impression that you skimmed the article, noticed the lack of NetBSD and decided to start flaming. Get over it.

          1. By Intrepid| () on

            Because NetBSD fills the initial criteria of the base OS of the author. Linux, MacOS X Server, and NT do not--they are not fully open sourced cores that are BSD derived.

            Why do you have a such a hard time comprehending that? You bought the author's elimination of commericially firewall solutions. You don't hold the same, equal criteria down to the OS choice?

            You have to draw a line somewhere based on fair and objective criteria. Of course, consideration needs to be given to personal interests. But if the article is going to be taken as more than flame-bait repackaged as a web article, it needs to keep those criteria fair. This article doesn't.

            I'm not surprised you have difficulty understanding this. Too many people take at face value comparisons that are, upon analyzation, really just talk. That's what this article was.

      3. By Noryungi () n o r y u n g i @ y a h o o . c o m on mailto:n o r y u n g i @ y a h o o . c o m

        I am definitely not an expert in *BSD, but here is a question that has bothered me for a while regarding OpenBSD:

        One common criticism I hear repeated again and again when it comes to its iron-clad security is something like this: "Yeah, well, OpenBSD has great security -- but only because few people use it. If it was used a lot more, it would also get its fair share of security issues".

        Also, given the announced merger of BSDi and FreeBSD, Jordan K. Hubbard (lead developer for FreeBSD) has promised to give OpenBSD "a run for its money".

        I was wondering what more specialist such as Jim and "Mr Nobody" (as well as "Dengue") think about these: is OpenBSD really using a strange form of "security-through-obscurity". And is it possible for FreeBSD to catch up with its audited cousin?

        Please note: this is a very serious question -- I do not want to start a flame war here... Just to launch a wider debate, so to speak.

        1. By Jim () on

          > is OpenBSD really using a strange form of "security-through-obscurity"

          No. Not at all. They have audited there code base to ensure there are very few problems (there can never be no problems). For proof, look at BeOS. I do not have numbers on the number of people that run BeOS compared to OBSD, but I *belive* it is less. There is a exploit that will crash a BeOS IP stack. There is nothing on that level on OBSD. It does not matter how many people run a OS, if there is a problem sooner or later it will be found.

          > And is it possible for
          FreeBSD to catch up with its audited cousin?

          I dunno. With enough effort anything is possible. This is more of a wait and see what FBSD project does with their new resources.

          Security has never been the focus of the FBSD project remember. They are meeting the goals they set out for. Are they going to change some of their goals? I would not could them out, but it is no sure thing either.


        2. By Nobody You'd Know () on

          The correct answer to your question, in summary, is: No. No amount of use is going to turn up the kinds of careless programming mistakes that are commonly found in other operating systems.

          The reason is that a dozen or so people have spent -years,- some of them working what are normally called full time hours, running those kinds of errors out of the code. Nobody else even comes close.

          Now, I can't make you believe. If you want to believe, you either need to read code and understand it, follow security lists and get to know developers, find someone you trust and take his word, or else just plain out assume. Some of those methods are better than others.

        3. By Nobody You'd Know () on

          As the title says, I apologize for the double reply. I forgot to mention the bit about Jordan Hubbard talking about giving OpenBSD a run for its money. (Note added after writing: this is a bit long and rantish. If you don't like that, don't read it. I don't have time to edit it right now.)

          Let's pretend for a moment that he finds 12 people who are all as capable as the OpenBSD audit team and want to spend a few years securing FreeBSD.

          Let's pretend they use the OpenBSD methodology for doing so, such that the results can reasonably be expected to be similar in terms of the quality of the code comprising the operating system itself.

          Now, are they going to change their configuration so that it is secure by default, even though that will mean alienating users who want everything enabled without having to mess with it? Are they going to quit installing every package under the sun, start looking for security audit work in their ports, reject and/or remove ports that have unworkable problems even if those ports are in common use, and so on?

          Of course not. They're trying to be "RedHat BSD." That directly conflicts with security, and always will. (See Bruce Schneier's commentary at regarding complexity vs security. Essentially, you can regard a linear increase in complexity as an exponential decrease in security.)

          And yes, to counter the obvious inane reply, they COULD change their focus. They could give up on trying to be a better Linux, give up on being the ultimate in user friendly, cut their codebase to a minimum even when it means losing functionality, and so forth. But ask Jordan if they will. You already know the answer.

          He might tell you they'll secure their OS without compromises or loss of anything they have today. If he does, see if he wants to buy some oceanfront property in Mongolia. FreeBSD people have been forming committees, appointing officers, putting up mailing lists, and so forth with the word "security" in them for years. So far, nothing but hot air and fixes for demonstrable exploits have emerged. Even HP can do that. Who cares?

          1. By Still Nobody's fan () on

            >Are they going to quit installing every package under the sun,
            Is there _any_ proof to that? Last time I was installing FreeBSD I finished with base OS only, with not a single package installed whatsoever. Of course, I had opportunity to select among _loads_ available packages but nobody was forcing them on me. Care to explain how OpenBSD differs on this respect? Does OpenBSD claim that all available ports from it's ports collections are secure? Does OpenBSD audit them?

            FreeBSD auditing team works and does its job well no matter what you think about them. You also forgetting that OpenBSD's source tree changed are monitired by more than one FreeBSD committer and all _reasonable_ get imported into FreeBSD. The same holds true for NetBSD, so security situation with other BSD's is not as bad as you trying to convince everyone. Again, stop being religous, get your facts straight.

            1. By Nobody You'd Know () on

              Explain why Free has almost as many exploits as Linux over the last couple of years while Open has had precisely zero that weren't merely denial of service.

              I've seen lots of evidence that FreeBSD people are well intentioned, intelligent, and in some cases hard working. However, in the area of security, there is little to show for it as yet.

              And, getting back to the point, which was about "upgrading" ipf, I make two notes which, if people are reasonable, should END this discussion:

              1) When a -real- problem emerged, the Open people had a patch out almost instantaneously which upgrades your system's ipf. This is hardly the "impossibility" that the original author Jim suggested it was.

              2) Most of the recent versions of ipf have been buggier than the previous version. "Upgrading" is not always the right answer when the newer version is brand new. (And this is not intended as a slight against ipf; it is true of almost any new software, the primary exception usually being BSD based operating systems, which all seem to improve with time:)

              1. By Bill Marquette () on

                To add to point number 2 :) Since Darren Reed has already released 3.5alpha does that mean that we should immediately bring it into the tree? No! I've mentioned this on another board, 3.4.x where x is <4 isn't stable (and I'm NOT saying .4 is stable), that's why there's a .4. Granted the issue isn't totally about stability, but that's the first thing that stands out to me when we start talking about OBSD being more stable (or less so) than FBSD-STABLE. The 3.3 tree had TONS of problems up until it hit double digit releases. Because of that, we kept with the 3.2 tree. For those that care, you can import the 3.4 tree into OpenBSD, I've done took less than 30 minutes. No it wasn't as simple as untar and compile, it took me a few minutes of looking at how 3.3 had been applied. All the same, it wasn't hard. Will it break my CVS updates? Not especially, although they won't be clean...but hell that's part of what CVS is for!

          2. By I am a monkey, my name is Bengo, and i like to cli () on http://www.

            Just surfing around, as a current linux user and flirt with OpenBSD, i discovered and this article (and series of replies)

            I can't speak for everyone, and i know i certainly run *A LOT* of bleeding edge code, but as far as default installs goes this comment irked me:

            >>Now, are they going to change their configuration so that it is secure by default, even though that will mean alienating users who want everything enabled
            without having to mess with it?

            If Install blahBSD or blah release of linux, as a someone just seeing what the os is about, if i want to mess around with something i'll INSTALL it. if i'm a windows jockey just getting to know what this unix stuff is, i'll get a book that tells me how to set up, mySQL say, or apache. and they're free, and i can do that, and that's great.

            But i see NO reason why these services should be enabled per default! Picturing myself as someone just starting w/unix, if something sounded interesting i'd look into it, and mess with it, but why on earth should distrobutions be shipped that have things like nfs, apache, finger, etc. enabled!?

            Call me reductionist, call me paranoid, if i buy a car, i'll look into getting a 1000watt stereo, i'll look into putting nitro boosters into it, but if these were default items, then why the hell should i be bothered with them? it only takes time that i didn't want to give to unsinstall/disable the program, and that's just a waste.

            right okay. so in conclusion. who really does want "everything enabled without having to mess with it"

            1. By Bill Marquette () on

              However, alot of people make one of two choices. Install all. Install default. How many people (discounting the ones that read here, cause we've already established we aren't the norm) really choose "custom install" or "install bare minimum, I'll do the rest of the work later when I figure out how to install packages". If you're sufficiently familiar with an OS you might (probably will) try the later, however as a new user you're likely to decide that the developers know best. I for one when I'm first learning an OS (make sure it's behind a nice firewall) and take the install all option. Why? Because I don't want to deal with the details of the system, I want to get a feel for it first in all it's glory, then I'll make the decision after having SEEN the OS what to remove. If it means installing twice, it's not a big deal, I was already prepared to install it again. Those of you that still have your original OpenBSD install running as it was (with exception to package addition) when you installed it, raise your hands. I'll bet that nobody does, not because you all suck, but because we all tried it then maybe found a better way to run it. I've built a number of OpenBSD systems, each one gets closer to the zen that I'm striving for.


      4. By Nobody You'd Know () on

        Problems that libraries can have(whether libc or some other library):

        1) Buffer overruns. If they happen in library code that is given user input, that's no better than if they happened in your code. You still lose.

        2) Lousy use of environment variables in setuid programs. Some libraries are partially configurable this way. In a setuid program, if they don't disable that feature, you're just as toasty as if your program had trusted the environment itself. This is particularly bad in commercial products, where it is not always even documented, and in which it often takes the form of bad use of PATH and/or library linkage info.

        3) improper use of /tmp. This is less common in libraries than the other two are, because use of /tmp is less common, but that won't make you feel any better if it happens to you. Race conditions suck.

        4) Perhaps the most common problem: badly designed interfaces that have no replacements. OpenBSD has provided better replacements for several of these; others have been slow to follow.

        5) Logic errors permitting operations that should not be allowed. This is more common than you might think, both in libraries and elsewhere(for an example of 'elsewhere,' see the 2.6 OpenBSD fix that prevents ordinary users from changing the media setting on a network interface. It can happen, even in BSD variants!)

        There may be other categories(almost certainly are, in fact.) These are the commonly reported ones in recent times.

        Note that none of these are necessarily obscure, hard to exploit, or even any different from bugs in programs themselves. Some may be. Some won't be. The point is, if you are running programs linked against libraries you can't trust, you can't trust the programs either. ANY of them.
        ssh might be functionally no better than rsh in such conditions.

    2. By james phillips () on file:/dev/null

      Wouldn't a more accurate test as a firewall system be to enable the exact same services(i.e. IPF and SSH/OpenSSH), on identical machines, load the exact same rulesets on both machines, and place both in front of identical webservers and hack away? After all, the point being made was about Open|Free BSD as a firewall , not about which provides the more secure default installation.

      1. By Nobody You'd Know () on

        That'll make the contest take a lot longer, but it won't change the results.

    3. By nameless () nameless on mailto:nameless

      What has me really curious is that "Nobody"
      references gaping holes in FreeBSD, yet I
      have found no outstanding remote root exploits
      against FreeBSD on bugtraq, cert, freebsd-security, rootshell, etc etc etc.

      What holes are you refering to?

      1. By Nobody You'd Know () on

        The ones nobody has exploited yet. How do I know they exist? Consider:

        OpenBSD found, fixed, and has mostly forgotten about over 3000 bugs in the code they started with, as of a year or so ago. That wasn't counting all the efforts, but rather the main audit work. FreeBSD has received no such audit.

        Now, if you want to live in a dreamland in which none of those bugs exist in FreeBSD or else they exist but have no security consequences, so be it.

        Some of us prefer reality.

    4. By Nobody's Big Fan () on

      It's nice to be religious fanatic. OpenBSD is secure, all others are not, end of discussion. If only life was so simple.
      You seem to believe that OpenBSD is soo secure than nothing wrong can possibly happen with installed with default settings server between major OS releases. Well, that's simply not true and recent semconfig and IPF wulnerabilities can serve as good examples of otherwise.

      And while I like OpenBSD, I cannot stand someone bashing other OSes, even Linux, using only religios beliefs to support flames. The a=b vs. a==b bugs DO NOT HAPPEN in FreeBSD any more often that they are hapening in OpenBSD. Rather than picking up distant rumours from sloppy magazine writers, you'd better do your own research. The bug mentioned in the publication which probably gave you this idea was actually in long defunct ifdef'ed code. Get your fact straight.

      It also will be rather interesting to see 'lots' of security patches for FreeBSD. All latest security advisories were affecting Net-, Free- and Open- BSD's equally.

      1. By Nobody You'd Know () on

        First, the points raised, then some other stuff:

        1) OpenBSD pretty much -is- so secure that if I keep up with any patches that may be relevant to me on their errata page, I never need to mess with anything else except new releases.

        2) I actually read code. Particularly diffs that appear to fix something interesting. A nasty habit I acquired in relation to my profession. I've seen some pretty gross things fixed in both Open and Free. The difference is, the Open people fixed them -before- they got published and -before- the kiddies were using them. The Free people fixed -some- of them by reading the fixes the Open people did, thus avoiding the "work" part of "audit work."

        3) The latest security advisories include Kerberos. Note that Open was not affected. Perhaps it is YOU who should do some research and get his facts straight.

        By the way, I do see legitimate uses(many!) for FreeBSD. I do not include network security on that list, but I probably would if Open didn't exist.

        1. By Fan () on

          Nope. You still are having problems with reality:)
          The followign is a quotation from FreeBSD-SA-00:19 security advisory which clearly states that OpenBSD is affected by the problem too. If is of any consolation, NetBSD issued advisory on it's own which states just due to partial fix made in 1994, the consequences for Net- and Open- BSD's are not as severe as they are for FreeBSD, but reported bug constitutes serious security break nonetheless. It was FreeBSD auditing team, not OpenBSD's one who has found the problem. I guess this fact should stop you from dismissing FreeBSD auduting team as something not serious.
          Category: core
          Module: kernel
          Announced: 2000-05-23
          Credits: Peter Wemm
          Affects: 386BSD-derived OSes, including all versions of FreeBSD,
          NetBSD and OpenBSD.
          Corrected: 2000-05-01
          FreeBSD only: NO

          I. Background

          System V IPC is a set of interfaces for providing inter-process
          communication, in the form of shared memory segments, message queues
          and semaphores. These are managed in user-space by ipcs(1) and
          related utilities.

          II. Problem Description

          An undocumented system call is incorrectly exported from the kernel
          without access-control checks. This operation causes the acquisition
          in the kernel of a global semaphore which causes all processes on the
          system to block during exit() handling, thereby preventing any process
          from exiting until the corresponding "unblock" system call is issued.

          This operation was intended for use only by ipcs(1) to atomically
          sample the state of System V IPC resources on the system (i.e., to
          ensure that resources are not allocated or deallocated during the
          process of sampling itself).

          In the future, this functionality may be reimplemented as a sysctl()

          III. Impact

          An unprivileged local user can cause every process on the system to
          hang during exiting. In other words, after the system call is issued,
          no process on the system will be able to exit completely until another
          user issues the "unblock" call or the system is rebooted. This is a
          denial-of-service attack.

          IV. Workaround

          None available.

          1. By Intrepid| () on

            False. You're overblowing the nature of the advisory.

            Also, NetBSD and OpenBSD both followed up stating that it was not as severe on their systems. This is something the FreeBSD obviously forgot to check; they simply laid it down that they were vulnerable in the like. I don't consider that very competent on their part to state another system is vulnerable to the same extent as their own bug, when in fact, if they had *looked*, they'd see it wasn't.

            btw, OBSD has a patch for this, shortly after it was announced on bugtraq. Also, 2.7 and betas were not vulnerable, per Theo's followups.

            Oddly, I'm not sure why it takes 2-3 days for FreeBSD to post their advisories.

            1. By Fan () on

              I am reading the same Bugtraq as you do. I just do not filter out facts that do not agree with my religion. NetBSD and OpenBSD _were_ affected. That is the point I am trying to make. I know that consequences were not as severe as for FreeBSD and I have mentioned that in my posting. But systems were affected affected and you cannot claim they weren't.

              >btw, OBSD has a patch for this, shortly after it was >announced on bugtraq. Also, 2.7 and betas were not
              >vulnerable, per Theo's followups
              FreeBSD fix appeared in CVS on May 1 11:29:44 2000 UTC:

              1.26 Mon May 1 11:13:40 2000 UTC by peter
              Remove the undocumented, flawed, broken-as-designed semconfig() syscall.

              As far I can see, that is several hours _before_ corresponding commit appeared in OpenBSD CVS repository. What makes you belive that FreeBSD team is any slower in reacting to security problems?

              I as wrote already, it's fine to be religious fanatic. It's not fine to blame everyone who does not share your own blind faith. I do refuse to believe that most bugs could be found by just looking at the source code, no matter how good the programmer who stared at the code is. As far as I know nobody has witnessed Theo walking on water yet and he did not demonstrate any other super-human abilities yet, so there is no reason to believe that the code he has ever touched has become sacred in any way. If this belief gives you (false) sense of security, fine. I just hardly see how it can give you right to despise other people as fools and incapable programers.

          2. By Nobody You'd Know () on

            This isn't a "security breach" any more than the ability to write and compile a program is a security breach. The results of the following program are MUCH, MUCH worse than anything that could have come from your so-called 'breach,' and yet any user who could have done what you are talking about can do this:


            for(;;) fork();
            return 0;

      2. By Intrepid| () on

        >All latest security advisories were affecting Net-, Free- and Open- BSD's equally.

        You must not be reading the same Bugtraq everyone else does. Some of those advisories never checked the other OSs--FreeBSD recently released one that stated a bug was in NetBSD and OBSD but in reality, they were in neither.

        1. By Fan () on

          Please go and re-read the advisory. Being affrected "not as severely" is not equal to "unaffected".

  2. By Noryungi () n o r y u n g i @ y a h o o . c o m on (none)

    ...Feel the love. Smell the flames! Let the war begin! =)

    Sorry, I could not resist.

  3. By Beldon () on

    "Don't know much about TCP
    Even less ICMP
    Don't know how to make a subnet class
    Even script kiddies would kick my ass
    But if an OS that can be bought
    Will install securely by default
    What a wonderful thing that would be

    Don't know much about LAND attack
    Don't know how to spoof an IP stack
    Don't know much about the port I'm on
    Can't decide to leave a daemon on
    If I install OpenBSD
    And it does most of my work for me
    What a wonderful thing that will be

    Now I don't claim to be a sys admin
    But now broadband's in my town
    And I have to put something between me
    And the people who know how to bring me down

    Don't know much about DDoS
    And my shell programming is a mess
    Don't know how to build a firewall
    Don't know much about nothin' at all
    But if I can shield my root account
    Without emptying my bank account
    What a wonderful thing that would be."

    1. By niekze () on


  4. By bengt () on

    then we should stand by this fact and simply rename -current to -stable.

    Everybody else in the software world means approximatly the same thing with -stable and -current. If OpenBSD thinks that -current is really everybody elses -stable, then we should explain this to the world so that it can understand.

    1. By Nobody You'd Know () on

      But it isn't. The FreeBSD -stable branch is at least known to compile and appear to work correctly. OTOH, OpenBSD -current is not even guaranteed to compile, and there are occasions when in fact it does not.

      The correct way to manage production machines under OpenBSD is to use the latest release version of the OS and apply any patches that the developers produce for that release when/if you will benefit from them.

      And it works really, really well. Even for firewalls. :-)

  5. By pixel fairy () on mailto:pixel [shift +2] [not photoshop] ORG(y)

    I do think having a -STABLE branch is a good thing for ease of use, ie. for a workstation when you dont have time to apply patches (cvsup + makeworld does take longer, but less of your time)

    -STABLE is the main reason i recommend freebsd to people new to unix, even though its actually less effort to set up openbsd for most general purposes (especially server related).

    freebsds irq config thing at the begenning of the install probably scares alot of people away, but its a great thing when you have a crappy (procomp etc) board that likes to hang during auto detect routines and is really finicky about when and from what it will boot.

    you can get around this in openbsd as well of course, but it does not just get that stuff out of the way.

    as for jim, since he knew freebsd so he probably should have stuck to that on the production machine anyway. dont experiment with something new by throwing into production.

    1. By Marcus () on

      But there is an OPENBSD_2_7 branch in the cvs in which patches for Openbsd 2.7 are put. (Just as there was for 2.6, and I'm assuming versions before then). Just keep on pulling updates on this branch and you get the patches


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]