Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Paul Hampson]

On Wed, Apr 02, 2003 at 09:46:52AM +0200, Dariush Pietrzak wrote:
> > of proportion... Some things in security _have_ to be obscure. Your
> > password, for example. Or the primes used to generate your PGP private
>  There's a difference between 'obscure' and 'secret'.

In this context, I'd suggest that the difference is that things that
need to be obscured _might_ be security risks, or are high-effort
risks (your password-protected GPG secret key) and things that need
to be kept secret are the low-effort risks, or things that are known
to open up the security (your GPG secret key passphrase)

> All you gain by removing kernel-loading capability from your kernel is to
> force cracker to search memory to find entry points.
>  That's like hiding key to your door under your doormat.

No, the key's the same. It's the lock that's been moved. Or rather,
removed... Now the key must be inserted into the keyhole in such a way
as to drop the tumblers. Sure, someone experienced enough could do it
easily, but the guy who just wanders past and decides to look under your
mat will get discouraged

Not that I'm suggesting that the earlier poster's security setup (you
have to _be_ root to make this work anyway) is a doormat level of
security... But the metaphor needed stretching. :-)

> 
> > Security-by-obscurity refers to securing things by relying on the
> > obscurity of the _processes and functionality_ behind the security system,
>  that fits this description. 

No it doesn't. In this case, that would be hiding the Linux source code
so that there was no reference to _find out_ how to load a module
without modutils.

Besides, security through obscurity isn't all it's cracked down to
be... Ask distributed.net how well their keyblock uploading code works,
security wise...

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpVqVnG2TPyz.pgp
Description: PGP signature

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Paul Hampson]

On Wed, Apr 02, 2003 at 09:46:52AM +0200, Dariush Pietrzak wrote:
> > of proportion... Some things in security _have_ to be obscure. Your
> > password, for example. Or the primes used to generate your PGP private
>  There's a difference between 'obscure' and 'secret'.

In this context, I'd suggest that the difference is that things that
need to be obscured _might_ be security risks, or are high-effort
risks (your password-protected GPG secret key) and things that need
to be kept secret are the low-effort risks, or things that are known
to open up the security (your GPG secret key passphrase)

> All you gain by removing kernel-loading capability from your kernel is to
> force cracker to search memory to find entry points.
>  That's like hiding key to your door under your doormat.

No, the key's the same. It's the lock that's been moved. Or rather,
removed... Now the key must be inserted into the keyhole in such a way
as to drop the tumblers. Sure, someone experienced enough could do it
easily, but the guy who just wanders past and decides to look under your
mat will get discouraged

Not that I'm suggesting that the earlier poster's security setup (you
have to _be_ root to make this work anyway) is a doormat level of
security... But the metaphor needed stretching. :-)

> 
> > Security-by-obscurity refers to securing things by relying on the
> > obscurity of the _processes and functionality_ behind the security system,
>  that fits this description. 

No it doesn't. In this case, that would be hiding the Linux source code
so that there was no reference to _find out_ how to load a module
without modutils.

Besides, security through obscurity isn't all it's cracked down to
be... Ask distributed.net how well their keyblock uploading code works,
security wise...

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgp0.pgp
Description: PGP signature

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Tim Nicholas]

On Wed, Apr 02, 2003 at 09:46:52AM +0200, Dariush Pietrzak wrote:
> > of proportion... Some things in security _have_ to be obscure. Your
> > password, for example. Or the primes used to generate your PGP private
>  There's a difference between 'obscure' and 'secret'.

This is true.

> All you gain by removing kernel-loading capability from your kernel is to
> force cracker to search memory to find entry points.
>  That's like hiding key to your door under your doormat.

Thats not true. Or rather if it is, then using the key is
considerably harder than simply opening the door (which would be
equivalent of having module support using your metaphor).

But disabling module support isn't obscuring anything, its genuinely
changing the system. The attacker is in fact going to have to do
something different and more difficult to modify the kernel. 
You seem to be saying that if there is one way of achieving a
security breach, then you shouldn't bother stopping other ways of
achieving the same result. This is clearly ridiculas.

Yours, 

Tim

-- 
Tim Nicholas  ||  Cilix
Email: [EMAIL PROTECTED]||Wellington, New Zealand
http://tim.nicholas.net.nz/   ||   Cell/SMS: +64 21 337 204
"Sir, I think you have a problem with your brain being missing."

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dariush Pietrzak]

> of proportion... Some things in security _have_ to be obscure. Your
> password, for example. Or the primes used to generate your PGP private
 There's a difference between 'obscure' and 'secret'.
All you gain by removing kernel-loading capability from your kernel is to
force cracker to search memory to find entry points.
 That's like hiding key to your door under your doormat.

> Security-by-obscurity refers to securing things by relying on the
> obscurity of the _processes and functionality_ behind the security system,
 that fits this description. 
-- 
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294  05E0 BCC7 02C4 75CC 50D9

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Tim Nicholas]

On Wed, Apr 02, 2003 at 09:46:52AM +0200, Dariush Pietrzak wrote:
> > of proportion... Some things in security _have_ to be obscure. Your
> > password, for example. Or the primes used to generate your PGP private
>  There's a difference between 'obscure' and 'secret'.

This is true.

> All you gain by removing kernel-loading capability from your kernel is to
> force cracker to search memory to find entry points.
>  That's like hiding key to your door under your doormat.

Thats not true. Or rather if it is, then using the key is
considerably harder than simply opening the door (which would be
equivalent of having module support using your metaphor).

But disabling module support isn't obscuring anything, its genuinely
changing the system. The attacker is in fact going to have to do
something different and more difficult to modify the kernel. 
You seem to be saying that if there is one way of achieving a
security breach, then you shouldn't bother stopping other ways of
achieving the same result. This is clearly ridiculas.

Yours, 

Tim

