New Kernel Crash-Exploit discovered (linux)

A bug has been reported that lets a simple C program crash the kernel, effectively locking the whole system. Affects both 2.4.2x and 2.6.x kernels on the x86 architecture. It does not require root access to work. There are patches available, but it will require recompiling your kernel at the moment.

NOTE: this is not a remote exploit. A user must have shell access to make use of the bug. It will not elevate user privs. It would, however, provide a very efficient DOS attack.

I tested it on one of my test boxes, and it does work exactly as intended. The kernel locks up and requires a hard reboot to continue.

The impact of this defect in the kernel should be fairly minimal for most users, and is primarily of particular importance to systems that allow untrusted users access to shell accounts.

The link provided above contains C code that you can compile to test this with if desired. Some Gentoo kernels are apparently unaffected.

Patched kernels should be available soon for those not interested in rolling your own kernel.

Yeah, but BSD fabled stability comes at a price: BSD generally lags Linux development: OpenBSD for example is JUST NOW getting support for SMP -- I've been running an SMP Linux for what, about seven years now?? Interestingly enough, as Linux starts to gather steam, the synergy between the two open source systems Linux and BSD is having interesting spin offs -- for example BSD borrowed the new Linux scheduler from 2.6, improved it, and Linux borrowed back these improvements. I think Linux and BSD are starting to merge...

Don't get me wrong, I was brought up on BSD (4.1 and 4.2 ;) its just that BSD tends to have a slightly more primative GUI (unless you get a MAC and pay for Apple's added value), typically just because there are fewer software folks to port the applications as quickly as they do for Linux (Apple Linux has the same problem -- it tends to run a versions or two behind the main x86 Linux stream).

I find Linux servers stable and secure enough to run our WWW and email, which they have done for years and years, with uptimes in the MONTHS...

BSD does lag behind Linux in development - for the sole reason that code which is not considered "well-tested" doesn't make it into the kernel. The disadvantage is that there is no "bleeding-edge" hardware support, but the advantage is that once the hardware is supported, you're pretty much guaranteed it will work well, without much effort. On the other hand, many of the "bleeding-edge" Linux drivers (try using a devel kernel sometime) don't work, many of the interfaces to the Linux kernel change between releases, and programs built for an older version of kernel don't necessarily work with newer versions.

I used Linux for six years, in production environments. I rarely had a system upgrade go well - I usually ended up having to re-install. Currently, I work for Oracle, who is pushing for everyone to adopt Linux. Unfortunately, most of our software (not the database, but our "clustered filesystem" driver) only works on a specific release of the kernel, and then, only with a very specific set of patches. This is clearly MUCH more effort than the added functionality is worth, wouldn't you say? After gritting my teeth with each Linux component upgrade, I finally tried FreeBSD out after a friend gave me a CD. It installed much more quickly, with less overhead, and has been more maintanable overall than most Linux distributions ever could be. (My comparisons are against RedHat 4.1 and Slackware, of course. Nowadays, I prefer Lycoris, but I've coded for them so I'm biased... :))

