[RFC] prevention of syscalls from writable segments, breaking bug exploits

[RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Aloni]

It is known that most remote exploits use the fact that stacks are
executable (in i386, at least).

On Linux, they use INT 80 system calls to execute functions in the kernel
as root, when the stack is smashed as a result of a buffer overflow bug in
various server software.

This preliminary, small patch prevents execution of system calls which
were executed from a writable segment. It was tested and seems to work,
without breaking anything. It also reports of such calls by using printk.


--- linux/arch/i386/kernel/entry.S	Tue Dec 12 20:04:08 2000
+++ linux/arch/i386/kernel/entry.S	Wed Jan  3 22:46:24 2001
@@ -78,8 +78,16 @@
 exec_domain	= 16
 need_resched	= 20
 tsk_ptrace	= 24
+tsk_mm		= 44
 processor	= 52
 
+/*
+ * these are offsets into vm_area_struct
+ */
+
+vmas_flags	= 20
+
+
 ENOSYS = 38
 
 
@@ -196,6 +204,26 @@
 	pushl %eax			# save orig_eax
 	SAVE_ALL
 	GET_CURRENT(%ebx)
+
+	/* only execute code from non-writable segments */
+	pushl %ebx
+	pushl %eax
+	movl tsk_mm(%ebx),%eax		# get current->mm
+	movl (EIP+8)(%esp),%ebx		# get caller EIP
+	pushl %ebx
+	pushl %eax
+	call find_vma
+	addl $8,%esp
+	testl %eax,%eax
+	je no_vm_area
+	movl vmas_flags(%eax), %ebx
+	andl $0x02, %ebx
+	cmpl $0x02, %ebx
+	je sys_from_wrong_mem
+no_vm_area:
+	popl %eax
+	popl %ebx
+	
 	cmpl $(NR_syscalls),%eax
 	jae badsys
 	testb $0x02,tsk_ptrace(%ebx)	# PT_TRACESYS
@@ -252,6 +280,15 @@
 tracesys_exit:
 	call SYMBOL_NAME(syscall_trace)
 	jmp ret_from_sys_call
+
+sys_from_wrong_mem:
+	GET_CURRENT(%ebx)
+	push %ebx
+	call print_bad_syscall
+	addl $4,%esp	
+	
+	popl %eax
+	popl %ebx
 badsys:
 	movl $-ENOSYS,EAX(%esp)
 	jmp ret_from_sys_call
--- linux/arch/i386/kernel/process.c	Wed Jan  3 22:57:42 2001
+++ linux/arch/i386/kernel/process.c	Wed Jan  3 22:57:55 2001
@@ -765,3 +765,8 @@
 }
 #undef last_sched
 #undef first_sched
+
+void print_bad_syscall(struct task_struct *task)
+{
+	printk("process %s (%d) tried to syscall from an executable segment!\n", task->comm, task->pid);
+}


-- 
Dan Aloni 
dax@karrde.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Aloni]

On Wed, 3 Jan 2001, Dan Aloni wrote:

> +
> +void print_bad_syscall(struct task_struct *task)
> +{
> +	printk("process %s (%d) tried to syscall from an executable segment!\n", task->comm, task->pid);
> +}

Hmm, should be "writable segment", perhaps ;-)

-- 
Dan Aloni 
dax@karrde.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bugexploits

[Brian Gerst]

Dan Aloni wrote:
> 
> It is known that most remote exploits use the fact that stacks are
> executable (in i386, at least).
> 
> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buffer overflow bug in
> various server software.
> 
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to work,
> without breaking anything. It also reports of such calls by using printk.

Do you realise how much overhead you just added to every single
syscall?  It won't work anyways, for the same reasons every other
non-exec stack patch has been rejected - exploits exist that don't write
any code to the stack, you just need two pointers.

--

				Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Alexander Viro]

On Wed, 3 Jan 2001, Dan Aloni wrote:

> It is known that most remote exploits use the fact that stacks are
> executable (in i386, at least).
> 
> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buffer overflow bug in
> various server software.
> 
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to work,
> without breaking anything. It also reports of such calls by using printk.

Get real. Attacker can set whatever registers he needs and jump to one
of the many instances of int 0x80 in libc. There goes your protection.

Win: 0
Loss: cost of find_vma() (and down(&mm->mmap_sem), BTW) on every system
call.

And the reason to apply that patch would be...?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Erik Mouw]

On Wed, Jan 03, 2001 at 11:13:31PM +0200, Dan Aloni wrote:
> It is known that most remote exploits use the fact that stacks are
> executable (in i386, at least).
> 
> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buffer overflow bug in
> various server software.
> 
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to work,
> without breaking anything. It also reports of such calls by using printk.

Cool.

> --- linux/arch/i386/kernel/process.c	Wed Jan  3 22:57:42 2001
> +++ linux/arch/i386/kernel/process.c	Wed Jan  3 22:57:55 2001
> @@ -765,3 +765,8 @@
>  }
>  #undef last_sched
>  #undef first_sched
> +
> +void print_bad_syscall(struct task_struct *task)
> +{
> +	printk("process %s (%d) tried to syscall from an executable segment!\n", task->comm, task->pid);
                                                         ^^^^^^^^^^
I suppose this should read "writable"...

> +}


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Aloni]

On Wed, 3 Jan 2001, Alexander Viro wrote:

> > This preliminary, small patch prevents execution of system calls which
> > were executed from a writable segment. It was tested and seems to work,
> > without breaking anything. It also reports of such calls by using printk.
> 
> Get real. Attacker can set whatever registers he needs and jump to one
> of the many instances of int 0x80 in libc. There goes your protection.

But unlike syscalls, offsets inside libc do change. Aren't they?
Programs don't have to use libc, they can be compiled as static.

-- 
Dan Aloni 
dax@karrde.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Steven Walter]

On Wed, Jan 03, 2001 at 04:54:38PM -0500, Alexander Viro wrote:
> On Wed, 3 Jan 2001, Dan Aloni wrote:
> 
> > It is known that most remote exploits use the fact that stacks are
> > executable (in i386, at least).
> > 
> > On Linux, they use INT 80 system calls to execute functions in the kernel
> > as root, when the stack is smashed as a result of a buffer overflow bug in
> > various server software.
> > 
> > This preliminary, small patch prevents execution of system calls which
> > were executed from a writable segment. It was tested and seems to work,
> > without breaking anything. It also reports of such calls by using printk.
> 
> Get real. Attacker can set whatever registers he needs and jump to one
> of the many instances of int 0x80 in libc. There goes your protection.
> 
> Win: 0
> Loss: cost of find_vma() (and down(&mm->mmap_sem), BTW) on every system
> call.
> 
> And the reason to apply that patch would be...?

Should be a moot point, anyway, as x86 has a seperate stack for each
priviledge level.  Even if the kernel somehow tried to execute code in a
lower priviledge segment (stack or otherwise) shouldn't a GPF get
generated?
-- 
-Steven
"Voters decide nothing.  Vote counters decide everything."
				-Joseph Stalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Hollis]

On Wed, 3 Jan 2001, Alexander Viro wrote:
> On Wed, 3 Jan 2001, Dan Aloni wrote:
> > without breaking anything. It also reports of such calls by using printk.
> Get real.

Why do you always have to be insulting alex? Sheesh.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Doug McNaught]

Dan Hollis <goemon@anime.net> writes:

> On Wed, 3 Jan 2001, Alexander Viro wrote:
> > On Wed, 3 Jan 2001, Dan Aloni wrote:
> > > without breaking anything. It also reports of such calls by using printk.
> > Get real.
> 
> Why do you always have to be insulting alex? Sheesh.

I was thinking it's about time this flamewar^Wthread came up again.
Shall we start a pool on total # of messages, first invocation of
Godwin's law, etc?

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Nicolas Noble]

