http://isec.pl/vulnerabilities04.html

"Impact:
=======

Since no special privileges are required to use the mremap(2) system
call any process may misuse its unexpected behavior to disrupt the kernel
memory management subsystem. Proper exploitation of this vulnerability may
lead to local privilege escalation including execution of arbitrary code
with kernel level access. Proof-of-concept exploit code has been created
and successfully tested giving UID 0 shell on vulnerable systems.

The exploitability of the discovered vulnerability is possible, although
not a trivial one. We have identified at least two different attack
vectors for the 2.4 kernel series. All users are encouraged to patch all
vulnerable systems as soon as appropriate vendor patches are released."

Updated kernels appear to already be at http://www.kernel.org/

Good way to start out the day :)

-David

I'm probably blind as a bat but where do you see the remote root capability mentioned?

From the article I get the impression that you need to be able to execute code or find a security hole in another application that let you execute code in order to leverage this.

Any running process can exploit this hole. If someone uploads something and runs it, they have root access. If this is via uploading files to tmp via a php exploit, or someone signing up legitimately and uploading a binary - doesn't matter, as they could get a root shell.

New kernel changelog:
http://kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.24

-David

The patched versions are running well - fwiw there has also been an exploit for this code released earlier today. At this point, it's only a matter of time before it gets rolled up into a rootkit, since the vulnerability goes back to the 2.2 kernels.

This has been posted to /. as well:
http://slashdot.org/article.pl?sid=04/01/05/176252&mode=flat&tid=106&tid=126&tid=172&tid=185

This'll also be a good test for those who have recently-EOL'd redhat machines...

-David

Originally posted by thedavid


This'll also be a good test for those who have recently-EOL'd redhat machines...

-David

Redhat still released a fix.

Originally posted by idologic_dh
Redhat still released a fix.

Indeed. Just noticed this myself - good on them for supporting this update. For those who want a linky:
https://rhn.redhat.com/errata/RHSA-2003-417.html

-David

Originally posted by thedavid
Any running process can exploit this hole.

Exactly. That makes it a local root hole.

Originally posted by cperciva
Exactly. That makes it a local root hole.

Including daemons :) That's a razor-thin line :laugh:

BTW - the depenguinator was mentioned in that /. posting - thought you'd be interested.

-David

Hi. The date on the new kernel (uname -a) from redhat shows Dec 18 - did they fix the vuln. on dec 18th and only tell us about it today?

Originally posted by MaB
Hi. The date on the new kernel (uname -a) from redhat shows Dec 18 - did they fix the vuln. on dec 18th and only tell us about it today?

Seems like it...

--------------------------
We have provided kernel updates for Red Hat Linux 7.1-8.0 with this
advisory as these were prepared by us prior to December 31 2003. Please
note that Red Hat Linux 7.1, 7.2, 7.3, and 8.0 have reached their end of
life for errata support and no further errata will be issued for those
distributions.
-----------------------------

is what bugzilla@redhat.com sent along with links to updated packages.

Does anyone else find it disturbing that the linux kernel maintainer (and RedHat, and presumably other distributors) apparently knew about this exploitable root hole for almost three weeks before announcing it and releasing a patch?

that worrys me cperciva.


btw someone could easily hack ur machine using system() in php with this hole once they get a hold of the exploit

not my server :)

Originally posted by cperciva
Does anyone else find it disturbing that the linux kernel maintainer (and RedHat, and presumably other distributors) apparently knew about this exploitable root hole for almost three weeks before announcing it and releasing a patch?

Yes... And this goes back to the 2.2 versions of the kernel at least - so that means that it'd be *fantastic* to base a rootkit off of. That's a seriously large version range, and the exploit is now public, as well.

Just finished patching up 6 machines, so that's settled, till the next root hole at least.

-David

^^ Why is it disturbing? It's the standard form of fixing a problem, the full disclosure mentality:


Someone discovers exploit / flaw in program
Contacts manufacturer / maintainer and gives them 2 weeks - 2 months to respond or fix the issue or it's made public
Manufacturer / maintainer responds, states problem will be fixed by x
Manufacturer releases advisory and fix simultaneously.

Originally posted by thedavid
Yes... And this goes back to the 2.2 versions of the kernel at least - so that means that it'd be *fantastic* to base a rootkit off of. That's a seriously large version range, and the exploit is now public, as well.

Just finished patching up 6 machines, so that's settled, till the next root hole at least.

-David

lately its seemed like every 30-40 days a newone is released :S the only time i restart my servers is kernels