-- 
Tim Nicholas  ||  Cilix
Email: [EMAIL PROTECTED]||Wellington, New Zealand
http://tim.nicholas.net.nz/   ||   Cell/SMS: +64 21 337 204
"Sir, I think you have a problem with your brain being missing."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Paul Hampson]

On Tue, Apr 01, 2003 at 09:43:38PM +0200, Dariush Pietrzak wrote:
> > One reason is security:
> > it's relatively easy for an intruder to install a kernel module based
> > rootkit, and then hide her processes, files or connections.
> isn't it security-by-obscurity?

No, that's stretching the definition of security-by-obscurity all out
of proportion... Some things in security _have_ to be obscure. Your
password, for example. Or the primes used to generate your PGP private
key.

Security-by-obscurity refers to securing things by relying on the
obscurity of the _processes and functionality_ behind the security system,
instead of the _data_ used to secure it. It's a bad idea because
_processes and functionality_ is a much smaller search domain than
_data_.

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpRnP4OTL1b9.pgp
Description: PGP signature

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dariush Pietrzak]

> of proportion... Some things in security _have_ to be obscure. Your
> password, for example. Or the primes used to generate your PGP private
 There's a difference between 'obscure' and 'secret'.
All you gain by removing kernel-loading capability from your kernel is to
force cracker to search memory to find entry points.
 That's like hiding key to your door under your doormat.

> Security-by-obscurity refers to securing things by relying on the
> obscurity of the _processes and functionality_ behind the security system,
 that fits this description. 
-- 
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294  05E0 BCC7 02C4 75CC 50D9


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Paul Hampson]

On Tue, Apr 01, 2003 at 09:43:38PM +0200, Dariush Pietrzak wrote:
> > One reason is security:
> > it's relatively easy for an intruder to install a kernel module based
> > rootkit, and then hide her processes, files or connections.
> isn't it security-by-obscurity?

No, that's stretching the definition of security-by-obscurity all out
of proportion... Some things in security _have_ to be obscure. Your
password, for example. Or the primes used to generate your PGP private
key.

Security-by-obscurity refers to securing things by relying on the
obscurity of the _processes and functionality_ behind the security system,
instead of the _data_ used to secure it. It's a bad idea because
_processes and functionality_ is a much smaller search domain than
_data_.

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgp0.pgp
Description: PGP signature

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dale Amon]

On Tue, Apr 01, 2003 at 01:57:10PM -0500, Phillip Hofmeister wrote:
> Assuming an intruder made his way in with root privs couldn't he also
> modify /dev/kmem or directly access the kernel memory by some other
> means?  I beleive this topic has also been discussed in the past (dig
> deep into the archives) and it was concluded that not allowing modules
> to be loaded does not really protect you from your kernel being
> modified at run-time.

You have to use grsec to close the others up. A
"grey hat" friend of mine noted that a rootkit module
was his favorite hack when he was in that line of work.

-- 
--
   IN MY NAME:Dale Amon, CEO/MD
  No Mushroom clouds over Islandone Society
London and New York.  www.islandone.org
--

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dale Amon]

On Tue, Apr 01, 2003 at 01:57:10PM -0500, Phillip Hofmeister wrote:
> Assuming an intruder made his way in with root privs couldn't he also
> modify /dev/kmem or directly access the kernel memory by some other
> means?  I beleive this topic has also been discussed in the past (dig
> deep into the archives) and it was concluded that not allowing modules
> to be loaded does not really protect you from your kernel being
> modified at run-time.

You have to use grsec to close the others up. A
"grey hat" friend of mine noted that a rootkit module
was his favorite hack when he was in that line of work.

-- 
--
   IN MY NAME:Dale Amon, CEO/MD
  No Mushroom clouds over Islandone Society
London and New York.  www.islandone.org
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Wade Richards]

On Tue, 01 Apr 2003 13:57:10 EST, Phillip Hofmeister writes:
>Assuming an intruder made his way in with root privs couldn't he also
>modify /dev/kmem or directly access the kernel memory by some other
>means?  I beleive this topic has also been discussed in the past (dig
>deep into the archives) and it was concluded that not allowing modules
>to be loaded does not really protect you from your kernel being
>modified at run-time.

Not allowing modules to be loaded doesn't protect you in much the same
way as a solid oak door with a 1" deadbolt doesn't make your house
secure.

Security isn't an absolute all-or-nothing thing.

More difficult to exploit == more secure.
Less difficult to exploit == less secure.

Good security design is about making it "more secure".  You don't try
to make it completely secure, because that's impossible(*).  You just make
it more and more secure, until it is secure enough for the expected
threats.

Somebody with a chainsaw, welding torch, and/or lots of explosives can
break into my house, even with my solid oak door.  I don't use this as
an excuse to not bother locking my door.

--- Wade

*Some people think that a computer with no network or power at the
bottom of a well that's been filled with concrete is secure.  I don't
think so, I think that it's just going to take a little digging before
a cracker can break into it.

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Barroso]

* Dariush Pietrzak ([EMAIL PROTECTED]) wrote:
> > One reason is security:
> > it's relatively easy for an intruder to install a kernel module based
> > rootkit, and then hide her processes, files or connections.
> isn't it security-by-obscurity?
> Determined hacker can still relatively easily insert code into kernel 
> (vide phreack magazine articles )

True, but not in a so-automated way and definetively more advanced
skills would be needed. It's not security-by-obscurity at all, it's only
one layer of basic protection.

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Wade Richards]

On Tue, 01 Apr 2003 13:57:10 EST, Phillip Hofmeister writes:
>Assuming an intruder made his way in with root privs couldn't he also
>modify /dev/kmem or directly access the kernel memory by some other
>means?  I beleive this topic has also been discussed in the past (dig
>deep into the archives) and it was concluded that not allowing modules
>to be loaded does not really protect you from your kernel being
>modified at run-time.