(FreeBSD != OpenBSD, btw. OpenBSD lags well behind the others for the reason that it is extremely paranoid about updates. Each new feature must go through an extensive regression test before it's considered secure enough [i.e., without root-exploitable bugs] for inclusion in the kernel.)

For the record, FreeBSD supported plug-and-play before Linux did. It also supports SATA more stably than the reports I've heard from Linux 2.6. Our CardBus support may not be totally caught up with Linux yet, but it's rare that you find a device that's not supported. FreeBSD had a working bluetooth stack before Linux did.

As for the GUI, KDE runs on FreeBSD as well as it does on Linux, so there really isn't any difference in using the two. In fact, most Linux programs run just fine under FreeBSD - check out the ports tree if you don't believe me.

The final advantage I give for running FreeBSD over Linux is that FreeBSD is shipped as a unit-tested bundle. What do I mean by that? I mean the kernel, the bintools, fileutils, compiler, and all of the base products are built and tested as a single unit before release. Linux, on the other hand, is only a kernel. Any tools that you use (/bin/ls, /bin/bash, etc) are third-party add-ons which aren't maintained in the same place as the kernel. If you track the bleeding-edge Linux development kernel, this leads to many interesting situations where the bintools don't match the Kernel ABI.

hope I haven't bored you to death with all of this flotsam. :)

BSD's philosophy of shipping things out as a "total package" is a two edged sword -- you end up with OpenBSD, FreeBSD, and of course, NetBSD, each with a different kernel, hence OpenBSD just now supporting SMP.

Linux uses a different philosophy, which unbundles the kernel, allowing many distributions, all using the same kernel base. This has advantages of course: in a general sense you get more bang for the buck -- all distributions benefit from kernel enhancements, whereas you have FreeBSD kernel developers, OpenBSD kernel developers, and NetBSD kernel developers.

As a result, there are by definition fewer troops to look at each type of kernel. If you have lower market share, this can be really bad news.

Using RedHat4.1 and Slackware as comparison points for Linux is not terribly fair. Any BSD would have been better than those relics. But modern Linux distributions have become astonishingly slick, and things *really* work out of the box these days, wifi, even SATA.

Back in the old days i used to have to recompile the kernel to support NFS servering for example, now it all happens automatically, since about RedHat7.3. The RedHat or SuSe automatic net based install tools are also getting *really* nice. It means that it takes only about 2 minutes (not a typo) of my time to setup and install a new machine -- i type in a couple of commands on the installation server, boot up the new machine with a special CD-ROM, and walk away. The installation is automatic from that point forward.

All anaconda and python based...

So, if you hurl flotsam in my direction, i'll hurl jetsam right back!! cheers...

You bring up some excellent points! Yep, the three main BSD's have certainly drifted in their own directions, though for good reason - Each project has a different primary focus: FreeBSD strives to be the most stable operating system, NetBSD strives to run on the largest number of platforms, and OpenBSD seeks to be more secure than any other OS. The projects do still share code between each other from time to time, so any feature lag is primarily self-inflicted. If one of the features developed by one of the *BSD's ends up looking attractive to the others, they pick it up quickly - FreeBSD has taken quite a bit of security-related fixes from OpenBSD, for example.

The Linux philosophy isn't limited to itself - Check out the Debian/FreeBSD project, which runs the FreeBSD kernel underneath the standard Linux (GNU) utilities. It's kinda scary! :)

I understand that RH41 and Slackware aren't a really great comparison, but at the time I made the switch from Linux to BSD, that was the "most stable" Linux flavors. I think RH51 had been out for a month, and wasn't much improved over RH41. After many hours of frustration, I booted FreeBSD, and haven't really looked back since. I've messed around with some of the latest RedHat releases (RH9 and Fedora), and while they look very attractive, underneath the hood, they still have the same managability problems I saw in the past. If you want to see a dependency nightmare, try running Oracle 9i RAC on top of OCFS. It's certified against RedHat Advanced Server 2.5 (I think the RHAS 3 certification just came out recently), but it is nearly impossible to install, due to the number of items (INCLUDING THE KERNEL) which need to be downgraded and rebuilt.

Granted, it's most likely Oracle's problem related to the way OCFS was written, but I find it humorous to know that it's possible to write third-party Linux kernel drivers which will only build against ONE SINGLE version of the kernel. (The FreeBSD kernel API doesn't change very frequently, so the same source will typically last you quite a few releases more than it would if it were written for Linux.)

I dunno - Which OS you select certainly amounts to preference. I come from a script-oriented, command-line, software-engineering background, so I prefer the administration and upgrade tools which ship with FreeBSD. If I want to install a package, it's usually as simple as running the command "pkg_add -r (package_name)," and the package is downloaded and installed (including all dependencies). Therefore, being someone who doesn't like to use GUI tools (like RedHat up2date), I am destined to stick with BSD.

Out of curiosity - have you tried FreeBSD 5.2.1 before? The installer still sucks (sorry - any Linux runs circles around our installer, you've definitely gotten me there), but once you get it up and running, I guarantee that it's the most maintainable operating system you'll ever see! (To give you an idea of how maintainable it is, I've been running FreeBSD on a PPro since 1998. This server's been upgraded from version 2.2.6 all the way up to version 5.1. I never had an upgrade toast my computer, never lost any data on the box due to feature creep, never had to worry about fetching an obtuse version of a library to get something to work - Everything just worked out of the box. Perhaps not the best example, but it's been my experience anyway.... :) )

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.