Originally posted by thelinuxguy
lately its seemed like every 30-40 days a newone is released :S the only time i restart my servers is kernels

I noticed that as well... It's always sad seeing those "uptime" days go away...

/sheds a single tear

-David

thedavid, thanks. Just upgraded the kernel on all servers. uuuhhh. :cool:

Originally posted by cperciva
Does anyone else find it disturbing that the linux kernel maintainer (and RedHat, and presumably other distributors) apparently knew about this exploitable root hole for almost three weeks before announcing it and releasing a patch?

This is a surprise to you? any responsible individual reporting security vulnerabilities will wait for a vendor supplied patch to release their advisories. Most of the time if it is vuln that could have potentially horrific consequences for the user base they coordinate with the vendors in such a way the advisories and meaty technical detail about the issue are released hours or up to a couple of days after the official patches are release, this at least buys responsible admins/users a slight head start to get the systems up to date.

Originally posted by thedavid
Including daemons :) That's a razor-thin line :laugh:


I think there's a pretty big fat line between users you gave access to your machine, and non-users.

Cperciva, what scares me is that they take their time patching and releasing the fixes and wait until an exploit is available in the wild before they realize they better hurriedly rush the fixes out the door.

I think its best for them to take their time and ensure the patch is safe and works correctly than rush it out the door.

Originally posted by thelinuxguy
lately its seemed like every 30-40 days a newone is released :S the only time i restart my servers is kernels

Same here :bawling:

Just tried this exploit code on one of the test machines that was mailed around in one of the security mailists, which is a 'proof-of-concept' code for this mremap() issue. Worked like a charm. The server was rebooted immediately. So, guys, patch your kernels asap and giving SSH access to users has never been a good idea. Scary... :(((

Yeah, same here phpdeveloper worked perfect on 2.4 and 2.6 kernels. not long before the root exploit will be out on every site imaginable

our initial posting contains a mistake about the vulnerability of the 2.2
kernel series. Since the 2.2 kernel series doesn't support the
MREMAP_FIXED flag it is NOT vulnerable. The source states
"MREMAP_FIXED option added 5-Dec-1999" but it didn't make into recent
2.2.x. We apologize for inconvenience.

[Complete information about this errata can be found at the following location:
https://rhn.redhat.com/network/errata/errata_details.pxt?eid=1932

Security Advisory - RHSA-2003:417-08
------------------------------------------------------------------------------
Summary:
Updated kernel resolves security vulnerability

Updated kernel packages are now available that fix a security
vulnerability which may allow local users to gain root privileges.

Description:
The Linux kernel handles the basic functions of the operating system.

Paul Starzetz discovered a flaw in bounds checking in mremap() in the Linux
kernel versions 2.4.23 and previous which may allow a local attacker to
gain root privileges. No exploit is currently available; however, it is
believed that this issue is exploitable (although not trivially.) The
Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2003-0985 to this issue.

All users are advised to upgrade to these errata packages, which contain a
backported security patch that corrects this issue.

Red Hat would like to thank Paul Starzetz from ISEC for disclosing this
issue as well as Andrea Arcangeli and Solar Designer for working on the patch.

These packages also contain a fix for a minor information leak in the real
time clock (rtc) routines. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2003-0984 to this issue.

We have provided kernel updates for Red Hat Linux 7.1-8.0 with this
advisory as these were prepared by us prior to December 31 2003. Please
note that Red Hat Linux 7.1, 7.2, 7.3, and 8.0 have reached their end of
life for errata support and no further errata will be issued for those
distributions.

References:
http://www.securityfocus.com/bid/9154/discussion/
------------------------------------------------------------------------------

This issue has already been posted in this forum, look in the below threads.

its good to look before posting sometimes :)

New version repaires the hole in mremap(2) system call, no other new features adds on.

Think ur a bit late unless this is another update:

http://www.webhostingtalk.com/showthread.php?s=&threadid=222895

Hmmm..., Haven't had the chance to read others' posts. :D

time to clean up some of the kernel update threads :)

Originally posted by cperciva
Does anyone else find it disturbing that the linux kernel maintainer (and RedHat, and presumably other distributors) apparently knew about this exploitable root hole for almost three weeks before announcing it and releasing a patch?

This is not really disturbing; as good security practice would imply the security consultant/consultancy company that discovered the exploit notified all applicable vendors ahead of time before making the exploit public. And when it was finally released; it was released in conjunction with applicable patches thus allowing people to immunize themselves from it.

That I call coordination and professionalism.