Not allowing modules to be loaded doesn't protect you in much the same
way as a solid oak door with a 1" deadbolt doesn't make your house
secure.

Security isn't an absolute all-or-nothing thing.

More difficult to exploit == more secure.
Less difficult to exploit == less secure.

Good security design is about making it "more secure".  You don't try
to make it completely secure, because that's impossible(*).  You just make
it more and more secure, until it is secure enough for the expected
threats.

Somebody with a chainsaw, welding torch, and/or lots of explosives can
break into my house, even with my solid oak door.  I don't use this as
an excuse to not bother locking my door.

--- Wade

*Some people think that a computer with no network or power at the
bottom of a well that's been filled with concrete is secure.  I don't
think so, I think that it's just going to take a little digging before
a cracker can break into it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dariush Pietrzak]

> One reason is security:
> it's relatively easy for an intruder to install a kernel module based
> rootkit, and then hide her processes, files or connections.
isn't it security-by-obscurity?
Determined hacker can still relatively easily insert code into kernel 
(vide phreack magazine articles )

-- 
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294  05E0 BCC7 02C4 75CC 50D9

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Barroso]

* Dariush Pietrzak ([EMAIL PROTECTED]) wrote:
> > One reason is security:
> > it's relatively easy for an intruder to install a kernel module based
> > rootkit, and then hide her processes, files or connections.
> isn't it security-by-obscurity?
> Determined hacker can still relatively easily insert code into kernel 
> (vide phreack magazine articles )

True, but not in a so-automated way and definetively more advanced
skills would be needed. It's not security-by-obscurity at all, it's only
one layer of basic protection.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Phillip Hofmeister]

On Tue, 01 Apr 2003 at 07:49:29PM +0200, David Barroso wrote:
> One reason is security:
> it's relatively easy for an intruder to install a kernel module based
> rootkit, and then hide her processes, files or connections.

Ahh, yea.

Assuming an intruder made his way in with root privs couldn't he also
modify /dev/kmem or directly access the kernel memory by some other
means?  I beleive this topic has also been discussed in the past (dig
deep into the archives) and it was concluded that not allowing modules
to be loaded does not really protect you from your kernel being
modified at run-time.

-- 
Phil

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
--
Excuse #35: Secretary plugged hairdryer into UPS 



pgpYQqJa4hNRZ.pgp
Description: PGP signature

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Ralf Dreibrodt]

Hi,

David Barroso wrote:
> 
> * Marcin Owsiany ([EMAIL PROTECTED]) wrote:
> > On Tue, Apr 01, 2003 at 02:30:17PM +0100, Dale Amon wrote:
> > > On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser 
> > > wrote:
> > > > In a server enviroment, where there no need to load modules at run-time,
> > > > could be a "usable workaorund", but, in a workstation machine, i don't
> > > > think thats a great idea.
> > >
> > > In a server environment it is preferable not to
> > > compile with modules at all.
> >
> > Why?
> 
> One reason is security:
> it's relatively easy for an intruder to install a kernel module based
> rootkit, and then hide her processes, files or connections.

i have an "old" kernel with modules and didn't updated it, because of the 
ptrace bug.

this is the reason why:

www1:~# grep CAP_SYS_MODULE /etc/lids/lids.cap
-16:CAP_SYS_MODULE
www1:~# grep CAP_SYS_PTRACE /etc/lids/lids.cap
-19:CAP_SYS_PTRACE

For fun i tried the exploit, it didn't worked, it needs access to /proc.
I gave that user access to /proc and tried it again.
The user got logged out, i got an email.

Regards,
Ralf Dreibrodt

-- 
MesosTelefon 49 221 4855798-1
Eupener Str. 150 Fax 49 221 4855798-9
50933 Koeln  Mail[EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dariush Pietrzak]

> One reason is security:
> it's relatively easy for an intruder to install a kernel module based
> rootkit, and then hide her processes, files or connections.
isn't it security-by-obscurity?
Determined hacker can still relatively easily insert code into kernel 
(vide phreack magazine articles )

-- 
Dariush Pietrzak,
Key fingerprint = 40D0 9FFB 9939 7320 8294  05E0 BCC7 02C4 75CC 50D9


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-security] Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Christian Hammers]

On Tue, Apr 01, 2003 at 05:46:46PM +0100, David Ramsden wrote:
> I've made sure no no-ptrace module is loaded and I'm sure the kernel hasn't
> been patched. I can "echo '/sbin/modprobe' > /proc/sys/kernel/modprobe" and 
> try the above and I'll get a root prompt first time.

Ok, I have to admit, that I'm unable to reproduce it now. 

Maybe it made an error the first time (I took the screen output and 
URLs in the last mail from an old email from me that I archived).

But it's still the preferable solution as it does not break module
autoloading :-)

bye,

-christian-

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Barroso]

* Marcin Owsiany ([EMAIL PROTECTED]) wrote:
> On Tue, Apr 01, 2003 at 02:30:17PM +0100, Dale Amon wrote:
> > On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser wrote:
> > > In a server enviroment, where there no need to load modules at run-time,
> > > could be a "usable workaorund", but, in a workstation machine, i don't
> > > think thats a great idea.
> > 
> > In a server environment it is preferable not to
> > compile with modules at all.
> 
> Why?

One reason is security:
it's relatively easy for an intruder to install a kernel module based
rootkit, and then hide her processes, files or connections.

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Phillip Hofmeister]

On Tue, 01 Apr 2003 at 07:49:29PM +0200, David Barroso wrote:
> One reason is security:
> it's relatively easy for an intruder to install a kernel module based
> rootkit, and then hide her processes, files or connections.

Ahh, yea.

