New Linux Kernel Vulnerability

Stop Or I'll Noop writes "Paul Starzetz writes, "A critical security vulnerability has been found in the Linux kernel memory management code inside the mremap(2) system call due to missing function return value check. This bug is completely unrelated to the mremap bug disclosed on 05-01-2003 except concerning the same internal kernel function code." Full scoop here." Update: 03/07 20:53 GMT by T : This vulnerability (and fixes) were mentioned briefly in an update to this earlier posting.

Comments

Many eyes, but wide open or tight shut ?

[Space cowboy]

I'm not sure whether this is a triumph of the distributed nature of the kernel, or a catastrophic failure of the whole model... The mremap() code was presumably
looked at in great depth just recently, after a critical vulnerability was found. A few weeks go by and another hugely important hole is found...

Since no special privileges are required to use the mremap(2) system call any
process may use its unexpected behavior to disrupt the kernel memory management
subsystem.

Proper exploitation of this vulnerability leads to local privilege escalation
giving an attacker full super-user privileges. The vulnerability may also lead
to a denial-of-service attack on the available system memory.

Now I know the consequences of a problem bear little relation to its root cause, but I am a little surprised at how this managed to find its way through all these eyes looking at the offending code a week or so ago. Actually making it work as a security hole looks to be reasonably complex, (which may be why it wasn't found, I guess), but if one piece of code can have 2 major vulnerabilities in as many weeks, maybe it's time to start worrying about when Linux *does* take over the desktop...

I thought the automated 'Stanford Checker' (sp ?) was ideal for this sort of problem ? (Where the returned value from a function is ignored...) Perhaps it was flagged up but took some in-depth analysis for the kernel developers to realise it really was a problem...

So, is this a master-stroke of the development model, with various people around the world all individually checking code and Hey! Someone found something, or is it a "failure" where all those people missed it the first time around, and it's a pure fluke it was found now.... I'm still not sure, but I'll give the benefit of the doubt to the model - hey, it's been fixed! :-)

Simon

Re:Many eyes, but wide open or tight shut ?

[whig]

I'd be more inclined to call this a demonstration of the successful "many-eyes" approach. The latest mremap() vulnerability took only a few weeks to be discovered, and the folks publishing it are "eyes" that have alerted kernel developers to the problem.

Re:Many eyes, but wide open or tight shut ?

[Liselle]

In my humble opinion, it's an unavoidable part of making software. We have to be realistic: closed or open source, as a program gets more and more complex, more elaborate bugs come out, and some of them turn out to be exploitable. Having strict coding guidelines can help, having lots of eyes looking at the code helps, but ninja vulnerabilities will still stealth through.

My thinking is that Linux on the desktop is going to need a contingency plan for a widespread vulerability, similar to what Microsoft does with Automatic Updates. I know it's not perfect, but I'll be damned if I can think of anything better. It's nice to think you can make a bullet-proof kernel, but also naive.

Re:Many eyes, but wide open or tight shut ?

[H4x0r Jim Duggan]

Yeh, but if you read the security report, this problem exists in *all* 2.2, 2.4, and 2.6 Linux's - so this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

That's a long time. Maybe some crackers have been using this exploit during that time (or, of course, maybe they haven't).

Re:Many eyes, but wide open or tight shut ?

[imbaczek]

Fortunatly, it's just an update to a previous report, not a new bug.

Re:Many eyes, but wide open or tight shut ?

[wojci]

Having strict coding guidelines can help, having lots of eyes looking at the code helps, but ninja vulnerabilities will still stealth through.

I am sure that many people developing and using The Linux Test Project test suite would also help find more bugs.
(Found by google after I began wondering if any automated test effort was taking place.)

Re:Many eyes, but wide open or tight shut ?

[hobbesmaster]

Erm, the problem is that this is a local exploit, not a remote one. I doubt that very many crackers have been using this exploit, because you have to have a local account in the first place to do it.

Re:Many eyes, but wide open or tight shut ?

[wojci]

The Linux Test Project test suite

Re:Many eyes, but wide open or tight shut ?

[CoreDump01]

Local as in an 0wn3d apache / sendmail / whatever server?

Re:Many eyes, but wide open or tight shut ?

[BiggerIsBetter]

My thinking is that Linux on the desktop is going to need a contingency plan for a widespread vulerability, similar to what Microsoft does with Automatic Updates.

I'm guessing you don't use Linux then. All major distros release such updates very quickly, and RedHat at least had a desktop icon that alerted users if updates were available. The kernel will get patched if it needs to, but it's up to the distro vendors to include something "idiot proof" to yell if the system needs an update.

Re:Many eyes, but wide open or tight shut ?

[BlowChunx]

From the article: Proper exploitation of this vulnerability leads to local privilege escalation giving an attacker full super-user privileges.

Now, I am not a hacker, but I think after I got local access via another exploit, I would use this current vulnerability to get root, install my back door/zombie code, etc. and leave quietly.

Every exploit is serious.

Re:Many eyes, but wide open or tight shut ?

[Cobron]

Yeah, but I do have the idea that there are less "Bad guys" in Open Source - land, because of the encouragement to submit bugreports.
In open source you get acknowledgment from the authors and community, there aren't many other places to search for an ego-boost in closed-source land than on hacker-boards.

What I mean with the above is that I think that the chances that "Good Guys" spot the error are greater than that "Bad Guys" find and exploit them in OSS than in Closed Source Softw.

Re:Many eyes, but wide open or tight shut ?

[bickerdyke]

gentoo's emerge -U world comes pretty close to an automatic update

Re:Many eyes, but wide open or tight shut ?

[AKnightCowboy]

Yeh, but if you read the security report, this problem exists in *all* 2.2, 2.4, and 2.6 Linux's - so this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

So basically this proves that Linux is just as insecure as Windows is. There have been lots of major kernel vulnerabilities floating around in the past 6 months. I guess it's time to switch to OpenBSD.

Re:Many eyes, but wide open or tight shut ?

[spitzak]

If your eyes were a little wider open you would see that this is NOT A NEW BUG! In fact it is the exact same one (the *second* in mremap(), not the third) as reported in a Slashdot article well over a month ago.

I actually read the bug report then, and I read it now, and when I got down to the bug explanation (with the lines of X's representing memory) I realized it was the exact same one I had seen before!

Re:Many eyes, but wide open or tight shut ?

[the_2nd_coming]

uhh...no, see the diffrence is that Linux might have many local exploits that have not been found, but the structure of the OS makes it very hard for a remote exploit.

Re:Many eyes, but wide open or tight shut ?

[sporty]

Just as there are many bad guys in the world, there are many good ones. In the case of closed source, anyone cannot fix the problem directly. With opensource, even if it's just a bug, I can fix it myself if I am so inclined.

So the many eyes thing still holds. One could further argue, that opensource stuffs can achieve higher quality faster, as both the stupid errors get flushed out really fast.

Re:Many eyes, but wide open or tight shut ?

[LittleLebowskiUrbanA]

"So basically this proves that Linux is just as insecure as Windows is."

OK, let's compare patch release times for Windows versus Linux. As far as OpenBSD, it IS one of the most secure OSs' in the world but it still has its vulnerabilities and a couple as of late.
I would still run OpenBSD in a security sensitive situation. I find it easier to lock down than anything else.

Re:Many eyes, but wide open or tight shut ?

[iantri]

Automatic Update? Put the following into your crontab at an interval of your choosing:

On Debian/Red Hat with APT:
apt-get update && apt-get dist-upgrade

On Red Hat with up2date:
up2date -u

On Mandrake:
urpmi.update && urpmi --auto-select

And so on.. Now obviously these could be imrpoved (i.e. mail the admin if it fails), but auto-updating is a lot easier under Linux.

Re:Many eyes, but wide open or tight shut ?

[Anonymous Coward]

Oh, sure... That's great..

And when something breaks, you'll have no idea what caused it, and you'll have to jump through some hoops to make it work again.

No thanks.

Re:Many eyes, but wide open or tight shut ?

[Liselle]

The kernel will get patched if it needs to, but it's up to the distro vendors to include something "idiot proof" to yell if the system needs an update.

Absolutely. It wasn't a suggestion for a solution to a problem, just a statement of fact. Obviously everyone has an update routine for patching.

Re:Many eyes, but wide open or tight shut ?

[Carl T]

RedHat at least had a desktop icon that alerted users if updates were available

SuSE has a similar thing. Dunno about other distros.

There are a couple of problem here though:
There are a number of steps that need to be taken before a patch is installed, and each of them may take quite a bit of time: computer needs to check for patches, mirror server (if any) needs to have patches from main patch server (in my case this is sometimes an issue, but I could go directly to ftp.suse.com, if it's not completely bogged down already), user needs to be alerted, user needs to choose to patch. All this could be done in an automated way, but it would still take some time, during which the machine would be vulnerable.
And then, after patching, programs or the whole machine may need to be restarted. This can't very well be automated, at least not by default.

I'm semi-admining a SuSE 8.2 box where the automatic update script emailed me every day with a list of already-installed patches. Stupid. :-P So I got it to not email me. So now I have no clue when I need to reboot, and the machine is probably open to several known vulnerabilities right now.

I'd say that single(ish)-user machines really need to be properly firewalled, but unfortunately there's no such thing as a satisfactory default policy. (Outgoing IRC traffic, for instance, should be open for IRCers but not for anyone else.) On multi-user machines there's no substitute for vigilant admins.

Re:Many eyes, but wide open or tight shut ?

[Cramer]

It's not 5 years before "The Good Guys" spotted it; it's taken many years for anyone to spot it.

Had there not been other problems with mremap(), no one would've looked this closely at the code. What they've found is a very involved exploitation despite their claim of "easy to exploit".

Re:Many eyes, but wide open or tight shut ?

[larry bagina]

Quite a few virtual hosting companies run on linux, and UML is popular for virtual servers. $5 a month could get you a local account on a linux box with a good net connection.

Re:Many eyes, but wide open or tight shut ?

[AKnightCowboy]

uhh...no, see the diffrence is that Linux might have many local exploits that have not been found, but the structure of the OS makes it very hard for a remote exploit.

Really now? So if I send you a binary attachment and you run it, you won't be exploited? Care to try one I have here? People are complaining about the EXACT same thing on Windows. All these recent Windows vulnerabilities have been local exploits. Exploits of any kind are never excusable and are the result of poor coding.

Re:Many eyes, but wide open or tight shut ?

[Ironica]

You make a very salient point about why Open-Source software may be less vulnerable to attack than proprietary software. Basically, if you discover a vulnerability in a closed-source program, there is NO honorable way to get recognition or respect for your digging... the best you can do is quietly report it to the company and hope they fix it, knowing they will not usually acknowledge you for reporting it. With OS, you can gain respect and recognition for reporting the vulnerability to the community and helping them fix it. In *both* cases, you generally get no fiscal reward for your work, so the recognition and the fix are all you're motivated by. Therefore OS gives more motivation to report bugs, while proprietary software gives more motivation to exploit bugs.

Re:Many eyes, but wide open or tight shut ?

[Lord of Ironhand]

Agreed. If someone is interested in how an opensource program works, that person simply looks at the source code, and possibly even finds bugs to fix or report. If someone is interested in how a closed-source program works, he/she will have to learn things like reverse engineering. Searching for info on how to do this will probably drive that person into the black hat community very quickly.

Re:Many eyes, but wide open or tight shut ?

[DrSkwid]

It's the failure of 'if in doubt, add a new system call' "design" process.

If you rely on Linux for security, you're a fool.

Re:Many eyes, but wide open or tight shut ?

[iantri]

Actually, my mistake. You don't even need to get it to mail the admin.

By default, cron mails the results of cronjobs to it's owner (in this case, root), so each computer will report in. If something breaks, (it refuses to update), you will see it. If something breaks, (the update screws up your systems), you will see which update caused it (and this is the same problem you would have with Windows Update, anyway).

If the computer doesn't report in, then there is a problem. The admin can check on the computer and see why it doesn't seem to be doing its' cronjobs.

So it works a lot better than you think..

Re:Many eyes, but wide open or tight shut ?

[Tony-A]

Had there not been other problems with mremap(), no one would've looked this closely at the code. What they've found is a very involved exploitation despite their claim of "easy to exploit". [Emphasis added]

That's like a mathematician saying something is "trivial".
Don't complain, a good mathematician can show you something non-trivial.

Methinks the best comparison of security is how hard it is to find a crack. (and how much noise is generated for how small a crack;)

Further, it seems that Open Source when it finds one takes the effort to find its friends and neighbors. Closed Source tends to plug the crack, somewhat, at that's the end of it. Repeat the process and Open Source is much more secure.

Re:Many eyes, but wide open or tight shut ?

[MrLizardo]

I suggest apt-get update && apt-get upgrade

dist-upgrade is a little severe in that it can remove packages whose dependencies cannot be met with the latest update. This is almost certainly not what you would want in a non-interactive setup. :)

-Mr Lizard

Re:Many eyes, but wide open or tight shut ?

[mangu]

And when something breaks, you'll have no idea what caused it,

No, not at all. IMHO, this is one of the greatest advantages of Linux over Windows: there's a /var/log/messages file which tells you what went wrong. One of the most frustrating tasks in Windows sysadmin is when you are trying to install something and it fails. Often, you have only one choice: reinstall.

Re:Many eyes, but wide open or tight shut ?

[DrSkwid]

I have no idea

plan9 has 17 I think

Saying "yeah, but what about windows" to every criticism is pretty childish.

Re:Many eyes, but wide open or tight shut ?

[Tony Hoyle]

...and getting root on that will get you...?

Nowhere. You're inside a virtual machine.

My virtual host gives me root access and the right to install anything I like (except IRC). I've got the thing running debian :)

UML rocks :)

Re:Many eyes, but wide open or tight shut ?

[Foolhardy]

Most of ntdll.dll's entry points (all the Nt* functions) simply load a kernel function ID into AX and use a software interrupt to enter kernel mode. It represents NT's system call interface.
It has 285 of those in xpsp1.
The first release of NT(3.1) has 178.

Re:Many eyes, but wide open or tight shut ?

[Com2Kid]

• All major distros release such updates very quickly,

Yes, and just like windows update, a simple software patch has the potential to hose an entire system!

Nice to know the Linux crowd is keeping up with MS. :)

Re:Many eyes, but wide open or tight shut ?

[Ironica]

This guy deserves an insightful mod. (emphasis added)

*ahem*

[displays 46th chromosome, which is clearly an X]

Re:Many eyes, but wide open or tight shut ?

[airjrdn]

