On 14 Feb 2008 at 17:35, Jakub Jelinek wrote:
> Where do you see a mispredicted branch?
try it with -Os (gentoo gcc 4.2.2):
:
0: 48 83 ec 58 sub$0x58,%rsp
4: 65 48 8b 04 25 28 00 00 00 mov%gs:0x28,%rax
d: 48 89 44 24 48 mov
On 14 Feb 2008 at 21:25, Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > really, the best defense is to reduce the useful lifetime of any
> > leaked canary, and you can't get better than syscall granularity
> > without disproportional effort and impact elsewhere (and
On 14 Feb 2008 at 20:00, Ingo Molnar wrote:
> > the best practical defense against leaking the canary is to change its
> > value on every syscall but it has some performance impact in
> > microbenchmarks.
>
> yeah, that's not really practical (especially as it would deplete our
> entropy pool
On 14 Feb 2008 at 18:00, Ingo Molnar wrote:
some comments:
> x86: fix execve with -fstack-protect
the commit comment says:
> This hack was true up to the point the stackprotector added
> another word to the stack frame. Shifting all the addresses
> by 8 bytes, crashing and burning any exec
On 14 Feb 2008 at 8:30, Ingo Molnar wrote:
> --- linux-x86.q.orig/arch/x86/kernel/process_64.c
> +++ linux-x86.q/arch/x86/kernel/process_64.c
> @@ -166,6 +166,15 @@ static inline void play_dead(void)
> void cpu_idle(void)
> {
> current_thread_info()->status |= TS_POLLING;
> +
> +#ifdef
On 14 Feb 2008 at 8:30, Ingo Molnar wrote:
--- linux-x86.q.orig/arch/x86/kernel/process_64.c
+++ linux-x86.q/arch/x86/kernel/process_64.c
@@ -166,6 +166,15 @@ static inline void play_dead(void)
void cpu_idle(void)
{
current_thread_info()-status |= TS_POLLING;
+
+#ifdef
On 14 Feb 2008 at 18:00, Ingo Molnar wrote:
some comments:
x86: fix execve with -fstack-protect
the commit comment says:
This hack was true up to the point the stackprotector added
another word to the stack frame. Shifting all the addresses
by 8 bytes, crashing and burning any exec
On 14 Feb 2008 at 20:00, Ingo Molnar wrote:
the best practical defense against leaking the canary is to change its
value on every syscall but it has some performance impact in
microbenchmarks.
yeah, that's not really practical (especially as it would deplete our
entropy pool pretty
On 14 Feb 2008 at 21:25, Ingo Molnar wrote:
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
really, the best defense is to reduce the useful lifetime of any
leaked canary, and you can't get better than syscall granularity
without disproportional effort and impact elsewhere (and i'm sure
On 14 Feb 2008 at 17:35, Jakub Jelinek wrote:
Where do you see a mispredicted branch?
try it with -Os (gentoo gcc 4.2.2):
foo:
0: 48 83 ec 58 sub$0x58,%rsp
4: 65 48 8b 04 25 28 00 00 00 mov%gs:0x28,%rax
d: 48 89 44 24 48 mov
On 13 Feb 2008 at 17:48, Ingo Molnar wrote:
> hm, had to pull it again because it crashed in testing:
i've only tested .24, not .25 so maybe something changed. did you
make sure that
write_pda(stack_canary, next_p->stack_canary);
was removed from arch/x86/kernel/process_64.c:__switch_to?
On 13 Feb 2008 at 8:29, Randy Dunlap wrote:
> Is it signed-off-by: pageexec ?
no it isn't, on purpose as i won't give out my real name that the
DCO requires.
> Couldn't that be a problem?
no it couldn't. no employer -> no problem. the little pleasures of life.
--
To unsubscribe from
On 12 Feb 2008 at 9:00, Arjan van de Ven wrote:
> I just read the excellent LWN writeup of the vmsplice security thing, and
> that got me
> wondering why this attack wasn't stopped by the CONFIG_CC_STACKPROTECTOR
> option... because
> it plain should have been...
what makes you think it should
On 12 Feb 2008 at 9:00, Arjan van de Ven wrote:
I just read the excellent LWN writeup of the vmsplice security thing, and
that got me
wondering why this attack wasn't stopped by the CONFIG_CC_STACKPROTECTOR
option... because
it plain should have been...
what makes you think it should have
On 13 Feb 2008 at 8:29, Randy Dunlap wrote:
Is it signed-off-by: pageexec ?
no it isn't, on purpose as i won't give out my real name that the
DCO requires.
Couldn't that be a problem?
no it couldn't. no employer - no problem. the little pleasures of life.
--
To unsubscribe from this list
On 13 Feb 2008 at 17:48, Ingo Molnar wrote:
hm, had to pull it again because it crashed in testing:
i've only tested .24, not .25 so maybe something changed. did you
make sure that
write_pda(stack_canary, next_p-stack_canary);
was removed from arch/x86/kernel/process_64.c:__switch_to?
On 6 Dec 2007 at 9:44, Mathieu Desnoyers wrote:
> It is correct to assume that the WP bit will always be activated, in
> every configuration, even though we don't use the DEBUG_RODATA ?
yes, without it the kernel couldn't rely on page faults to trigger
copy-on-write on userland pages for example
On 5 Dec 2007 at 21:02, Mathieu Desnoyers wrote:
> Fix a memcpy that should be a text_poke (in apply_alternatives).
>
> Use kernel_wp_save/kernel_wp_restore in text_poke to support DEBUG_RODATA
> correctly and so the CPU HOTPLUG special case can be removed.
>
> Add text_poke_early, for
On 5 Dec 2007 at 21:02, Mathieu Desnoyers wrote:
Fix a memcpy that should be a text_poke (in apply_alternatives).
Use kernel_wp_save/kernel_wp_restore in text_poke to support DEBUG_RODATA
correctly and so the CPU HOTPLUG special case can be removed.
Add text_poke_early, for alternatives
On 6 Dec 2007 at 9:44, Mathieu Desnoyers wrote:
It is correct to assume that the WP bit will always be activated, in
every configuration, even though we don't use the DEBUG_RODATA ?
yes, without it the kernel couldn't rely on page faults to trigger
copy-on-write on userland pages for example
On 27 Nov 2007 at 13:50, [EMAIL PROTECTED] wrote:
> Change loops controlled by 'for (i = 0; i < NR_CPUS; i++)' to use
> 'for_each_possible_cpu(i)' when there's a _remote possibility_ of
> dereferencing a non-allocated per_cpu variable involved.
actually, it's not that remote, it happens every
On 27 Nov 2007 at 13:50, [EMAIL PROTECTED] wrote:
Change loops controlled by 'for (i = 0; i NR_CPUS; i++)' to use
'for_each_possible_cpu(i)' when there's a _remote possibility_ of
dereferencing a non-allocated per_cpu variable involved.
actually, it's not that remote, it happens every time
On 13 Nov 2007 at 13:46, Mathieu Desnoyers wrote:
> +void *text_poke_early(void *addr, const void *opcode, size_t len)
> +{
> + memcpy(addr, opcode, len);
> + text_sync(addr, len);
> + return addr;
> +}
why do you need this function (vs. using text_poke throughout)?
> +#define
On 13 Nov 2007 at 13:46, Mathieu Desnoyers wrote:
+void *text_poke_early(void *addr, const void *opcode, size_t len)
+{
+ memcpy(addr, opcode, len);
+ text_sync(addr, len);
+ return addr;
+}
why do you need this function (vs. using text_poke throughout)?
+#define
> yes, i agree with you, __libc_dlopen_mode() is an easier target (but not
> _that_ easy of a target, see further down), and your code looks right
actually, line 25 is crap (talk about 'coding while intoxicated' ;-),
it should be 'if (dlerror())' of course. also, you should really try
to run the
> btw., do you consider PaX as a 100% sure solution against 'code
> injection' attacks (meaning that the attacker wants to execute an
> arbitrary piece of code, and assuming the attacked application has a
> stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed
> way?
your question
btw., do you consider PaX as a 100% sure solution against 'code
injection' attacks (meaning that the attacker wants to execute an
arbitrary piece of code, and assuming the attacked application has a
stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed
way?
your question is
yes, i agree with you, __libc_dlopen_mode() is an easier target (but not
_that_ easy of a target, see further down), and your code looks right
actually, line 25 is crap (talk about 'coding while intoxicated' ;-),
it should be 'if (dlerror())' of course. also, you should really try
to run the
> still wrong. What you get this way is a nice, complicated NOP.
not only a nop but also a likely crash given that i didn't adjust
the declaration of some_function appropriately ;-). let's cater
for less complexity too with the following payload (of the 'many
other ways' kind):
[field1 and other
> From http://pax.grsecurity.net/docs/pax.txt:
>
>The goal of the PaX project is to research various defense mechanisms
>against the exploitation of software bugs that give an attacker arbitrary
>read/write access to the attacked task's address space.
>
> Could you please explain
From http://pax.grsecurity.net/docs/pax.txt:
The goal of the PaX project is to research various defense mechanisms
against the exploitation of software bugs that give an attacker arbitrary
read/write access to the attacked task's address space.
Could you please explain how PaX
still wrong. What you get this way is a nice, complicated NOP.
not only a nop but also a likely crash given that i didn't adjust
the declaration of some_function appropriately ;-). let's cater
for less complexity too with the following payload (of the 'many
other ways' kind):
[field1 and other
> > dl_make_stack_executable() will nicely return into user_input
> > (at which time the stack has already become executable).
>
> wrong, _dl_make_stack_executable() will not return into user_input() in
> your scenario, and your exploit will be aborted. Check the glibc sources
> and the
dl_make_stack_executable() will nicely return into user_input
(at which time the stack has already become executable).
wrong, _dl_make_stack_executable() will not return into user_input() in
your scenario, and your exploit will be aborted. Check the glibc sources
and the implementation of
> and how do you force a program to call that function and then to execute
> your shellcode? In other words: i challenge you to show a working
> (simulated) exploit on Fedora (on the latest fc4 devel version, etc.)
> that does that.
i don't have any Fedora but i think i know roughly what you're
> Umm, so exactly how many applications use multithreading (or otherwise
> trigger the GLIBC mprotect call), and how many applications use nested
> functions (which is not ANSI C compliant, and as a result, very rare)?
i think you're missing the whole point of paxtest. it's not about what
glibc
Umm, so exactly how many applications use multithreading (or otherwise
trigger the GLIBC mprotect call), and how many applications use nested
functions (which is not ANSI C compliant, and as a result, very rare)?
i think you're missing the whole point of paxtest. it's not about what
glibc et
and how do you force a program to call that function and then to execute
your shellcode? In other words: i challenge you to show a working
(simulated) exploit on Fedora (on the latest fc4 devel version, etc.)
that does that.
i don't have any Fedora but i think i know roughly what you're
38 matches
Mail list logo