Assuming an intruder made his way in with root privs couldn't he also
modify /dev/kmem or directly access the kernel memory by some other
means?  I beleive this topic has also been discussed in the past (dig
deep into the archives) and it was concluded that not allowing modules
to be loaded does not really protect you from your kernel being
modified at run-time.

-- 
Phil

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
--
Excuse #35: Secretary plugged hairdryer into UPS 



pgp0.pgp
Description: PGP signature

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Marcin Owsiany]

On Tue, Apr 01, 2003 at 02:30:17PM +0100, Dale Amon wrote:
> On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser wrote:
> > In a server enviroment, where there no need to load modules at run-time,
> > could be a "usable workaorund", but, in a workstation machine, i don't
> > think thats a great idea.
> 
> In a server environment it is preferable not to
> compile with modules at all.

Why?

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Ramsden]

- Original Message -
From: "Christian Hammers" <[EMAIL PROTECTED]>
To: "David Ramsden" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, April 01, 2003 4:48 PM
Subject: Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace
vulnerability in 2.2 and 2.4 kernels]


[snip]
>
> Can it be that you had loaded no-ptrace-module.o or someone patched your
> kernel? See:
>
[snip]

It's the 2.2.20 kernel from Debian (did an apt-get install of the .deb
kernel-image package).
I then did: echo '/this/doesnt/exist' > /proc/sys/kernel/modprobe
And tried what you did Christian. See below:

$ uname -r
2.2.20
$ gcc ptrace-kmod.c -o ptrace-kmod
$ ls -al ptrace-kmod*
-rwxr-xr-x1 scarlet  scarlet  9028 Apr  1 17:40 ptrace-kmod
-rw-r--r--1 scarlet  scarlet  3736 Apr  1 17:37 ptrace-kmod.c
$ id
uid=1007(scarlet) gid=1007(scarlet) groups=1007(scarlet)
$ ./ptrace-kmod
[-] Unable to attach: Operation not permitted
Killed
$ ./ptrace-kmod

$ ./ptrace-kmod
[+] Attached to 25763

$ ./ptrace-kmod
[+] Attached to 25770

$ id
uid=1007(scarlet) gid=1007(scarlet) groups=1007(scarlet)
$ cat /proc/sys/kernel/modprobe
/this/doesnt/exist
$

I've made sure no no-ptrace module is loaded and I'm sure the kernel hasn't
been patched.
I can "echo '/sbin/modprobe' > /proc/sys/kernel/modprobe" and try the above
and I'll get a root prompt first time.

Maybe it doesn't work for the 2.4.x kernel series?
Can anyone else try this maybe and report back :-)

Cheers.
David.

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Ralf Dreibrodt]

Hi,

David Barroso wrote:
> 
> * Marcin Owsiany ([EMAIL PROTECTED]) wrote:
> > On Tue, Apr 01, 2003 at 02:30:17PM +0100, Dale Amon wrote:
> > > On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser wrote:
> > > > In a server enviroment, where there no need to load modules at run-time,
> > > > could be a "usable workaorund", but, in a workstation machine, i don't
> > > > think thats a great idea.
> > >
> > > In a server environment it is preferable not to
> > > compile with modules at all.
> >
> > Why?
> 
> One reason is security:
> it's relatively easy for an intruder to install a kernel module based
> rootkit, and then hide her processes, files or connections.

i have an "old" kernel with modules and didn't updated it, because of the ptrace bug.

this is the reason why:

www1:~# grep CAP_SYS_MODULE /etc/lids/lids.cap
-16:CAP_SYS_MODULE
www1:~# grep CAP_SYS_PTRACE /etc/lids/lids.cap
-19:CAP_SYS_PTRACE

For fun i tried the exploit, it didn't worked, it needs access to /proc.
I gave that user access to /proc and tried it again.
The user got logged out, i got an email.

Regards,
Ralf Dreibrodt

-- 
MesosTelefon 49 221 4855798-1
Eupener Str. 150 Fax 49 221 4855798-9
50933 Koeln  Mail[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-security] Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Christian Hammers]

On Tue, Apr 01, 2003 at 05:46:46PM +0100, David Ramsden wrote:
> I've made sure no no-ptrace module is loaded and I'm sure the kernel hasn't
> been patched. I can "echo '/sbin/modprobe' > /proc/sys/kernel/modprobe" and 
> try the above and I'll get a root prompt first time.

Ok, I have to admit, that I'm unable to reproduce it now. 

Maybe it made an error the first time (I took the screen output and 
URLs in the last mail from an old email from me that I archived).

But it's still the preferable solution as it does not break module
autoloading :-)

bye,

-christian-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Barroso]

* Marcin Owsiany ([EMAIL PROTECTED]) wrote:
> On Tue, Apr 01, 2003 at 02:30:17PM +0100, Dale Amon wrote:
> > On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser wrote:
> > > In a server enviroment, where there no need to load modules at run-time,
> > > could be a "usable workaorund", but, in a workstation machine, i don't
> > > think thats a great idea.
> > 
> > In a server environment it is preferable not to
> > compile with modules at all.
> 
> Why?

One reason is security:
it's relatively easy for an intruder to install a kernel module based
rootkit, and then hide her processes, files or connections.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Christian Hammers]

On Tue, Apr 01, 2003 at 02:40:44PM +0100, David Ramsden wrote:
> > >   echo unexisting_binary > /proc/sys/kernel/modprobe
> > > Can we trust this solution ?
> > NO, it does not prevent the exploit.
> >
> > It does prevent the km3.c example exploit but not e.g.
> >   http://isec.pl/cliph/isec-ptrace-kmod-exploit.c
> 
> I'd have to disagree with you there.
> I've done this to one Debian box (3.0 running 2.2.20) and it does stop the
> above exploit:
> 
> $ echo "/this/doesnt/exist" > /proc/sys/kernel/modprobe
> $ gcc isec-ptrace-kmod-exploit.c -o isec-ptrace-kmod-exploit
> $ ./isec-ptrace-kmod-exploit
> $ [+] Attached to 18765
> (gets stuck here - have to use Ctrl+C)
> $