Automatic Update? Put the following into your crontab at an interval of your choosing:

On Debian/Red Hat with APT:
apt-get update && apt-get dist-upgrade


On Red Hat with up2date:
up2date -u

On Mandrake:
urpmi.update && urpmi --auto-select

And so on.. Now obviously these could be imrpoved (i.e. mail the admin if it fails), but auto-updating is a lot easier under Linux.

A lot easier than what? In Windows I check the box that says automatically install updates. If I remember correctly, that box may actually be checked by default.

On Debian/Red Hat with APT:
apt-get update && apt-get dist-upgrade

On Red Hat with up2date:
up2date -u

On Mandrake:
urpmi.update && urpmi --auto-select

Take a look at that, any idea why a TON more people run Windows?

Re:Many eyes, but wide open or tight shut ?

[mcbridematt]

But doesn't UML have a big performance hit?

Re:Many eyes, but wide open or tight shut ?

[Wolfrider]

--Guess what happens when apt-get upgrade (or dist-upgrade) breaks the system? You get two choices:

1. Restore from backup (if you're lucky)

2. Reinstall

--At least for home users, it's much easier to start over with a fresh install (especially if, like me, you're running off a Knoppix or Mepis live-cd install) than try to figure out what went wrong and why -- THAT process can take hours (or days!)

--True story: I recently did apt-get update/upgrade on my Knoppix boxes, and WVDIAL broke on *both.* I didn't know this until after a reboot/hangup however. Kppp was also acting flaky and wouldn't connect. Lucky for me, I had a Vmware Knoppix DVD install that hadn't been touched for a while; got wvdial and squid running in there, so I was able to downgrade wvdial to stable on the regular boxes (apt-get install wvdial/stable).

--I still have to figure out how to put wvdial on "Hold" w/o using Aptitude though. Anybody got a command-line equivalent for that?

Re:Many eyes, but wide open or tight shut ?

[CyberDruid]

[displays 46th chromosome, which is clearly an X]

Young lady, on this site we do not expose ourselves in public. The dress code clearly states that skirts must go _below_ the 46:th chromosome.

Re:Many eyes, but wide open or tight shut ?

[horza]

You make a very salient point about why Open-Source software may be less vulnerable to attack than proprietary software. Basically, if you discover a vulnerability in a closed-source program, there is NO honorable way to get recognition or respect for your digging... the best you can do is quietly report it to the company and hope they fix it, knowing they will not usually acknowledge you for reporting it.

Not only that, if you are too enthusiastic about getting them to fix their vulnerability you also risk going to jail.

Phillip.

Re:Many eyes, but wide open or tight shut ?

[juhaz]

Take a look at that, any idea why a TON more people run Windows?

Dunno. Why is that? Because they saw something one guy or another posted on Slashdot and automatically thought it was the only way?

Re:Many eyes, but wide open or tight shut ?

[smallfries]

I think that you're a little harsh on the kernel developers. If you read the whole advisory (especially the part about how to exploit this) and then read the code, its quite a chain of events that leads to an exploitable situation.

Much like being good at chess, or perhaps crosswords, finding these types of vulnerabilities takes a lot of lateral thinking and quite a few imaginative leaps. The simple fact is that the code in the kernel is complicated, that leads to lots of possible contexts for lots of possible code paths to be executed in. Finding these holes in just one of those paths in a particular context is hard.

On your last point, this is something that is covered in most verification courses. There is always 'one more bug' in any piece of software (as long as it isn't completely trivial). Its really a philisophical question as to whether finding a new bug should make you think the software is more or less secure. Personally I would tend to go with the approach that the more bugs that are found - the less are left.

Re:Many eyes, but wide open or tight shut ?

[airjrdn]

My point being, many things are still very non-intuitive in Linux. Even if it means copying the way Windows does something Linux is going to have to change to gain decent amounts of desktop market share.

Like it or not, Windows is the standard. To overtake it, Linux will have to meet and improve on the standard; NOT just with regards to security but also with regards to the user interface.

Re:Many eyes, but wide open or tight shut ?

[Mignon]

Ironica: My name is Ironica.
AC: Ironica. The Ironica? That posted the +5 insightful comment on open source vs. closed source vulnerabilities? Jesus.
Ironica: What?
AC: I just thought, um, you were a guy.
Ironica: Most guys do.

Re:Many eyes, but wide open or tight shut ?

[Tinidril]

just like windows update, a simple software patch has the potential to hose an entire system!

Of course any patch has that potential, but by experience has been that this is much more of a problem with MS than with Linux.

OSS software tends to divide functionality into smaller discrete units with better defined functional requirements than with closed source. I think its a combination of the fact that OSS tends to be more academic than closed source, and that OSS projects would be dificult to build in a community model if the code were organized in a giant knot.

A lot of problems in mremap...

[LucidityZero]

Wasn't there a (third) problem with mremap back around summertime too? These all sound like barebones, common mistakes. Who is contributing this source? Was it all the same person? Maybe we should be checking his/her code a bit more closely!

Re:A lot of problems in mremap...

[Anonymous Coward]

Maybe is was Linus, and we should stop accepting his contributions :-)

Re:A lot of problems in mremap...

[Hello this is Linus]

quiet you. >:(

Re:A lot of problems in mremap...

[Otter]

These all sound like barebones, common mistakes. Who is contributing this source? Was it all the same person? Maybe we should be checking his/her code a bit more closely!

19 minutes later, and no one has blamed SCO yet? What's wrong with you people today?

Install windows!

[Compunerd]

Get windows CD
Boot
Install

bah

Re:Install windows!

[SphericalCrusher]

Yeah, and get ten times the critical updates. Plus, Microsoft seems to always wait half of a year to a year to fix them, but with Linux, it's done really quickly. (Hints this bug)

Re:Install windows!

[arose]

Reboot in 60 seconds...
Reboot in 60 seconds...
Reboot in 60 seconds... ...

Re:Install windows!

[pwroberts]

> Get windows CD
> Boot
> Install

So where does "Profit!!!" go?

Re:Install windows!

[marcello_dl]

>> Get windows CD >> Boot >> Install >So where does "Profit!!!" go? To Microsoft ;)

Re:Install windows!

[arose]

And you haven't connected an unprotected Windows 2000 or Windows XP machine to the net my anonymous friend.

Re:Install windows!

[paranode]

Get windows CD
Boot
Install

Get worm
Get Windows CD
Boot
Install
Reboot
Repeat as required.

Damn

[Broken_Windows]

I really did not want to spend my Sunday patching kernels.

Re:Damn

[Anonymous Coward]

Don't bother. There's no published exploit. Have a beer. Watch the game. Don't worry. Relax. What's your IP?

Re:Damn

[Tremanhil]

So turn off your PC, pop a bag of Kettle Corn or Pop Secret into the microwave and spend part of your Sunday popping kernals... and the rest watching movies.

And patch your kernel another day.

Re:Damn

[fire-eyes]

If you'd have kept up to the latest stable, you wouldn't have this problem.

Re:Damn

[f0rt0r]

Hmm, is this available via Yum repositories? One of my suprises was that this utility installs new kernels for me automagically. On the down side, my network card module breaks ( so far ) every time I boot to the new kernel that Yum installed. But I think I can live with recompiling the NIC module now and then.

Re:Damn

[pyrrhonist]

pop a bag of Kettle Corn or Pop Secret into the microwave

It's not a good idea to use products that rely on security through obscurity.

dupe

[Feyr]

huu dupe? that thing was released over a week ago!

Not a new vulnerability

[Anonymous Coward]

This is the same vulderability that was disclosed a few weeks ago. The advisory was updated on March 1st to include exploit code.

Re:Not a new vulnerability

[jmorris42]

> A lot of us depend on these kind of heads-up notices from Slashdot.

Except this one is from Feb 19 so it is old stale news. RedHat issued an srpm which I grabbed, built and distributed to my WBEL users way back on that date and it has the exact same CVE id number. If your system has been vulnerable all this time it is really your fault for not subscribing to your distributer's security mailing list. Slashdot really isn't the proper forum for you get be getting your security notices.

I'm guessing that we can expect a patch from SCO?

[rivaldufus]

After all, if they can expect people to license Linux from them, they should be providing support.

Does this mean...

[mcx101]

...I'm going to have to patch the kernels on the Debian servers and reboot again?

That'll be the third time in as many months.

Re:Does this mean...

