Contributed by Dengue on from the courtesy-of-BSD-Today dept.
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)
Latest Articles
Credits
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 deadly.org 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.]
By Nobody You'd Know () on
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.
Comments
By Jim () on
> 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.
Jim
Comments
By Nobody You'd Know () on
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 deadly.org. What is the world coming to? :)
Comments
By Jim () on
> 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.
Jim
Comments
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.
Comments
By Jim () on
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.
Jim
Comments
By Intrepid| () intrepid@pobox.com on mailto:intrepid@pobox.com
* 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.
By Intrepid| () intrepid@pobox.com on mailto:intrepid@pobox.com
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.
Comments
By Jim () on
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.
Jim
Comments
By Intrepid| () intrepid@pobox.com on mailto:intrepid@pobox.com
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.
By action () on
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.
Comments
By Intrepid| () intrepid@pobox.com on mailto:intrepid@pobox.com
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.
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
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.
Comments
By Jim () on
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.
Jim
By Nobody You'd Know () on
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.
By Nobody You'd Know () on
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 www.counterpane.com 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?
Comments
By Still Nobody's fan () on
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.
Comments
By Nobody You'd Know () on
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:)
Comments
By Bill Marquette () on
By I am a monkey, my name is Bengo, and i like to cli () nospam@noemailaddy.com on http://www.
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"
Comments
By Bill Marquette () on
--Bill
By Nobody You'd Know () on
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.
By james phillips () dengue@deadly.org on file:/dev/null
Comments
By Nobody You'd Know () on
By nameless () nameless on mailto:nameless
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?
Comments
By Nobody You'd Know () on
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.
By Nobody's Big Fan () on
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.
Comments
By Nobody You'd Know () on
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.
Comments
By Fan () on
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
Patch: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:19/semconfig.patch
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()
node.
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.
Comments
By Intrepid| () intrepid@pobox.com on mailto:intrepid@pobox.com
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.
Comments
By Fan () on
>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.
By Nobody You'd Know () on
#include
#include
int
main()
{
for(;;) fork();
return 0;
}
By Intrepid| () intrepid@pobox.com on mailto:intrepid@pobox.com
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.
Comments
By Fan () on
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.
By Beldon () beldon@scamail.com on mailto:beldon@scamail.com
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."
Comments
By niekze () on
By bengt () bengt@softwell.se on mailto:bengt@softwell.se
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.
Comments
By Nobody You'd Know () on
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. :-)
By pixel fairy () on mailto:pixel [shift +2] [not photoshop] ORG(y)
-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.
Comments
By Marcus () on