Can it be that you had loaded no-ptrace-module.o or someone patched your 
kernel? See:

$ uname -r
2.4.19
$ gcc isec-ptrace-kmod-exploit.c -o isec-ptrace-kmod-exploit
In file included from /usr/include/asm/user.h:5,
 from /usr/include/linux/user.h:1,
 from isec-ptrace-kmod-exploit.c:37:
/usr/include/linux/ptrace.h:22: warning: `PTRACE_SYSCALL' redefined
/usr/include/sys/ptrace.h:103: warning: this is the location of the
previous definition

(it's a very old machine, workes fine on others)

$ id
uid=1001(ch) gid=1005(ch) groups=1005(ch)

$ ls -al isec-ptrace-kmod-exploit*
-rwxr-xr-x1 ch   ch   8964 Apr  1 17:46 isec-ptrace-kmod-exploit
-rw-r--r--1 ch   ch   3737 Apr  1 17:45 
isec-ptrace-kmod-exploit.c

$ ./isec-ptrace-kmod-exploit 
[+] Attached to 4660
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4000ecb4
[+] Now wait for suid shell...
sh-2.03# exit
exit

Q.E.D. :-)

bye,

  -christian-

-- 
"That's one small step for man, one giant leap for mankind"
- first words of a human on the moon, Neil Armstrong 1969
"Let's get this motherfucker out of here!"
- last words of a human on the moon, Eugene Cernan 1972

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Marcin Owsiany]

On Tue, Apr 01, 2003 at 02:30:17PM +0100, Dale Amon wrote:
> On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser wrote:
> > In a server enviroment, where there no need to load modules at run-time,
> > could be a "usable workaorund", but, in a workstation machine, i don't
> > think thats a great idea.
> 
> In a server environment it is preferable not to
> compile with modules at all.

Why?

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Ramsden]

- Original Message -
From: "Christian Hammers" <[EMAIL PROTECTED]>
To: "David Ramsden" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, April 01, 2003 4:48 PM
Subject: Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace
vulnerability in 2.2 and 2.4 kernels]


[snip]
>
> Can it be that you had loaded no-ptrace-module.o or someone patched your
> kernel? See:
>
[snip]

It's the 2.2.20 kernel from Debian (did an apt-get install of the .deb
kernel-image package).
I then did: echo '/this/doesnt/exist' > /proc/sys/kernel/modprobe
And tried what you did Christian. See below:

$ uname -r
2.2.20
$ gcc ptrace-kmod.c -o ptrace-kmod
$ ls -al ptrace-kmod*
-rwxr-xr-x1 scarlet  scarlet  9028 Apr  1 17:40 ptrace-kmod
-rw-r--r--1 scarlet  scarlet  3736 Apr  1 17:37 ptrace-kmod.c
$ id
uid=1007(scarlet) gid=1007(scarlet) groups=1007(scarlet)
$ ./ptrace-kmod
[-] Unable to attach: Operation not permitted
Killed
$ ./ptrace-kmod

$ ./ptrace-kmod
[+] Attached to 25763

$ ./ptrace-kmod
[+] Attached to 25770

$ id
uid=1007(scarlet) gid=1007(scarlet) groups=1007(scarlet)
$ cat /proc/sys/kernel/modprobe
/this/doesnt/exist
$

I've made sure no no-ptrace module is loaded and I'm sure the kernel hasn't
been patched.
I can "echo '/sbin/modprobe' > /proc/sys/kernel/modprobe" and try the above
and I'll get a root prompt first time.

Maybe it doesn't work for the 2.4.x kernel series?
Can anyone else try this maybe and report back :-)

Cheers.
David.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dale Amon]

On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser wrote:
> In a server enviroment, where there no need to load modules at run-time,
> could be a "usable workaorund", but, in a workstation machine, i don't
> think thats a great idea.

In a server environment it is preferable not to
compile with modules at all.

-- 
--
   IN MY NAME:Dale Amon, CEO/MD
  No Mushroom clouds over Islandone Society
London and New York.  www.islandone.org
--

Re: [d-security] Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Christian Hammers]

On Tue, Apr 01, 2003 at 02:40:44PM +0100, David Ramsden wrote:
> > >   echo unexisting_binary > /proc/sys/kernel/modprobe
> > > Can we trust this solution ?
> > NO, it does not prevent the exploit.
> >
> > It does prevent the km3.c example exploit but not e.g.
> >   http://isec.pl/cliph/isec-ptrace-kmod-exploit.c
> 
> I'd have to disagree with you there.
> I've done this to one Debian box (3.0 running 2.2.20) and it does stop the
> above exploit:
> 
> $ echo "/this/doesnt/exist" > /proc/sys/kernel/modprobe
> $ gcc isec-ptrace-kmod-exploit.c -o isec-ptrace-kmod-exploit
> $ ./isec-ptrace-kmod-exploit
> $ [+] Attached to 18765
> (gets stuck here - have to use Ctrl+C)
> $

Can it be that you had loaded no-ptrace-module.o or someone patched your 
kernel? See:

$ uname -r
2.4.19
$ gcc isec-ptrace-kmod-exploit.c -o isec-ptrace-kmod-exploit
In file included from /usr/include/asm/user.h:5,
 from /usr/include/linux/user.h:1,
 from isec-ptrace-kmod-exploit.c:37:
/usr/include/linux/ptrace.h:22: warning: `PTRACE_SYSCALL' redefined
/usr/include/sys/ptrace.h:103: warning: this is the location of the
previous definition