[Weird O'Puns]

It's only a local exploit. So, if you are doing things correctly and other programs don't have any security issues that would give attacker access to your computer, you should be fine.

...but it is still a security risk. So, if I were you I'd patch.

Re:Does this mean...

[Akoma The Immortal]

Ignorance is a bliss!!

How can I break my own uptime record of 253 days beetween reboot when you patch all the useless local exploits!?!?! Stop it!!

14:37:24 up 42 days, 14:38, 1 user, load average: 1.50, 0.48, 0.16

And comming down because of you!!

Geeee, those FOSS guys are terrible.

Re:Does this mean...

[jjeffries]

I'm wondering the same thing. Is this the same problem that was patched in debian's 2.4.24-3?

Re:Does this mean...

[Wolfrider]

--Be thankful you're not a Mainframe admin - back in my day, (at least up to Y2000) we had to IPL those suckers every weekend. 'Struth. Very rarely did a particular MF box last more than 2 weeks w/o being IPL'ed.

Re:Which kernels are effected

[Broken_Windows]

From the release: Version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2

Well, as they say...

[Anonymous Coward]

In Linux it's a bug...

In Windows it's a feature.

Re:Well, as they say...

[merdark]

Well, this particular bug has been a *feature* of Linux for a good number of years.

With bugs like that, who needs features!

Amazing what a one line oversight can do

[Anonymous Coward]

Just compare the time and effort putting together the 3 page write up on the bug to the cost of reviewing and fixing the code in question when it was originally written. I believe the study that found that once the bug leaves the development shop to go to consumers it costs $9000 per line to fix. It's as true in open source as it is for closed source.

Re:Amazing what a one line oversight can do

[cperciva]

I believe the study that found that once the bug leaves the development shop to go to consumers it costs $9000 per line to fix.

That figure depends largely upon how many customers you have and how sophisticated your patch-distribution system is. In pre-internet days, a critical problem might have meant shipping a floppy disk to each of your customers (of course, this reduced the chance of problems being classified as "critical"). Now, most security problems in FreeBSD can be fixed in two minutes using 50kB of bandwidth and binary patches. Most operating systems fall somewhere in the middle, distributing entire files, or even complete packages, every time a one-line security fix is necessary, with the effect of requiring a 50-fold (or more, in the case of packages) increase in bandwidth (and, over slow connections, time).

Someone from Microsoft explained this to me as "we've got huge amounts of bandwidth, so we really don't need to save bandwidth by using patches"... it doesn't surprise me that Microsoft ignores the fact that delta compression would benefit their customers, but I expected better from Apple or the Linux community.

Re:Amazing what a one line oversight can do

[addaon]

Mostly, I agree with you. But do realize that the advantage of distributing the whole package is that the distributor doesn't need to know what version all customers are using. 1.0 is released, everyone gets it. It's found to have a bug. 1.0.1 comes out, then 1.0.2.... so there are three versions in the wild, if not everyone upgrades perfectly. Release three patches, and QA three different things, or release 1.0.3 as a complete package, so everyone who does update now has the exact same thing?

Re:Amazing what a one line oversight can do

[cperciva]

Release three patches, and QA three different things, or release 1.0.3 as a complete package, so everyone who does update now has the exact same thing?

No. Build 1.0.3. Build binary patches for each of (1.0 -> 1.0.3), (1.0.1 -> 1.0.3), (1.0.2 -> 1.0.3). Provide a simple shell script which looks at the MD5 hashes of files on disk and downloads the appropriate patch. Everyone who upgrades ends up with exactly the same files; no need to QA anything more than once.

(This assumes that you trust the binary patch tool to work properly; but you can check the MD5 hashes of the files post-patch to ensure that everything worked, and download the complete file if anything went wrong. My experience with FreeBSD Update is that around 1% of systems -- usually from AMD -- have heat-induced problems during the patching process, so at least for commodity hardware, this final verification is necessary.)

Re:Amazing what a one line oversight can do

[virtual_mps]

Patches tend to be a nightmare from a support perspective. You end up with an exponential increase in the number of packages you are expected to provide support for, which is beyond the ability of any organization. I'd rather have a stable system with an integrated set of packages than an unstable mess of incompatible patches.

Re:Amazing what a one line oversight can do

[cperciva]

Only if you do things wrong. I'm not talking about a pick-your-own-subset-of-linux-kernel-patches situation here; I'm talking about using patching to update everyone to the same official release. You'd have exactly the same files on disk as you get by downloading the entire package; the only difference is that by using binary patches you can reduce the bandwidth requirement by a factor of 50.

Re:2.6.3?

[say]

Oops. That HTML posting problem. This was what I was trying to say:

Apparently, only <= 2.6.2 is affected. How could this be fixed in 2.6.3 without anyone noticing that it might be a problem in earlier kernels?

Can someone quickly fix this ?

[Anonymous Coward]

So we can get back to bitching about Window's security flaws :D

Re:Can someone quickly fix this ?

[CmdrTHAC0]

Done. Tell you what--I'll even include the fix in 2.4.25.

Re:Can someone quickly fix this ?

[Bombcar]

I don't get your sig. It just prints 42. I was hoping for something exciting, like 43.

Re:Damn (all your base are belong to us)

[kompiluj]

Oh really? I am running 2.4.25 on my all systems for two weeks already - since the first advisory. Patch or be patched.

Not a big deal really

[jmoen]

Seems like none of the current releases are affected by this anyway. Ref. the article:
Only version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2

-jmoen-

Re:Not a big deal really

[Nicolas Pillot]

But every time i hear about security holes and people saying the latest version fixes it, i wonder how many "old" version are running around the world, and how long it will take (if ever) to be updated.

Re:Not a big deal really

[Schugy]

I'm running Linux 2.4.25 but I have the original SuSE-kernel installed too. It's not a big deal to patch Linux 2.4.25 and recompile it. Companies like amazon or web.de don't use a single server, they'll patch one after another. These two would be out of business without Linux and they will survive this little pain.

"Windows users: want Security, install linux"???

[Padrino121]

Slowly but surely as Linux is getting more mainstream it seems the same kind of holes that perpetually plague Windows exist in Linux as well.

It might be time to take a page from the MS book and take a few weeks for a full line by line audit.

Somewhere . . .

[Prince Vegeta SSJ4]

A Giddy Billionaire is scheming:

Kernel 2.6.4-rc2-bk3: Never, I'll Never turn to the Dark side, I'm open source...like my father before me.

Bill: So be it, open source

Bill: if you will not be turned, you will be destroyed (shooting purple lightning bolts)

Bill: You will pay the price for your lack of vision

Kernel 2.6.4-rc2-bk3: Linus please (in agony).

.....to be continued

I await my -5 (Troll)

Clueless lamer

[baudbarf]

How does one go about patching his kernel, pray tell?

Re:Clueless lamer

[KingOfBLASH]

Well it depends what distribution of Linux you're using. On some versions it's as simple as downloading an RPM via an update script and rebooting, on others it actually involves compiling the kernel. What distribution are you using?

Re:Clueless lamer

[baudbarf]

EW!! I'd rather not HAVE an OS!!

From the link...

[Spoing]

1. Synopsis: Linux kernel do_mremap VMA limit local privilege escalation vulnerability

Local, not remote.

In general: If an attacker has local access or can gain the equivelent by using a remote access tool, a local exploit can be a problem.

So, personally I'm not too worried though others with different types of users or configurations might have a high level of concern.

Re:From the link...

[cyborch]

I have to agree. This is at most a yellow alert. If I see a remote root exploit I change my server firewall settings to extreme paranoia (drop all packages from everywhere) and upgrade immediately, for bugs that only affect local users I am less worried. If people gain sheel access to my server they already have gotten past my defenses, which are based around keeping people from getting inside, not around keeping them from getting root priviledges once they are inside.

Re:From the link...

[Spoing]

1. If people gain sheel access to my server they already have gotten past my defenses, which are based around keeping people from getting inside, not around keeping them from getting root priviledges once they are inside.

Exactly. Over time the seperation of access rights as in SELinux is also a very good thing;

Don't allow local access

If local access is gained, protect the important resources and protect other local accounts

If the local accounts can't be protected, limit what they can do (aka drop the superuser/root account)

I'm looking at the tools for this in Fedora Core test2 and in theory it looks possible, though it is an entirely different way of looking at things. I'd be surprised if in 3 years tech like the SELinux extentions aren't the default account and access methods.

Old news

[phaze3000]

This is why 2.6.3 was released, as discussed in this slashdot story from the 18th of Feb. The date on the linked article is March 1 - this is a second document on the same vulnerability that gives more details. It was not released at the time to give people a chance to patch.

Re:Old news

[Anonymous Coward]

This is why 2.6.3 was released, as discussed in this slashdot story from the 18th of Feb.

Slashdot in general needs to get a grip. Far too much of this kind of thing going on. Its getting close to the edge of not worth spending any time at all on slashdot.

known since 18. feb. 2004

[gst]

actually this vulnerability was announced on 18. feb. 2004 by isec (see http://lwn.net/Articles/71682/).

isec just waited some weeks until they released the exploit...

Re:known since 18. feb. 2004

[juhaz]

What should they say? And why?

The patch was released right after vuln, pretty much on the same day.

Example exploit is released only now, to make sure everyone is already patched.

Laymens terms?

[oldosadmin]

Could someone please say what this vulnerability is in English? That article made my head hurt.

Re:Laymens terms?

[WWWWolf]

Sure. A program can ask the operating system kernel to Do Things. Now, someone has found out that when you ask the kernel to Do Things certain way, the kernel subsequently thinks you are the Boss.

Like, you have this stack of forms you want the computer signed. You hand them over to the computer. One of the papers is "Do whatever I say" form that would give you the Power. The computer won't read it and just signs it along with the others, then hands you the forms back.

How's that for an explanation?

Re:Laymens terms?

[oldosadmin]

Ah. But this a local vulnerability right?

Forget patching the kernel, I'm just gonna lock my door.

P.S. I'm getting screwed by the no-karma Funny mod again. A +2 post == -2 karma for me. PLEASE FIX THIS.

Re:Laymens terms?

[WWWWolf]

Ah. But this a local vulnerability right?

Yes. had it been a remote one, the better analogy would be to send letters through an extremely overworked post office where the folks handling everything will stamp okay everything that has anything that has words "approval stamp here".

Or something. My explanation skills are considerably lower than they used to do (or maybe they werent that good to begin with).

Important to Remember

[rudy_wayne]

When a Windows vulnerability is patched, it is proof that closed source software is evil.

Wne a Linux vulnerability is patched, it is proof that open source software is wonderful.

Re:Important to Remember

[Anonymous Coward]

TO DO:

Log onto slashdot.
Bash Microsoft.
Bash the bashers of Microsoft.
Bash the bashers of the bashers of Microsoft.
... ad infinitum

Re:Important to Remember

[FattMattP]

When a Windows vulnerability is patched, it is proof that closed source software is evil.

You misspelled if.

Re:Important to Remember

[eldacan]

I don't either. I just wanted to point out that nobody claims that "When a Windows vulnerability is patched, it is proof that closed source software is evil". The fact that a patch is realeased is not relevant, what matters is when it's released. This applies to both OSS and proprietary software.

I thought the original comment to which I responded showed some confusion as to what is criticized in MS products and patches. Of course, when/if a critical Linux vulnerability is patched three months after its discovery, it's as bad as if it were in an MS product.

Re:Important to Remember

[eldacan]

A sufficiently long time I think. If you want to continue this discussion, I suggest we do it by email. You can write to elendur@hotmail.com .

Re:Important to Remember

[KingOfBLASH]

When a Windows vulnerability is patched, it is proof that closed source software is evil.

Wne [sic] a Linux vulnerability is patched, it is proof that open source software is wonderful.

You know there are -- among the many, many, many open vulnerabilities out there -- two which are particularly problematic for Windows users. (There are many more out there, but I figure I'll focus in on these two for now.

The first one allows an attacker to mask the real address of the site you're viewing in IE. So, go and open up a spam claiming that Paypal needs you to update your credit card number, and you'll actually see PayPal.com as the URL. The second one allows an attacker to crash IE and exploit arbitrary code when a user views a picture on a web page under IE.

As a Computer Programmer, I understand how hard it is to create 100% bug free code. Any system as complex as Windows or Linux is bound to contain some bugs and / or vulnerabilities. However, when an exploit is found in Windows (to the best of my knowledge those two exploits have yet to be patched), it takes forever to get a fix to the public.

On the other hand, as soon as I heard of the vulnerability in the Linux Kernel, I have the following options:

1. Patch it myself and submit the patch for everyone elses benefit
2. Disable the use of the system call that can be used to create the vulnerability until a patch is found.
3. Help test patches created by someone else -- possibly with much stronger C skills then mine (Hey, Linus can outprogram anyone as far as I'm concerned. There's no dishonor in being outgunned by the best)

Now, whereas I am pretty certain Slackware will have a package available for me to update my kernel in another 48 - 72 hours, and if it's absolutely urgent for me to fix it I can either disable it or fix it myself (something Windoze won't let you do -- although the nature of the vulnerability in the kernel may make disabling it impractical. But still, at least you have the option), Microsoft has not, to the best of my knowledge, fixed these vulnerabilities, even though it's been months.

This is why Open Source Software is so great. Technically sophisticated users hold the destiny of the software in their own hands. And I haven't even begun to get started on how great it is not to submit annoying feature requests, but to make software do what you want it to do.

Re:Important to Remember

[catenos]

Who said that I was talking about this vulnerability . All I said was that it is impossible to do any proper testing of a patch if it is realeased minutes/hours/days after it is discovered.

Two things:

1. Why aren't "days" enough to do proper testing? I agree that minutes aren't enough. And neither are hours usually, but there cases where I would argue that, depending on the kind of change, the testsuites and the QA requirements.

2. In OSS, most times a patch isn't released in the conventional meaning of the word ("released", I mean). The patch is made available (often when it is checked into CVS). What will be released is a new tar ball or announcement, after the QA process. Me, I consider it released, when my favored distribution has an updated package for it on its security site. And contrary to some Microsoft fixes, I never had a Mandrake or Debian security update break my installation - so the QA process seems to work.

It's simple to mix up those, because in closed source you don't see the step where a patch/fix is internally distributed from devs to QA. In OSS you do, but that doesn't imply an official release.

But on the other side, the difference in availibility matters. Having access to the patch before a security update is officially released, gives me a choice. If it's criticial enough for my infrastructure, I can dig into it and do my own QA and deploy it even before an official announcement is available.

Heck, if it's important enough, I can start even before a patch is available, because I have the source. And if you follow security lists, you will notice that it is no exception that a so created patch will find its way into the official release (in other words: the time to release is cut short, because a suggested fix is already available the moment the core team starts looking at the problem).

Re:Important to Remember

[Lennie]

Sorry, but the structure of the Linux kernel is quiet good, a lot of it is very seperated and thus does it does not cause problems in other places when you fix something in an one part.

I'm not sure, but I think it has something to do with the very great number of programmers involved, you really _have_ to seperate everything really well, otherwise things will fall over everytime a junior kernel hacker creates a patch.

Just read the source, it's quiet structured (although I do have to say that things like the the fairly recent 2.6 Interactivity and Responsiveness improvements will probably make it easier to get timing problems).

Re:Important to Remember

[jonadab]

> > When a Windows vulnerability is patched,
>
> You misspelled if.

Indeed. This is particularly relevant since we're currently discussing a
local privilege escalation vulnerability. Windows has had a local privilege
escalation vulnerability publically known for quite a long while now that
Microsoft has publically stated they will not fix. (Google for "shatter
attack".) They can't fix it easily because the fix would have to change
the Win32 API in a way that would break large numbers of applications,
including e.g. almost all antivirus software. Backward compatibility is
more important.

Of course, this (and any local priv escalation) is only a really big deal if
it can be combined with a trivial remote exploit that doesn't by itself give
privs. So, you want to patch it before a trivial remote exploit comes out.

Re:Important to Remember

[Lennie]

But atleast in the Linux world, _when you tested it_, you can fix the app yourself, you know exactly what changed in the kernel, and you have the code for the app (if it's opensource, anyway).

Story is a troll!!!!!

[bangular]

This story is old.

Version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2

2.6.3 and 2.4.25 have been out a while. This is _not_ a new vuln. All this will accomplish is a bunch of idiots saying "see, linux is insecure".

Re:Story is a troll!!!!!

[imsabbel]

Dont you think a security hole that is VERY OLD and still there is a lot worse than one that just slipped in with the last revision?

Re:Story is a troll!!!!!

[LuSiDe]

And >= 2.2.26 fixed this also.

Re:Story is a troll!!!!!

[sbrown123]

Its so old that it has already been fixed. This is reporting the second mremap issue that was reported a few months back.

Re:Story is a troll!!!!!

[Ironica]

Dont you think a security hole that is VERY OLD and still there is a lot worse than one that just slipped in with the last revision?

But, what he's saying is, it's NOT still there. It's been fixed already.

More critical vulnerability in FreeBSD

[chrysalis]

Another kernel vulnerability was recently found in all FreeBSD (4.X and 5.x) versions.

The TCP/IP stack can be stopped by sending unordered TCP fragments.

This is a serious remote vulnerability, and any FreeBSD with an open TCP port should be patched ASAP.

Here's a link to the official advisory :

ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisorie s/ FreeBSD-SA-04:04.tcp.asc

Regardless of the operating system you are running, always keep everything up to date.

Re:More critical vulnerability in FreeBSD

[cperciva]

Yes, more critical... in the sense that an easily detected (just look at the packets), non-spoofable (you can't do this without having finished a TCP handshake first), denial of service attack is more serious than a root exploit.

Re:More critical vulnerability in FreeBSD

[Homology]

Another kernel vulnerability was recently found in all FreeBSD (4.X and 5.x) versions.

The TCP/IP stack can be stopped by sending unordered TCP fragments.

This is a serious remote vulnerability, and any FreeBSD with an open TCP port should be patched ASAP.

Crashing a server via the TCP/IP stack is just a denial of service, however annoying it is. But getting rooted is far more serious in most cases.

Re:More critical vulnerability in FreeBSD

[Strog]

Yes it is a fairly serious thing. It's easy to stop if your firewall scrubs packets (puts them back in order). If it's a 5.x machine then you can install pf and do it on the host to be sure. A lot of people's setup already has scrubbing implemented (including my own) and have some protection from this already. This is no excuse for not keeping your box(es) patched and up to date regardless of OS. It's fairly trival to cron the patch update and even have it rebuild world/kernel when a new patch comes down the pipe.

Bottom line is that unpatched boxes can have the risk minimized through good admin'ing and even patched boxes can be trouble with bad. Patch those boxes and practice good security habits. :-)

i beg your pardon?

[hot_Karls_bad_cavern]

"...And how do you avid windows-baiters react to it? How come you hypocrites just blow Windows bugs out of proportion while attempting to cover up Linux kernel holes?..."

Um, the source code for the *fix* is listed *in* the article (you didn't read it did you?)

i don't call posting fixed code and owning up to an exploitable coding error "covering up".

Re:i beg your pardon?

[stock]

"Um, the source code for the *fix* is listed *in* the article (you didn't read it did you?)"

I did, the only thing which was posted was the source code for a exploit program. Not really what i would call a *fix*.

Robert

Re:i beg your pardon?

[Avihson]

---The grandparent post made the completely valid point that if Linux isn't perfect then you have no right to advocate it as secure and mock Windows for its flaws...It shows the BSDs as the preferred choice over both Linux and Windows, yet it doesn't have nearly as much hype as Linux.---

So since nothing is "perfect" then we should just STFU and accept the bull that MS sells us???

According to the quoted mindset, the Commodore vic-20 is more secure than either, since less people run it. How many evil hackers are out there breaking into vic-20 servers? What kind of warped logic is that? Security is a state of mind, a process, not a state of being.

You can't quantify "secureness" of a system. But you can rate the availability and complexity of the security exploits available for each OS.

They gave you the source code, and explained the vulnerability. Now Go exploit it if you can. If you can't then please sit down.

MS did NOT give out their source, yet everybody can exploit it. There are exploits coming in the email every day, I don't even have to search!

Learn to mitigate the vulnerabilities. I choose to do that by running linux and keeping up to date, some choose to run Windows and rely on MS to keep them secure. I have a better track record!

I received 5 emails today with attachments that I could not run, that did not auto load. I have yet to get a shell script in the mail that gained root access, and replicated itself to all of my email contacts.

Now if BSD does what people and Business need, then they will use it. I use BSD on my network, along with x86-Solaris, and Linux for the desktop (Redhat and Mepis). I choose not to use Microsoft products in my home or business, I only use them on site if my clients use them. It is not about "hype" it is all about choice. ZDnet chose Linux over BSD when they switched from Solaris for their webservers.

don't worry, be happy.

[nuckin futs]

No need to worry, and we all know why...
a patch will be out (if it isn't already out) within days, sometimes hours. I don't have to rely on MS.

Re:don't worry, be happy.

[OwlWhacker]

It's funny how Microsoft is mocked for its terrible patching, then it acts as if a miracle has occurred and starts telling everybody how Windows patches are available within weeks, but Linux patches are available in months.

What does evidence suggest? That Linux patches are out within days/weeks, but Microsoft patches are taking months/never.

It was the same with security, Microsoft was mocked for its terrible security, then it starts telling everybody how Windows security is so much better than Linux security.

I could be wrong, but I think that Microsoft is lying.

Re:Which kernels are effected

[pseudochaotic]

Whew! I just installed 2.6.3, and i was afraid i would have to reinstall again.

Re:"Windows users: want Security, install linux"??

[Padrino121]

Neither have I, but that wasn't the point of my post.

The goal a lot of people have is to make Linux mainstream, that means that less and less knowledgeable users will be using it. If Linux continues to suffer from kernel exploits from time to time just like Windows then those same users will be running executable mail viruses built for Linux just like they do for Windows now.

A lot of people I've seen using Linux have a false sense of security and therefore aren't as careful as they are on Windows (which is a scary thing because we all know how insecure Windows is).

Re:Here we go again

[bafu]

Do I laugh or do I cry? ...

Laugh, I would say. While both laughing and crying are versatile enough to be used regardless of whether it is a time of great happiness or great sadness, laughing is definitely more "out there".

just when I had finished compiling 2.4.25 on my systems..

Anyone who "just finished compiling" the latest release of their favorite kernel tree is all set (assuming the installed it), since this "new kernel vulnerability" is only new in the /. sense. I would think that people who are super-concerned about such things would recognize that in reading the bulletin.

Did I read the security bullentin correctly

No, you did not. :-( When it said...

2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2

...you mistook the 2.2 for a 2.4 and thought that it effected your 2.4.25 kernel.

This is medium old news.

[Anonymous Coward]

This is the second mremap() vulnerability finaly making it to slashdot. Note the date on the linked page, March 1.

You just thought it was the third because you already heard about two, and forgot that sometimes things take a week or so to make it to /.

Re:This is medium old news.

[Anonymous Coward]

And please note, that March 1 is the date of an update of the announcement. The bug was fixed in 2.4.25 and the original announcements are from mid february.
Everybody considering this bug "news" should check his way to track security announcements!

Re:Here we go again

[lordsilence]

Or I simply wrote that by purpose to see if you'd pull another flame on me.
On the other hand, I could just be trying to make an excuse :)
You'll never know will you?
This is getting too much off-topic.

Not the way to make friends.

[stock]

This guy investigating mremap is saving a new vulnerability for every week. He's working only to get his name printed everywhere. I cannot take this seriously. If he's a genuine security analyst, he'd fix _all_ mremap related bugs within 1 patch.

My biggest grief, is him not releasing source code patches for genuine kernel.org kernels. If he's so good to release sploits, he's good enough to submit source code patches.

Robert

Re:Not the way to make friends.

[Mr. Hankey]

This doesn't seem to be the case. It's the same vulnerability announced a few weeks ago, for which a fix has been available for some time. He updated it with exploit code on Monday, but this is after the fact. I woke up this morning, looked over and tried the exploit code, which failed. I then realized that it's testing for the same vulnerability that I've already patched. I suppose that it took so long to realize this proves that I'm not a morning person.

In short, he doesn't need to release a patch. Properly administered systems aren't even vulnerable anymore.

Date format

[mandrews]

disclosed on 05-01-2003

OK time for me to tilt at a few windmills. Aside from the date being off by a year (the link quotes the date as 05-01-2004), is this supposed to be 1st of May or the 5th of January?

In an international forum and for clarity, ISO 8601 dates. Therefore: 2004-01-05.

Sorry for the rant, but I work for an international company, and have spent sizable parts of meetings trying to figure out which version of a document is "most recent", 2/3/04 or 3/2/04.

Re:Date format

[mwillems]

Or UN dates:

03 May 2004
31 Jan 2005
03 Oct 2004

Even if you do those in another language, the meaning is still much clearer than 03/05/04

Michael

Re:Date format

[Lehk228]

or is that the 5th of january 2004...

in europe dates are done DD.MM.YYYY which really is a more logical system, although i prefer the reverse YYYY-MM-DD when used in File names because then a name sort puts them in the right order

Re:Date format

[Nicolas Pillot]

I have a dream : everyone starts working on the 13th of every month. There would be no date conflict, and furthermore, you would have much more holidays :-)

Re:Date format

[erikharrison]

Unfortunately, as logical as ISO dates are, they are hard for our American brains, spoiled by years of idiocy, to parse. I prefer this 1 - May - 2004 Unambiguous to everyone, but may make you look like a Scientologist

Re:Date format

[Zaiff Urgulbunger]

The above post was not in any way intended as "flamebait" -- it was a plain question!

Re:I'm guessing that we can expect a patch from SC

[shrinkwrap]

Expect a patch? I'd rather sue them! LOL

Re:Here we go again

[lordsilence]

Or irritating people who don't have access to 0days and trying to leech slashdot for vulns. could go back and do what-ever they were doing before, rather then flaming people who made a mistake. *yawns*

if you patched two weeks ago, you can ignore this

[redmoss]

This is partially redundant to a few of the other posts here saying that this vulnerability was already disclosed several weeks ago. However, I thought I'd add that if you already patched, check the vulnerability ID; in this case it's CAN-2004-0077. Your patch should have specifically mentioned this ID. If not, you need to patch again.

Thank $DEITY I don't need to patch/reboot again. I was starting to get a bit annoyed at having to patch the kernel twice in two months. Scheduling reboots of machines in use by many people is no fun.

Re:Here we go again

[lordsilence]

Appearently you and I have nothing better to do then write replies to eachother.
Yes, yawning is known to "spread".

Re:Install windows! more like

[frause]

Get a windows CD
Boot
Reboot
Install
Reboot
Install some more
Reboot
Continue installation
Reboot
Register windows installation
Change a setting
Reboot

bah

Patched in 2.6.3 apparently

[petabyte]

I'm fairly sure this was patched in 2.6.3. Running the test code included in the advisory on my 2.6.3 (vanilla) system shows:

[+] kernel 2.6.3 vulnerable: NO exploitable NO

There's also a patch to mremap listed in the 2.6.3 ChangeLog. So I don't know how "new" this bug is.

Re:Patched in 2.6.3 apparently

[caluml]

I've tried that exploit on all of my boxes the first time I read about it. However, it always fails, and never works. I am wondering if some of the grsecurity patches are disabling it.

calum@xxx calum $ ./mremap_pte

[+] kernel 2.4.20-gentoo-r9 vulnerable: YES exploitable YES
MMAP #9216 0x43000000 - 0x43001000Segmentation fault

Mar 7 18:49:38 xxx kernel: grsec: From xxx.xxx.xxx.xxx: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (mremap_pte:7672) UID(1000) EUID(1000), parent (bash:26711) UID(1000) EUID(1000)

Anyone know if the grsec stuff is saving me?

Re:Patched in 2.6.3 apparently

[BusDriver]

Yes, it is saving you.
That doesn't mean someone won't release an exploit that doesn't trigger pax though. It's just the way this particular example of the exploit is coded that PAX (part of Grsec) is catching. Doesn't mean someone can't code up a version of the exploit that won't trip PAX and hack you to bits!

Upgrade to the latest grsec, there are patches for the latest 2.4.25 kernel.

Re:Patched in 2.6.3 apparently

[caluml]

grsec is excellent - I really really like it. I know that just because it foils this current exploit doesn't mean that I'm safe and sound - but it does mean that any of the users on that box can't just grab that exploit and root it, and they're not likely to write their own exploits.
By the way, it seems that grsec has been superceded with selinux in 2.6 kernels - it seems a shame to me - and there don't seem to be any 2.6 grsec packages. Not that I'd upgrade that server to 2.6 - if it's not broken, right? - but do you know what's happening on that front?

Re:Damn (all your base are belong to us)

[October_30th]

Patch or be patched

No patched kernel yet available for my RedHat, SuSE or Gentoo distributions and I'm sure as hell not going to compile a vanilla kernel that would only mess up the package management system.

Re:"Windows users: want Security, install linux"??

[fwarren]

The goal a lot of people have is to make Linux mainstream, that means that less and less knowledgeable users will be using it. If Linux continues to suffer from kernel exploits from time to time just like Windows then those same users will be running executable mail viruses built for Linux just like they do for Windows now.

On a Windows box, there would have been no peer review. So instead of being discovered after 5 years, the only way we would know about it is if some hacker had reversed engineered it and exploited the problem. Then Microsoft would set on a patch for 6 months...if they decided to fix it at all.

In Linux, peer review found it, fixed it and made the information available, so you know that you have an exploit.

Linux seems much more Mainstream to me. Until people write perfect, bug free, secure software, give me a system that at least I can keep up to date and have a chance to protect myself.

So it costs $9,000, so what?

[raehl]

As long as it isn't YOUR $9,000.... ;)

Re:Here we go again

[lordsilence]

Thank you for the english-lesson. I'll be looking forward to our next session.

MS vs Linux debugging.

[innerweb]

If this had been a bug in MS, we may might not have heard about it for months or years unless someone on the outside published it. The crackers would have still had a good chance to have known about it.

What winds up happening is I pay MS to produce a product that I have very little input on. I buy the off the shelf solution to then develop 50% of the solution anyway. And, then it crashes, the documents are incorrect (updates might be available on their web sites), and I have no way of figuring out what the issues are without paying more $s for something I paid for already. If I tried to pull the same trick, I would loose my client.

Linux side is someone spots the issue, makes us aware of it in most cases. People have something more important than a paycheck at stake get to work on a fix for the problem. A, or multiple, potential fix(es) is(are) put up. Sometimes a fix goes straight in with minimal review (it works, most liked it), sometimes the fix gets kicked around to hash out any potential problems (in the full light of day, normally my apps do not break when the fix is rolled out.)

I like the public knowledge aspect of OSS. Yep, hackers have access to it also, but closed source never seemed to stop them, it just stop me from protecting myself.

Maybe we need to look at the next step for OSS? Maybe there is a better model for building OSS? Maybe companies might start providing more donations (like cheap lic fees) to a foundation that rewards freelance OSS programmers with cash for tackling certain problems (and does not pay until the code is peer reviewed and bug checked to a reasonable extent.) Maybe that would work better... Are certain organizations not starting to do that?

Given how much OSS has accomplished in the past decade with its relative lack of fees and "structure", imagine what might happen if more companies started using their proprietary source software budget to put bounties out on features they needed in OSS. True, not all features would they want to make public, but enough they would wat to so as to dramatically cut everyone's costs (GNU lic is important because of this). Most companies actually have very close to the same needs. But, their money goes to legal and marketing fees more than it seems to go to actual development fees with off the sheld software. What an economic waste! Check out John Nash for a rather different rather OSS view of the world.

In the end, you are left with a decision. The programmers at MS are very bright. The programmers in OSS are very bright. The real difference is the perceived safety of being able to blame MS (who you can not hold responsible yet - name one successful law suit against MS for the failure of their software to function as advertised) versus the cost effectiveness of not paying for huge legal and marketing fees (as well as other corporate overhead having very little to do with getting better or more code). I am not against programmers getting paid. I am against sloth and leeches in a corporate setting destroying the market in which programmers get paid.

InnerWeb

Re:MS vs Linux debugging.

[Izeickl]

"If this had been a bug in MS, we may might not have heard about it for months or years unless someone on the outside published it. The crackers would have still had a good chance to have known about it. "

But with the supposed 1000s of developers constantly looking at the Linux kernel why was the bug left in so long? How many months has this bug been in the kernel, easily open to the evil crackers to see? (Ive no clue, im asking as regardless if the bug is now fixed quickly or not, its been available for the oft praised peer review for X amount of time).

Re:MS vs Linux debugging.

[rruvin]

If this had been a bug in MS, we may might not have heard about it for months or years unless someone on the outside published it. And you didn't this time, either. This has been around since 2.2. How many years is that?

Re:MS vs Linux debugging.

[Tack]

But with the supposed 1000s of developers constantly looking at the Linux kernel why was the bug left in so long? How many months has this bug been in the kernel, easily open to the evil crackers to see? (Ive no clue, im asking as regardless if the bug is now fixed quickly or not, its been available for the oft praised peer review for X amount of time).

Nobody claims that peer review results in code which is free of bugs or security problems. The claim is the peer review model results in less bugs and security problems than the closed source model, given equivalent man power.

Cryptographers tend to be the most paranoid, security-conscious types, and any (respected) cryptographer is going to tell you that peer review is an absolute necessity. Peer review doesn't guarantee unbreakable algorithms, but if a dozen pairs of brilliant, and objective eyeballs review an algorithm and don't find any attacks, it's a hell of a lot more likely to be secure than some closed, proprietary algorithm.

It sucks that I have to update the kernel of all my Linux servers. But this is reality when you use complex software. I still feel much safer using OSS with a peer review model, because this way I don't have to trust that a company with an agenda (i.e. profit) has my best interests in mind.

Jason.

Re:MS vs Linux debugging.

[cpuffer_hammer]

You are not comparing the same things.The time from discovery to fix as apposed to the time from creation to fix. Your question is interesting, but the way you ask it is more political than scientific.

Re:MS vs Linux debugging.

[Chester K]

If this had been a bug in MS, we may might not have heard about it for months or years unless someone on the outside published it. The crackers would have still had a good chance to have known about it.

This vulnerability was in Linux 2.2, which means that we didn't hear about it for years until someone published it. The crackers had a good chance to have known about it.

This is not different than MS -- in fact, by implying that crackers are more up on security problems than the white hats are (since that makes bashing MS easier); it's worse for Linux that since the source showing the existance of this bug has been out there for 5 years, the bug was more easily discoverable by the black hats than an obscure buffer overflow in some code distributed binary-only.

Re:MS vs Linux debugging.

[Ironica]

Maybe companies might start providing more donations (like cheap lic fees) to a foundation that rewards freelance OSS programmers with cash for tackling certain problems (and does not pay until the code is peer reviewed and bug checked to a reasonable extent.) Maybe that would work better... Are certain organizations not starting to do that?

I certainly wish they would.

Re:MS vs Linux debugging.

[jpop32]

If this had been a bug in MS, we may might not have heard about it for months or years unless someone on the outside published it. The crackers would have still had a good chance to have known about it.

So, it's better, more secure when the said bug was sitting in plain sight, in publicly accessible source code, for 5 years, than locked tight, somewhere in Microsofts fallout shelter, and available only in binary? Crackers have a better chance of reverse engineering binaries, than simply reading the source?

It's so much fun when a Linux vulnerability is discovered. It amuses me to no end to see Linux zealots try to spin it as another victory and proof that Linux is more secure. :-)

name one successful law suit against MS for the failure of their software to function as advertised

Dude? Hello? Does _any_ software vendor anywhere guarantee anything regarding their products? I am yet to come across a piece of software that doesn't say 'if this SW burns down your house, kills your dog and rapes your sister, well, we didn't do it, nobody saw us do it, can't prove anything'.

Re:MS vs Linux debugging.

[innerweb]

Dude? Hello? Does _any_ software vendor anywhere guarantee anything regarding their products?

Uhh, yeah... We do. In writing

But, we do not promise the moon. We stick to engineering s solution instead of promising vaporware. If it does not work, we put work into it until it does. If for some reason we can not make it work, we refund the client. If it causes damage to the client, they can easily take their refund and go somewhere else. And, if it causes a problem with their stuff, we fix that as well. This has happened once in the early 90s, which is why we took a different path for development.

We are not a billion dollar corp, and we work on Linux, MS, and Mac. I am not a linux zealot, I program more for MS systems than anything else. It is where most of the money is at the moment.

So, it's better, more secure when the said bug was sitting in plain sight, in publicly accessible source code, for 5 years, than locked tight, somewhere in Microsofts fallout shelter, and available only in binary? Crackers have a better chance of reverse engineering binaries, than simply reading the source?

Uh, know any crackers? I do. They are the most brilliant programmers I have ever met. Either that says very little about the rest of us, or a whole lot about them. The guys I know (as far as I know) work inside companies at the request of the companies in a security auditing frame. And, they never need source and they always find many ways to crack. And I have watched them break into Linux/Unix/MS/Mac. None of them use MS products based on their experiences. That is why I choose to support the Linux model, because the people in the trenches who do the work that I know do that very thing.

Facts are facts though. This has been a bug since 2.x. It has been in the open (wild) where anyone with the proper itch can hit it. It has not been hit. That is why I mentioned the targeted reward. OSS is not perfect, but it is a far better model IMHO than the current commercial one. I believe that a hybrid model is the next model that we will wind up using, as it has the best benefits of both worlds. Yes and some of the biggest drawbacks from both worlds.

Fact is that Operating Systems are the new highways. Unless a good model is created to update, create and add onto this infrastructure without stranding current users or breaking old vehicles, governments will at some point have to step in to make it all work together. This is not unlike the early problems with electric power being delivered at different specs, thereby making it hard to get appliances that would work in many different locations. Dataflow is the root of the economy for the forseeable future. Just as the highway systems built the economy of the past 50 years. Mr. Gates got one thing right, the world needs to be able to use data without any worry about what data it is or where it is from. But, his company has never even come close to making it happen, and more often than not stands in the way of that happening. Information must flow. If it does not , it looses much of its value. Even the secret information is useless if it can not flow to those who need it.

InnerWeb

Re:Which kernels are effected

[Anonymous Coward]

Yeah, I just used my time dilator to install kernal 2.8.14, but then I checked and they've found yet another exploit that dates all the way back to version 2.0! So I set the time machine even further out and you're not going to believe this but--

+++no carrier

Fixed on SUSE kernels???

[multipart]

I can't exploit this on my SUSE kernel. All I get (after many attempts) is:

[+] kernel 2.4.21-192-athlon vulnerable: YES exploitable YES
MMAP #65530 0x50bfa000 - 0x50bfb000 [-] Failed

Perhaps this hasn't gone completely unnoticed...

Re:Fixed on SUSE kernels???

[Weird O'Puns]

There's a code for test program and instructions on how to compile and use it at the end of the report.

Re:That would be..

[Spoing]

1. That would be every admin of a linux server with user accounts... college student linux user accounts.

Yes, and probably ISPs with virtual domains on the same box/cluster. Neither are a problem for me though this could be a big pain for others.

eyes wide stupid?

[EvilAlien]

The only thing separating local exploits from remote in impact is the cracker finding a way to get unpriviledged access to the host. Lots of remote but "trivial" exploits are discovered, and sysadmins like to write those off as unimportant if they don't involve priv escalation... and with the next breath, write off all local-only priv escalation vulns.

You may trust your authorized users, but do you trust their passwords, habits in storing passwords ("You don't expect me to remember that, do you? Where are my post-it notes..."), and wisdom to not extend trust to ANYONE?

Do you also trust users to not run a piece of malicious code that shows up purporting to be some groovy new Linux app that will do some groovy new thing? Afterall, it would only have to require a vanilla user account... and Linux never gets viruses, so why worry? ;)

I think you see where I'm going with this. Local exploits need to be patched too, and sysadmins all too frequently think they don't because they are "only local".

Re:eyes wide stupid?

[Anonymous Coward]

Exactly. In the real world, remote rooting in one step might earn style points, but as a general rule, it just doesn't happen that often. It can be hard work keeping everything patched up to the nines, but if your company has ever called in a (good) pen testing team, you will have experienced first hand how a chain of seemingly 'trivial' vulnerabilities (including for e.g. escalating to the 'games' group) can result in the compromise of most of your most important assets.

Sysadmins who trivialize these 'moot' issues should realize that at some point, if not today, maybe next year, they are going to have to defend their judgement to an angry CEO who has just lost big money. I don't believe 'total security', even at the software can be attained. All we can do is to keep on patching, and to disclose these vulnerabilities in a responsible and efficient manner.

Re:eyes wide stupid?

[Some Dumbass...]

Lots of remote but "trivial" exploits are discovered, and sysadmins like to write those off as unimportant if they don't involve priv escalation...

Uh, no, that's not true. In fact, quite to the contrary, with so many systems' security being based almost entirely on not allowing access (e.g. a firewall and not much else) I daresay that most sysadmins would consider unauthorized access of any kind to be a major problem!

Re:eyes wide stupid?

[macdaddy]

Do you also trust users to not run a piece of malicious code that shows up purporting to be some groovy new Linux app that will do some groovy new thing?

Do you users actually know how to do such a thing? ... I didn't think so.

Re:eyes wide stupid?

[Endive4Ever]

A perfect snapshot example of the kind of admin arrogance that Personal Computer users revile.

The days of 'fill out form 11-B and wait two weeks and maybe we'll install that app for you' are gone.

That model of administration is dead, except in the largest most reptilian corporations.

Re:eyes wide stupid?

[Anonymous Coward]

simply disable all local user accounts.

I really dont understand what all the fuss is about.

Re:eyes wide stupid?

[Vintermann]

Remote rooting in one step makes worms much more likely, doesn't it? I suppose it's a bit hard to write a worm that gains local access first...

Does not compute.

[Raven42rac]

Let me get this straight, it has nothing to do with the bug from a year ago, except that it affects the same code in the same system call? Call me unenlightened, but, that sounds pretty similar to me.

Re:Here we go again

[lordsilence]

True. Which was corrected to me by someone anonymous whom I got into a flame with.. Silly, yes. Nevermind that.
Thanks for clearing things up for me.

Re:*squelch*

[fwarren]

Sorry,

A script kidddy would need to get local access to the box to be able to run code that could exploit this. Not a worry.

Now if this was a windows exploit, since your average user runs as administrator, then yes, script kiddies of the world would by rejoicing.

Re:if you patched two weeks ago, you can ignore th

[stock]

"If you patched two weeks ago?..."

So where _is_ that patch to fix these mremap bugs?

I wouldn't call a whole new kernel installation and kernel upgrade a PATCH.

Robert

Can't agree more

[Craig Ringer]

ISO dates are the way to go - for the sanity of everybody concerned. They sort lexically in a sensible way, they're in a reasonable order, and they're unambiguous (YYYY- not YY-).

This, of course, is why nobody uses them.

*sigh*

As the evil dictator-like sysadmin, at work all my in-house intranet tools report ISO dates. I had a few people confused at first, but now it's the accepted format at work for things like archive directories (hundreds of directories named NN-NN-NN, NN.NN.NN or NNNNNN can get rather confusing - YYYY-MM-DD is so much easier).

Now, if only the /rest/ of the world would change over.

While we're at it, can we have the ISO paper sizes adopted by the few holdouts, too? (I only wish...)

Re:Can't agree more

[Traa]

I predict the "Decamillenium bug"! Think of all those boxes that are still running 8000 years from now switching from 9999-12-31 to 10000-01-01, there goes the lexically sorted database.

(j/k)

Re:Can't agree more

[a_n_d_e_r_s]

Well, they are actually numbers so sort them as numbers, then everything are alright.

Re:Can't agree more

[addaon]

I'm sorry, but ISO dates still take more energy to parse. Why not just use 1 May 2004, or May 1 2004? Doesn't matter what you're used to, it's immediately comprehendable.

Re:Can't agree more

[C32]

No it's not!
A lot more people comprehend simple decimal numbers than your arbitrary latin-alphabet names for the months...

Re:Can't agree more

[addaon]

What language are the code comments in?

What language are the meetings conducted in?

Why not use that language for month names?

Re:Can't agree more

[PitaBred]

First off, fsck you for your blanket comment about Americans. It's not that we're all dumb, it's just that we can't keep the most ignorant amongst us off of the television and public message boards.
Secondly, I concur. Even as a native english speaker, I have to think a bit more when comparing Aug to Apr. They also don't lend themselves to being sorted by a computer very well, either.

Re:Can't agree more

[labratuk]

Other than the reasons pointed out by the other people already, it's because when you have a bunch of files for instance, using YYYYMMDD means that when sorted alphabetically, files appear in the right order.

Take 12th April, 17th December and 15th January for instance.

Written like that, first of all, being put first, the day is the most significant number, so the first thing the files will be sorted as will be the day, which ain't right.

Secondly, month names don't sort in the right order alphabetically either.

Using your naming scheme, those dates wouldn't get put in the right order at all.

Re:Can't agree more

[addaon]

That's like saying all numbers in file names should be zero-padded to eight digits, because otherwise foo2 and foo10 aren't sorted correctly... no, the solution is to use more intelligent sorting, not to prevent logical naming.

Re:Can't agree more

[wizardhat]

Actually, when files are sorted by name in Explorer on Windows XP, foo2 appears before foo10 (!)

Re:Can't agree more

[Zaiff Urgulbunger]

I predict the "Decamillenium bug"! Think of all those boxes that are still running 8000 years from now switching from 9999-12-31 to 10000-01-01, there goes the lexically sorted database.

You could be on to something there... patent the words "Decamillenium compliant" and I predict you'll be fabulously rich by your 8000th birthday!

Re:Can't agree more

[Zaiff Urgulbunger]

That's like saying all numbers in file names should be zero-padded to eight digits, because otherwise foo2 and foo10 aren't sorted correctly... no, the solution is to use more intelligent sorting, not to prevent logical naming.

I _think_ (as in I might be wrong!) that AmigaDOS could do this.

Re:Can't agree more

[Zaiff Urgulbunger]

It's not that we're all dumb, it's just that we can't keep the most ignorant amongst us off of the television and public message boards.

Very good comment - me likey very much!

Although I don't think you can really complain... afterall, your consistution does begin with the words "It's not that we're all dumb, it's just that we can't keep the most ignorant amongst us off of the television and public message boards."

;D

Re:Can't agree more

[mandrews]

1. Generally, the native langauge of the programmer.
2. Depends on the attendees.
3. It depends of the native language of the writer. Numbering systems are generally numbering neutral.

Re:Which kernels are effected

[Jeremy Erwin]

RTFA!

Version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2.


No, these kernels are affected. My guess is that kernels 2.2.26, 2.4.25. and 2.6.3 will be effected. The effect of a vulnerability is usually a bugfix release, as an unpatched kernel negatively affects security.

Re:2.6.3?

[Anonymous Coward]

Perhaps because someone actually bothered to check the return value of low-level kernel functions? This is vital to do throughout your source code, but many developers ignore return values to make their code easier to write and slightly smaller and faster to run. In the kernel, this can matter a *lot* because a little bit of extra return handling code passed around thousands of times a second in a low-level function can take a heck of a lot of extra CPU and RAM. So it can also be a performance trade-off by developers not realizing how easy it is to exceed that limit and require the return handling.

In theory, you can write functions to never require such return checking. In *practice*, though, it's hard to avoid this kind of buffer overflow. And make no mistake: exceeding the 65,535 16-bit limit hard-coded into various functions and source coded is not unusual and is a source of endless confusion.

Re:"Windows users: want Security, install linux"??

[LO0G]

Umm.

"On a Windows box, there would have been no peer review."

I doubt that even Microsoft lets security fixes be released without having other Microsoft programmers review all the relevant code. A more accurate comment might be:

"On a Windows box, there would have been no public peer review."

grsecurity

[mslinux]

Wouldn't grsecurity provide protection for this?

this vulnerability announcement is a month old

[Anonymous Coward]

this hole was found and patched by vendors a month ago. i personally submitted to slashdot at least 10 stories detailing this hole and how to patch it, and i was quite obviously ignored.

http://www.slackware.com/changelog/stable.php?cp u= i386
"
Wed Feb 18 03:44:42 PST 2004
patches/kernels/: Recompiled to fix another bounds-checking error in
the kernel mremap() code. (this is not the same issue that was fixed
on Jan 6) This bug could be used by a local attacker to gain root
privileges. Sites should upgrade to a new kernel. After installing
the new kernel, be sure to run 'lilo'.
For more details, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2004-0077
Thanks to Paul Starzetz for finding and researching this issue.
(* Security fix *)
"

2.4.25 and 2.6.3 are NOT affected by this hole, and there is a patch for 2.4.24 which you can make yourself by diffing a vanilla 2.4.24 kernel with slackware 9.1's 2.4.24 kernel source package.

CmdrTaco, before you post another "announcement" like this, do your homework. last thing we need is more security disinformation surrounding linux.

Re:Damn (all your base are belong to us)

[sjames]

No patched kernel yet available for my RedHat, SuSE or Gentoo distributions and I'm sure as hell not going to compile a vanilla kernel that would only mess up the package management system.

That's what source packages are for. For RPM systems, either add the patch to the spec file, or bump the version and get the new tar.bz2. Then rpmbuild -ba and be happy.

If that's too much pain (the .spec for kernel is a big hairball), build and install vanilla kernel from source and create an empty package for kernel-2.4.25 and install it to keep the version number in the database up to date.

Of course, many RedHat users just build the kernel and install from source, and don't worry about the kernel version in the rpm database. In most cases for the kernel, that's harmless.

Are we sure?

[tomstdenis]

I ran the test code in the advisory on a stock 2.4.25 build and it printed out NO and NO for both questions [vulnerable and exploitable].

Is this really a bug? [tinfoilhatmode] Is the advisory code correct? Or is this just so old that both 2.4 and 2.6 lines have it fixed already?

Tom

Re:Are we sure?

[tomstdenis]

Still doesn't answer the question "is this NEW?" I mean why is this being posted on slashdot? Obviously the kernel teams know about the flaw and have already fixed it.

Oh oh, I found a bug in Win 3.11... oh wait... that's an old release? Dang... Nobody will want to hear about that...

Tom

Re:Which kernels are effected

[Anonymous Coward]

*sigh* So many posts about which version is affected. Any kernels > 2.4.24 and > 2.6.2 will NOT be affected. This has been fixed for half a month at least and went into 2.4.25 and 2.6.3. If in doubt read the changelog, or heavan forbid the source.

Re:Which kernels are effected

[Rosco P. Coltrane]

Wonderful. scsi is broken on 2.6.3-gentoo-r1. My burner and USB disks don't work, and that's worse than a local root.

- ide-scsi is deprecated for CD burners
- USB now relies on hotplug/libusb/whatnot

Jesus man, why don't you read the fucking 2.6 migration FAQ before posting bollocks?

which are vulnerable

[CAIMLAS]

Ok, so I read the write up.

Here's the immediately pertinent part:

Proper exploitation of this vulnerability leads to local privilege escalation giving an attacker full super-user privileges. The vulnerability may also lead to a denial-of-service attack on the available system memory.

Tested and known to be vulnerable kernel versions are all

So it looks like we've all got to update to the latest of respective trees. I guess the days of running a kernel for months on end are pretty much over.

Re:Which kernels are effected

[Spolster]

Are you sure scsi is broken? I just upgraded to 2.6.3-gentoo-r1 at the same time as adding the scsi modules so that I can access my iRiver mp3 player as a USB hard disk and it works fine.

-AC kernels not affected.

[Anonymous Coward]

Just what the subject says.

Re:2.6.3?

[Anonymous Coward]

Because this story is really old, and the vulnerability was fixed when it was announced, and 2.6.3 was released.

Slashdot: when news breaks, you get the pieces.

Typical user experience.

[eean]

A typical user experience.
1) Buy computer with Windows XP Home Edition pre-installed.
2) They get a virus, perhaps even a trojan. Or maybe a worm, since the computer wasn't up-to-date. Or they were stupid and opened MyDoom. Regardless, it cripples the computer.
3) They buy or download an antivirus software. Perhaps their computer works well enough to install it, and reinstall Windows if it does not.
4)Ok, finally a working computer again. But since they browse the internet as administrator (as it works by default) they get spyware. Lot's of spyware. It builds up on each other and Internet Explorer has trouble starting. Pop-ups occur on every website, even Google or when IE isn't open. Perhaps their credit card info is stolen.
5) If their lucky, they would have heard of Ad-Aware or Spybot Search and Destroy and they somehow get it on their computer to install it (no IE remember?). It deals with most of the pop-ups. But nothing really works right. Reinstall Windows.
6) Go to step 2.

