Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] <>< 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] <>< 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] <>< 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] <>< 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 ;-) 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. 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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(>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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 ;-) chokesputter 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