On Wed, 3 Jan 2001, Dan Aloni wrote:

> 
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to work,
> without breaking anything. It also reports of such calls by using printk.
> 

Hum,

Allow-me to give you this URL where you will be able to find a more
complete patch to do the very same thing. I don't tell you this will work
as you need but I think this is a good reason to abandon your project
since this patch really do the same (and adds others security features to
the kernel)

Here: http://www.openwall.com/linux/

Best regards.

  -- Nicolas Noble


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Alexander Viro]

On Thu, 4 Jan 2001, Dan Aloni wrote:

> On Wed, 3 Jan 2001, Alexander Viro wrote:
> 
> > > This preliminary, small patch prevents execution of system calls which
> > > were executed from a writable segment. It was tested and seems to work,
> > > without breaking anything. It also reports of such calls by using printk.
> > 
> > Get real. Attacker can set whatever registers he needs and jump to one
> > of the many instances of int 0x80 in libc. There goes your protection.
> 
> But unlike syscalls, offsets inside libc do change. Aren't they?
> Programs don't have to use libc, they can be compiled as static.

Yes. And they will exit without system calls... how, exactly? Dumping core?
Libc or not, you _will_ have 0xcd 0x80 that can be executed. It's not like
searching for these two bytes was a problem, after all - several instructions
is all it takes.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Pavel Machek]

Hi!

> It is known that most remote exploits use the fact that stacks are
> executable (in i386, at least).
> 
> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buffer overflow bug in
> various server software.
> 
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to work,
> without breaking anything. It also reports of such calls by using
> printk.

Haha.

So exploit needs to call libc function to do dirty work for it. Not so
big deal.

Okay, it might do a trick and deter script kiddies; still it is even
weaker then non-executable stack patches.

								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Alexander Viro]

On Wed, 3 Jan 2001, Dan Hollis wrote:

> On Wed, 3 Jan 2001, Alexander Viro wrote:
> > On Wed, 3 Jan 2001, Dan Aloni wrote:
> > > without breaking anything. It also reports of such calls by using printk.
> > Get real.
> 
> Why do you always have to be insulting alex? Sheesh.

Sigh... Not intended to be an insult. Plain and simple advice. Idea is
broken for absolutely obvious reasons (namely, every real-life program
contains at least one syscall that it _can_ execute). Expecting _any_
part of userland to be rewritten into the form that would not have
such places (i.e. all IO is done by trusted processes that poll
memory areas shared with the programs needing said IO, exit is done
either by explicit kill() from another process or by dumping core, signals
are done by putting request into shared area and letting a trusted process
do the thing, etc.) warrants such suggestion, doesn't it? If somebody
seriously believes that it can be done (and that's the only way how this
patch could give any protection)... Well, scratch "get real", I've got a
nice bridge for sale.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Mark Zealey]

On Wed, 3 Jan 2001, Alexander Viro wrote:

> 
> 
> On Wed, 3 Jan 2001, Dan Hollis wrote:
> 
> > On Wed, 3 Jan 2001, Alexander Viro wrote:
> > > On Wed, 3 Jan 2001, Dan Aloni wrote:
> > > > without breaking anything. It also reports of such calls by using printk.
> > > Get real.
> > 
> > Why do you always have to be insulting alex? Sheesh.
> 
> Sigh... Not intended to be an insult. Plain and simple advice. Idea is
> broken for absolutely obvious reasons (namely, every real-life program

This doesnt stop syscalls, only syscalls from writable areas.

> contains at least one syscall that it _can_ execute). Expecting _any_
> part of userland to be rewritten into the form that would not have
> such places (i.e. all IO is done by trusted processes that poll
> memory areas shared with the programs needing said IO, exit is done
> either by explicit kill() from another process or by dumping core, signals
> are done by putting request into shared area and letting a trusted process
> do the thing, etc.) warrants such suggestion, doesn't it? If somebody
> seriously believes that it can be done (and that's the only way how this
> patch could give any protection)... Well, scratch "get real", I've got a
> nice bridge for sale.

