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 h
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.
--
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? that
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 CON
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 at
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 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'
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%ra
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 alternati
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 tim
> 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
> 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
> 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
> 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 c
> 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
> > 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 implementa
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 kernel
19 matches
Mail list logo