(it's a very old machine, workes fine on others)

$ id
uid=1001(ch) gid=1005(ch) groups=1005(ch)

$ ls -al isec-ptrace-kmod-exploit*
-rwxr-xr-x1 ch   ch   8964 Apr  1 17:46 isec-ptrace-kmod-exploit
-rw-r--r--1 ch   ch   3737 Apr  1 17:45 isec-ptrace-kmod-exploit.c

$ ./isec-ptrace-kmod-exploit 
[+] Attached to 4660
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4000ecb4
[+] Now wait for suid shell...
sh-2.03# exit
exit

Q.E.D. :-)

bye,

  -christian-

-- 
"That's one small step for man, one giant leap for mankind"
- first words of a human on the moon, Neil Armstrong 1969
"Let's get this motherfucker out of here!"
- last words of a human on the moon, Eugene Cernan 1972


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Ramsden]

- Original Message -
From: "Christian Hammers" <[EMAIL PROTECTED]>
To: "Marc Demlenne" <[EMAIL PROTECTED]>
Cc: "DouRiX" <[EMAIL PROTECTED]>; "Lutz Kittler"
<[EMAIL PROTECTED]>; 
Sent: Tuesday, April 01, 2003 2:04 PM
Subject: Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and
2.4 kernels]


[snip]
> >
> > What's the real effect of modifying /proc/sys/kernel/modprobe by, e.g.
> >   echo unexisting_binary > /proc/sys/kernel/modprobe
> >
> > Can we trust this solution ?
>
> NO, it does not prevent the exploit.
>
> It does prevent the km3.c example exploit but not e.g.
>   http://isec.pl/cliph/isec-ptrace-kmod-exploit.c
>

I'd have to disagree with you there.
I've done this to one Debian box (3.0 running 2.2.20) and it does stop the
above exploit:

$ echo "/this/doesnt/exist" > /proc/sys/kernel/modprobe
$ gcc isec-ptrace-kmod-exploit.c -o isec-ptrace-kmod-exploit
$ ./isec-ptrace-kmod-exploit
$ [+] Attached to 18765
(gets stuck here - have to use Ctrl+C)
$


> You have to patch the kernel or load and compile the following module:
>   http://www.securiteam.com/tools/5SP082K5GK.html (no-ptrace-module.c)
>
The above is probably the better solution.
But you can't beat patching the kernel, if it'll work - When are Debian
going to release a DSA on this? :)

I'm running 2.2.19 from when I upgraded from 2.2r2 and can't apt-get the
kernel-source-2.2.19 and same for 2.2.20. Most annoying. I don't want to
upgrade to 2.4.x yet.
If I could get the source for 2.2.19 or 2.2.20 from Debian then I could copy
the configuration file from /boot as .config and then just apply the kernel
patch and "make oldconfig" without having to re-do the config again.
Downloading the source from kernel.org and trying to use the config in /boot
has 'new features' and things.
(I'm not too confident at compiling the kernel and the default Debian one is
fine!).

Regards,
David.
--
David Ramsden
http://portal.hexstream.eu.org/

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Maurizio Lemmo - Tannoiser]

On martedì 01 aprile 2003, alle 14:20, DouRiX wrote:
> but isn't there a trick to surpass the bug while waiting for debian 
> updates ?

Actually, yes.

But i'm not really sure if it's a "good" workaorund. Anyway:

if you disable automatic loading module (a kernel feature), you may
ignore this vulnerability.

You may do this with:

echo "whatever" > /proc/sys/kernel/modprobe

So, whenever some automatism invoke this, produce an error.
Unfortunately, you may not discriminate what process can do this
safetely and wich not.

In a server enviroment, where there no need to load modules at run-time,
could be a "usable workaorund", but, in a workstation machine, i don't
think thats a great idea.

So, its prefereable, to get the patch and recompile the kernel, or take
the 2.4.20-patched kernel in proposed update.

my 0.2 cents.

> or won't be there a 2.4.18 update ? :)

I never seen a "kernel update", you may install different copy of them.

I suppose that will not be upgraded for this reason, and when will be
available the 2.4.20 (when it will be well tested) simply you could
install it.

meanwhile... (this is why i backported the patch. i like stable thinks.
2.4.18 run great for me. i'm not hurry for the new-verynew-release).

forgive my english.

-- 
Buffy: "Is this a get-in-my-pants thing? You guys in Sunnydale talk 
   like I'm the second coming."
--Buffy the Vampire Slayer: The Wish

Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Christian Hammers]

On Tue, Apr 01, 2003 at 02:06:12PM +0200, Marc Demlenne wrote:
> > but isn't there a trick to surpass the bug while waiting for debian 
> > updates ?
> 
> What's the real effect of modifying /proc/sys/kernel/modprobe by, e.g.
>   echo unexisting_binary > /proc/sys/kernel/modprobe
> 
> Can we trust this solution ?

NO, it does not prevent the exploit. 

It does prevent the km3.c example exploit but not e.g. 
  http://isec.pl/cliph/isec-ptrace-kmod-exploit.c

You have to patch the kernel or load and compile the following module:
  http://www.securiteam.com/tools/5SP082K5GK.html (no-ptrace-module.c)

bye,

-christian-

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Dale Amon]

On Tue, Apr 01, 2003 at 03:36:15PM +0200, Maurizio Lemmo - Tannoiser wrote:
> In a server enviroment, where there no need to load modules at run-time,
> could be a "usable workaorund", but, in a workstation machine, i don't
> think thats a great idea.

In a server environment it is preferable not to
compile with modules at all.

-- 
--
   IN MY NAME:Dale Amon, CEO/MD
  No Mushroom clouds over Islandone Society
London and New York.  www.islandone.org
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Rolf Kutz]

* Quoting Marc Demlenne ([EMAIL PROTECTED]):

>   echo unexisting_binary > /proc/sys/kernel/modprobe
> 
> Can we trust this solution ?
> What's the effect ?