That's a bit OTT, no? ;)

> 
> 
> 

-- 

Mark Zealey (aka JALH on irc.openprojects.net: #zealos and many more)
mark@itsolve.co.uk
mark@sexygeek.org
mark@x-paste.de

UL++++$ (GCM/GCS/GS/GM)GUG! dpu? s-:-@ a15! C+++>$ P++$>+++@ L+++>+++++$
!E---? W+++>$ N++@>+ o->+ w--- !M--? !V--? PS- PE--@ !PGP----? r++
!t---?@ !X---? !R- b+ !DI---? e->+++++ h+++*! y-

(www.geekcode.com)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Aloni]

On Wed, 3 Jan 2001, Alexander Viro wrote:

> > > > without breaking anything. It also reports of such calls by using printk.
> > > Get real.
> > 
> > Why do you always have to be insulting alex? Sheesh.
> 
> Sigh... Not intended to be an insult. Plain and simple advice. Idea is
[..]

Did you notice that question was ambiguous? I understood that sentence in
its other meaning, i.e, someone insulting Alex ;-)

Anyway, while it is agreed that you can't completely eliminate exploits,
it is recommended that, it should be at least harder to create them, maybe
it can even minimize the will to write them.

-- 
Dan Aloni 
dax@karrde.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Alexander Viro]

On Wed, 3 Jan 2001, Mark Zealey wrote:

> On Wed, 3 Jan 2001, Alexander Viro wrote:
> 
> > 
> > 
> > On Wed, 3 Jan 2001, Dan Hollis wrote:
> > 
> > > On Wed, 3 Jan 2001, Alexander Viro wrote:
> > > > On Wed, 3 Jan 2001, Dan Aloni wrote:
> > > > > without breaking anything. It also reports of such calls by using printk.
> > > > Get real.
> > > 
> > > Why do you always have to be insulting alex? Sheesh.
> > 
> > Sigh... Not intended to be an insult. Plain and simple advice. Idea is
> > broken for absolutely obvious reasons (namely, every real-life program
> 
> This doesnt stop syscalls, only syscalls from writable areas.

And? Syscall is a couple of bytes. 0xcd and 0x80. Find one in non-writable
area, put whatever you want into registers and jump to the address where
these two bytes sit. Voila. If all such places are in writable areas -
there you go, the process you've attacked could not perform any
system calls itself.

Come on, folks, you can't be serious - think for a couple of minutes and
you'll come up with a trivial way to work around such protection. In a
dozen bytes or so.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Mark Zealey]

On Wed, 3 Jan 2001, Alexander Viro wrote:

> 
> 
> On Wed, 3 Jan 2001, Mark Zealey wrote:
> 
> > On Wed, 3 Jan 2001, Alexander Viro wrote:
> > 
> > > 
> > > 
> > > On Wed, 3 Jan 2001, Dan Hollis wrote:
> > > 
> > > > On Wed, 3 Jan 2001, Alexander Viro wrote:
> > > > > On Wed, 3 Jan 2001, Dan Aloni wrote:
> > > > > > without breaking anything. It also reports of such calls by using printk.
> > > > > Get real.
> > > > 
> > > > Why do you always have to be insulting alex? Sheesh.
> > > 
> > > Sigh... Not intended to be an insult. Plain and simple advice. Idea is
> > > broken for absolutely obvious reasons (namely, every real-life program
> > 
> > This doesnt stop syscalls, only syscalls from writable areas.
> 
> And? Syscall is a couple of bytes. 0xcd and 0x80. Find one in non-writable
> area, put whatever you want into registers and jump to the address where
> these two bytes sit. Voila. If all such places are in writable areas -
> there you go, the process you've attacked could not perform any
> system calls itself.

And the ret and other stuff, you now have to search thru memory for a
10-byte sequance (sya?) to do the correct thing, what are the chances of
finding that, never mind coding all the stuff to find that into a faked
packet or whatever, this is gonna make the r00ter's life (do they have
one? ;) a lot harder, plus it will take a while to make a solution that
works.

