Re: [gentoo-hardened] Re: IRC presentation of SSXP on December 7th 20:00 UTC

[Alexander Gabert]

Hi folks,

for your info and decent google ML washing, here is the log of the irc 
session we had today regarding the introduction of SSXP.

It was a successful event, though there was a rather surprising momentum :)

Yes, we found a critical bug on x86 but it wasn't my fault.
No, it really wasn't, not this time :)

I will work on an updated version of SSXP that encodes the stored return 
address only and fix the bug on x86.

Thanks in advance and cheers,

Alex


> --- Log opened Thu Dec 07 15:19:28 2006
> 15:19 <@pappy-> ssxp: ping
> 15:19 <@pappy-> --- Log opened Thu Dec 07 15:19:28 2006
> 15:19 <@pappy-> 15:19 <@pappy-> ssxp: ping
> 15:19 <@pappy-> 15:19 <@pappy-> --- Log opened Thu Dec 07 15:19:28 2006
> 15:19 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> ssxp: ping
> 15:20 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> --- Log opened Thu Dec 07 15:19:28 2006
> 15:20 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> ssxp: ping
> 15:20 <@pappy-> 15:20 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> --- Log opened Thu Dec 07 15:19:28 2006
> 15:20 <@pappy-> 15:20 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> ssxp: ping
> 15:20 < GSF> uh oh
> 15:20 <@pappy-> 15:20 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> ssxp: ping
> 15:20 <@pappy-> 15:20 <@pappy-> 15:20 <@pappy-> 15:19 <@pappy-> 15:19 <@pappy-> --- Log opened Thu Dec 07 15:19:28 2006
> 15:20 <@pappy-> :)
> 15:21 < nms> i will be logging as well, so if anyone ends up with incomplete logs for some reason i might have patches :)
> 15:22 <@pappy-> tonight the only test system to show stuff is amd64
> 15:22 <@pappy-> the x86 host didnt compile
> 15:22 <@pappy-> because of glibc segfaults with gcc-3.4.x
> 15:22 <@pappy-> wasn't the fault of ssxp though :)
> 15:22 <@pappy-> compiled glibc-2.5 with gcc-3.4.x
> 15:22 <@pappy-> didnt like it
> 15:24 <@pappy-> i'll try to recompile it on my box again now
> 17:08 -!- pappy-_ [n=alex@×××××××××××××××××××××××××××××××××××.net] has joined #ssxp
> 17:11 <@ssxp> oops disconnect :)
> 17:11 -!- pappy-_ is now known as pap
> 17:12 -!- pap is now known as pappy-_
> 17:13 -!- mode/#ssxp [+o pappy-] by ssxp
> 17:13  * pappy-_ ponders his nickname
> 17:13 -!- mode/#ssxp [+o pappy-_] by ssxp
> 17:23 -!- pappy- [n=alex@×××××××××××××××××××××××××××××××××××.net] has quit [Read error: 110 (Connection timed out)]
> 17:23 -!- nms_ [n=martin@××××××××××××××××××××××××××××××.com] has joined #ssxp
> 17:27 -!- nms [n=martin@×××××××××××××××××××××××××××××.com] has quit [Read error: 145 (Connection timed out)]
> 17:37 -!- pappy-_ is now known as pappy-
> 17:43 -!- nms_ is now known as nms
> 19:02 < codejunky> Ich sitz in Hamburg, also geht das hier um 21:00 los? :)
> 19:03 <@ssxp> richtig
> 19:03 <@ssxp> date --utc zeigt dir die jeweilige utc zeit gerade
> 19:03 < codejunky> Ah okay.
> 19:04 < codejunky> Den kannte ich noch nicht ;)
> 19:06 -!- ssxp changed the topic of #ssxp to: Stack Smashing XOR Protection (SS(X)P) - welcome to the irc presentation - 20:00 UTC tonight - http://dev.gentoo.org/~pappy/ssxp/ || http://www0.fh-trier.de/~gaberta/ssxp/ || http://user.noxa.de/~pappy/ssxp/
> 19:06 -!- ssxp changed the topic of #ssxp to: Stack Smashing XOR Protection (SS(X)P) - welcome to the irc presentation - 20:00 UTC 21:00 CET tonight - http://dev.gentoo.org/~pappy/ssxp/ || http://www0.fh-trier.de/~gaberta/ssxp/ || http://user.noxa.de/~pappy/ssxp/
> 19:19 < Javi> damn, at 21 I won't be here
> 19:21 -!- CHTEKK [n=chtekk@gentoo/developer/chtekk] has joined #ssxp
> 19:39 <@ssxp> i can show amd64 and x86 SSXP assembler code tonight
> 19:40 <@ssxp> it looks that my x86 chroot is just finishing the gcc installation
> 19:43 -!- pipacs [i=theowl@×××××××××.com] has joined #ssxp
> 19:44 <@pappy-> hi pipacs
> 19:44 <@pappy-> welcome
> 19:45 < pipacs> salut
> 19:45 <@ssxp> comment allez vous
> 20:12 < voidptr> grabbing some smokes, later
> 20:27 < voidptr> puuh, bad weather :)
> 20:31 -!- Vinky [i=Vinky@gateway/tor/x-7fd72dcccf8a1169] has joined #ssxp
> 20:51 -!- ssxp changed the topic of #ssxp to: the next generation of stack protection: Stack Smashing XOR Protection - http://dev.gentoo.org/~pappy/ssxp
> 20:56 -!- mode/#ssxp [-o pappy-] by ssxp
> 20:59 <@ssxp> hello
> 20:59 < pappy-> welcome to my introduction of SSXP the stack smashing xor protection
> 20:59 < pappy-> first of all i'd like to introduce myself
> 21:00 < pappy-> then give you time for answering initial questions
> 21:00 < pappy-> then i present the solution
> 21:00 < pappy-> and you can tear it apart then
> 21:00 < pappy-> any questions?
> 21:01 < pappy-> okay, i'll just start to scroll
> 21:01 -!- phreak`` [n=phreak``@gentoo/developer/phreak] has joined #ssxp
> 21:02 < pappy-> my name is Alex, i'm one of the developers at Gentoo Hardened doing the hardened toolchain which consists of PIE and SSP code generation
> 21:02 < pappy-> i also do grsec and pax kernel
> 21:02 < pappy-> and misc stuff like scripts and maintaining, docs and helping users
> 21:03 < pappy-> the first steps of the hardened toolchain started in 2003 with a radical change in how we added SSP object code to the userland
> 21:03 < pappy-> back this time we decided there should be an automatic way to enable and instrument stack protection on executables automatically during building
> 21:04 < pappy-> which later became the all-famous haskell- and assembler- breaking hardened gcc
> 21:04 < pappy-> hardened gcc basically is a compiler that's trying to put SSP prologues and epilogues into binaries and libraries
> 21:05 < pappy-> and turning executables into position independent executables
> 21:06 < pappy-> the reason for this is obvious: position independent executables are more secure because their virtual memory layout allows for the most parts of the process to be unwritable and especially the executable parts unwritable
> 21:06 < pappy-> turning the stack nonexecutable then closes another possible way of introducing new executable code
> 21:06 < pappy-> this is achieved with using a PaX kernel that not only protects the executable's memory, it also randomizes the process
> 21:06 < pappy-> whcih means the libraries and the parts of the executable are randomly organized in memory for each new execution
> 21:07 < pappy-> we'll talk about that later (and why it's important)
> 21:07 < pappy-> so that's what i do basically
> 21:07 < pappy-> anybody having an initial question regarding the function of ssxp and it's design?
> 21:09 < pipacs> just a note
> 21:09 < pappy-> go ahead
> 21:10 < pipacs> we don't use PIEs because it makes w^x easier, as that's true for normal ET_EXEC executables as well after all
> 21:10 < pipacs> we use them for the sole purpose to be able to randomize them at runtime
> 21:10 < pappy-> and to disable text relocations
> 21:10 < pipacs> we don't have textrels in ET_EXEC either ;)
> 21:11 < pappy-> understood
> 21:11 < pipacs> TEXTRELs come from libs mostly, and PIEs if they're improperly compiled/linked
> 21:11 < pipacs> so in fact the introduction of PIEs made it all the more urgent/important to get rid of textrel prone code as much as possible
> 21:11 < pipacs> ok, that's all
> 21:12 < pappy-> if nobody has a question, i will talk about the history of SSP and it's predecessors and competitors a bit
> 21:12 < pappy-> professional readers among you will know the following URL's
> 21:12 < pappy-> http://www.phrack.org/archives/55/P55-08
> 21:12 < pappy-> http://www.phrack.org/archives/56/p56-0x05
> 21:13 < pappy-> back when these docs were written, lots of work has been invested in making SSP and other suites bulletproof against these described methods
> 21:14 < pappy-> the reordering of variables by SSP is the direct result of the testing and thinking done at these times
> 21:14 < pappy-> SSP itself is very mature
> 21:15 < pappy-> we are compiling very much packages with it and the only problems so far is C++ code, haskell (erlang) and assembler that modifies stack content.
> 21:15  * voidptr nods
> 21:15 < pappy-> it is also understandable that the PaX kernel does not "need" SSP
> 21:16 < pappy-> SSP itself may be even "inferior" to the model of PaX and it's protections
> 21:16 < pappy-> because it can "only" detect data being overwritten on the stack
> 21:16 < pappy-> in my understanding, the PaX kernel does not need SSP because even if an attacker can write shellcode to the stack, there is not much left to do because it's nonexecutable
> 21:17 < pappy-> also there is work done for PaX userland security stuff (pax-future.txt)
> 21:17 < pappy-> which will eventually supercede the work of SSP completely
> 21:17 < voidptr> Isn't prevention at that stage not just better? i mean, modifying any kernel data (that is located next to it on the stack) could already give the attacker some benefits
> 21:18 < voidptr> although it would only get handled at the function prologue i'm sure.
> 21:18 < pappy-> voidptr: every overwrite of critical data that can be prevented should be prevented.
> 21:18 < pappy-> if it's SSP preventing it, PaX does not have to kick in later.
> 21:18 < pappy-> that's my personal opinion.
> 21:18 < pappy-> i know that the PaX team is smiling at this
> 21:18 < pappy-> but there is enough room for every solution
> 21:19 < pappy-> basically, PaX is effective and "cheap" in terms of cost involved for runtime
> 21:19 < pappy-> the same holds true for -fstack-protector and -fstack-protector-all protecting functions with SSP
> 21:20 < pappy-> now, thinking it further
> 21:20 < pappy-> SSP sets up a guard on the stack
> 21:20 < pappy-> but does not protect the integrity of control data
> 21:20 < pappy-> control data that's fulfilling some important criterias
> 21:20 < pappy-> * it's always there
> 21:20 < pappy-> * it's having the same layout in every function stack frame
> 21:21 < pappy-> * you can find information about the state of current randomization in it
> 21:21 < pappy-> * you can easily use the return address as a jump pad to code you already found out where it is (even with randomization)
> 21:21 < pappy-> there have been wu-ftpd exploits where it was possible to read data from a process and after reading write data to the same process
> 21:21 < pappy-> you can't rule out that those things do not happen again.
> 21:22 < pappy-> so my idea was
> 21:22 < pappy-> protect the control data
> 21:22 < pappy-> which is not full bounds checking
> 21:22 < pappy-> and cannot be
> 21:22 < pappy-> because there is a speed vs. protection relationship
> 21:22 < pappy-> with full protection you need to sacrifice speed
> 21:22 < pappy-> and with speed you cannot have full protection
> 21:23 < pappy-> for this reason i decided to use the xor operation because it's fast, effective and it is possible to make it irreversible for an attacker under the following circumstances:
> 21:23 < pappy-> * every function in the current process is protected with SSXP
> 21:23 < pappy-> * PaX is randomizing the address space
> 21:23 < pappy-> * the attacker cannot read the original guard values from glibc
> 21:23 < pappy-> however, the attacker can be able to read the stack and write it as she or he wants to
> 21:24 < pappy-> in my understanding, using PaX and SSXP improves what PaX and SSP already delivers:
> 21:24 < pappy-> a profound base for protecting your machines from future exploit patterns
> 21:25 < pappy-> if you have questions i can answer now, otherwise i will show code now
> 21:27 < pappy-> the following excerpt from a prologue was generated using SSXP compiler on an intel x86 machina
> 21:27 < pappy-> 17         movl    %gs:20, %eax
> 21:27 < pappy-> 18         movl    %eax, -8(%ebp)
> 21:27 < pappy-> 19         xorl    %eax, %eax
> 21:27 < pappy-> if you have questions, please refer to the line numbers pasted leftmost
> 21:28 < pappy-> these three lines are the original SSP part of the prologue
> 21:28 < pappy-> it means: load the __guard value from %gs:20 into %eax register
> 21:28 < pappy-> %gs:20 is a special means of acessing data in the Thread Local Storage
> 21:28 < pappy-> do you want to learn about it or are you accustomed to this notation?
> 21:28 < pappy-> it'S got something to do with a selector
> 21:29 < pappy-> and segmentation based addressing on intel machine
> 21:29 < pappy-> you can shout stop if it's going to fast.
> 21:29 < pappy-> in line 18 we are moving this __guard original value to the stack slot reserved for the guard
> 21:30 < pappy-> in line 19 we are preventing information leak by zeroing out the original guard value
> 21:30 < pappy-> which is kind of moot because the guard is on the stack nevertheless in cleartext :)
> 21:30 < pappy-> but maybe there were trying to not give the value in a register to an attacker who could possibly do something bad with it
> 21:31 < pappy-> 20         movl    -8(%ebp), %eax
> 21:31 < pappy-> 21         xorl    -4(%ebp), %eax
> 21:31 < pappy-> 22         movl    %eax, -8(%ebp)
> 21:31 < pappy-> this code is taking the stored canary (with the guard value) from the stack slot into a register
> 21:32 < pappy-> does an xor operation with the saved frame pointer with it
> 21:32 < pappy-> and stores the result back in eax
> 21:32 < pappy-> which then (line 22) gets stored back in the canary
> 21:32 < pappy-> this procedure is described here: http://dev.gentoo.org/~pappy/ssxp/latex2html/node85.html
> 21:33 < pappy-> we are currently in the first part of the level1 encoding operation
> 21:33 < pappy-> we have done __guard1 xor sfptr == xguard (which is the canary location)
> 21:33 < pappy-> 23         movl    -8(%ebp), %eax
> 21:33 < pappy-> 24         xorl    0(%ebp), %eax
> 21:33 < pappy-> 25         movl    %eax, -8(%ebp)
> 21:33 < pappy-> the next part is with the return address
> 21:33 < pappy-> if i'm going to fast or you are already bored: just shout
> 21:34 < pappy-> also if you don't understand something, please feel free to disrupt and ask free away!
> 21:34 < pappy-> in line 23 we are getting the (this time halfway level1 encoded) canary value again
> 21:34 < pappy-> and xor the return address onto it
> 21:34 < pappy-> finally in 25 we store it back
> 21:34 < pappy-> this finalizes level1 encoding of prologue
> 21:34 < pappy-> please notice that gcc -O2 is optimizing this sequence
> 21:34 < pipacs> uhm, wait a sec
> 21:35 < pappy-> you don't need to think this is hardcoded assembler
> 21:35 < pipacs> are you sure the ebp offsets are fine?
> 21:35 < pappy-> pipacs: i guess so
> 21:35 < pappy-> pipacs: it's intel assembler
> 21:35 < pipacs> normally the prologue has: push ebp, mov ebp,esp -> saved eip is at ebp+4, saved ebp is at ebp+0
> 21:35 < pipacs> i.e. 4 bytes higher than what you showed us
> 21:37 < pappy-> rtx sfptr = gen_rtx_MEM (mode, frame_pointer_rtx);
> 21:37 < pipacs> if the quoted code was actually compiler generated, can you show the full prologue?
> 21:37 < pipacs> maybe there's something else done to the stack than what is usual
> 21:37 < pappy-> rtx retaddr = gen_rtx_MEM (mode, gen_rtx_PLUS (mode, frame_pointer_rtx, GEN_INT (GET_MODE_SIZE (mode))));
> 21:37 < pappy->  1         .file   "vuln-stack.c"
> 21:37 < pappy->  2         .text
> 21:37 < pappy->  3 .globl main
> 21:37 < pappy->  4         .type   main, @function
> 21:37 < pappy->  5 main:
> 21:37 < pappy->  6         leal    4(%esp), %ecx
> 21:37 < pappy->  7         andl    $-16, %esp
> 21:37 < pappy->  8         pushl   -4(%ecx)
> 21:37 < pappy->  9         pushl   %ebp
> 21:37 < pappy-> 10         movl    %esp, %ebp
> 21:37 < pappy-> 11         pushl   %ecx
> 21:38 < pappy-> 12         subl    $36, %esp
> 21:38 < pappy-> 13         movl    (%ecx), %eax
> 21:38 < pappy-> 14         movl    %eax, -24(%ebp)
> 21:38 < pappy-> 15         movl    4(%ecx), %eax
> 21:38 < pappy-> 16         movl    %eax, -28(%ebp)
> 21:38 < pappy-> 17         movl    %gs:20, %eax
> 21:38 < pappy-> 18         movl    %eax, -8(%ebp)
> 21:38 < pappy-> 19         xorl    %eax, %eax
> 21:38 < pappy-> 20         movl    -8(%ebp), %eax
> 21:38 < pappy-> 21         xorl    -4(%ebp), %eax
> 21:38 < pappy-> 22         movl    %eax, -8(%ebp)
> 21:38 < pappy-> 23         movl    -8(%ebp), %eax
> 21:38 < pappy-> 24         xorl    0(%ebp), %eax
> 21:38 < pappy-> 25         movl    %eax, -8(%ebp)
> 21:38 < pappy-> 26         movl    __stack_chk_fguard, %eax
> 21:38 < pappy-> 27         xorl    -4(%ebp), %eax
> 21:38 < pappy-> 28         movl    %eax, -4(%ebp)
> 21:38 < pappy-> 29         movl    __stack_chk_rguard, %eax
> 21:38 < pappy-> 30         xorl    0(%ebp), %eax
> 21:38 < pappy-> 31         movl    %eax, 0(%ebp)
> 21:38 < pappy-> 32         movl    -28(%ebp), %eax
> 21:39 < pappy-> 31 is the last instruction of SSXP prologue
> 21:39 < pipacs> i understand but
> 21:39 < pipacs> where is -4(%ebp) written to first?
> 21:40 < pipacs> pushl   -4(%ecx) ensures that the saved eip is just above the saved frame ptr, so far so good
> 21:40 < pipacs> which makes my maths still correct
> 21:40 < pappy-> pipacs: i will start gdb for you
> 21:40 < pipacs> but the only thing i see is a read from -4(ebp), w/o it having been ever written to
> 21:40 < pappy-> just tell me what you want to do
> 21:41 < pipacs> just trace until line 21 above
> 21:41 < pipacs> and dump the stack from ebp-8
> 21:41 < pappy-> ssxp@apocalypse ~ $ gcc -fPIE -o vuln-stack vuln-stack.c; /sbin/paxctl -pemsrx vuln-stack; gdb --quiet --args ./vuln-stack AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> 21:41 < pappy-> 0x080484c5 <main+49>:   xor    %eax,%eax
> 21:41 < pappy-> 0x080484c7 <main+51>:   mov    0xfffffff4(%ebp),%eax
> 21:41 < pappy-> 0x080484ca <main+54>:   xor    0xfffffff8(%ebp),%eax
> 21:42 < pipacs> (paxctl -mr is normally enough btw ;-)
> 21:42 < pappy-> i will single step to 0x080484ca
> 21:42 < pipacs> first x/8x $ebp-8
> 21:42 < pappy-> 0x080484ca in main ()
> 21:42 < pappy-> we are before the instruction xor    0xfffffff8(%ebp),%eax
> 21:42 < pappy-> it is not yet executed
> 21:42 < pipacs> it's ok
> 21:43 < pappy-> (gdb) x/8x $ebp-8
> 21:43 < pappy-> 0xbfc859c0:     0xbfc859e0      0xb7f6aff4      0xbfc85a08      0xb7e66d70
> 21:43 < pappy-> 0xbfc859d0:     0x08048570      0xb7f8eca0      0xbfc85a08      0xb7e66d70
> 21:43 < pipacs> and x/i 0xb7f6aff4 ?
> 21:43 < pappy-> (gdb) x/i 0xb7f6aff4
> 21:43 < pappy-> 0xb7f6aff4 <_IO_file_jumps+1556>:       jl     0xb7f6af93 <_IO_file_jumps+1459>
> 21:44 < pipacs> see, that's supposed to be the caller of 'main'
> 21:44 < pipacs> somewhere in libc presumably
> 21:44 < pappy-> well, i am generating the address this way:
> 21:44 < pipacs> but it's some unrelated 'code', probably not even in an executable area but some data
> 21:44 < pappy-> rtx sfptr = gen_rtx_MEM (mode, frame_pointer_rtx);
> 21:44 < pipacs> that generated proper asm as far as i see
> 21:44 < pappy-> which boils down to the memory location of the saved frame pointer
> 21:45 < pappy-> adding a pointer wide to it yields the return address
> 21:45 < pipacs> err, actually, no
> 21:45 < pappy-> rtx retaddr = gen_rtx_MEM (mode, gen_rtx_PLUS (mode, frame_pointer_rtx, GEN_INT (GET_MODE_SIZE (mode))));
> 21:45 < pipacs> it's off by 4 as well
> 21:45 < pipacs> you're missing an offset of 4 in your calculations somehow
> 21:45 < pipacs> for both the saved ebp and eip
> 21:46 < pipacs> i don't know gcc rtl syntax to help you unfortunately
> 21:46 < pappy-> well, rtl syntax is easy
> 21:46 < pipacs> but the asm speaks for itself and you can see it from the stack dump as well
> 21:46 < pappy-> frame_pointer_rtx describes the memory location
> 21:47 < pipacs> there's a gcc intrinsic called __builtin_return_address() or something like that, can you check what it's defined as for i386?
> 21:47 < pipacs> 'cos it's supposed to do the same access for the saved eip as you try to
> 21:47 < pipacs> therefore i assume it does the proper calculation already
> 21:47 < pipacs> anyway, don't let me hold you up, this is a bug you can fix later
> 21:48 < pappy-> well we can look at it now
> 21:48 < pappy-> i'm grateful for your eagle eyes
> 21:48 < pappy-> error: too few arguments to function '__builtin_return_address
> 21:49 < pipacs> pass a 0 for the current frame
> 21:49 < pipacs> (it can look up the return addr in higher frames as well, but i think it needs frame ptr for that)
> 21:50 < pappy-> #include <stdio.h>
> 21:50 < pappy-> int main(void) {
> 21:50 < pappy->         __builtin_return_address(0);
> 21:50 < pappy-> }
> 21:50 < pappy-> main:
> 21:50 < pappy->         leal    4(%esp), %ecx
> 21:50 < pappy->         andl    $-16, %esp
> 21:50 < pappy->         pushl   -4(%ecx)
> 21:50 < pappy->         pushl   %ebp
> 21:50 < pappy->         movl    %esp, %ebp
> 21:50 < pappy->         pushl   %ecx
> 21:50 < pappy->         popl    %ecx
> 21:50 < pappy->         popl    %ebp
> 21:50 < pappy->         leal    -4(%ecx), %esp
> 21:50 < pappy->         ret
> 21:50 < pipacs> that's a bit too much optmized ;)
> 21:51 < pipacs> write it into a global variable
> 21:51 < pappy-> int main(void) {
> 21:51 < pappy->         printf("%x\n", __builtin_return_address(0));
> 21:51 < pappy->         leal    4(%esp), %ecx
> 21:51 < pappy->         andl    $-16, %esp
> 21:51 < pappy->         pushl   -4(%ecx)
> 21:51 < pappy->         pushl   %ebp
> 21:51 < pappy->         movl    %esp, %ebp
> 21:51 < pappy->         pushl   %ecx
> 21:51 < pappy->         subl    $20, %esp
> 21:51 < pappy->         movl    4(%ebp), %eax
> 21:51 < pappy->         movl    %eax, 4(%esp)
> 21:51 < pappy->         movl    $.LC0, (%esp)
> 21:51 < pappy->         call    printf
> 21:51 < pappy->         addl    $20, %esp
> 21:51 < pipacs> see the movl    4(%ebp), %eax ?
> 21:51 < pappy->         popl    %ecx
> 21:51 < pappy->         popl    %ebp
> 21:51 < pappy->         leal    -4(%ecx), %esp
> 21:51 < pappy->         ret
> 21:51 < pappy-> yeah, you're right
> 21:51 < pipacs> that's the +4 as it should be
> 21:51 < pappy-> it's  4(%ebp)
> 21:52 < pappy-> i see
> 21:52 < pappy-> but then i don't understand the frame_pointer_rtx
> 21:52 < pappy-> why it's showing the wrong location
> 21:52 < pipacs> maybe you're supposed to re-bias it yourself
> 21:52 < pappy-> rebias?
> 21:52 < pipacs> that's why i told you to check the gcc sources
> 21:52 < pipacs> well add 4 explicitly or something to that effect
> 21:52 < pappy-> i see
> 21:53 < pappy-> add pointerwidth
> 21:53 < pappy-> to make it machine independent
> 21:53 < pipacs> or even +8 if i'm not mistaken
> 21:53 < pipacs> since you had -8/-4 vs 0/4
> 21:53 < pappy-> well -8 was the canary
> 21:54 < pappy-> and -4 was the frame pointer stored
> 21:54 < pappy-> and 0 was the saved return address
> 21:54 < pipacs> ok, +4 it is then
> 21:55 < pipacs> i wonder, maybe frame_pointer_rtx is a ptr/reference to the first free slot *below* the saved ebp
> 21:55 < pipacs> is there some doc about it?
> 21:55 < pappy-> 17         movl    %gs:20, %eax
> 21:55 < pappy-> 18         movl    %eax, -8(%ebp)
> 21:55 < pappy-> this is moving the 32bit value (4byte) to -8
> 21:55 < pappy-> which leaves the saved frame pointer at -4
> 21:55 < pappy-> which leaves the retaddr at 0
> 21:56 < pappy-> pipacs: i had tests running that showed me that i was in fact encoding and decoding the return address and saved frame pointer
> 21:56 < pappy-> but i will double check and send you mail with output
> 21:56 < pappy-> so you can see for yourself
> 21:56 < pipacs> well, you can see that what you take as return address is not
> 21:56 < pipacs> maybe your stack dump was off by 4 as well :)
> 21:56 < pappy-> it was gdb
> 21:57 < pappy-> movl    4(%ebp), %eax
> 21:57 < pappy-> this one is making me wonder
> 21:57 < pappy-> i'll research it :)
> 21:57 < pappy-> back to topic
> 21:58 < pappy-> now let's assume the problems are fixed and we are encoding the return address and saved frame pointer
> 21:58 < pipacs> sure
> 21:58 < pappy-> which means an attacker can read the stack
> 21:58 < pappy-> and will get the values
> 21:58 < pappy-> now, in an nonrandomized setup
> 21:58 < pappy-> the attacker can easily revert the retrieved values to the original values
> 21:58 < pappy-> because he or she will usually know the target (or be local on the machine)
> 21:59 < pappy-> http://dev.gentoo.org/~pappy/ssxp/latex2html/node98.html
> 21:59 < pappy-> which means when the original return address is known
> 21:59 < pappy-> and the original saved frame pointer
> 21:59 < pappy-> the attacker can simply read the stack
> 21:59 < pappy-> and recompute the xor operation
> 21:59 < pappy-> which makes it necessary to randomize the process for SSXP to have any valueable effect
> 21:59 < pappy-> otherwise, if you dont randomize you can use SSXP only for integrity checking
> 22:00 < pappy-> but if you have information leaking and the attacker knows the original values, the concept is worthless and falls down to the normal SSP behaviour
> 22:00 < pappy-> which means linear reading, linear writing is possible to override the protection
> 22:00 < pappy-> just read the stack, fix up the values, write it back
> 22:00 < pappy-> there is no encryption done
> 22:00 < pappy-> it's only a simple mathematical operation everybody can recreate
> 22:01 < pappy-> so, when using SSXP with process randomization, we are preventing the control data to be modified.
> 22:01 < pappy-> or in this case data -4 bytes below our control data.
> 22:01 < pappy-> *g*
> 22:01 < pappy-> any questions?
> 22:03 < pappy->         movq    8(%rbp), %rax
> 22:03 < pappy-> pipacs: this is amd64
> 22:03 < pipacs> +8 for retaddr?
> 22:03 < pappy-> 15         movq    %fs:40, %rax
> 22:03 < pappy-> 16         movq    %rax, -8(%rbp)
> 22:03 < pappy-> 17         xorl    %eax, %eax
> 22:04 < pappy-> 18         movq    -8(%rbp), %rax
> 22:04 < pappy-> 19         xorq    0(%rbp), %rax
> 22:04 < pappy-> 20         movq    %rax, -8(%rbp)
> 22:04 < pappy-> 21         movq    -8(%rbp), %rax
> 22:04 < pappy-> the 22         xorq    8(%rbp), %rax
> 22:04 < pappy-> 23         movq    %rax, -8(%rbp)
> 22:04 < pipacs> -8/0 vs 0/8 i think
> 22:04 < pipacs> same problem
> 22:04 < pipacs> ah, 0/8
> 22:04 < pipacs> that seems better
> 22:04 < pappy-> pipacs: it's the same patch
> 22:04 < pappy-> exactly the same patch
> 22:05 < pipacs> you're still off by 4 on i386 as far as i see it though
> 22:05 < pappy-> yeah you're absolutely right
> 22:05 < pipacs> actually, can you show me the full prologue on amd64?
> 22:05 < pappy->  3 .globl main
> 22:05 < pappy->  4         .type   main, @function
> 22:05 < pappy->  5 main:
> 22:05 < pappy->  6 .LFB2:
> 22:05 < pappy->  7         pushq   %rbp
> 22:05 < pappy->  8 .LCFI0:
> 22:05 < pappy->  9         movq    %rsp, %rbp
> 22:05 < pappy-> 10 .LCFI1:
> 22:05 < pappy-> 11         subq    $48, %rsp
> 22:05 < pappy-> 12 .LCFI2:
> 22:05 < pappy-> 13         movl    %edi, -36(%rbp)
> 22:05 < pappy-> 14         movq    %rsi, -48(%rbp)
> 22:05 < pappy-> 15         movq    %fs:40, %rax
> 22:06 < pappy-> 16         movq    %rax, -8(%rbp)
> 22:06 < pappy-> 17         xorl    %eax, %eax
> 22:06 < pappy-> 18         movq    -8(%rbp), %rax
> 22:06 < pappy-> 19         xorq    0(%rbp), %rax
> 22:06 < pappy-> 20         movq    %rax, -8(%rbp)
> 22:06 < pappy-> 21         movq    -8(%rbp), %rax
> 22:06 < pappy-> 22         xorq    8(%rbp), %rax
> 22:06 < pappy-> 23         movq    %rax, -8(%rbp)
> 22:06 < pappy-> 24         movq    __stack_chk_fguard(%rip), %rax
> 22:06 < pappy-> 25         xorq    0(%rbp), %rax
> 22:06 < pappy-> 26         movq    %rax, 0(%rbp)
> 22:06 < pappy-> 27         movq    __stack_chk_rguard(%rip), %rax
> 22:06 < pappy-> 28         xorq    8(%rbp), %rax
> 22:06 < pappy-> 29         movq    %rax, 8(%rbp)
> 22:06 < pappy-> 30         movq    -48(%rbp), %rax
> 22:06 < pappy-> 31         addq    $8, %rax
> 22:06 < pappy-> 32         movq    (%rax), %rsi
> 22:06 < pappy-> 33         leaq    -32(%rbp), %rdi
> 22:06 < pappy-> 34         call    strcpy
> 22:06 < pappy-> 35         movl    $0, %eax
> 22:06 < pappy-> rguard is the guard responsible for triggering the level2 encoding of the stored return address in place
> 22:07 < pipacs> ok, it seems to be fine
> 22:07 < pappy-> fguard does the same for frame pointer
> 22:07 < pappy-> pipacs: so it's a gcc bug
> 22:07 < pappy-> *sigh*
> 22:07 < pappy-> sorry about that
> 22:07 < pipacs> on google i saw references to hard_frame_ptr_rtx
> 22:07 < pappy-> i should've checked that more carefully
> 22:07 < pipacs> maybe that's what you need?
> 22:07 < pappy-> pipacs: i will check for it
> 22:07 < pappy-> the problem was that the whole testing was done on amd
> 22:07 < pappy-> also the gdb testing
> 22:07 < pipacs> or just check how gcc itself defines __builtin_return_address
> 22:07 < pappy-> where i compared the stack frames before-after
> 22:08 < pipacs> gcc -m32 and you get i386 asm ;)
> 22:09 < pappy-> pipacs: doing gcc -m32 on the amd64 machine yields the same problem
> 22:09 < pappy-> -4 is missing
> 22:09 < pappy-> nevermind
> 22:09 < pappy-> how do you like the concept
> 22:09 < pappy-> as you saw it working on amd64 now at least
> 22:10 < pipacs> like it as in?
> 22:10 < pappy-> do you think it delivers more than SSP
> 22:10 < pipacs> what was the threat model that you're protecting against but ssp doesn't?
> 22:11 < pappy-> well ssp doesn't protect against attacks where the control data can be written to directly
> 22:11 < pappy-> using a formatstring or a write-after-read attack on the stack
> 22:11 < pappy-> because ssp is putting a canary on the stack
> 22:11 < pappy-> which can be read, then written to
> 22:11 < pipacs> ah sure, it's a definitive improvment against those attacks
> 22:12 < pappy-> so how would you rate it in conjunction with PaX
> 22:12 < pipacs> it's not comparable, like ssp or anything that comes from the 'bug prevention' angle
> 22:12 < pipacs> pax comes from the 'exploit technique prevention' angle
> 22:13 < pipacs> imagine it as a two dimensional matrix, rows are exploit techniques, columns are bugs classes
> 22:13 < pipacs> ssp & co cover columns
> 22:13 < pipacs> pax & co cover rows
> 22:13 < pappy-> well i know that
> 22:13 < pipacs> obviously there's some overlap, i.e. they prevent exploiting certain bugs by certain exploit techniques
> 22:14 < pappy-> well, i wanted your opinion on the encoded control data
> 22:14 < pipacs> the rest differs in ways you can't compare, i mean, you can't just put a number behind them and say a > b
> 22:14 < pappy-> would it be worth to use that for making it harder to do information leaking about ASLR?
> 22:15 < pappy-> i don't want you to say: PaX is better...
> 22:15 < pipacs> well, you encode 2 particular pointers on the stack
> 22:15 < pipacs> but usually there're many more
> 22:15 < pappy-> i just like to know if it's a good measure
> 22:15 < pappy-> pipacs: i know, that's another thing
> 22:15 < pappy-> my model is good if the program does not use function pointers
> 22:15 < pappy-> which are a good starting point for an attack
> 22:16 < pappy-> but as i previously said:
> 22:16 < pappy-> the frames are always there
> 22:16 < pipacs> i'd say encoding the saved EIP is more useful than encoding the saved frame ptr
> 22:16 < pappy-> which implies it makes good friendly target for attackers
> 22:16 < pipacs> because code ptrs come (mostly) from function calls only
> 22:16 < pappy-> pipacs: frame pointer gives information leak about stack randomization
> 22:16 < pipacs> so you're effectively encoding all of them on the stack
> 22:16 < pipacs> however there're usually many stack-related ptrs on the stack
> 22:16 < pipacs> addresses of local variables
> 22:17 < pappy-> hrm
> 22:17 < pipacs> tehrefore hiding saved ebp is less useful since the entropy in the stack ptr can be recovered from the other ptrs
> 22:17 < pappy-> okay so it would make sense to go with EIP encoding
> 22:17 < pipacs> see what i mean?
> 22:17 < pappy-> and skip frame pointer altogether
> 22:17 < pappy-> i'd live with that because it makes the SSXP patch very easier
> 22:17 < pappy-> much clumsy stuff can go (like frame pointer enforced)
> 22:17 < pipacs> well, that or extend it to all ptrs spilled on the stack, or at least those ptrs for which you can prove that they are stack related
> 22:17 < pappy-> pipacs: yeah, thanks for the heads up
> 22:17 < pipacs> which would get you quite close to what pointguard purported to be
> 22:18 < pappy-> pipacs: i want to keep it inexpensive in terms of prologue and epilogue runtime
> 22:18 < pappy-> with respect to PaX randomization being hidden as good as possible
> 22:18 < pappy-> so people reading the stack cannot easily learn about addresses
> 22:18 < pipacs> also, you can use the randomness in esp itself (under pax/execshield/2.6.1x)
> 22:19 < pipacs> although that'd leak if one can read the stack
> 22:19 < pipacs> which you say you assume in your threat model
> 22:19 < pappy-> yes
> 22:19 < pappy-> i assume full stack read and write after the read
> 22:19 < pipacs> in that case though, the guard should not be spilled on the stack either
> 22:20 < pappy-> how do you mean that?
> 22:20 < pipacs> it should be read and kept in a register, never written to the stack
> 22:20 < pipacs> -8(ebp) holds your guard, right?
> 22:20 < pappy-> there is three guards
> 22:20 < pappy-> pipacs: did you read the paper?
> 22:20 < pipacs> ah, we're not at the end of it ;)
> 22:20 < pipacs> not all of it, apparently
> 22:20 < pappy-> you have been a very lazy boy
> 22:20 < pappy-> shame on you
> 22:20 < pappy-> for being so unprepared
> 22:20 < pipacs> but what you showed so far, it used one guard to encode 2 ptrs, and that one guard was spilled on the stack
> 22:20 < pappy-> no
> 22:20 < pappy-> no no
> 22:21 < pipacs> <pappy-> 15         movq    %fs:40, %rax
> 22:21 < pipacs> <pappy-> 16         movq    %rax, -8(%rbp)
> 22:21 < pappy-> http://dev.gentoo.org/~pappy/ssxp/latex2html/node85.html
> 22:21 < pipacs> what's taht do then?
> 22:21 < pappy-> look this please
> 22:21 < pappy-> i showed and explained the level1
> 22:21 < pappy-> which does saved frame ptr xor retaddr xor guard -> canary
> 22:21 < pappy-> and then level2 encoding is transforming the cleartext values of saved frame pointer and retaddr
> 22:22 < pappy-> 23         movq    %rax, -8(%rbp)
> 22:22 < pappy-> 24         movq    __stack_chk_fguard(%rip), %rax
> 22:22 < pappy-> 25         xorq    0(%rbp), %rax
> 22:22 < pappy-> 26         movq    %rax, 0(%rbp)
> 22:22 < pipacs> ok
> 22:22 < pappy-> this is the level2 encoding of the saved frame pointer
> 22:22 < pappy-> it is using a different guard
> 22:22 < pappy-> for the reason you said
> 22:22 < pappy-> spilling the guard on the stack is not an option if the original data is still there
> 22:23 < pappy-> because then you just unroll the operations
> 22:23 < pappy-> 27         movq    __stack_chk_rguard(%rip), %rax
> 22:23 < pappy-> 28         xorq    8(%rbp), %rax
> 22:23 < pappy-> 29         movq    %rax, 8(%rbp)
> 22:23 < pipacs> i see one potential attack though
> 22:23 < pappy-> which is
> 22:23 < pipacs> if i can read enough stack, i may be able to read more than frame
> 22:23 < pipacs> and i'd get then two pairs of encoded values w/ rguard/fguard
> 22:24 < pappy-> how do you mean that
> 22:24 < pipacs> xoring them together would get rid of rguard/fguard and leave the xor of two more or less related (predictable by the attacker) frame and eip values
> 22:24 < pipacs> i have ebp1 ^ fguard, and ebp2 ^ fguard
> 22:24 < pappy-> okay
> 22:24 < pipacs> xor them together (as i leaked enough stack)
> 22:24 < pappy-> sure
> 22:25 < pipacs> i get ebp1 ^ ebp2
> 22:25 < pappy-> yes
> 22:25 < pipacs> which reveals some info about ebp itself
> 22:25 < pappy-> i know
> 22:25 < pipacs> hmm, maybe nothing useful though
> 22:25 < pappy-> but what can you do with that
> 22:25 < pipacs> as the high bits are likely 0
> 22:25 < pipacs> let's take eip instead
> 22:25 < pappy-> k
> 22:25 < pipacs> so i could learn eip1 ^ eip2
> 22:26 < pipacs> and i'd know a priori where they're supposed be (since i can know the control flow chain at that point based on the src/user input)
> 22:26 < pappy-> yes
> 22:26 < pipacs> that'd reveal info about library addresses or their relative distance at least
> 22:26 < pappy-> but randomization
> 22:27 < pipacs> not so much useful under pax though as all libs are shifted by the same amount
> 22:27 < pipacs> so again, the high bits would be 0 or some otehr constant
> 22:27 < pipacs> anyway, just an idea, i don't immediately see much else 'wrong' with this scheme
> 22:27 < pappy-> yes but can you take the info from eip1 ^ eip2 to form an address that can be used for an attack?
> 22:27 < pappy-> with a reasonable probability not to miss?
> 22:28 < pipacs> pappy, probably not to directly predict an address
> 22:28 < pipacs> but maybe  reduce the 'guess space'
> 22:28 < pappy-> i know
> 22:28 < pipacs> it'd need more thinking ;)
> 22:28 < pappy-> but reducing the guess space wont give you a chance with grsec locking you out after 15 segfaults
> 22:28 < pipacs> tell mayhem about it, im sure he won't hesitate ;P
> 22:28 < pappy-> you can always be lucky
> 22:28 < pappy-> but i would give you the win if you're lucky
> 22:28 < pappy-> whois mayhem
> 22:29 < pipacs> the guy who critized you the other day ;)
> 22:29 < voidptr> the anti-pax!
> 22:29 < pappy-> pipacs: so you would suggest i fix the obvious x86 errors with the generated assembler, throw away the frame pointer encoding
> 22:29 < pappy-> the guy who critizised me?
> 22:30 < pappy-> btw, where is pbusser
> 22:30 < pipacs> well, considering that you assume stack leaking and that there're usually other stack related ptrs spilled on the stack, encoding ebp doesn't seem particularly useful
> 22:30 < pappy-> pipacs: getting rid of frame pointer encoding was on my list nonetheless, because the patch sux because it enforces frame pointer
> 22:31 < pappy-> and i'll make it more gentle when i only do work on the always existing eip
> 22:31 < pappy-> without making speculations about ebp
> 22:31 < pipacs> also, as a bonus exercise, you could try to identify function ptrs spilling on the stack
> 22:31 < pappy-> you would never imagine how hard it is to find out in gcc source whether the currently constructed function (in gcc/function.c) is actually having a frame pointer at the moment or not
> 22:31 < pipacs> and encode/decode them as needed
> 22:32 < pipacs> that'd get you closer to pointguard and even beat it as you'd actually have working code, unlike them ;P
> 22:32 < pappy-> yeah, harass me, i deserve it
> 22:32 < pappy-> that bug with x86 makes me sad now
> 22:32 < pappy-> i'm throwing my own party here with broken stuff
> 22:33 < pappy-> pipacs: after the hardened toolchain migration work is done with gcc-4 and glibc-2.4 and glibc-2.5 i want to add this to hardened
> 22:33 < pappy-> USE="ssxp"
> 22:33 < pappy-> in the hardened toolchain
> 22:33 < pappy-> together with PaX it's way to go to supercede normal SSP
> 22:33 < pappy-> because it rocks the return address from being tampered with
> 22:33 < pappy-> whcih is my main point of interest
> 22:34 < pappy-> that valueable little precious item always in the same location makes up a good target for hijackers that recognize they can't do much with a nonexecutable stack
> 22:34 < pappy-> and my personal belief is that SSXP blocks a bit of those
> 22:34 < pappy-> at least the very simple ones
> 22:34 < pappy-> which is a good start for me
> 22:34 < pipacs> pappy, have you read the pax-future doc?
> 22:34 < pappy-> pipacs: yeah
> 22:34 < pipacs> in particular d.1 ? ;)
> 22:35 < pipacs> see, i had plans for something similar as well
> 22:35 < pappy-> i stole it
> 22:35 < pipacs> something cheap but still somewhat useful
> 22:35 < pappy-> to be honest.
> 22:35 < pappy-> from your dea
> 22:35 < pappy-> idea
> 22:35 < pappy-> i was just faster :P
> 22:35 < pipacs> although checking for function ptr derefences will be more powerful and useful
> 22:35 < pipacs> hah
> 22:35 < pipacs> i doubt i thought of it first
> 22:35 < pipacs> since it's such a simple idea
> 22:35 < pappy-> well, you planted the seed
> 22:36 < pappy-> and i'm gracious i know you
> 22:36 < pappy-> because without help of people like you people like me would never think of anything like that
> 22:36 < pappy-> and that's what the community owes you
> 22:36 < pappy-> you are making other people look good in front of the users
> 22:36 < pappy-> because we learn much from your sexperience
> 22:36  * pappy- laughs
> 22:36 < pappy-> sorry bout the s
> 22:36 < pappy-> *haha*
> 22:36 < pappy-> <-- white and nerdy
> 22:37 < pappy-> actually i am looking forward to pax-future.txt
> 22:37 < pappy-> and i wonder when you will show the first pieces
> 22:37 < pappy-> because it will be a milestone
> 22:37 < pappy-> and hardened gentoo will love this stuff
> 22:38 < pappy-> everybody is silent
> 22:38 < pappy-> i thought this was going to be a meeting
> 22:38 < pappy-> break the ice guys, i feel lonely
> 22:39 < pappy-> i would like to know who of you guys read the paper
> 22:39 < pappy-> i received lots of positive input on it
> 22:39 < pappy-> what can i do to improve it?
> 22:40 < pipacs> make it shorter maybe... ? :)
> 22:40 < pappy-> *g*
> 22:40 < pappy-> i was trying to get a professional version working
> 22:40 < pappy-> without the novice explanations
> 22:40 < pipacs> when i see 80+ pages for a paper... i tend not to be too motivated to read it from cover to cover ;P
> 22:40 < pappy-> pipacs: well, there is a good index
> 22:40 < pappy-> and you for example can skip chapter 1 and 2 completely
> 22:40 < pappy-> because it deals with endianness, stack layout, etc
> 22:41 < pappy-> i was trying to give a hands-on experience
> 22:41 < voidptr> i only skipped through it
> 22:41 < voidptr> sorry :)
> 22:41 < pappy-> perhaps you are not the right audience for it- the people who loved it all didn't know what a stack pointer is
> 22:41 < voidptr> and i liked the idea, from what i saw, and also now that you explained it here
> 22:42 < pappy-> and for you guys it's probably really bloated
> 22:42 < pappy-> voidptr: thanks for cheering me up :)
> 22:42 < pappy-> phreak``: and you, how did you like the idea?
> 22:42 < pappy-> phreak is my man at the hardened kernel pimping
> 22:43 < pappy-> pipacs: thanks for your time, i appreciate it
> 22:43 < phreak``> pappy-: have to read the backlog :) I was looking at 2.6.19 ;)
> 22:43 < pappy-> pipacs: i can send the log around the world, can i?
> 22:43 < pappy-> phreak``: *grrrr*
> 22:43 < pipacs> oh shit, i forgot about that
> 22:43 < pipacs> after *careful* editing, khm ;P
> 22:44 < pappy-> "khm"?
> 22:44 < pipacs> i hope i was all politically correct this time though ;)
> 22:44 < voidptr> hah
> 22:44 < pappy-> well, who gives a fck about political correctness
> 22:44 < pappy-> now is the time to fuel some greasy jokes about selinux and fedora core
> 22:44 < pappy-> give your best folks!
> 22:44 < pipacs> you'll soon find out if you don't pay attention ;P
> 22:44 < pappy-> it's still logging
> 22:45 < pappy-> i will have to have a word with #gcc upon that frame pointer rtx thing
> 22:45 < pappy-> it's hilarious
> 22:45 < pappy-> on amd64 it uses the right offset
> 22:45 < pappy-> on x86 it doesn't
> 22:48 < pappy-> thanks to all of you for having the chat
> 22:48 < pappy-> i would've brought some catering but irc is not very useful for that
> 22:48 < voidptr> humm, now that i think about it again... i suppose most of the exploitable kernel bugs found would never be prevented by ssp, or even full bounds checking
> 22:49 < voidptr> prevented/catched, whatever you want to call it :)
> 22:49 < pappy-> voidptr: elaborate
> 22:49 < voidptr> well lots of stuff found are logic mistakes
> 22:51 < voidptr> well, lets say that environment sanitation on obsd, ld_preload etc that was recently published.
> 22:51 < voidptr> it's just a bug, application/kernel logic
> 22:51 < pappy-> These functions may be used to get information about the callers of a
> 22:51 < pappy-> function.
> 22:51 < pappy->  -- Built-in Function: void * __builtin_return_address (unsigned int
> 22:51 < pappy->           LEVEL)
> 22:52 < voidptr> an acl system would catch it, yes
> 22:52 < pappy-> pipacs: do you think i can tinker with that in gcc/function.c ?
> 22:52 < pappy-> pipacs: because when gcc/function.c runs, i don't think i can use it
> 22:52 -!- benkoren [n=ben@65.162.43.173] has joined #ssxp
> 22:52 < pappy-> because it would give the address of the function that's generating the object code
> 22:52 < pappy-> benkoren: hi, i didnt forget you, sending you the log ASAP
> 22:52 < benkoren> pappy-: i really appreciate that
> 22:52 < pappy-> voidptr: well, nothing helps you from that
> 22:52 < pappy-> voidptr: the world is free
> 22:53 < pappy-> voidptr: we cannot protect everything everywhere
> 22:53 < pappy-> because it would even contradict our own interests
> 22:53 < pappy-> if everything was ultra secure
> 22:53 < pappy-> you couldn't download something from the web
> 22:53 < pappy-> or not talk to strangers on irc any more
> 22:53 < pappy-> because it would all be restricted
> 22:53 < pappy-> voidptr: the message is to make the difference between what you can do and what can't be done
> 22:54 < pappy-> voidptr: which boils down to giving your users the advantage
> 22:54 < pappy-> so that the pirates attack another ship
> 22:54 < pappy-> not yours
> 22:54 <@ssxp> if they want to sink it, they'll do nonetheless.
> 22:54 < pappy-> whatever you do
> 22:54 < voidptr> sure, but in case of ssp in kernel, what i heard was that it breaks stuff &/or has a notable performance hit
> 22:54 < pappy-> you can ultrasecure your OS and everything around it
> 22:55 < pappy-> if someone walks into your house with a gun, you are done
> 22:55 < voidptr> so, if it has little benefit, i'd personally not use it :)
> 22:55 < pappy-> voidptr: well, i guess SSP has no big chance to catch overflows in the kernel
> 22:55 < pappy-> because that's kind of "out of the scope"
> 22:55 < pappy-> there is buffer overflows every day
> 22:56 < pappy-> just today, look at madwifi
> 22:56 < pappy-> remote execution via network
> 22:56 < pappy-> stack overflow in driver
> 22:56 < voidptr> i see
> 22:56 < pappy-> if it would have been compiled with SSP or something similar, it would probably have prevented that
> 22:56 < pappy-> but if not, there is enough defense left
> 22:56 < pappy-> like pax killing it or grsecurity containing it
> 22:57 < voidptr> well what you would see is your X locking up? ;)
> 22:57 < pappy-> voidptr: yeah, some kind of that way
> 22:57 < voidptr> (and in that case i wouldn't be thankful pax saved me, but i would be annoyed :P)
> 22:58 < voidptr> because i wouldn't know :)
> 22:58 < pappy-> well that's a question of taste
> 22:58 < voidptr> hehe :)
> 22:58 < pappy-> i'd rather be protected and ceased
> 22:58 < pappy-> rather than rooted and running
> 22:58 < voidptr> of course :)
> 22:58 < pappy-> http://user.noxa.de/~pappy/ssxp.log
> 22:59 < benkoren> i have to say i've been running the hardened toolchain with X+KDE on top of it for about a week now and have had no such problems, not that there aren't elseware though
> 22:59 < pappy-> benkoren: ping: http://user.noxa.de/~pappy/ssxp.log
> 22:59 < benkoren> pappy-: thank you
> 22:59 < pappy-> you'Re welcome
> 22:59 < pappy-> codejunky: did you like it?
> 23:00 < pappy-> i wonder where the blonde chicks have been, they said they'd come in the channel and show their boobs around
> 23:01 < voidptr> i'm heading to bed, thanks and good luck
> 23:01 < pappy-> yeah me too
> 23:01 < pappy-> writing a test at school tomorrow
> 23:02 < pappy-> pipacs: thanks again man for stopping by and making a fool out of me just for 4 bytes.
> 23:02 < pappy-> pipacs: next time you just don't say anything :P
> 23:02  * pappy- cuddles pipacs
> 23:03 < pappy-> phreak``: i'm calling it a day
> 23:03 < pappy-> guys, have fun and enjoy
> 23:03 < pappy-> peace out!