Weekly Edition
Return to the Security page
| |||||||||||||
A second remote hole for OpenBSD
Visitors to the OpenBSD site will notice
that it now reads "Only two remote holes in the default install, in more
than 10 years!" That's one more than it had a little while ago. The
details can be found in this Core Security
advisory: it seems that the problem was in the IPv6 code. It's amusing
to read the timeline - the OpenBSD folks were apparently not enthusiastic
about accepting the existence of a remotely exploitable vulnerability.
They did accept it, though, and their record over many years remains
impressive.
(Log in to post comments)
A second remote hole for OpenBSD Posted Mar 14, 2007 16:13 UTC (Wed) by copsewood (subscriber, #199) [Link] Has OpenBSD IPV6 code been included in any other OSs, embedded systems or other networking stacks ? If so these should be checked for this vuln. The reason I ask is that many systems have obtained networking code from BSD in the past. Or maybe the OpenBSD code in question came from another system with free and compatible licensing. Either way checks are needed.
A second remote hole for OpenBSD Posted Mar 14, 2007 16:19 UTC (Wed) by djrom (guest, #26074) [Link] In the advisory text:. 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. So, apparently, the OpenBSD team already did the check and the vulnerability seems to be OpenBSD-specific.
They use the KAME stack Posted Mar 14, 2007 18:45 UTC (Wed) by jd (guest, #26381) [Link] (With their own custom mods.)KAME is used by the other BSDs. A derivative, Usagi, used to be available for Linux but there have been no updates for some time and the project has fallen quiet. (KAME itself was halted after the main protagonists decided it was good enough and not worth maintaining as a separate project. A stupid decision, IMHO. If the conformance tests aren't even close to being finished, then "good enough" can't possibly be defined.) If, as has been said elsewhere, the bugs only apply to the OpenBSD IPv6 stack, then the bugs were most likely in the port-specific code. (If it had been an interaction between the port-specific stuff and the mainline code, then the bug would have still existed in the other versions even if it couldn't be exploited to the same degree.) All in all, I am really bothered by the very poor attitude I am seeing towards IPv6 work at the moment. Attitude is ultimately the culprit for all security flaws. Had the attitude been better and development healthier, this problem would either have been fixed much sooner or possibly never arisen at all.
v6 Posted Mar 16, 2007 5:46 UTC (Fri) by gvy (guest, #11981) [Link] Maybe rare folks really need v6 right now, right? (judging on some recent conclusions it well might be the situation for at least a dozen years more)
What have the V6 folks ever done for us? Posted Mar 16, 2007 17:33 UTC (Fri) by jd (guest, #26381) [Link] This reminds me of that sketch in Monty Python's "Life of Brian". Here are some things that v6 supplies (aside from addresses):
Some of these have been backported to IPv4, but the IPv4 versions aren't always terribly interoperable and aren't efficient as they're not designed in. Some are not obviously useful - mobility? - but when you consider the headaches they're having with IP on any mass transit system (having a single monopolistic ISP is a "popular" solution, where a current solution even exists), the sole benefit of having a static solution over a dynamic one is that one ISP gets richer. Oh, you thought you got a benefit from it? Gimme a break. (In fact, it is very likely the anti-monopolistic nature of IPv6 that is hindering adoption. If it had allowed companies like AT&T or Telus to pwn the Internet, it would have been adopted globally in a week. It is precisely because it empowers users to do their own thing that network providers are avoiding it like the plague.)
What have the V6 folks ever done for us? Posted Mar 19, 2007 13:14 UTC (Mon) by copsewood (subscriber, #199) [Link] Thanks for this summary. In addition to commercial monopolistic motivation (which I'm sure exists) there is also the problem of displacing an existing network with a new one suggested by Metcalf's law. This problem is likely to be overcome by new applications e.g. requiring all mobile phones having client/server IP connectivity and OLPC which can only be achieved through availability of more addresses. ISPs will be keen to make money from these new applications even if there are fewer opportunities to monopolise them.
v6 Posted Mar 22, 2007 9:53 UTC (Thu) by Cato (subscriber, #7643) [Link] IPv6 is finally entering real practically-driven deployments - I'm not counting the various ISPs who've done IPv6 as a service for use by leading-edge business customers and research labs, only the companies that are deploying it because they more or less have to, driven by future IP address shortages.
Comcast is deploying IPv6 already in its core and will deploy it for customers, largely because it's already exhausted the 10.x address space and is having to use public IPv4 space for customers. With about 10 IP addresses per triple-play household, and 10s of millions of customers, there's a strong driver to do this sooner rather than later, and the cable world's DOCSIS 3.0 standards for cable modems are now out, and support IPv6.
For more details, including a presentation from Comcast on their IPv6 deployment plans, and some other indicators of IPv6 demand becoming real, see http://slashdot.org/comments.pl?sid=225734&cid=18286172
A second remote hole for OpenBSD Posted Mar 14, 2007 17:15 UTC (Wed) by ajross (subscriber, #4563) [Link] I have to wonder if that "Only N remote holes" marketing tactic is doing more harm than good. Inevitably, it leads to the kind of semantic games we see here: a verified buffer overflow and kernel crash (which is always, almost by definition, a potential remote code execution vulnerability until it can be proven unexploitable) was only termed a non-security DoS issue until CORE came up with an actual exploit.One has to wonder if the psychological difficulty of bumping that "Only N" count made the OpenBSD team less receptive to this bug report than they otherwise might have been. But they did fix the bug, and they did, ultimately, increment N. So all's well that ends well, I guess.
A second remote hole for OpenBSD Posted Mar 14, 2007 18:53 UTC (Wed) by drag (subscriber, #31333) [Link] It's usefull in some cases. For instance with OpenBSD. 2 remote holes in 10 years is pretty damn impressive. There is no if, ands, or butts about it.
If Linux had that same sort of track record most of us would of considured the whole security thing a solved problem. As it stands right now the only reason Linux looks good sometimes is because Windows looks so bad. When compared to other contemporary OSes Linux security is pretty sad sometimes.
But ya it leads to games. For instance take Microsoft's IIS6.
One of the primary reasons why IIS6 is very secure and IIS5 isn't is because Windows 2000 server shipped with all sorts of scripts enabled and pretty much all features were running and active. While with Windows 2003 it was shipped in a fairly locked-down configuration.
When you get a Windows 2003 server all it can do, pretty much, is show static html.
So that is the configuration were Microsoft reports vunerabilities on. So they have very small amount of vunerabilities aviable.
However if you look at what sort of things need to be enabled and what people actually use when they use IIS6 you realise that when Microsoft reports vunerabilities it has divided up all these things into different catagories.
So if you have a vunerabilities with ASP/ASP.net server stuff it won't show up as a IIS6 vunerability. When you go to Secunia and compare Apache vs IIS6 all sorts of Apache mod's and especially OpenSSL support shows up on those lists were the comparable features for Windows do not.
Also with vunerability numbers it can be deceiving because the criteria for declaring something a vunerability is much different. With Microsoft unless something is realy shown to be exploitable it's not a vunerability and won't show up in advisories. With Open Source developers any programming bug, if it has a _chance_ to be a problem it's reported. Also information disclosure is taken more seriously in advisories by OSS developers, generally.
So with comnparing Windows 2003 vs Redhat 4, Redhat has many many more vunerabilities reported. Problems with OO.org, problems with desktop applications, majhonng games, potential problems, predictable tmp files, etc etc.
Were with Windows 2003 you won't even see any IE vunerabilities show up.. Microsoft considures that a seperate product, I guess, when it comes to classifications and that's how it appears with Secunia.com's statistics.
And in addition to that Microsoft has admited on one or more occasion that they still do not practice full disclosure. If they feel that it's not important to tell people about a problem, they won't.
HOWEVER even when you take all of that into considuration and match functionality for functionality between a Windows 2003 server and a Linux server it's obvious that Linux is starting to fall behind in the whole security stuff with web services and such. Generally speaking, with administrators of equal skill level and websites with similar functionality, if you setup a Windows 2003-based web server vs a Linux-based web server the Windows server is going to be more secure.
But it's not nearly as lopsided as it would appear by comparing vunerabilities by numbers.
A second remote hole for OpenBSD Posted Mar 14, 2007 19:43 UTC (Wed) by ajross (subscriber, #4563) [Link] It's usefull in some cases. For instance with OpenBSD. 2 remote holes in 10 years is pretty damn impressive. There is no if, ands, or butts about it. [...] When compared to other contemporary OSes Linux security is pretty sad sometimes. I think you've been fooled by the marketing. That's 2 remote holes in the default install. The default OpenBSD install, I believe, is a bare host (albeit with networking enabled), and only sshd listening on port 22. Comparing this metric to an unqualified "Linux" as a whole is precicely the kind of poor analysis that I argue the "Only N holes" marketing slogan encourages. If you're not going to specify your target, the above really isn't anything but a nicely worded fanboi flame. Which brings up a good point, actually: how many remote holes have there actually been in the kernel over the past few years? Does anyone track this stuff on the Linux side? It's the "default install" nonsense that gets difficult. Red Hat might issue an advisory for, say, Apache, but that wouldn't count under OpenBSD's security metric. Really, only kernel bugs and sshd issues are comparable.
A second remote hole for OpenBSD Posted Mar 14, 2007 20:57 UTC (Wed) by drag (subscriber, #31333) [Link] """Does anyone track this stuff on the Linux side?"""
Ya sure.
And when OpenBSD say 'default install' I take it to mean all the officially supported software. Not just the default configuration they happen to ship out. This is the software that they take most seriously with audits and such things. They tend to be very serious about this sort of thing.
And that's not just 'oh how it comes from the cdrom', but it's firewall stuff and there are a few more services then just sshd that OBSD provides by default. If I remember correctly.
This is opposed to any vunerabiltiies in their 'ports' system, which contains the information nessicary to install various non-core software packages. The ports system is not considured part of the 'default install'.
Out of ports there are varying degrees of seriousness and auditing. Apache is a good example of something they take seriously as their Apache versions is modified a bit, they havent' moved to the 2.0 code base yet. It's been extremely audited and their modifications are to increase security and such.
Their version of Apache has had a small number of holes in it, but it's nothing compared to what you have with the sort of Apache software that a typical Linux distribution ships.
The Linux distributions that come close are going to be things like Slackware and Debian Stable that only ship very well-used Apache versions based on the 1.3.x code base. (and Of course Debian being Debian has Apache2 aviable)
OpenBSD realy is a very impressive peice of work. It's the one system I would feel comfortable throwing out on the internet with no firewall or anything else to monitor and just let it sit serving web pages with only occasional updates.
Of course it's I/O performance is shit, it's SMP support is primative, and the userfreindliness is a throw back to the late 80's.
But you can't have everything, can you?
I mentioned Secunia in my last post. They are only one of dozens of places you can access vunerability databases, but they have a nicer interface which makes it usefull for showing links to.
Keep in mind that, like I mentioned before, it's easy to get into number matching games with Secunia so keep a critical eye on the sorts of vunerabilities.
Comparing remote holes is probably somewhat reliable though.
So you asked about remote holes on the Linux kernel.
http://secunia.com/product/2719/?task=statistics
There are 114 advisories on the Linux 2.6.x series kernel. Out of those about 19% are remote.
However keep in mind that something may be a 'DOS' now, can be a exploit later.
Also some advisories have multiple vunerabilities. So you can have a advisory that has 3-4 or more different bugs in it. They were just reported from a bunch.
But doing a quick overview of the situation shows that you have about 3 bugs that are repoted to allow remote access with the Linux 2.6 kernel from 2003 to 2007.
Looks like the same vunerabilities were present in 2.4 kernel also.
Now if you want a more serious look I suggest checking out OSVDB.
It's 'open source' not in the sort of software it tracks, but how it's completely open. Other places like Secunia or such allow a sort of overview access, but OSVBD has free access and a high level of quality.
It allows access to it's database directly and you can obtain copies of it.
So this would allow you to do fancy things like tie it into a security analysis tool so that when you find services on your network you can look up any vunerability information on them.
Or you can do a much more scientific data analysis of vunerabilities for doing more accurate comparisions.
Also they have rss feeds and I beleive you can set it up to retreive email notifications on various software packages.
Another important information they provide is vendor information, like contact information (which can be suprisingly hard to find sometimes).
A second remote hole for OpenBSD Posted Mar 14, 2007 21:23 UTC (Wed) by ajross (subscriber, #4563) [Link] Obviously this is turning into a Linux vs. BSD flame war, which has little to nothing to do with my original point of "Is OpenBSD's marketing slogan helping or huirting?". So this will be my last post. But it strikes me that this is a rather good meta-example of why silly marketing is a Bad Thing. Rather than argue about actual security flaws, or potential problems with the OpenBSD development process, we get sidetracked by OpenBSD fans into a "Linux is so much worse!" flame. when OpenBSD say 'default install' I take it to mean all the officially supported software. Not just the default configuration they happen to ship out. I think you've been hoodwinked. Granted, I can't find clear definitions of "remote hole" or "default install" on their website (another reason this kind of marketing gimmick is dumb). But I strongly suspect that "default install" means the software you get when you install the operating system using the default settings. Any other interpretation seems, to me, to be overly generous (and potentially insecure), no? There are 114 advisories on the Linux 2.6.x series kernel. Out of those about 19% are remote. 16% are unpatched. 2% will lead to system access, while 45% are DOS (usually crashes). OK, I call your bluff. I just looked at these in the expanded list of these vulnerabilities (not the pie charts -- the actual list). And I couldn't find any of them that fit the OpenBSD definition of a "remote hole" (i.e. code execution, not DoS) in the "default install" of a major Linux distribution. There were plenty of local issues, to be sure, and lots of DoS opportunities. And I saw a few remotely exploitable holes or "security bypass" bugs, but only in little-used code that (as far as I am aware) major vendors don't ship enabled. So as far as I can see, the "OpenBSD N" value for the linux kernel over the lifetime of the Secunia database is in fact, zero, which I amusingly note is somewhat less that two. Did I miss something?
A second remote hole for OpenBSD Posted Mar 14, 2007 22:22 UTC (Wed) by drag (subscriber, #31333) [Link] """Obviously this is turning into a Linux vs. BSD flame war,"""
If you say so. It seemed very civil to me so far.
""Rather than argue about actual security flaws, or potential problems with the OpenBSD development process, we get sidetracked by OpenBSD fans into a "Linux is so much worse!" flame.""
I mentioned quite a few times things related to OpenBSD's development proccess. (code auditing, etc)
My ultimate point in all of this is that yes saying 'N holes' is usually misleading, but in this case it's not. It's just a one liner, if you want to pick it appart you can, but its still mostly valid and is actually pretty good.
You and I both know that pretty much any Linux distribution, if you take a ten year history look at it, will show much more then 2 remote holes.
This does not stop me from prefering Linux distributions over OpenBSD though. It's not enough for me that a release has to be secure, it has to actually usefull... which generally OpenBSD is not for the stuff I want.
""OK, I call your bluff. I just looked at these in the expanded list of these vulnerabilities (not the pie charts -- the actual list). And I couldn't find any of them that fit the OpenBSD definition of a "remote hole" (i.e. code execution, not DoS) in the "default install" of a major Linux distribution. There were plenty of local issues, to be sure, and lots of DoS opportunities. And I saw a few remotely exploitable holes or "security bypass" bugs, but only in little-used code that (as far as I am aware) major vendors don't ship enabled.""
Well first off your the one that said that only Kernel vunerabilities and Sshd vunerabilities count. So I am just responding to your own restrictions you put on this discussion. Of course this is rather bizzare since OpenBSD does a lot more then just have a kernel and a remote shell, but whatever you want.
The three vunerabilities, which is just the kernel I mentioned are:
http://secunia.com/advisories/14713/
http://secunia.com/advisories/16406/
They aren't hugely serious. Linux kernel itself is pretty nice.
A second remote hole for OpenBSD Posted Mar 15, 2007 0:32 UTC (Thu) by ajross (subscriber, #4563) [Link] I know I promised not to post again. But now you're starting to post explicit misinformation. Please be careful to get things correct. Maybe you amisinterpreted the argument I was making? The point here is to judge the Linux kernel by the same standard as OpenBSD uses for their (IMHO) ridiculous slogan, not to enumerate other (obviously important) kinds of flaws, and not for the purpose of flaming about platforms, but as an exercise to show use useless a metric "Only N holes" is. http://secunia.com/advisories/13232/[1] From the description: "Multiple vulnerabilities have been reported in the Linux Kernel, which potentially can be exploited by malicious, local users to ...". How exactly does this qualify as a "remote hole?" OpenBSD's metric is specifically about network-exploitable vulnerabilities, not local root exploits. http://secunia.com/advisories/14713/[2] This is another local vulnerabilty. It's clearly not a "remote hole". You can't compromise a system remotely via bluetooth; the bug is that you can achieve root locally by exploing a bug with the syscall handlers. http://secunia.com/advisories/16406/[3] This was never verified as anything but a DoS, so by OpenBSD's own standards (silly ones, of course, which is my whole point) it doesn't count. The bug in the OpenBSD IPv6 code was not termed a remote hole until someone wrote an exploit, so clearly it's not fair to tag Linux with a different standard. I'm sorry, but every one of those vulnerabilities would be rejected by the OpenBSD team as part of their "Only N holes" metric. Are you starting to agree with me now that it's perhaps not as informative a slogan as you might have originally thought?
A second remote hole for OpenBSD Posted Mar 15, 2007 1:03 UTC (Thu) by drag (subscriber, #31333) [Link] Oh, ok. :)
(see? It is possible to have a rational discussion.)
A second remote hole for OpenBSD Posted Mar 15, 2007 3:52 UTC (Thu) by tetromino (subscriber, #33846) [Link] IMHO, you have misinterpreted the advisories.
http://secunia.com/advisories/13232/[1] refers to the first part of the advisory (note the [1]), which is a true remote exploit:
"Stefan Esser has reported multiple vulnerabilities within the smb filesystem (smbfs) implementation that are caused due to various types of errors when handling server responses.
Successful exploitation requires that a malicious person has control over a smb server or is able to intercept and manipulate traffic."
The "local users" refers to the second part of the advisory (the unix_dgram_recvmsg() issue). For some reason, Secunia's summary blurb only describes the second part. Go figure.
http://secunia.com/advisories/14713/[2]
"A signedness error in the "bluez_sock_create()" function when creating bluetooth sockets can potentially be exploited to gain root privileges on a vulnerable system."
If I'm reading this right, a malicious user can take over a server by crafting malicious bluetooth packets, in other words, that's a remote root. (Remember, bluetooth devices can be very long-range: http://www.smallnetbuilder.com/content/view/24256/98/)
A second remote hole for OpenBSD Posted Mar 15, 2007 16:17 UTC (Thu) by bronson (subscriber, #4806) [Link] Because OpenBSD ships with neither SMBFS nor Bluetooth enabled by default, these remote holes would not count against it. Therefore, they should not count against Linux. As ajross was saying, you need to compare apples to apples.
Personally, I think pretty much any measurement against OpenBSD's default install is meaningless. Nobody runs it! "Only 12 remote holes in a fully-provisioned OpenBSD LAMP setup!" would be a much better statistic.
A second remote hole for OpenBSD Posted Mar 15, 2007 14:10 UTC (Thu) by jond (subscriber, #37669) [Link] Well first off your the one that said that only Kernel vunerabilities and Sshd vunerabilities count. So I am just responding to your own restrictions you put on this discussion.That's my interpretation of their slogan too. I'm pretty confident its what they actually mean: I think I may have got that from an OpenBSD talk I went to once.
A second remote hole for OpenBSD Posted Mar 15, 2007 22:53 UTC (Thu) by roskegg (subscriber, #105) [Link] From the mouth of Theo himself at various live appearances, the remote hole thing is based on default install with default configuration. If you enable any service in the base system that is not enabled in the default configuration, it is not counted toward the remote hole count.
A second remote hole for OpenBSD Posted Mar 14, 2007 23:09 UTC (Wed) by akumria (subscriber, #7773) [Link] And when OpenBSD say 'default install' I take it to mean all the officially supported software. Not just the default configuration they happen to ship out. This is the software that they take most seriously with audits and such things. They tend to be very serious about this sort of thing. That's what you take it to mean but a lot of people, including me, take "default install" to mean the OpenBSD kernel and OpenSSH. I'd say that for those two components the number of times the "default install" has been remotely compromised would be very similiar on most *BSDs and Linux. Especially as everyone is using OpenSSH.
A second remote hole for OpenBSD Posted Mar 15, 2007 4:45 UTC (Thu) by k8to (subscriber, #15413) [Link] For the record, OpenBSD does enable a few more things, like portmap, by default. So the list is *a bit* longer than that, but not much.
A second remote hole for OpenBSD Posted Mar 16, 2007 8:25 UTC (Fri) by miod (guest, #41457) [Link] Actually, portmap has been disabled by default since a fair number of OpenBSD releases already.
A second remote hole for OpenBSD Posted Mar 16, 2007 15:03 UTC (Fri) by k8to (subscriber, #15413) [Link] Just goes to show.......
Um. So uh, I guess my OpenBSD usage is a bit dated.
A second remote hole for OpenBSD Posted Mar 15, 2007 23:10 UTC (Thu) by man_ls (subscriber, #15091) [Link] I'm surprised no-one has called on this:Generally speaking, with administrators of equal skill level and websites with similar functionality, if you setup a Windows 2003-based web server vs a Linux-based web server the Windows server is going to be more secure.Ehm, excuse me? Windows 2003 more secure than Linux? Let me put this into perspective. I have two machines; one I load with the latest RHEL 4, the other one with the latest Windows 2003, default install. I place both machines on the public internet without a firewall, and wait to see which one stays out of trouble for a longer time. Would you bet for the Win2k3? Same scenario, now I place both machines behind a firewall and just expose a web server (Apache on RHEL, IIS on w2k3), static HTML. Bets? I know I keep my main machine connected via ADSL without a firewall and have never had a successful intrusion (that I know of); this with Debian, SUSE, Gentoo and lately Ubuntu. I had something which might have been a sporadic DOS with Dapper, long gone with Edgy. Maybe things have changed a lot, but even with w2k3 I wouldn't bet to stay connected long enough to download the latest patches without getting infected.
FUD is not needed here Posted Mar 14, 2007 19:32 UTC (Wed) by mheily (guest, #27123) [Link] Why are you trying to spread FUD about the OpenBSD developers? Do you have any evidence to back up your "psychological analysis" of them?
OpenBSD takes security very seriously. The OpenBSD project released a patch within 48 hours of being notified of a remotely exploitable vulnerability. When the issue was first reported as a denial of service, they released a patch six days later. That's a pretty good response time, IMHO.
The reason this was initially treated as a denial-of-service problem is that the buffer overflow did not directly involve user-supplied data. It is non-trivial to exploit this kind of problem, and kudos should be given to Core for figuring out a way.
Any piece of complex software cannot be proven correct; it can only be proven to be *incorrect* in certain corner cases.
FUD is not needed here Posted Mar 14, 2007 20:20 UTC (Wed) by ajross (subscriber, #4563) [Link] Do you have any evidence to back up your "psychological analysis" of them? As explained: they apparently tried to "cover up" a serious security issue as a denial of service. I suggested that the reason might be because they were afraid of having to increment their "Only N holes" counter. That seems like a reasonable line or argument to me. There is some factual evidence (click on the link above), that I combined with other facts (the "Only N holes" marketing slogan) to suggest a hypothesis (the "psychological analysis"). Now, you may not agree with me, and I may be wrong, but I think this is well above the level of "FUD". I'll be honest, I think the "Only N holes" slogan is a dumb idea. At best, it has the effect of fooling the users (or fan base) into thinking it means more than it really does. At worst, it actively encourages the developers to "cook the books" in an attempt to avoid incrementing N. And please don't pretend that a kernel overflow bug is ever a minor issue that can be fixed with a silent (non-security) bugfix. It's a huge deal, and sweeping it under the rug as a DoS until someone can prove you incorrect is just wrong. This should have been disclosed as a potential security issue instantly.
Ignorance is not an excuse for spreading FUD Posted Mar 15, 2007 3:12 UTC (Thu) by mheily (guest, #27123) [Link] There is nothing in the advisory that supports your claim that there was some kind of attempted "cover up" to "cook the books" so that the OpenBSD project wouldn't have to increment a number in their marketing slogan. In fact, the opposite occurred; the problem was handled quickly and professionally, with full disclosure and communication between the project developers and the security researchers, and patches were released as new information about the severity of the problem was discovered. What more do you want?
There are plenty of ways to cause a kernel panic that don't lead to privilege escalation or remote code execution. If every bug that causes a kernel panic is treated as a critical security vulnerability, we would all drown in a sea of false positives and be constantly patching and rebooting our servers for no good reason.
At most, there was a linguistic disagreement on using the word 'vulnerability' to describe a denial-of-service issue. The OpenBSD project uses the term 'reliability fix' to describe patches for denial-of-service issues. They only use the term 'security vulnerability' when there is a possibility of remote code execution. Both types of problems are taken seriously, and patches for both types of problems are backported from the CVS repository to the stable releases.
Your insinuation that they tried to issue a silent fix for the problem is totally wrong.
Your claim that by advertising a low number of remote holes they are "fooling the users" about the overall system security is false. The OpenBSD website states in bright red letters:
"The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security."
It is clear that you are ignorant of the facts surrounding this incident, the nature of the OpenBSD project, and the general process of reporting and resolving security flaws. Please refrain from making baseless accusations that only serve to spread fear, uncertainty, and doubt about the OpenBSD developers.
Foo is not an excuse for Bar Posted Mar 15, 2007 4:50 UTC (Thu) by k8to (subscriber, #15413) [Link] Describing likely security problems as mere denial of service is a sort of downgrade. Some people do so further, downgrading such things to "bug fixes". Strictly speaking such terms are not incorrect, and such descriptions may be defensible (do you describe everything as the maximum *possible* damage it can do?) But this type of action is the "cover up" being described.
I think that was quite evident.
Ignorance is not an excuse for spreading FUD Posted Mar 15, 2007 16:44 UTC (Thu) by bronson (subscriber, #4806) [Link] I must disagree with you mheily. It's simply good security practice to treat an exploit as its worst potential outcome. This particular exploit had components that could be used to remote the box, yet the OpenBSD team chose to categorize it as nuisance. That's unfortunate, isn't it?
Reading the report starting with, 'OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack,' shows how reluctant the OpenBSD team was to categorize it properly, even after the exploit was demonstrated. Why were they so reluctant?
Don't get me wrong -- OpenBSD is fantastically secure and I often use it myself. But their response in this case was uncharacteristically sloppy. How many machines were rooted in the nine days it took to convince the OpenBSD team of this bug's severity?
FUD is not needed here Posted Mar 15, 2007 2:21 UTC (Thu) by lysse (guest, #3190) [Link] "Why are you trying to spread FUD about the OpenBSD developers?"
Legitimate criticism, backed up with examples, is pretty much the polar opposite of FUD. Frankly, members of this community should know better than to throw the label around as a way of discrediting an argument with which they disagree.
FUD is not needed here Posted Mar 15, 2007 9:19 UTC (Thu) by Wol (guest, #4433) [Link] "Any piece of complex software cannot be proven correct" ...
Well, it's maths, so while maths can be proven correct, there is no guarantee that it mirrors reality - that's Science's domain.
What's that Knuth quote? "Beware of bugs, I have only proved this program correct, I have not proved that it works".
Don't get me on my database hobbyhorse :-) and remember that Maths proves things "correct in theory", Science proves things "wrong in practice". The latter is more important but people prefer to dwell on the former :-(
Cheers,
A second remote hole for OpenBSD Posted Mar 15, 2007 6:55 UTC (Thu) by bluefoxicy (guest, #25366) [Link] Ubuntu should follow the same behavior as OpenBSD in this respect. Considering Ubuntu has no open ports in the default install (perhaps Avahi now), the only possible remote holes involve kernel-level networking stack exploits. These do not occur very often, even in Linux.
I count OpenBSD's marketing as hand-waving because of this. If there's only one thing for you to knock (the network stack), then there's only one place holes can occur, and thus exposure comes out pretty low.
Now if OpenBSD loaded with SSH + Avahi + RPC + NFS, maybe I'd be impressed; give me remote holes in an enterprise server install involving a baseline of Apache, MySQL, FTP, and SSH. Consider that OpenBSD implements some subset of the PaX functionality (i.e. a partial NX emulation on 32-bit, similar to ExecShield; but no NX policy like PaX mprotect() or SELinux exec* permissions) and some similar but different protections (per-mmap() and per-malloc() randomizations instead of per-execution randomization); as well as full stack smash protection and a security-enhanced memory allocator. They should really be bragging about not having remote holes in code that's exploitable on OTHER platforms.
A second remote hole for OpenBSD Posted Mar 15, 2007 12:01 UTC (Thu) by k8to (subscriber, #15413) [Link] I believe OpenBSD does enable RPC by default. At least it did at some point in its history and did not incur any holes. I find this impressive myself.
But I think the "no default remote holes" is really trying to draw attention to two different things. OpenBSD has good engineering in the security department and tends to avoid compromises and exploits. We are all aware of this aspect of it, though some feel this sloganing is not very indicitave of that fact. But I think it is _also_ drawing attention to the conservative installation policy. Perhaps we are ignoring this aspect because the limitation of exposure is now the default thinking across most Linux variants and most Unix admins, but I can assure you it was not 10 years ago.
In other words, it may be that this slogan has simply gotten a bit out of date in that most unixes no longer foolishly turn on all kinds of services open to the world. Or at least most Free unixes.
A second remote hole for OpenBSD Posted Mar 16, 2007 7:32 UTC (Fri) by bluefoxicy (guest, #25366) [Link] Fedora.
it's just a beta Posted Mar 16, 2007 23:39 UTC (Fri) by gvy (guest, #11981) [Link] > FedoraOne should know he's in er... testbed when one installs Fedora. Consider bringing up IPv6 by default, which is even worse a security setup/maintenance nightmare than I would have though night before.
There are more OpenBSD-like Linux distros like Owl and ALT, where basesystem is additionally audited and tools like control(8) are in place to facilitate retaining admin-specified permissions on potentionally privileged binaries -- like "public/wheel/wheelonly/restricted" for su(8). Those that wouldn't crash-dive into 2.6 kernels and apache 2.0 when that would really be too much grief for reasonable sysadmins.
Disclaimer: I participate in this spring's ALTLinux release, as usual, but have long disliked RHL and Fedora for practical reasons (with much respect to Red Hat, of course).
Only one remote holes in the default install, in more than 3 days! Posted Mar 15, 2007 16:13 UTC (Thu) by terminator (guest, #2292) [Link] I tend to think OpenBSD's claim as the subject states. In fact, M$ can claim "No single remote hole in the default install of DOS, in lifetime!" But this is completely pointless considering the functionality of DOS without networking. So is the same for OpenBSD in some sense.
Only one remote holes in the default install, in more than 3 days! Posted Apr 15, 2007 12:28 UTC (Sun) by hlovdal (guest, #44671) [Link] In fact, M$ can claim "No single remote hole in the default install of DOS, in lifetime!" But this is completely pointless considering the functionality of DOS without networking.Someone made a comparision between CP/M and Windows NT some years ago, declaring CP/M to be vastly more secure than Windows NT :)
|
|||||||||||||