I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
No you're not... and we are a lot in this very embarrassing situation...
You can compile (you need kernel-pae-devel's rpm) and insmod this kernel module while waiting for redhat to push out a new kernel and then that centos reroll it. http://home.powertech.no/oystein/ptpatch2008/
kfx
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, Feb 11, 2008 at 11:58 AM, kfx kadafax@gmail.com wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
No you're not... and we are a lot in this very embarrassing situation...
You can compile (you need kernel-pae-devel's rpm) and insmod this kernel module while waiting for redhat to push out a new kernel and then that centos reroll it. http://home.powertech.no/oystein/ptpatch2008/
I still see no kernel updates for Centos and I got two Fedora 8 kernel updates since this exploit happened.
Is my yum broken?
I tried yum clean all yum update
and still nothing :(
Valent Turkovic wrote:
On Mon, Feb 11, 2008 at 11:58 AM, kfx kadafax@gmail.com wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
No you're not... and we are a lot in this very embarrassing situation...
You can compile (you need kernel-pae-devel's rpm) and insmod this kernel module while waiting for redhat to push out a new kernel and then that centos reroll it. http://home.powertech.no/oystein/ptpatch2008/
I still see no kernel updates for Centos and I got two Fedora 8 kernel updates since this exploit happened.
Is my yum broken?
I tried yum clean all yum update
and still nothing :(
kernel-2.6.18-53.1.13.el5
is the bug fix kernel. If you aren't seeing it - I think your yum config file is likely set up incorrectly.
Where is it pointing for updates?
On Fri, Feb 15, 2008 at 7:48 PM, Michael A. Peters mpeters@mac.com wrote:
Valent Turkovic wrote:
On Mon, Feb 11, 2008 at 11:58 AM, kfx kadafax@gmail.com wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
No you're not... and we are a lot in this very embarrassing situation...
You can compile (you need kernel-pae-devel's rpm) and insmod this kernel module while waiting for redhat to push out a new kernel and then that centos reroll it. http://home.powertech.no/oystein/ptpatch2008/
I still see no kernel updates for Centos and I got two Fedora 8 kernel updates since this exploit happened.
Is my yum broken?
I tried yum clean all yum update
and still nothing :(
kernel-2.6.18-53.1.13.el5
is the bug fix kernel. If you aren't seeing it - I think your yum config file is likely set up incorrectly.
Where is it pointing for updates?
#released updates [updates] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 enabled=1
Valent Turkovic wrote:
Where is it pointing for updates?
#released updates [updates] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5 priority=1 enabled=1
Try commenting out the mirrorlist and uncommenting the baseurl Then run yum clean headers yum update kernel
That should bring it in - I know the baseurl listed there has it. I noticed the priority line - is it possible you have a different repo set with a higher priority causing an issue?
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
No, you are not safe - and you should have rebooted after the last kernel update (2.6.18-53.1.5.el5 is current). But that kernel isn't safe either.
See https://bugzilla.redhat.com/show_bug.cgi?id=432251 for a temporary workaround.
Cheers,
Ralph
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
Define safe :)
The RHEL-5 (and therefore the centos-5) kernels ARE susceptible to this issue, so no you are NOT safe.
Here is the upstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=432251
However, this issue is actively being worked by the upstream provider and a fix will be released VERY soon.
This issue is not remotely exploitable and initially requires local user access to gain root.
Here is more info on this issue as well:
https://www.redhat.com/archives/fedora-list/2008-February/msg01215.html
Thanks, Johnny Hughes
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
The current kernel is 53.1.6.el5
If yum isn't seeing it - it probably needs to clean its cached headers.
try:
yum clean headers yum update kernel
However - the 53.1.6.el5 release also is vulnerable, so you may as well wait for the exploit to be fixed before updating. I'm guessing CentOS will do it fairly quickly after rhel does.
On Mon, 2008-02-11 at 04:52 -0800, Michael A. Peters wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
The current kernel is 53.1.6.el5
If yum isn't seeing it - it probably needs to clean its cached headers.
try:
yum clean headers yum update kernel
However - the 53.1.6.el5 release also is vulnerable, so you may as well wait for the exploit to be fixed before updating. I'm guessing CentOS will do it fairly quickly after rhel does.
I understand that a known root exploit must be patched but I'm curious to know if we upgrade to the fixed kernel once released will it also include the degraded nfs performance discussed here:
On Feb 11, 2008 8:19 AM, Scott McClanahan scott.mcclanahan@trnswrks.com wrote:
On Mon, 2008-02-11 at 04:52 -0800, Michael A. Peters wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
The current kernel is 53.1.6.el5
If yum isn't seeing it - it probably needs to clean its cached headers.
try:
yum clean headers yum update kernel
However - the 53.1.6.el5 release also is vulnerable, so you may as well wait for the exploit to be fixed before updating. I'm guessing CentOS will do it fairly quickly after rhel does.
I understand that a known root exploit must be patched but I'm curious to know if we upgrade to the fixed kernel once released will it also include the degraded nfs performance discussed here:
We have to wait and see, but my impression is that the nfs fix would not be in the updated kernel (I hope I am wrong). They are talking about getting it into 5.2 (even possibly into 5.3). I can see that this is a problem. Now, we can not "stay with 53.1.4" on the systems where the local root exploit is a serious problem.
Akemi
Akemi
On Mon, 2008-02-11 at 10:45 -0800, Akemi Yagi wrote:
On Feb 11, 2008 8:19 AM, Scott McClanahan scott.mcclanahan@trnswrks.com wrote:
On Mon, 2008-02-11 at 04:52 -0800, Michael A. Peters wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
The current kernel is 53.1.6.el5
If yum isn't seeing it - it probably needs to clean its cached headers.
try:
yum clean headers yum update kernel
However - the 53.1.6.el5 release also is vulnerable, so you may as well wait for the exploit to be fixed before updating. I'm guessing CentOS will do it fairly quickly after rhel does.
I understand that a known root exploit must be patched but I'm curious to know if we upgrade to the fixed kernel once released will it also include the degraded nfs performance discussed here:
We have to wait and see, but my impression is that the nfs fix would not be in the updated kernel (I hope I am wrong). They are talking about getting it into 5.2 (even possibly into 5.3). I can see that this is a problem. Now, we can not "stay with 53.1.4" on the systems where the local root exploit is a serious problem.
Akemi
Akemi
Yes, until now we had no problem stalling on 53.1.4. I guess we'll have to test how badly the nfs performance degradation actually is under a heavy load in our environment.
Scott McClanahan kirjoitti viestissään (lähetysaika maanantai, 11. helmikuuta 2008):
On Mon, 2008-02-11 at 10:45 -0800, Akemi Yagi wrote:
On Feb 11, 2008 8:19 AM, Scott McClanahan scott.mcclanahan@trnswrks.com
wrote:
On Mon, 2008-02-11 at 04:52 -0800, Michael A. Peters wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
The current kernel is 53.1.6.el5
If yum isn't seeing it - it probably needs to clean its cached headers.
try:
yum clean headers yum update kernel
However - the 53.1.6.el5 release also is vulnerable, so you may as well wait for the exploit to be fixed before updating. I'm guessing CentOS will do it fairly quickly after rhel does.
I understand that a known root exploit must be patched but I'm curious to know if we upgrade to the fixed kernel once released will it also include the degraded nfs performance discussed here:
We have to wait and see, but my impression is that the nfs fix would not be in the updated kernel (I hope I am wrong). They are talking about getting it into 5.2 (even possibly into 5.3). I can see that this is a problem. Now, we can not "stay with 53.1.4" on the systems where the local root exploit is a serious problem.
Akemi
Akemi
Yes, until now we had no problem stalling on 53.1.4. I guess we'll have to test how badly the nfs performance degradation actually is under a heavy load in our environment.
Ofcource there's a way, get vanilla kernel 2.6.24.2 and use old config compile it and run. I've done it.
Jarmo
On Mon, 11 Feb 2008, jarmo wrote:
Scott McClanahan kirjoitti viestissään (lähetysaika maanantai, 11. helmikuuta 2008):
On Mon, 2008-02-11 at 10:45 -0800, Akemi Yagi wrote:
On Feb 11, 2008 8:19 AM, Scott McClanahan scott.mcclanahan@trnswrks.com
wrote:
On Mon, 2008-02-11 at 04:52 -0800, Michael A. Peters wrote:
Valent Turkovic wrote:
I saw that there is a local root exploit in the wild. http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
And I see my centos box still has: 2.6.18-53.1.4.el5
yum says there are no updates... am I safe?
Valent.
The current kernel is 53.1.6.el5
If yum isn't seeing it - it probably needs to clean its cached headers.
try:
yum clean headers yum update kernel
However - the 53.1.6.el5 release also is vulnerable, so you may as well wait for the exploit to be fixed before updating. I'm guessing CentOS will do it fairly quickly after rhel does.
I understand that a known root exploit must be patched but I'm curious to know if we upgrade to the fixed kernel once released will it also include the degraded nfs performance discussed here:
We have to wait and see, but my impression is that the nfs fix would not be in the updated kernel (I hope I am wrong). They are talking about getting it into 5.2 (even possibly into 5.3). I can see that this is a problem. Now, we can not "stay with 53.1.4" on the systems where the local root exploit is a serious problem.
Yes, until now we had no problem stalling on 53.1.4. I guess we'll have to test how badly the nfs performance degradation actually is under a heavy load in our environment.
Ofcource there's a way, get vanilla kernel 2.6.24.2 and use old config compile it and run. I've done it.
And *poof* you lost all support or reproducability that people crave when using CentOS or RHEL.
So yes, it is a possibility, but probably unlikely when people have chosen CentOS or RHEL. And especially for those systems that are considered production (or important) and that are the most vulnerable you may not want to do this. (Or maybe instead you need to !)
Dag Wieers wrote:
On Mon, 11 Feb 2008, jarmo wrote:
Scott McClanahan kirjoitti viestissään (lähetysaika
maanantai, 11. helmikuuta
2008):
On Mon, 2008-02-11 at 10:45 -0800, Akemi Yagi wrote:
On Feb 11, 2008 8:19 AM, Scott McClanahan
wrote:
On Mon, 2008-02-11 at 04:52 -0800, Michael A. Peters wrote:
Valent Turkovic wrote: > I saw that there is a local root exploit in the wild. >
http://blog.kagesenshi.org/2008/02/local-root-exploit-on-wild.html
> > And I see my centos box still has: 2.6.18-53.1.4.el5 > > yum says there are no updates... am I safe? > > Valent.
The current kernel is 53.1.6.el5
If yum isn't seeing it - it probably needs to clean
its cached
headers.
try:
yum clean headers yum update kernel
However - the 53.1.6.el5 release also is
vulnerable, so you may as
well wait for the exploit to be fixed before
updating. I'm guessing
CentOS will do it fairly quickly after rhel does.
I understand that a known root exploit must be
patched but I'm curious
to know if we upgrade to the fixed kernel once
released will it also
include the degraded nfs performance discussed here:
We have to wait and see, but my impression is that the
nfs fix would
not be in the updated kernel (I hope I am wrong). They
are talking
about getting it into 5.2 (even possibly into 5.3). I
can see that
this is a problem. Now, we can not "stay with 53.1.4"
on the systems
where the local root exploit is a serious problem.
Yes, until now we had no problem stalling on 53.1.4. I
guess we'll have
to test how badly the nfs performance degradation
actually is under a
heavy load in our environment.
Ofcource there's a way, get vanilla kernel 2.6.24.2 and use
old config
compile it and run. I've done it.
And *poof* you lost all support or reproducability that people crave when using CentOS or RHEL.
So yes, it is a possibility, but probably unlikely when people have chosen CentOS or RHEL. And especially for those systems that are considered production (or important) and that are the most vulnerable you may not want to do this. (Or maybe instead you need to !)
Yes, true, but say you are running a shell account system and want to know it isn't vulnerable, can't wait until upstream provides a fix and don't want to run some possibly flaky work-around patch, what then?
I think one needs to weigh the consequences in these scenarios instead of saying it should be all one way or the other.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Mon, 11 Feb 2008, Ross S. W. Walker wrote:
Dag Wieers wrote:
On Mon, 11 Feb 2008, jarmo wrote:
Ofcource there's a way, get vanilla kernel 2.6.24.2 and use
old config
compile it and run. I've done it.
And *poof* you lost all support or reproducability that people crave when using CentOS or RHEL.
So yes, it is a possibility, but probably unlikely when people have chosen CentOS or RHEL. And especially for those systems that are considered production (or important) and that are the most vulnerable you may not want to do this. (Or maybe instead you need to !)
Yes, true, but say you are running a shell account system and want to know it isn't vulnerable, can't wait until upstream provides a fix and don't want to run some possibly flaky work-around patch, what then?
I think one needs to weigh the consequences in these scenarios instead of saying it should be all one way or the other.
Then I would opt to patch the latest Red Hat kernel with eg. the Debian patch rather than running a 2.6.24.2 kernel that may have numerous yet-unknown compatibility problems with parts of the system that interact with the kernel. And I would make an RPM out of it that upgrades smoothly to the next CentOS release.
But then again, this would be advice for a minority and not something I would recommend to everyone on this list.
Dag Wieers wrote:
On Mon, 11 Feb 2008, Ross S. W. Walker wrote:
Dag Wieers wrote:
On Mon, 11 Feb 2008, jarmo wrote:
Ofcource there's a way, get vanilla kernel 2.6.24.2 and use
old config
compile it and run. I've done it.
And *poof* you lost all support or reproducability that people crave when using CentOS or RHEL.
So yes, it is a possibility, but probably unlikely when people have chosen CentOS or RHEL. And especially for those systems that are
considered
production (or important) and that are the most
vulnerable you may not
want to do this. (Or maybe instead you need to !)
Yes, true, but say you are running a shell account system
and want to
know it isn't vulnerable, can't wait until upstream provides a fix and don't want to run some possibly flaky work-around patch, what then?
I think one needs to weigh the consequences in these
scenarios instead
of saying it should be all one way or the other.
Then I would opt to patch the latest Red Hat kernel with eg. the Debian patch rather than running a 2.6.24.2 kernel that may have numerous yet-unknown compatibility problems with parts of the system that interact with the kernel. And I would make an RPM out of it that upgrades smoothly to the next CentOS release.
Problem with Debian patch is it may conflict with some of the RH backports, but if it works why not submit it to CentOS team for testing as I hear the RH current workaround has issues with GPFs.
If it works then maybe a "FastTrack" kernel could be put out on CentOS?
Easiest way for me would be to adapt a FC8 kernel package to C5 then try to play with a back-ported patch from a third-party system into an already heavily patched kernel.
But then again, this would be advice for a minority and not something I would recommend to everyone on this list.
I personnally run my systems behind the firewall, but I suppose anybody who has CentOS/RHEL 5 that is Internet facing would worry a little bit more.
I wonder if any existing user-land utilities have hooks into vmsplice that may be able to be accessed via PHP, Perl, or CGI?
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Mon, Feb 11, 2008 at 04:26:57PM -0500, Ross S. W. Walker wrote:
Problem with Debian patch is it may conflict with some of the RH backports, but if it works why not submit it to CentOS team for testing as I hear the RH current workaround has issues with GPFs.
I think that's with the powertech.no "ptpatch2008" kernel module which tries to patch the problem in your existing kernel -- not with the actual fix.
I personnally run my systems behind the firewall, but I suppose anybody who has CentOS/RHEL 5 that is Internet facing would worry a little bit more.
Do you ever use network-accessing applications which might have bugs?
I wonder if any existing user-land utilities have hooks into vmsplice that may be able to be accessed via PHP, Perl, or CGI?
It's a system call.
Matthew Miller wrote:
On Mon, Feb 11, 2008 at 04:26:57PM -0500, Ross S. W. Walker wrote:
Problem with Debian patch is it may conflict with some of the RH backports, but if it works why not submit it to CentOS team for testing as I hear the RH current workaround has issues with GPFs.
I think that's with the powertech.no "ptpatch2008" kernel module which tries to patch the problem in your existing kernel -- not with the actual fix.
Ah, ok, I feel a little better about it then. The reports weren't specific about which patch was used and I assumed it was the patch on bugzilla.
I personnally run my systems behind the firewall, but I suppose anybody who has CentOS/RHEL 5 that is Internet facing would worry a little bit more.
Do you ever use network-accessing applications which might have bugs?
Yes, but always through transparent proxies which scan all traffic.
BTW aren't we all using network-accessing applications which might have bugs all the time? I would say every application we use has bugs, how big or small they are is as yet to be seen, so I trust NOTHING.
I wonder if any existing user-land utilities have hooks into vmsplice that may be able to be accessed via PHP, Perl, or CGI?
It's a system call.
Yes, but conceivable an application can make use of such a system call since it is exploitable from user land and hence the concern.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Mon, Feb 11, 2008 at 06:00:14PM -0500, Ross S. W. Walker wrote:
I wonder if any existing user-land utilities have hooks into vmsplice that may be able to be accessed via PHP, Perl, or CGI?
It's a system call.
Yes, but conceivable an application can make use of such a system call since it is exploitable from user land and hence the concern.
Well, the point is there's nothing wrong with the system call *inherently*. There's just a flaw in its implementation which a carefully-crafted program can exploit. A program which just happens to use the system call as it is intended to be used isn't any more dangerous than any other code.
Matthew Miller wrote:
On Mon, Feb 11, 2008 at 06:00:14PM -0500, Ross S. W. Walker wrote:
I wonder if any existing user-land utilities have hooks into vmsplice that may be able to be accessed via PHP, Perl, or CGI?
It's a system call.
Yes, but conceivable an application can make use of such a system call since it is exploitable from user land and hence the concern.
Well, the point is there's nothing wrong with the system call *inherently*. There's just a flaw in its implementation which a carefully-crafted program can exploit. A program which just happens to use the system call as it is intended to be used isn't any more dangerous than any other code.
Sorry this thread keeps getting taken further out of context on each reply.
Yes I understand there is nothing inherently wrong with the concept of the vmsplice() system call and it adds a lot of benefit to the Linux kernel.
But if an application uses a system call, and that call to the system API depends on user input that isn't properly checking bounds, then said application can be used as a vector to system penetration.
That is all I am saying and was asking if anybody knew if such a vector existed in any PHP, Perl or CGI module as it would be the most likely method of leveraging the flaw if one did not have a shell account on that machine.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Mon, Feb 11, 2008 at 10:56:28PM -0500, Ross S. W. Walker wrote:
Yes, but conceivable an application can make use of such a system call since it is exploitable from user land and hence the concern.
Well, the point is there's nothing wrong with the system call *inherently*. There's just a flaw in its implementation which a carefully-crafted program can exploit. A program which just happens to use the system call as it is intended to be used isn't any more dangerous than any other code.
Sorry this thread keeps getting taken further out of context on each reply.
Yes I understand there is nothing inherently wrong with the concept of the vmsplice() system call and it adds a lot of benefit to the Linux kernel.
But if an application uses a system call, and that call to the system API depends on user input that isn't properly checking bounds, then said application can be used as a vector to system penetration.
That is all I am saying and was asking if anybody knew if such a vector existed in any PHP, Perl or CGI module as it would be the most likely method of leveraging the flaw if one did not have a shell account on that machine.
And here's what I'm saying. :) The exploit requires a certain amount of specialized setup before the vmsplice call. And, this stuff isn't likely to be user-supplied input since we're talking about memory management. To say that a flaw in an existing program (let alone a script) made to do that setup is an unlikely vector is an understatement. I'd be a lot more worried about sloppy PHP, Perl, or CGI code having exploits which let you run arbitrary user-level code (happens all the time), because that + this = remote root.
Dag Wieers kirjoitti viestissään (lähetysaika maanantai, 11. helmikuuta 2008):
And *poof* you lost all support or reproducability that people crave when using CentOS or RHEL.
So yes, it is a possibility, but probably unlikely when people have chosen CentOS or RHEL. And especially for those systems that are considered production (or important) and that are the most vulnerable you may not want to do this. (Or maybe instead you need to !)
Oh, I thought, quikiest way, if afraid to become exploited. Sorry, my missunderstanding.
Jarmo
jarmo wrote:
Ofcource there's a way, get vanilla kernel 2.6.24.2 and use old config compile it and run. I've done it.
I am running a 2.6.24.x kernel built like that on CentOS 5.1 x86_64, but be careful, some manual tweaking with "make menuconfig" is required, since there are too many differences between the kernel versions to rely entirely on "make oldconfig".
Bottom line - it works, but it's not 100% automatic.
On Feb 11, 2008 10:52 AM, Scott McClanahan scott.mcclanahan@trnswrks.com wrote:
On Mon, 2008-02-11 at 10:45 -0800, Akemi Yagi wrote:
We have to wait and see, but my impression is that the nfs fix would not be in the updated kernel (I hope I am wrong). They are talking about getting it into 5.2 (even possibly into 5.3). I can see that this is a problem. Now, we can not "stay with 53.1.4" on the systems where the local root exploit is a serious problem.
Akemi
Yes, until now we had no problem stalling on 53.1.4. I guess we'll have to test how badly the nfs performance degradation actually is under a heavy load in our environment.
Good news! CentOS is going to offer the updated kernel (-53.1.13) with the nfs patch applied -- thanks to Johnny Hughes. Let's wait to hear from him.
Akemi
Akemi Yagi wrote:
On Feb 11, 2008 10:52 AM, Scott McClanahan scott.mcclanahan@trnswrks.com wrote:
On Mon, 2008-02-11 at 10:45 -0800, Akemi Yagi wrote:
We have to wait and see, but my impression is that the nfs fix would not be in the updated kernel (I hope I am wrong). They are talking about getting it into 5.2 (even possibly into 5.3). I can see that this is a problem. Now, we can not "stay with 53.1.4" on the systems where the local root exploit is a serious problem.
Akemi
Yes, until now we had no problem stalling on 53.1.4. I guess we'll have to test how badly the nfs performance degradation actually is under a heavy load in our environment.
Good news! CentOS is going to offer the updated kernel (-53.1.13) with the nfs patch applied -- thanks to Johnny Hughes. Let's wait to hear from him.
Akemi
There is a kernel that matches upstream and it is released to the centos-5 tree and available via the normal yum updates.
It is patched for this root exploit issue, but the NFS is still broken per this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=321111
SO ... there are kernels available here (that you will need to manually install) which SHOULD fix this root exploit AND work with NFS:
http://people.centos.org/~hughesjr/kernel/5/
This is a testing kernel ... it seems to work for me and has passed testing on several other CentOS servers ... and it has a backported patch from the 2.6.18-80.el5 testing upstream RHEL server.
Each person who wants to use this needs to test it first for themselves ... if it breaks your machine you get to keep all pieces :D
I will also be rolling this same NFS patch into the centosplus kernel for centos-5 which is currently building.
Thanks, Johnny Hughes
on 2/13/2008 6:52 AM Johnny Hughes spake the following:
Akemi Yagi wrote:
On Feb 11, 2008 10:52 AM, Scott McClanahan scott.mcclanahan@trnswrks.com wrote:
On Mon, 2008-02-11 at 10:45 -0800, Akemi Yagi wrote:
We have to wait and see, but my impression is that the nfs fix would not be in the updated kernel (I hope I am wrong). They are talking about getting it into 5.2 (even possibly into 5.3). I can see that this is a problem. Now, we can not "stay with 53.1.4" on the systems where the local root exploit is a serious problem.
Akemi
Yes, until now we had no problem stalling on 53.1.4. I guess we'll have to test how badly the nfs performance degradation actually is under a heavy load in our environment.
Good news! CentOS is going to offer the updated kernel (-53.1.13) with the nfs patch applied -- thanks to Johnny Hughes. Let's wait to hear from him.
Akemi
There is a kernel that matches upstream and it is released to the centos-5 tree and available via the normal yum updates.
It is patched for this root exploit issue, but the NFS is still broken per this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=321111
SO ... there are kernels available here (that you will need to manually install) which SHOULD fix this root exploit AND work with NFS:
http://people.centos.org/~hughesjr/kernel/5/
This is a testing kernel ... it seems to work for me and has passed testing on several other CentOS servers ... and it has a backported patch from the 2.6.18-80.el5 testing upstream RHEL server.
Each person who wants to use this needs to test it first for themselves ... if it breaks your machine you get to keep all pieces :D
I soo love that last line! I could just imagine someone like Jack Nicholson saying it in a movie.
On Wed, 13 Feb 2008 08:28:12 -0800 Scott Silva ssilva@sgvwater.com wrote:
Each person who wants to use this needs to test it first for themselves ... if it breaks your machine you get to keep all pieces :D
I soo love that last line! I could just imagine someone like Jack Nicholson saying it in a movie.
The two-part warranty: If you break it, you get to keep both pieces.
The lifetime warranty: If it breaks, we kill you.
I think there's one more but I can't remember what it is at the moment.
Scott Silva wrote:
on 2/13/2008 6:52 AM Johnny Hughes spake the following:
Each person who wants to use this needs to test it first
for themselves
... if it breaks your machine you get to keep all pieces :D
I soo love that last line! I could just imagine someone like Jack Nicholson saying it in a movie.
That's the standard OSS guarantee. ;-)
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
The official patch for debian is out since a couple of hours... Why does it take so long for RHEL ? Just a question, not a troll or something.
kfx
On Mon, 11 Feb 2008, kfx wrote:
The official patch for debian is out since a couple of hours... Why does it take so long for RHEL ? Just a question, not a troll or something.
1. ask them
2. there have been reports of stability problems with the patch -- it does little good to rush out a fix for a non-remote root exploit that causes boxes to crash. One assumes some robustness testing is in play. I certainly hope so.
-- Russ herrold
R P Herrold wrote:
On Mon, 11 Feb 2008, kfx wrote:
The official patch for debian is out since a couple of hours... Why does it take so long for RHEL ? Just a question, not a troll or something.
- ask them
it was a question, not a troll (bis).
- there have been reports of stability problems with the patch
you mean that adding a validation of users input in a code lead to stability problem ?
-- it does little good to rush out a fix for a non-remote root exploit that causes boxes to crash. One assumes some robustness testing is in play. I certainly hope so.
-- Russ herrold
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
kfx wrote:
R P Herrold wrote:
On Mon, 11 Feb 2008, kfx wrote:
The official patch for debian is out since a couple of hours... Why does it take so long for RHEL ? Just a question, not a troll or something.
- ask them
it was a question, not a troll (bis).
However, you are asking the wrong people ... we have no idea.
Also ... it *_IS_* trolling (or at least certainly silly) to post that Debain had the patch and RHEL doesn't ... so let's make RHEL be Debain. Fedora also has the patch released and RHEL doesn't ... I don't want RHEL to be Fedora either.
Maybe you are using the wrong distro ... I want stable kernels on my servers, so I'll take the extra day of testing. For people who do not want stable and tested software, switch distros.
- there have been reports of stability problems with the patch
you mean that adding a validation of users input in a code lead to stability problem ?
What we mean is this ... once a patch is created upstream it must go through several testing phases. To look for regressions, to QA to verify it does not cause other problems, be compared/intergrated with the other custom patches Red Hat has in its kenrel (more than 1000).
It also needs to be tested against the NEWER things that they have already created and have in the pipeline for release.
Once they do that they will test it under load on many different platforms and THEN they will release it.
As stated earlier in this thread, there *_IS_* still probably going to be a performance issue with NFS when they release this kernel ... so we might have to figure out how we fix that later (as continuing to use 2.6.18-53.1.4 is not really now a viable option).
-- it does little good to rush out a fix for a non-remote root exploit that causes boxes to crash. One assumes some robustness testing is in play. I certainly hope so.
Russ's comment is exactly the issue at stake. They can not just rush this package out the door to potentially break people's machines ... it needs to be QA tested and regression tested. That is what Enterprise Linux is about, tested and stable releases.
Rest assured that as soon as the upstream people have a patch, so will the CentOS team. However, we are not going to rush a non tested patch out the door. There are patches listed on the upstream bug, if you (figurative ... meaning anyone who wants to not wait) really want to integrate that into your own kernels in the interim then please do.
Thanks, Johnny Hughes
Johnny Hughes wrote:
kfx wrote:
R P Herrold wrote:
On Mon, 11 Feb 2008, kfx wrote:
The official patch for debian is out since a couple of hours... Why does it take so long for RHEL ? Just a question, not a troll or something.
- ask them
it was a question, not a troll (bis).
However, you are asking the wrong people ... we have no idea.
Also ... it *_IS_* trolling (or at least certainly silly) to post that Debain had the patch and RHEL doesn't ... so let's make RHEL be Debain. Fedora also has the patch released and RHEL doesn't ... I don't want RHEL to be Fedora either.
hu ? Well you are right, my question was a bit silly but this thread was closed (for me at least) yesterday with Mr Van Dolson's last intervention. Why do you come out now from nowhere like "hey troll spotted! you are silly" or what ? It's just that it is a hard time for rhel, the 1.6 NFS issue then this one. And now we are going to have to choice between being exploitable or a decent nfs support.
Maybe you are using the wrong distro ... I want stable kernels on my servers, so I'll take the extra day of testing. For people who do not want stable and tested software, switch distros.
And the "change distro" speech is quite puerile, you think we all have the choice ? or that we can switch dozen of servers like this ? I can imagine that this exploit is not dramatic for a lot of people. But in certain case, like in scholar environment, where we have a lot of untrusted user's accounts, something like this IS problematic.
[...]
Rest assured that as soon as the upstream people have a patch, so will the CentOS team.
And thank you for your work.
However, we are not going to rush a non tested patch out the door. There are patches listed on the upstream bug, if you (figurative ... meaning anyone who wants to not wait) really want to integrate that into your own kernels in the interim then please do.
I did, for the record: http://people.redhat.com/dzickus/el5/ BEWARE that it will remove ALL the older kernels.
Regards, kfx
Thanks, Johnny Hughes
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Feb 12, 2008 8:40 AM, kfx kadafax@gmail.com wrote:
However, we are not going to rush a non tested patch out the door. There are patches listed on the upstream bug, if you (figurative ... meaning anyone who wants to not wait) really want to integrate that into your own kernels in the interim then please do.
I did, for the record: http://people.redhat.com/dzickus/el5/ BEWARE that it will remove ALL the older kernels.
No, that is simply not true. I have tested a couple of kernels from http://people.redhat.com/dzickus/el5/ and neither removed my older kernels and I was able to go back to my original kernel without a hitch. Maybe you did not install the kernel *correctly* ?
Akemi
Regards, kfx
Akemi Yagi wrote:
On Feb 12, 2008 8:40 AM, kfx kadafax@gmail.com wrote:
I did, for the record: http://people.redhat.com/dzickus/el5/ BEWARE that it will remove ALL the older kernels.
No, that is simply not true. I have tested a couple of kernels from http://people.redhat.com/dzickus/el5/ and neither removed my older kernels and I was able to go back to my original kernel without a hitch. Maybe you did not install the kernel *correctly* ?
My bad, you are right. I did a "rpm -Uvh kernel-xen-2.6.18-80.el5.x86_64.rpm"
kfx
Akemi
Regards, kfx
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Feb 12, 2008 11:40 AM, kfx kadafax@gmail.com wrote:
I did, for the record: http://people.redhat.com/dzickus/el5/ BEWARE that it will remove ALL the older kernels.
It will do this if you install via rpm -Uvh, as the the upgrade implies the removal of older versions. -ivh will install it next to the other packages.
I' d guess you used the wrong rpm command for dealing with kernels.
-
Akemi Yagi -
Dag Wieers -
Florin Andrei -
Frank Cox -
jarmo -
Jim Perrin -
Johnny Hughes -
kfx -
Matthew Miller -
Michael A. Peters -
R P Herrold -
Ralph Angenendt -
Ray Van Dolson -
Ross S. W. Walker -
Scott McClanahan -
Scott Silva -
Valent Turkovic