You can't dynamically load and unload modules
anymore. If you load all the modules you need
before doing it, you're fine.

> It seems to work fine, and to block the exploit on my box.
> But i don't know the effect on the system, since i guess this file has a
> good reason to be present on a debian box ... 
> So is it a good idea to modify it this way ?

Untill you installed a patched kernel, yes, if you
don't need to dynamically (un)loaded modules.

- rk

-- 
http://www.stop1984.com/

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Lutz Kittler]

>
> but isn't there a trick to surpass the bug while waiting for debian
> updates ?
>
> or won't be there a 2.4.18 update ? :)
>

You can disable autoloading for kernel modules:
echo "x" > /proc/sys/kernel/modprobe .

 lutz

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Marc Demlenne]

> but isn't there a trick to surpass the bug while waiting for debian 
> updates ?

What's the real effect of modifying /proc/sys/kernel/modprobe by, e.g.
  
  echo unexisting_binary > /proc/sys/kernel/modprobe

Can we trust this solution ?
What's the effect ?

It seems to work fine, and to block the exploit on my box.
But i don't know the effect on the system, since i guess this file has a
good reason to be present on a debian box ... 
So is it a good idea to modify it this way ?

Thanx.

-- 
   __o   
 _`\<,_  Marc Demlenne   Public Key on www.keyserver.net
(_)/ (_) GPG/768FA483 BFD8 E61B 180C 3E7A 3435  D393 B605 9979 768F A483

Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[David Ramsden]

- Original Message -
From: "Christian Hammers" <[EMAIL PROTECTED]>
To: "Marc Demlenne" <[EMAIL PROTECTED]>
Cc: "DouRiX" <[EMAIL PROTECTED]>; "Lutz Kittler"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, April 01, 2003 2:04 PM
Subject: Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and
2.4 kernels]


[snip]
> >
> > What's the real effect of modifying /proc/sys/kernel/modprobe by, e.g.
> >   echo unexisting_binary > /proc/sys/kernel/modprobe
> >
> > Can we trust this solution ?
>
> NO, it does not prevent the exploit.
>
> It does prevent the km3.c example exploit but not e.g.
>   http://isec.pl/cliph/isec-ptrace-kmod-exploit.c
>

I'd have to disagree with you there.
I've done this to one Debian box (3.0 running 2.2.20) and it does stop the
above exploit:

$ echo "/this/doesnt/exist" > /proc/sys/kernel/modprobe
$ gcc isec-ptrace-kmod-exploit.c -o isec-ptrace-kmod-exploit
$ ./isec-ptrace-kmod-exploit
$ [+] Attached to 18765
(gets stuck here - have to use Ctrl+C)
$


> You have to patch the kernel or load and compile the following module:
>   http://www.securiteam.com/tools/5SP082K5GK.html (no-ptrace-module.c)
>
The above is probably the better solution.
But you can't beat patching the kernel, if it'll work - When are Debian
going to release a DSA on this? :)

I'm running 2.2.19 from when I upgraded from 2.2r2 and can't apt-get the
kernel-source-2.2.19 and same for 2.2.20. Most annoying. I don't want to
upgrade to 2.4.x yet.
If I could get the source for 2.2.19 or 2.2.20 from Debian then I could copy
the configuration file from /boot as .config and then just apply the kernel
patch and "make oldconfig" without having to re-do the config again.
Downloading the source from kernel.org and trying to use the config in /boot
has 'new features' and things.
(I'm not too confident at compiling the kernel and the default Debian one is
fine!).

Regards,
David.
--
David Ramsden
http://portal.hexstream.eu.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Maurizio Lemmo - Tannoiser]

On martedì 01 aprile 2003, alle 14:20, DouRiX wrote:
> but isn't there a trick to surpass the bug while waiting for debian 
> updates ?

Actually, yes.

But i'm not really sure if it's a "good" workaorund. Anyway:

if you disable automatic loading module (a kernel feature), you may
ignore this vulnerability.

You may do this with:

echo "whatever" > /proc/sys/kernel/modprobe

So, whenever some automatism invoke this, produce an error.
Unfortunately, you may not discriminate what process can do this
safetely and wich not.

In a server enviroment, where there no need to load modules at run-time,
could be a "usable workaorund", but, in a workstation machine, i don't
think thats a great idea.

So, its prefereable, to get the patch and recompile the kernel, or take
the 2.4.20-patched kernel in proposed update.

my 0.2 cents.

> or won't be there a 2.4.18 update ? :)

I never seen a "kernel update", you may install different copy of them.

I suppose that will not be upgraded for this reason, and when will be
available the 2.4.20 (when it will be well tested) simply you could
install it.

meanwhile... (this is why i backported the patch. i like stable thinks.
2.4.18 run great for me. i'm not hurry for the new-verynew-release).

forgive my english.

-- 
Buffy: "Is this a get-in-my-pants thing? You guys in Sunnydale talk 
   like I'm the second coming."
--Buffy the Vampire Slayer: The Wish


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[DouRiX]

Maurizio Lemmo - Tannoiser wrote:

On lunedì 31 marzo 2003, alle 16:02, DouRiX wrote:


Does someone know where is debian about this issue ?





i've noticed that there kernel 2.4.20 with ptrace patch included, in
proposed-update.

For my puorpose, i've backported that patch, for work with kernel 2.4.18
(from debian).

works for me.

patch with:

cd /path/to/source
patch -p1 < /path/to/patch

you may find it here:

http://erlug.linux.it/~tann/pkg/linux-2.4.18-ptrace-tann.patch

(there also a kernel image bf2.4 with patch incorporated, if you trust
me.. :) )


thanks,

but isn't there a trick to surpass the bug while waiting for debian 
updates ?


or won't be there a 2.4.18 update ? :)

@+
--
DouRiX
["Advertising copy. Where sentences are replaced by participle phrases.
  Noun phrases. And dangling conjunctions. Bleah." -- K]

Re: [d-security] Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Christian Hammers]

On Tue, Apr 01, 2003 at 02:06:12PM +0200, Marc Demlenne wrote:
> > but isn't there a trick to surpass the bug while waiting for debian 
> > updates ?
> 
> What's the real effect of modifying /proc/sys/kernel/modprobe by, e.g.
>   echo unexisting_binary > /proc/sys/kernel/modprobe
> 
> Can we trust this solution ?

NO, it does not prevent the exploit. 

It does prevent the km3.c example exploit but not e.g. 
  http://isec.pl/cliph/isec-ptrace-kmod-exploit.c

You have to patch the kernel or load and compile the following module:
  http://www.securiteam.com/tools/5SP082K5GK.html (no-ptrace-module.c)

bye,

-christian-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Rolf Kutz]

* Quoting Marc Demlenne ([EMAIL PROTECTED]):

>   echo unexisting_binary > /proc/sys/kernel/modprobe
> 
> Can we trust this solution ?
> What's the effect ?

You can't dynamically load and unload modules
anymore. If you load all the modules you need
before doing it, you're fine.

> It seems to work fine, and to block the exploit on my box.
> But i don't know the effect on the system, since i guess this file has a
> good reason to be present on a debian box ... 
> So is it a good idea to modify it this way ?

Untill you installed a patched kernel, yes, if you
don't need to dynamically (un)loaded modules.

- rk

-- 
http://www.stop1984.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Lutz Kittler]

>
> but isn't there a trick to surpass the bug while waiting for debian
> updates ?
>
> or won't be there a 2.4.18 update ? :)
>

You can disable autoloading for kernel modules:
echo "x" > /proc/sys/kernel/modprobe .

 lutz




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Marc Demlenne]

> but isn't there a trick to surpass the bug while waiting for debian 
> updates ?

What's the real effect of modifying /proc/sys/kernel/modprobe by, e.g.
  
  echo unexisting_binary > /proc/sys/kernel/modprobe

Can we trust this solution ?
What's the effect ?

It seems to work fine, and to block the exploit on my box.
But i don't know the effect on the system, since i guess this file has a
good reason to be present on a debian box ... 
So is it a good idea to modify it this way ?

Thanx.

-- 
   __o   
 _`\<,_  Marc Demlenne   Public Key on www.keyserver.net