> 
> Come on, folks, you can't be serious - think for a couple of minutes and
> you'll come up with a trivial way to work around such protection. In a
> dozen bytes or so.
> 
> 
> 

-- 

Mark Zealey (aka JALH on irc.openprojects.net: #zealos and many more)
mark@itsolve.co.uk
mark@sexygeek.org
mark@x-paste.de

UL++++$ (GCM/GCS/GS/GM)GUG! dpu? s-:-@ a15! C+++>$ P++$>+++@ L+++>+++++$
!E---? W+++>$ N++@>+ o->+ w--- !M--? !V--? PS- PE--@ !PGP----? r++
!t---?@ !X---? !R- b+ !DI---? e->+++++ h+++*! y-

(www.geekcode.com)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug

[Alan Cox]

> On Linux, they use INT 80 system calls to execute functions in the kernel
> as root, when the stack is smashed as a result of a buffer overflow bug in
> various server software.
> 
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to work,
> without breaking anything. It also reports of such calls by using printk.

And I swap the int80 for a jmp to an int80 at a predictable location in ld.so

If you are going to do stack tricks then look at Solar Designers patches, he
has at least worked through the issues and even thought about using null bytes
in jump targets for libraries to stop some operations (string stuff)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Alexander Viro]

On Thu, 4 Jan 2001, Dan Aloni wrote:

> Did you notice that question was ambiguous? I understood that sentence in
> its other meaning, i.e, someone insulting Alex ;-)

<choke><sputter> Well, _that_ definitely takes more than posting a patch ;-)

> Anyway, while it is agreed that you can't completely eliminate exploits,
> it is recommended that, it should be at least harder to create them, maybe
> it can even minimize the will to write them.

<shrug> large overhead to every syscall and protection that can be defeated
in a couple of instructions. Doesn't look like a good tradeoff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Jeff Dike]

karrde@callisto.yi.org said:
> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment. It was tested and seems to
> work, without breaking anything. It also reports of such calls by
> using printk.

Have you tried running UML on this kernel?

				Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Hollis]

On Thu, 4 Jan 2001, Dan Aloni wrote:
> Anyway, while it is agreed that you can't completely eliminate exploits,
> it is recommended that, it should be at least harder to create them, maybe
> it can even minimize the will to write them.

The argument against these sort of protection mechanisms seems to be "well
its not perfect, so we shouldnt have it at all".

Lets use that argument against uid/gid then. Since it's impossible to
protect against exploits, let's dispose of uid/gid entirely and run
everything as root ;-)

"stack guarding is a false sense of security". Well, so is ipchains, so
lets discard that as well...?

Really, these arguments cut both ways. If you are going to argue against
something because it's not perfect, you should be aware that you're
arguing against other kernel protection mechanisms also.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Gerhard Mack]

On Thu, 4 Jan 2001, Dan Aloni wrote:

> On Wed, 3 Jan 2001, Alexander Viro wrote:
> 
> > > > > without breaking anything. It also reports of such calls by using printk.
> > > > Get real.
> > > 
> > > Why do you always have to be insulting alex? Sheesh.
> > 
> > Sigh... Not intended to be an insult. Plain and simple advice. Idea is
> [..]
> 
> Did you notice that question was ambiguous? I understood that sentence in
> its other meaning, i.e, someone insulting Alex ;-)
> 
> Anyway, while it is agreed that you can't completely eliminate exploits,
> it is recommended that, it should be at least harder to create them, maybe
> it can even minimize the will to write them.
> 
> -- 
> Dan Aloni 
> dax@karrde.org
> 

You are much better off working on ways to reduce the number of processes
that need to be root..

As for these protections my system emails me when a process overflows it's
buffers,  But that's not a kernel function. ;) 

	Gerhard


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Nicolas Noble]

Excuse-me but, am I wrong or is this thread completely useless?

