some new remote kernel exploit?

some new remote kernel exploit?

[Jure Pecar]

Hi all,


Please see my post to the redhat list at

https://listman.redhat.com/pipermail/valhalla-list/2003-April/025830.html


I'm getting more and more affraid ... since now the the third box was
targeted and there were more attempts at 22:00-22:47 localtime (gmt+1).

rpm -Va shows nothing suspicious, so i hope these are still only attempts. 

I have put the ksymoops from the logs at http://nerv.eu.org/oopsen/ if you
want to see them all.

I'm pretty much without ideas how to track this down ... expect to sit at
the computer for the next 24h and be ready to start dumping traffic at the
moment it starts again.


Please cc me on replies. Thanks.

-- 

Jure Pecar

Re: some new remote kernel exploit?

[Alan Cox]

On Maw, 2003-04-08 at 02:33, Jure Pecar wrote:
> I'm pretty much without ideas how to track this down ... expect to sit at
> the computer for the next 24h and be ready to start dumping traffic at the
> moment it starts again.

If its an attack, then it would imply someone patched the kernel image 
syscall table stuff or around there and got it wrong, perhaps precisely
because your kernels are custom.

SIGRTMIN, F_SETOWN(-getpgrp()) and threads

[Lamont Granquist]

I'm attempting to send SIGRTMIN to an entire pgrp composed of threads.
I'm running into issues with the management thread getting this signal and
dying because it is uncaught in that thread.  Is there any way to make the
management thread ignore this signal?  (and i'm running linux 2.4.20-ish
and glibc-2.2.4-19.3)

Re: SIGRTMIN, F_SETOWN(-getpgrp()) and threads

[Alex Riesen]

Lamont Granquist, Tue, Apr 29, 2003 01:34:21 +0200:
> 
> I'm attempting to send SIGRTMIN to an entire pgrp composed of threads.
> I'm running into issues with the management thread getting this signal and
> dying because it is uncaught in that thread.  Is there any way to make the
> management thread ignore this signal?  (and i'm running linux 2.4.20-ish
> and glibc-2.2.4-19.3)
> 

ignore it before pthreads are initialized?

int main(int argc, char* argv[])
{
    signal(SIGRTMIN, SIG_IGN);
    ...

Re: SIGRTMIN, F_SETOWN(-getpgrp()) and threads

[Lamont Granquist]

On Tue, 29 Apr 2003, Alex Riesen wrote:
> Lamont Granquist, Tue, Apr 29, 2003 01:34:21 +0200:
> >
> > I'm attempting to send SIGRTMIN to an entire pgrp composed of threads.
> > I'm running into issues with the management thread getting this signal and
> > dying because it is uncaught in that thread.  Is there any way to make the
> > management thread ignore this signal?  (and i'm running linux 2.4.20-ish
> > and glibc-2.2.4-19.3)
> >
>
> ignore it before pthreads are initialized?
>
> int main(int argc, char* argv[])
> {
>     signal(SIGRTMIN, SIG_IGN);
>     ...

That doesn't work.  After the first pthread_create() if you raise() the
signal again (even if you ignore it in the thread that you create) you'll
still have the manager thread exit.

Re: SIGRTMIN, F_SETOWN(-getpgrp()) and threads

[Alex Riesen]

Lamont Granquist, Tue, Apr 29, 2003 22:14:22 +0200:
> > > I'm attempting to send SIGRTMIN to an entire pgrp composed of threads.
> > > I'm running into issues with the management thread getting this signal and
> > > dying because it is uncaught in that thread.  Is there any way to make the
> > > management thread ignore this signal?  (and i'm running linux 2.4.20-ish
> > > and glibc-2.2.4-19.3)
> > ignore it before pthreads are initialized?
> >
> > int main(int argc, char* argv[])
> > {
> >     signal(SIGRTMIN, SIG_IGN);
> >     ...
> That doesn't work.  After the first pthread_create() if you raise() the
> signal again (even if you ignore it in the thread that you create) you'll
> still have the manager thread exit.

probably because it is used by pthreads for internal communication.
It's mentioned in 2.2.5 (at least) sources.