(_)/ (_) GPG/768FA483 BFD8 E61B 180C 3E7A 3435  D393 B605 9979 768F A483


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[DouRiX]

Maurizio Lemmo - Tannoiser wrote:
On lunedì 31 marzo 2003, alle 16:02, DouRiX wrote:

Does someone know where is debian about this issue ?




i've noticed that there kernel 2.4.20 with ptrace patch included, in
proposed-update.
For my puorpose, i've backported that patch, for work with kernel 2.4.18
(from debian).
works for me.

patch with:

cd /path/to/source
patch -p1 < /path/to/patch
you may find it here:

http://erlug.linux.it/~tann/pkg/linux-2.4.18-ptrace-tann.patch

(there also a kernel image bf2.4 with patch incorporated, if you trust
me.. :) )
thanks,

but isn't there a trick to surpass the bug while waiting for debian 
updates ?

or won't be there a 2.4.18 update ? :)

@+
--
DouRiX
["Advertising copy. Where sentences are replaced by participle phrases.
  Noun phrases. And dangling conjunctions. Bleah." -- K]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Maurizio Lemmo - Tannoiser]

On lunedì 31 marzo 2003, alle 16:02, DouRiX wrote:
> Does someone know where is debian about this issue ?
> 
> 

i've noticed that there kernel 2.4.20 with ptrace patch included, in
proposed-update.

For my puorpose, i've backported that patch, for work with kernel 2.4.18
(from debian).

works for me.

patch with:

cd /path/to/source
patch -p1 < /path/to/patch

you may find it here:

http://erlug.linux.it/~tann/pkg/linux-2.4.18-ptrace-tann.patch

(there also a kernel image bf2.4 with patch incorporated, if you trust
me.. :) )

-- 
Master: "You killed the girl that sought the Slayer?"
Xander: "It was too easy."
Willow: "I felt cheap."
--Buffy the Vampire Slayer: The Wish

[Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[DouRiX]

Hi everybody,

Does someone know where is debian about this issue ?



I see that there is already an update but only for mips 
(http://www.debian.org/security/2003/dsa-270), do you know why ?


Thanks in advance,

--
DouRiX
 ["Don't fear, Just play the game ..." -- ]

Re: [Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[Maurizio Lemmo - Tannoiser]

On lunedì 31 marzo 2003, alle 16:02, DouRiX wrote:
> Does someone know where is debian about this issue ?
> 
> 

i've noticed that there kernel 2.4.20 with ptrace patch included, in
proposed-update.

For my puorpose, i've backported that patch, for work with kernel 2.4.18
(from debian).

works for me.

patch with:

cd /path/to/source
patch -p1 < /path/to/patch

you may find it here:

http://erlug.linux.it/~tann/pkg/linux-2.4.18-ptrace-tann.patch

(there also a kernel image bf2.4 with patch incorporated, if you trust
me.. :) )

-- 
Master: "You killed the girl that sought the Slayer?"
Xander: "It was too easy."
Willow: "I felt cheap."
--Buffy the Vampire Slayer: The Wish


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Fwd: Re: LWN: Ptrace vulnerability in 2.2 and 2.4 kernels]

[DouRiX]

Hi everybody,

Does someone know where is debian about this issue ?



I see that there is already an update but only for mips 
(http://www.debian.org/security/2003/dsa-270), do you know why ?

Thanks in advance,

--
DouRiX
 ["Don't fear, Just play the game ..." -- ]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]