Since Alan Cox and I said that Solar Design has done a complete patch to
do the same, and since this patch is alvailble to everybody at
http://www.openwall.com in that way that everybody can download it and
have the choice to install it or not, do we still need to discuss over a
way to include a similar patch into the kernel?

Regards,

  -- Nicolas Noble

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Gerhard Mack]

On Wed, 3 Jan 2001, Dan Hollis wrote:

> On Thu, 4 Jan 2001, Dan Aloni wrote:
> > Anyway, while it is agreed that you can't completely eliminate exploits,
> > it is recommended that, it should be at least harder to create them, maybe
> > it can even minimize the will to write them.
> 
> The argument against these sort of protection mechanisms seems to be "well
> its not perfect, so we shouldnt have it at all".
> 
> Lets use that argument against uid/gid then. Since it's impossible to
> protect against exploits, let's dispose of uid/gid entirely and run
> everything as root ;-)
> 
> "stack guarding is a false sense of security". Well, so is ipchains, so
> lets discard that as well...?
> 
> Really, these arguments cut both ways. If you are going to argue against
> something because it's not perfect, you should be aware that you're
> arguing against other kernel protection mechanisms also.
> 

Your comparing actual security with stack guarding? Stack guarding mearly
makes the attack diffrent.. rootkits are already available to defeat it.

	Gerhard



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Hollis]

On Wed, 3 Jan 2001, Gerhard Mack wrote:
> Your comparing actual security with stack guarding? Stack guarding mearly
> makes the attack diffrent.. rootkits are already available to defeat it.

url?

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Gerhard Mack]

On Wed, 3 Jan 2001, Dan Hollis wrote:

> On Wed, 3 Jan 2001, Gerhard Mack wrote:
> > Your comparing actual security with stack guarding? Stack guarding mearly
> > makes the attack diffrent.. rootkits are already available to defeat it.
> 
> url?

Ugh do you have any idea how hard it is to find 2 year old exploits?

Heres the best I could find on short notice:

http://www.insecure.org/sploits/non-executable.stack.problems.html
http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html

 
--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Dan Hollis]

On Wed, 3 Jan 2001, Gerhard Mack wrote:
> On Wed, 3 Jan 2001, Dan Hollis wrote:
> > On Wed, 3 Jan 2001, Gerhard Mack wrote:
> > > Your comparing actual security with stack guarding? Stack guarding mearly
> > > makes the attack diffrent.. rootkits are already available to defeat it.
> > url?
> Ugh do you have any idea how hard it is to find 2 year old exploits?
> Heres the best I could find on short notice:
> http://www.insecure.org/sploits/non-executable.stack.problems.html
> http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html

You said there were rootkits specifically targetting stackguard.

These URLs simply describe attacks on stackguard, where are the
stackguard rootkits?

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Andi Kleen]

On Wed, Jan 03, 2001 at 04:54:38PM -0500, Alexander Viro wrote:
> 
> Win: 0
> Loss: cost of find_vma() (and down(&mm->mmap_sem), BTW) on every system

It could actually be optimized a lot, e.g. by just read/writing to a byte
in the caller's current code page and handling the exception. 

But I agree with you that it's rather useless. It'll break some existing 
exploits, but it's so easy to workaround that exploit writers would quickly
adapt and then you have a ugly check with no purpose after a few weeks.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[David Huggins-Daines]

Dan Aloni <karrde@callisto.yi.org> writes:

> This preliminary, small patch prevents execution of system calls which
> were executed from a writable segment.

How does signal return work, then?

-- 
David Huggins-Daines		-		dhd@eradicator.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Andi Kleen]

On Wed, Jan 03, 2001 at 10:20:37PM -0500, David Huggins-Daines wrote:
> Dan Aloni <karrde@callisto.yi.org> writes:
> 
> > This preliminary, small patch prevents execution of system calls which
> > were executed from a writable segment.
> 
> How does signal return work, then?

Newer glibc sets a sa_restorer.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[David Huggins-Daines]