I work at the campus helpdesk, so I see students with these sorts of problems all the time. I have a problem respecting an OS that will get a worm before the user has a chance to do Windows Update, an occurance I've seen a few times.

Re:Typical user experience.

[hatmouse]

Maybe you could provide a CD with the updates. Have the students upgrade before they log on to the net. just a thought

Re:Typical user experience.

[Endive4Ever]

That isn't his job. His job is to sit on his hands and watch them struggle, then come here and slag Microsoft for fun.

Re:Typical user experience.

[iantri]

The OS should not have vulerabilities so bad that anyone can be infected by a virus in under 2 minutes (as I have had it happen to me, over a dialup connection).

Also.. Microsoft has made it incredibly difficult to get updates without using Windows Update.. they shut down their FTP server a while ago, so the only way to get individual updates is to search through the Knowledge Base, and it's a pain in the ass.

At least with Linux I can download ftp.mydistro.com/pub/mydistro/2.3/i386/updates/* and have all the updates ready to be installed..

Re:Typical user experience.

[eean]

Yes, we have distributed such CDs. Doesn't mean everyone uses them. We also have a McAfee license for every student. Next year we will probably be giving such a CD as part of the welcome-to-the-dorms pack of junk everyone gets.

Ad-Aware and I think Spybot Search and Destroy both are for non-commercial use only, which I think means can't give them out, though I'm not sure. Ad-Aware would cost like $15000 if we wanted to give it to every student (when they can just download it free). Though, as I said, I'm not sure on this.

Re:Typical user experience.

[Wolfrider]

--If I were you, I'd look into setting up a Linux-based Squid (or $other) proxy/cache server for your Internet connection. I've had no problems with viruses or the like, and also run Zonealarm on the Win boxen. (Altho it must be admitted I'm still running W98.) Squid works over dialup and broadband, BTW.

--My friend is also running a Squid server (I helped him set it up) and AFAIK he doesn't have problems with people trying to own his Win-XP boxes.

--If you're interested, you can email me and I'll send you a sample squid.conf file. Just put "Request for squid.conf" in the Subject line.

--There is a "Windows Corporate" update link for individual updates (at least for 98:)
http://www.microsoft.com/windows98/downloads /corpo rate.asp

--Also see (check bottom of page for link):
http://www.microsoft.com/windowsxp/home/do wnloads/ default.asp

Re:Typical user experience.

[iantri]

What exactly does a caching proxy sever have to do with viruses, pray tell?

Surely you mean a firewall?

Re:Typical user experience.

[Wolfrider]

--Nope. All my boxes use the proxy server for their Internet connection. Never had problems with Win-based attacks, even when I wasn't running *any* firewall (iptables.) My friend is running Squid and nothing else (no firewall at all) with most ports closed, and he has reported "no problems."

--If you're behind a proxy cache server like Squid, they can't see you. (At least, AFAIK. knockwood) Viruses are indeed a slightly different matter, but much less of a problem when you don't use IE or click on $random-attachment-that-you-weren't-expecting.

Re:Typical user experience.

[iantri]

I think I understand now.

Your machines have no directly addressable IP, and they are not behind a NAT.

The only method of communicating with the outside world is through the proxy.

Therefore, random apps (and viruses) can not communicate with the rest of the world.

Correct?

Re:Typical user experience.

[Wolfrider]

--You got it. :) In addition, I don't use DHCP - all my boxes have Class A fixed IP's (10.0.x.x); and with a couple of simple Iptables rules, no "spoofed" addresses can get in over the PPP link. Plus, no box is allowed to access anything on the network unless it's listed in my etc/hosts file. All this, along with Zonealarm, has kept things pretty stable so far.

--The downside is, I can't ping (or ssh to) anywhere in the outside world without logging in and doing so directly from the Internet-connected box; the upside is, in my experience the setup is pretty well secured against outside attacks. (And the only "internal" user is me. ;-) Wget, most browsers, apt-get, and gaim all work thru the proxy with the addition of a couple of environment vars and/or menu settings.

--I'm also not running any servers (except for the occasional BitTorrent, which has pretty much ceased after being forced to switch back to dialup) so the way I have things configged might not work for everyone; but then again, I haven't had any problems with being hax0red inside of 2 minutes, either. ;-) YMMV.

--I agree with you though; the OS itself should not be so blatantly vulnerable "out of the box."

DD-MMM-YYYY

[ChrisCampbell47]

ISO 8601 is OK, and it's great for sorting and automated systems, but for readability AND unamibiguity, I use MM-DDD-YYYY (e.g. 07-Mar-2004). I've been using this format since the day I started working for a company that did 99% of its business with non-US customers (nearly a decade ago). Some US folks may look at me funny when I do it that way, but nobody has EVER been confused about what date I meant ...

Re:DD-MMM-YYYY

[Helvick]

for readability AND unamibiguity, I use MM-DDD-YYYY (e.g. 07-Mar-2004). I've been using this format since the day I started working for a company that did 99% of its business with non-US customers (nearly a decade ago). Some US folks may look at me funny when I do it that way, but nobody has EVER been confused about what date I meant ....

Well you just confused me, MM-DDD-YYYY is not what you used - it's DD-MMM-YYY.

Re:Damn (all your base are belong to us)

[SiChemist]

There is a patched kernel at least for RedHat:

https://rhn.redhat.com/errata/RHSA-2004-065.html

Note in the third paragraph:

"Paul Starzetz discovered a flaw in return value checking in mremap() in the Linux kernel versions 2.4.24 and previous that may allow a local attacker to gain root privileges. No exploit is currently available; however this issue is exploitable. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0077 to this issue."

This is the same CVE as the article. The patch was issued 2004-02-18.

This issue was patched in Fedora on 19 Feb with 2.4.22-1.2174. See the Fedora announce list here:

http://www.redhat.com/archives/fedora-announce-lis t/2004-February/thread.html

Re:if you patched two weeks ago, you can ignore th

[MikeBabcock]

Its a source-level patch. See `man patch`. I understand the sarcasm inherent in your statement and yet I don't see peoples' problem with doing a quick recompile and reboot. Its really that simple.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Most exploits NOT remote

[bangular]

This is so stupid. They are not the same kind of holes. People who write things like this don't understand the severity of exploits. This is LOCAL, not remote. If fact, I am hard pressed to think of any remotely exploitable problems in the linux kernel in the last 3 years. A local root isn't a problem for 98% of linux systems. As long as any daemons listening for network connections are up to date, you really don't have anything to worry about. One could run 2.4.0 with no patches without worry as long as all network daemons are up to date.

In fact, I know of a red hat 6.2 box just running apache and ipchains on a 100mhz box that has been running for at least 4 years without a single security problem. It probably has at least 20 local roots, but it doesn't matter because apache has had a good security history.

The point is, we almost NEVER see the equivalent of local roots on windows boxen. Everything we see is remotely exploitable. It's rare that Linux sees anything remotly exploitable (in popular software...Joe's cgi script doesn't count). And when we do, the "fragmentation" of distributions that everyone bitches about helps immensly. Because most packages are compiled differently, the memory address to exploit are different. So it's difficult to exploit a box and usually you have to brute force it. As we see more things like non-executable stack patches and random memory patches these problems will be extremely difficult to exploit.

The proof is in the pudding... when's the last time we saw anything in linux so widely exploitable that 90% of affected machines are infected within 10 minutes of the release of a worm? We should have seen hundreds of apache worms by now since there are at least as many apache installations as IIS. MySQL? MySQL has gained huge popularity and is on almost as many boxen as SQL server. Why haven't we seen a single MySQL worm?

Re:Most exploits NOT remote

[Effugas]

MySQL doesn't listen on its network interface by default, that's why.

Supposed vulnerability

[sloanster]

Just to add my .02, I've tested this exploit code on a representative sample my boxes here, some running stock fedora kernels, some running 2.6 kernels, and NONE of the systems is exploitable, though the reports vary depending on kernel.

So, before the fud machine starts churning out all these opinions on how insecure linux is, let's check our facts OK?

neo: /home/jjs
(tty/dev/pts/1): bash: 1016 > ./a.out

[+] kernel 2.6.3-ck1 vulnerable: NO exploitable NO

gibson: /home/jjs
(tty/dev/pts/1): bash: 126 > ./a.out

[+] kernel 2.4.22-1.2174.nptlsmp vulnerable: YES exploitable YES

MMAP #65525 0x50bf5000 - 0x50bf6000
[-] Failed

Re:Supposed vulnerability

[lintux]

How did you compile the exploit? It didn't work on my machine either, initially, but when I compiled it correctly (-fomit-frame-pointer seems to be important), it did work.

Re:Supposed vulnerability

[sloanster]

OK, recompiled with -fomit-frame-pointer and the results are the same.

Also, I found that older suse kernels are exploitable, but the current one is not -

corplxwebdev01: /home/jjs
(tty/dev/pts/0): bash: 6 > ./a.out

[+] kernel 2.4.21-192-default vulnerable: YES exploitable YES

MMAP #65526 0x50bf6000 - 0x50bf7000
[-] Failed

Re:if you patched two weeks ago, you can ignore th

[stock]

"Its a source-level patch. See `man patch`. I understand the sarcasm inherent in your statement and yet I don't see peoples' problem with doing a quick recompile and reboot. Its really that simple. "

Oh yes i know how to use /usr/bin/patch . But where is the patch itself? like linux-2.4.24-mremap.patch ? for instance

cat linux-2.4.24-mremap.patch | patch -p0

would do the job. However _where_ is the linux-2.4.24-mremap.patch to be found?

Robert

Re:Damn (all your base are belong to us)

[inode_buddha]

Running 2.6.4-rc1 here... this is the vuln that motivated the move, besides wanting to get into 2.6 in general.

Re:Install windows! more like

[gnu-generation-one]

"Get a windows CD
Boot
Reboot
Install
Reboot
Install some more
Reboot
Continue installation
Reboot
Register windows installation
Change a setting
Reboot
bah"

You forgot the video drivers.

Security through obscurity?

[mangu]

this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

Well, I think this proves that the "security through obscurity" model is, at best, ineffective. If it has been so long there for anyone to see and the "good" guys didn't see it, what makes you believe that the "bad" guys would spot it?

I don't have hard data to prove this, but I believe that the following two points are true: (1) there are more good guys than bad guys, or otherwise society as we know it wouldn't exist; and (2) good guys are smarter than bad guys, because our current social organization tends to favor being honest. Good guys get good salaries, bad guys are sent to jail.

So, if it took many smart good guys five years to find this vulnerability, how many years it would take a few stupid bad guys to find it?

Re:Security through obscurity?

[jonadab]

> I don't have hard data to prove this, but I believe that the following
> two points are true: (1) there are more good guys than bad guys, or
> otherwise society as we know it wouldn't exist; and (2) good guys are
> smarter than bad guys, because our current social organization tends to
> favor being honest. Good guys get good salaries, bad guys are sent to jail.

You're heading in the right direction with this reasoning, but the details of
your conclusions are off. First, there aren't really more good guys than bad
guys. You'd reach that conclusion by assuming that anyone who's not a good
guy is a bad guy, but in fact most people don't give a rip about security one
way or the other. They have other things to think about.

Second, it's not _exactly_ true that good guys are smarter than bad guys.
What is true is that there are a lot of bad guys who don't have their stuff
together -- but there are a few who do, and they're very smart, much smarter
than the average good guy and probably smarter than most of the smart good
guys too. These are the real professional crackers. The teeming masses of
security bad guys however are just fooling around, which is why despite that
most of those who do concern themselves with security issues are bad guys,
it _seems_ like there are more good guys -- because the baddies who are just
fooling around don't get much accomplished. They waste most of their time
trying to impress other bad guys, keeping secrets from one another, and so
on and so forth. The good guys also can openly share information (patches
and whatnot) with anyone, and so even the ones who dabble can have access
to real information, so they have a tendency to be more effective than
similarly underdevoted bad guys.

> our current social organization tends to favor being honest. Good guys
> get good salaries, bad guys are sent to jail.

This is true, but it's also mostly irrelevant. Most bad guys don't choose
to be bad guys because it pays better. There are exceptions, of course, but
most have other motivations. Often it just boils down to depravity.

However, many or most bad guys don't have the strength of character to make
themselves do things when they don't feel like it today, and so consequently
they're not as dedicated and therefore not as effective as they would be.
Again, there are exceptions.

Re:Security through obscurity?

[Wolfrider]

> (1) there are more good guys than bad guys, or otherwise society as we know it wouldn't exist; and (2) good guys are smarter than bad guys, because our current social organization tends to favor being honest. Good guys get good salaries, bad guys are sent to jail.

--(1) is demonstrably false. If you think "people are basically good", you're not living in the Real World. "Good people" are the EXCEPTION. It's *very* nice when you find them and can interact with them, because it's such a welcome relief from the norm. I do try to be as good as possible to other people (Golden Rule) but even I know I'm *not* basically "good at heart." I have to continually fight the temptation to "take the easy way out" - because being scrupulously honest is HARD. Making a conscious effort to be "nice" to other people *all the time* is HARD.

--(2) is true for the most part (check current jail population) although I dunno if I would use the term "smarter." Except for the ones that haven't been caught (yet.)

You are not alone!

[kompiluj]

It did not work on any of my SuSE (same kernel as yours), Redhat and Gentoo systems. The only vulnerable ones were Debian boxen (sic!)
Strange... First this FreeBSD bug, now something wrong with Debian

Re:"Windows users: want Security, install linux"??

[Nicolas Pillot]

I fear the day i have to buy a AV-tool for Linux. My opinion is : if a user is too stupid and runs email-executables, at least the only thing he deserves is to have all his personnal files deleted. Users should always be sponsored.

Re:if you patched two weeks ago, you can ignore th

[Sam H]

However _where_ is the linux-2.4.24-mremap.patch to be found?

I extracted it from the 2.4.25 patch: mremap-patch.diff

Bittorrent Auto Update

[KrackHouse]

If they do create this wouldn't it make sense to use BitTorrent? The distro's server could push out a bit torrent link to the update app and you wouldn't even have to go to the command line to do it.

Re:Bittorrent Auto Update

[BiggerIsBetter]

Why yes. Yes it would. I'd wondered about that before... and came to the conclusion that it's brilliant where bandwidth is cheap. It's not cheap where I live. :-(

My god when will Microsoft learn?

[Pvt_Waldo]

When are they ever going to get their act together and stop releasing such a buggy OS with these security violations!

Oh.... wait....

Oh You Rotten Bastards, sniffle

[Sinical]

My gateway box:

[+] kernel 2.2.25 vulnerable: YES exploitable NO

cerberus:~$ uptime
11:32:26 up 353 days, 12:09, 1 user, load average: 0.02, 0.02, 0.00

cerberus:~$ uname -a
Linux cerberus 2.2.25 #3 Wed Mar 19 22:23:56 MST 2003 i586 unknown

Argh, now it'll be another 1.5 years before I can watch it roll over.

Double standard?

[steve_stern]

When a Linux bug is found, its a triumph of the open-source community. "Look, we had access to the source code, we found a bug, and we fixed it".

When Windows has a bug a comment saying "The bugs aren't in the software. THEY'RE IN THE CORPORATE CULTURE OF THIS PARTICULAR VENDOR" get modded to +5 Insightful.

Another +5 Insightful comment says "I still wouldn't say Microsoft is getting 'better' though. They'd be getting 'better' if the vulnerabilities didn't exist in the first place!"

I wonder what he has to say about this vulnerability existing in the first place.

This patch requires a reboot, right? Kinda funny that nobody complains about it, but in this article, someone says "Of course I like to reboot all the time. Otherwise I would be running Linux" in response to his newly-patched computer asking him if he'd like to reboot.

Re:Double standard?

[sloanster]

This patch requires a reboot, right?

Are you being deliberately naive - to load a fixed kernel, it is required to load the fixed kernel, you do understand that, correct? However, for anything other than loading a new kernel, linux does not need to be rebooted, and that includes system lib updates, distribution upgrades etc.

Proof-of-Concept Code

[0xB00F]

I tried the "Proof-of-Concept" code. Nice thing about it is that it tells you two things. 1) If your kernel is vulnerable 2) If your vulnerability is exploitable.

I have one kernel that is vulnerable but not exploitable according to the Proof-of-Concept code. Saves me some time to not patch, recompile and reboot a new kernel.

I wish future vulnerability announcements will be like this one. e.g. contain Proof-of-Concept exploit code that can tell me whether or not the kernel/software I am running is vulnerable and/or exploitable.

Re:Proof-of-Concept Code

[Monster Zero]

If you try to compile with GCC 2.96, you get the following error:

Error: unbalanced parenthesis in operand 1.

The solution (for me) was to compile it with GCC 3.3.2.

The output on my system (unfortunately for me) is:

$ ./mremap_pte /bin/ping /bin/bash

[+] kernel 2.4.20-28.7bigmem vulnerable: YES exploitable YES

MMAP #65530 0x50bfa000 - 0x50bfb000 [+] Success

Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]

[-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
[-M mtu discovery hint] [-S sndbuf]
[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination

Re:Proof-of-Concept Code

[brain1]

Tried it on 2.6.3. Good test code. I'm squeaky clean. That's the good thing about open source. Everythings in the clear, and we can fix it. We, as programmers, worry about the code being correct. We dont care about "corporate images". We just want the exploit plugged and the code to be as perfect as we can make it.

Re:Proof-of-Concept Code

[ThaReetLad]

the bad thing about open source is that every former windows user who has installed debian from a knoppix cd will never get a little pop-up to ask them if they want to download and run a patch to protect them.

Debian not affected?

[buddha42]

Can somebody explain to me why debian doesn't seem to be adressing this?

http://www.debian.org/security/

Re:Debian not affected?

[harlows_monkeys]

Can somebody explain to me why debian doesn't seem to be adressing this?

They addressed it on 18 Feb.

OT: Re:Date format

[MightyYar]

I agree that date formats are confusing, but I don't think that ISO format solves anything. I still don't know whether the user is aware of the standard. I usually use the DD-MMM-YYYY format because it removes all ambiguity: 05-JAN-2004.

Re:Energy to process

[addaon]

I meant by people. ISO dates are /easier/ to parse by a computer than what I proposed (which is, incidentally, what most international companies I've worked for use).

Re:Dead or not..

[LuckyStarr]

If you really consider this (thinking of FreeBSD), use the old branch (4.x). I managed to crash the kernel of 5.1 repeatedly by copying stuff via scp. :-( They apparently need to do some homework on the new branch. The old one is quite stable though.

Looks like we finally found...

[Biogenesis]

The code that SCO wrote.

Why use ISO

[Slowleggs]

Because Earth's ~250(?) languages uses different names for the 3rd month :) So programs/databases has to know ~250 x 12 x 2 words for month. (Two because you don't always say 'february' but 'feb'). Also what happens if language A uses a name for month X that is the same as language B's name for month Y?

Re:Why use ISO

[alienmole]

...because you don't always say 'february' but 'feb'). Also what happens if language A uses a name for month X that is the same as language B's name for month Y?

Who are you calling a february? That's a mortal insult in my language, you insensitive clod!

Public knowledge for over two weeks

[bigberk]

The advisory was released Feb. 18, so this has all been public knowledge for over two weeks. This USENET post shows the vulnerability and upcoming exploit was known about, and slashdot is just plain late on this one.

You have had two weeks to patch your systems. I know slackware's advisory was sent right after the vulnerability became public knowledge.

Re:"Windows users: want Security, install linux"??

[goranb]

I doubt that even Microsoft lets security fixes be released without having other Microsoft programmers review all the relevant code

Exactly... Otherwise you might have patches/updates that would break your system even worse, right?
Well, IIRC, that has happened in the past... ;)

judicial use of 'noexec'

[Anonymous Coward]

this is why anywhere unpriviledged users can write (/home, /var, /tmp, etc.) should be on a partition mounted 'noexec'. If a cracker can get local access, but not execute their own code, they are limited as to what they can do. This is also another good use of chroot, although the BSD 'jail' is a more robust solution.

Re:judicial use of 'noexec'

[mvdwege]

Nope. Sorry, won't work. As long as users have execute access to ld-linux.so.2 (which lives in /lib) or the equivalent on non-Linux boxes, they can run any ELF executable, noexec or not.

And AFAIK, ld-linux.so.2 has to be executable by all in order for the system to function normally, but I am not quite sure there.

Mart

Re:judicial use of 'noexec'

[mvdwege]

Scratch what I just said. It seems that this hole is closed. I get 'Operation not permitted' when I try to run an executable. It appears that noexec really means noexec.

Mart

Way Too Idealistic

[EventHorizon]

That's a very naive, idealistic argument. American business often maximizes shareholder value by being as dishonest as possible, short of clearly breaking commonly enforced laws. Under your argument, Darl McBride is a "good guy" because he's a) rich from the SCOX pump-n-dump and b) not in jail (yet).

Anyway, go read "The Art Of War" or watch "The Godfather". It is a serious error to assume your enemy is weak, and I would recommend against that philosophy when securing critical assets.

Enough already ... Obscurity has its place

[duck_prime]

this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

Well, I think this proves that the "security through obscurity" model is, at best, ineffective. If it has been so long there for anyone to see and the "good" guys didn't see it, what makes you believe that the "bad" guys would spot it?

Well jeez, this actually sounds like an argument *for* security through obscurity. If it took so long to find the bug even with open source access, imagine how long it would have taken to find the exploit in a closed-source product.

Don't forget ... security through obscurity (S.T.O) is not in itself a bad thing. If you don't know what you're looking for, you're unlikely to find it. The real problem with S.T.O. is that if you are relying solely on it, it is a 'brittle' defence: once an attacker is aware of the 'hidden secret' it's game over.

So ... do you use a password on your accounts? After all, that's security through obscurity, right?

Re:Enough already ... Obscurity has its place

[darkvizier]

"So ... do you use a password on your accounts? After all, that's security through obscurity, right?"

Whether or not you use a password has little to do with obscurity. The question is whether or not the algorithm used to make the key is publicly known.

I do agree with you that "STO" is not necessarilly bad. If a company is obtaining security through obscurity, then not only do you not have the key to the lock, you don't even know how the lock works.

The premise behind open source, as I understand it, is using algoriths that are very difficult to crack even when you know exactly how they work. With closed source, the danger is that the designers might choose to asume that their algorithm will remain secret, and base their security on that fact. If closed source developers assumed that their software would eventually be operating in a worst case scenario (open source), and used algorithms that maintained security even after the source was compromised, closed source would actually be considerably more secure. Deadlines, profit motives, and decreasing execution time give incentive to trim the edges though, so security is skimped in favor of other considerations, because they figure they can rely on obscurity to make up for good code.

That is where the problem lies. Not in the fact that they don't show us the code, but that the code wasn't good to begin with. Truth is, the perfect coder WOULD be better off developing closed source. I wouldn't waste your time searching for a perfect coder though... God's the only one that might fit the ticket, and my guess is he's not employed by Microsoft.

Re:Enough already ... Obscurity has its place

[jmodule]

So ... do you use a password on your accounts? After all, that's security through obscurity, right?

Absolutley not! A password is merely a secret value that's a part of a known security process, there's nothing obsecure about it at all.

When talking about security, obsecurity means you don't let others know how your security process works, otherwise they'd be able to figure out how to easily crack it. Good security means your process can't be easily cracked even if the process is known.

Re:if you patched two weeks ago, you can ignore th

[redmoss]

Heh... OK, call it a kernel update or upgrade then. Since I used precompiled kernel packages that came with my Linux distribution, I honestly didn't do any traditional patching nor kernel recompiling. It was all apt-get update, apt-get upgrade, etc; pretty simple actually. The reboot was of course still disruptive though.

cannot disable sys_mremap

[EventHorizon]

One technical point: you cannot just "disable" mremap() without breaking the dynamic link loader and many userspace applications. There was, however, an unofficial kernel module that you could load into a vulnerable kernel to replace sys_mremap with a non-exploitable version (which in theory is racey, but it basically works and postpones the reboot).

Re:cannot disable sys_mremap

[KingOfBLASH]

I was talking in general about vulnerabilities, which is why I said later in the post: "something Windoze won't let you do -- although the nature of the vulnerability in the kernel may make disabling it impractical. But still, at least you have the option". I apologize for not making that clearer.

However, the point still stands that if something is broken under linux I can (many times) disable it until it can be fixed. Under Windows, this is almost never possible (just look at the port 135 hole that worms have been exploiting for years. Why can't people turn off whatever service the viruses are breaking into?)

Re:cannot disable sys_mremap

[EventHorizon]

I love Linux so I want to agree, but consider this:

1. You can't really turn off Linux mremap()
2. sshd is critical on remote Linux machines. You can't just turn it off if it's vulnerable.
3. Repeat #2 for Apache, BIND, sendmail, etc.

4. The RPC TCP ports etc are _not_ required on a large portion of Windows desktop machines.
5. Microsoft is (finally) putting a firewall in XP SP2 that could (potentially) mask much of this attack surface.

I do agree that open source is more flexible in terms of security. However not all of the flexibility translates into practical advantage. I think it's more feasible to close TCP ports on your average Windows client machine than on a Linux server.

The really big win with open source is that you could, if your data is worth it, hire someone to audit the code prior to rolling it out. With Windows you are playing russian roulette with a mostly loaded gun.

Re:cannot disable sys_mremap

[KingOfBLASH]

1. You can't really turn off Linux mremap()
2. sshd is critical on remote Linux machines. You can't just turn it off if it's vulnerable.
3. Repeat #2 for Apache, BIND, sendmail, etc.

Although I agree with statement 1, and have discussed it in the parent, I don't agree with your second and third statements. First of all, sshd is required to access remote machines -- but that doesn't mean you should allow the world access to it. You should properly configure your hosts.allow and hosts.deny files in /etc so that only domains people who need to access SSH from actually can. That, and firewalling off SSH (or disabling them) for access from the net if your boxen are on your local network means that even when an exploit is found it is not always trivial to exploit it.

The same goes for BIND, and Sendmail. You shouldn't be running open mail relays anyways, so those programs shouldn't be accessible across the net -- thus making your box much harder to break into.

4. The RPC TCP ports etc are _not_ required on a large portion of Windows desktop machines. 5. Microsoft is (finally) putting a firewall in XP SP2 that could (potentially) mask much of this attack surface.

I hope microsoft finally starts closing off these holes. However, I question Microsoft's competence as far as security goes. It takes an awful long times to fix holes and exploits. However, Microsoft will always have a fixed number of people working for them -- some of them quite competent. Personally speaking, the more I get into Linux the more personal coding I do, and the more I contribute to OpenSource projects. I think this is why Open Source is going to be the last nail in Microsoft's coffin.

Re:*squelch*

[Alioth]

A script kidddy would need to get local access to the box to be able to run code that could exploit this. Not a worry.

Let me disabuse you of this 'Not a worry' right away before you become an admin on real systems.

Treat all local root exploits as if they are remote root exploits. Why?

Can you guarantee someone on your server isn't running a web (PHP or CGI) script that has a local, unprivileged user exploit which can then be used to exploit the local root exploit?

Can you guarantee all your users have good passwords?

Can you guarantee your users aren't actually script kiddies?

I almost got my machine rooted using a local root exploit last year when the script kiddie exploited an insecure PHP script to install the root exploit. It was just fortunate I had set up a workaround to prevent the root exploit from working.

The Doom of Linux!

[I-R-Baboon]

Version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2

And me having kept up to date running a 2.6.3 kernel.

The horrors!

2.6.3 Unaffected:

[$alex_n42]

alex_n@styx alex_n $ ./mremap_pte
[+] kernel 2.6.3 vulnerable: NO exploitable NO

Re:2.6.3 Unaffected:

[ultranova]

Vulnerable:YES exploitable:no

What does this mean ? How can a machine be vulnerable but not exploitable ?

uptime

[Andrewkov]

Great, there goes my uptime record..

Re:Energy to process

[Zaiff Urgulbunger]

More specifically, I think you're refering to "American people". No where else in the world (to my knowledge) uses for format "mmm dd, yyyy". I know thats the way Americans read dates, but you don't have to write them exactly as you read them! The same way you don't read "11" as "one-one" or "onety-one"!!

Not really

[eean]

No, they come in and we fix the problem most of the time. Usually an anti-virus and a spyware/ad-aware scan fixes it. Sometimes it doesn't. And if it does, the machines aren't always working like their supposed to, but they do work. We don't provide full support to students computers, we refer them downtown if they need something drastic like an OS reinstall.

Then I can here and 'slag Microsoft' (slag: the "the scum formed by oxidation at the surface of molten metals") out of frustration. And for some fun.

Oh, yes, send me a binary...

[hummassa]

Please. So, to run it I have to chmod +x it; ooh, but /home is mounted noexec, so I log as root, cp it to ... hmm ... /usr/local/bin ... nope, no /usr/local ... ok, /usr/bin it is ..., oops, it's mounted read-only, I'll have to mount -o rw,remount /usr then I'll chmod +x it, aaah ... now I go back to my regular account and execute it.
How this compares to send me a fscking html-with-vbscript that will be executed while in the preview pane of Outlook Express and downloads another executable that has the power to install itself as a device driver and run in kernel mode?????
Even if I have to click on the attachment, it will execute right away!!!!

Re:Oh, yes, send me a binary...

[Foolhardy]

How this compares to send me a fscking html-with-vbscript that will be executed while in the preview pane of Outlook Express and downloads another executable that has the power to install itself as a device driver and run in kernel mode?????

This is a problem with OE, not Windows, and it has been fixed for a long time. Programs can only install device drivers when priveleged. Do you run your mail client as root? Normal users can't install drivers. Also, Outlook and other Internet Explorer based programs put downloaded files, like attachments, into the current user's profile under "Temporary Internet Files". You could always deny everyone execute access in that directory to get the same effect as noexec.
You can also deny users from writing and creating files by the use of ACLs for an effect like mounting read-only. If anything, the security model of WinNT is more flexible than a standard Linux system.

Re:Oh, yes, send me a binary...

[Com2Kid]

• This is a problem with OE, not Windows

OE is shipped with the Windows OS standard, albiet it is a fair bit easier to remove than many people would lead others to believe (MS has removal instructions up on their site IIRC), but it would be nice if setup-time installation options existed.

• Programs can only install device drivers when priveleged.

Permissions are a funky thing, various dongles may or may not require device driver permissions for use, then again on the flip side I have seen systems locked down so tight I couldn't use a USB drive on them.

• so, Outlook and other Internet Explorer based programs put downloaded files, like attachments, into the current user's profile under "Temporary Internet Files".

Lovely security violation, I love that, even if you are not allowed to save files, simply click link, select open, wait until Windows pops up an error stating you don't have permissions to open that file, leave the error there, drop to DOS, get the file. :)

• You could always deny everyone execute access in that directory to get the same effect as noexec.

And likely break so much stuff it isn't even funny. Do .fla files require exec privs or not?

• You can also deny users from writing and creating files

Oh yes, but the system maintains these properties. Try to download files from some site, system will write a temporary copy to the temporary internet files directory, from there, see above, heh. I have setup entire directory trees in temp directories because often those temp directories have all read/write privileges enables.

Security restrictions just mean finding another path to the same destination. :)

Well except for installing the Java1.4x VM, 1.3x installs very well with restricted permissions, but 1.4x for some inane reason wants a higher level of access, *sigh*.

I hate being stuck on machines with 1.3x. Who the heck sets up a computer lab, used by Java students, with 1.3x? Who ever they are I hope they aren't surprised when they find their systems mangled beyond belief! Yeesh, fools.

Re:Which kernels are effected

[anthonyrcalgary]

I'm not migrating to 2.6 from 2.4. I'm having problems with stuff that *works* in 2.6.2. If the security problem is fixed in a version of the kernel where basic functionality doesn't work, I'm not going to upgrade.

Re:NOT Funny

[mcx101]

You're right. I wasn't joking; I was serious. I have no idea why I was modded funny. It's very inconvenient to schedule a reboot on a server (and making sure someone is in the server room in case it all goes horribly wrong).

Re:Which kernels are effected

[anthonyrcalgary]

see the thread on the gentoo forums.

Re:If i recall that scene correctly...

[Prince Vegeta SSJ4]

no, Bill is the emperor.

Or code-monkey see what other code monkey intended

[Luban Doyle]

It might just as well be that the mistake made by the originator of the bug or insecurity was hard to spot because it made sense, at least on the surface, to those trying to follow the program logic to analyze it for problems. It certainly wasn't likely to be a syntax error or the compiler would have caught it, so it seems [to me] like it must be a procedural mistake in the program logic or a storage/retrieval error.

I haven't taken time to look at the fix and the original code to see what is broken and how to write it one-notch-better-for-now. Do you have a pointer to the patch or is it still too early to find it?

Using windows more like...

[ulrikp]

Your mouse has moved.
Windows has to be rebooted for this change to take effect.
[Reboot now] [Reboot later]
:-)

Re:Energy to process

[raidient]

>The same way you don't read "11" as "one-one" or "onety-one"!!

Oh, read THAT article... [pardon my duh]!

[Luban Doyle]

OK, I went back to the article and found the ---->code listing-----!!

I STILL haven't looked at it long enough to decipher what the error is. It says somethng about elevating privilege level by writing over an unprotected virtual memory area in a certain way. I promise not to post again on this topic until after I have tried to reason through the fixed code.

And prob'ly not after that either! Doh!

Please Mod Parent Up

[0xB00F]

Thank you.

mremap() bug is one big dirty giant hole

[stock]

Hmm i'd say that mremap() bug is one big dirty giant hole, which has been lurking for ages. The fact that the kernel maintainers don't have a simple fix in the form of a small patch is striking.

In fact : the complete vmmem remap MM stuff has been rewritten going from 2.4.24 to 2.4.25. The only sane thing to do, is to install 2.4.25 from scratch. That polish kernel hacker certainly lifted some heavy rock, and now all the dirty stuff is flying in your face. The exploit he posted sofar gives me root-shell on ALL my Linux machines.

Robert

Re:mremap() bug is one big dirty giant hole

[sloanster]

The fact that the kernel maintainers don't have a simple fix in the form of a small patch is striking.
Not sure what you mean - you could no doubt extract just the fix for that issue, but why? Just install an updated kernel package from your vendor.

The exploit he posted sofar gives me root-shell on ALL my Linux machines.
sounds like we're not using the vendor-supplied update mechanism, huh? you should look into that, things really do go better if you let the system work, and keep your systems up to date.

Code audit time?

[Platinum Dragon]

Since security is something programmers always need to be concerned about, maybe it's time a few kernel hackers devoted a few months to thorough vulnerability audits of at least the 2.4 and 2.6 kernels? I get the feeling everyone's been so busy adding hardware support, features, and backporting stuff to earlier stable kernels that security may have fallen to the wayside. The particular way that the kernel is developed doesn't seem to lend itself to a freeze and audit, but maybe this is something a few of the kernel gods could undertake before 2.7 is branched.

If nothing else, it would demonstrate that the Linux folk are as serious about clean, secure code as the BSD teams, and heck, it's an intrinsically Good Thing to do from time to time.

New exploit for an already fixed issue.

[Anonymous Coward]

It should be noted that this is simply a new way of exploiting the same mremap bug that had been reported before. It was fixed with the 2.4.25 kernel patch.

That works

[Craig Ringer]

That's an acceptable (and reasonable) solution when writing on the 'net, or developing user interfaces, and one I tend to forget about because of the common prevalence these days of 'shorthand' dates as the standard.

It doesn't solve the lexical sorting issue, though - you still need ISO dates for that purpose.

Same as monkey problem

[TheLink]

The people who believe the fallacy that many eyes make bugs shallow are ignorant or stupid.

Coz if it actually is true you might as well throw monkeys at the problem, and add some beetles and spiders too while you're at it.

It's skill in that particular issue/area that counts.

Many user eyes can spot common user GUI problems, coz they're users and the problems are user level problems.

But they are unlikely to identify an SQL injection issue etc. They may notice something different happening but not go much further.

Imagine getting thousands of Slashdotters to check your spelling and grammar for "free" instead of a single trained editor. Wonder why that hasn't turned up in an Ask Slashdot yet ;).

Tried running the exploit in 2.6.1

[sharath_48105]

Here's the output I get: [+] kernel 2.6.1 vulnerable: YES exploitable YES MMAP #65530 0x50bfa000 - 0x50bfb000 [+] Success Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline] [-p pattern] [-s packetsize] [-t ttl] [-I interface or address] [-M mtu discovery hint] [-S sndbuf] [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination But no root shell... :( How can this lead to an exploit? Must have been fixed before.

change of language ?

[rkoot]

Wouldn't it be a good idea to rewrite the kernel in a different language, say, Ada95?
I believe that these exploits couldn't be in the kernel *if* it was written in Ada95.

r.

Re:change of language ?

[rkoot]

for those that like to mod "funny", a link that might clear up some minds.

http://www.cl.cam.ac.uk/~mgk25/ada.html

r.

Man, listen to yourself talking...

[hummassa]

1: This is a problem with OE, not Windows,: OE comes standard with windows; most people use it because Outlook proper is much heavier;
2: and it has been fixed for a long time.: No, it does not fixes itself. The user has to fix it, or the sysadmin if inside some enterprise. You install any Win2k from the CD, and you have a buggy mail client by default;
3: Programs can only install device drivers when priveleged. Do you run your mail client as root? Normal users can't install drivers.: Yes, I and all other Win95/98/ME using people around the world run our email clients as root/Administrator. Or do you think every small firm/govment agency out there has the resources to migrate from 9x to NT? [Disclaimer: hummassa works at a State Representative House in Brasil] Worse, as using a lot of commercial software require dongles and stuff, many of us running NT/2k/XP run all stuff as Administrator or PowerUser, too;
4: Also, Outlook and other Internet Explorer based programs put downloaded files, like attachments, into the current user's profile under "Temporary Internet Files". You could always deny everyone execute access in that directory to get the same effect as noexec.: Why isn't it by default?
5: You can also deny users from writing and creating files by the use of ACLs for an effect like mounting read-only. If anything, the security model of WinNT is more flexible than a standard Linux system.: Please, don't ACL vs. rwxrwxrwx me. [Disclaimer: hummassa is a seasoned sysadmin] With a well-tought structure of groups; rwx does exactly the same thing as ACLs, but keeps stuff more organized.

Re:Man, listen to yourself talking...

[Foolhardy]

1. Yes. I am trying to say that a poor design decision in Outlook or Outlook Express does not mean a basic design flaw in Windows (as the parent imples).
2. Win2k gold is 3 years old now; there little excuse to not download the patch for OE by now... It's not on AutoUpdate?
3. Windows 9x isn't secure. If cost is the issue, I don't know what to say. Mabye you can find some NT 3.51 licences cheap somewhere, since it is EOL. Even NT 3.51 is much more secure than 9x.
As for applications that require more privileges than they should (like installing drivers), Windows is plagued with those programs, and I personally blame the developers of the applications. As a workaround, you could just run only those programs as admin with a runas script or something. Or run as admin by default and risky programs (like OE and IE) as a lesser user. (if you trust your users)
4. It should be default. I think Microsoft has some crappy defaults too. Still, it is easy enough to implement yourself (in this case).
5. You are right, those can be just as good. The parent implied that Windows(NT) couldn't be secure because you can't mount readonly or noexec. I wanted to show that you can use ACLs to create the same effect. (Personally, I perfer ACLs because of the extra granularity, esp for special cases.)

FTP, POP3, etc

[phorm]

FTP, POP3, and many other protocols tend to use unencrypted passwords. If any of those work as a local user... it's not too hard to sniff one. After that, you're just an upgrade to root away from the gold (one of the reasons I'm plying SCP/SFTP and secure-POP3 here)