Andi Kleen <ak@suse.de> writes:

> On Wed, Jan 03, 2001 at 10:20:37PM -0500, David Huggins-Daines wrote:
> > Dan Aloni <karrde@callisto.yi.org> writes:
> > 
> > > This preliminary, small patch prevents execution of system calls which
> > > were executed from a writable segment.
> > 
> > How does signal return work, then?
> 
> Newer glibc sets a sa_restorer.

Hmm, maybe sigaction(2) should stop documenting it as "obsolete and
should not be used" then :-)

-- 
David Huggins-Daines		-		dhd@eradicator.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits

[Gerhard Mack]

On Wed, 3 Jan 2001, Dan Hollis wrote:

> On Wed, 3 Jan 2001, Gerhard Mack wrote:
> > On Wed, 3 Jan 2001, Dan Hollis wrote:
> > > On Wed, 3 Jan 2001, Gerhard Mack wrote:
> > > > Your comparing actual security with stack guarding? Stack guarding mearly
> > > > makes the attack diffrent.. rootkits are already available to defeat it.
> > > url?
> > Ugh do you have any idea how hard it is to find 2 year old exploits?
> > Heres the best I could find on short notice:
> > http://www.insecure.org/sploits/non-executable.stack.problems.html
> > http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html
> 
> You said there were rootkits specifically targetting stackguard.
> 
> These URLs simply describe attacks on stackguard, where are the
> stackguard rootkits?

I'll correct myself then: there were non exec stack patches.   Keep in
mind  part of the problem is that some compilors actually use that feature
look up "trampolines" for more info.

Also I was in error to refer to it as stack guarding.. Stack guard is a
compilor. I acually use libsafe it's preferable for 2 reasons. 
  1 It's entirely userspace and it works fine.
  2 If someone manages to render it useless I'll simply uninstall it.

	Gerhard

PS Although personally I think linux reoutation is most harmed by distribs
who insists on installing software with bad security records.  But that's
not relevent to linux-kernel.



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

2.2.19pre6 maestro3 driver requires ac97_codec (but doesn't claim so)

[Richard A Nelson]

The following (psuedo)patch to line 97 of drivers/sound/Makefile
corrects the problem:

 obj-$(CONFIG_SOUND_FUSION)      += cs46xx.o ac97_codec.o
 obj-$(CONFIG_SOUND_ICH)         += i810_audio.o ac97_codec.o
 obj-$(CONFIG_SOUND_MAESTRO)     += maestro.o
!obj-$(CONFIG_SOUND_MAESTRO3)    += maestro3.o
 obj-$(CONFIG_SOUND_SONICVIBES)  += sonicvibes.o
 obj-$(CONFIG_SOUND_TRIDENT)     += trident.o ac97_codec.o
 obj-$(CONFIG_SOUND_VIA82CXXX)   += via82cxxx_audio.o ac97_codec.o

 obj-$(CONFIG_SOUND_FUSION)      += cs46xx.o ac97_codec.o
 obj-$(CONFIG_SOUND_ICH)         += i810_audio.o ac97_codec.o
 obj-$(CONFIG_SOUND_MAESTRO)     += maestro.o
!obj-$(CONFIG_SOUND_MAESTRO3)    += maestro3.o ac97_codec.o
 obj-$(CONFIG_SOUND_SONICVIBES)  += sonicvibes.o
 obj-$(CONFIG_SOUND_TRIDENT)     += trident.o ac97_codec.o
 obj-$(CONFIG_SOUND_VIA82CXXX)   += via82cxxx_audio.o ac97_codec.o



-- 
Rick Nelson
Microsoft Corp., concerned by the growing popularity of the free 32-bit
operating system for Intel systems, Linux, has employed a number of top
programmers from the underground world of virus development. Bill Gates stated
yesterday: "World domination, fast -- it's either us or Linus". Mr. Torvalds
was unavailable for comment ...
(rjm@swift.eng.ox.ac.uk (Robert Manners), in comp.os.linux.setup)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/