[SHARE to FreeBSD kernel team]a little idea for preventing user stack from hacker attacking

Raffeale

Active Member

Reaction score: 35
Messages: 216

today , i think a lot about the explit stack , i want to share it to freebsd , i dont know whether the idea is right or not!
as some internet program's some function has bugs , maybe it cause the stack overflow (overwrite by a function's local variable) the hacker will construct some speical opcode to run some function , for example:
they can push an address to a system function and some parameter . when they do it , the stack pointer is fixed ,why ? when you call a function ,you have to pass the parameter to it , that means you must push the parameter to the stack , for example , you will call execve system function , you have to pass the path and arvg , so hacker must construct a parameter in stack and some parameter is pointer (example : execv function 's path) .that means the path parameter must push the stack , the hacker push a stack pointer to stack (this stack pointer which point to a program path ,and the path have to push the stack as well ), when this happen , we can let the system know whether this calling is from user space? we can check the stack frame to check the return address which should in .text address space. how to do it , i have a idea to do it , we can use the /ld-elf.so to make a interception layer(dynamic link library middle layer) for program's dynamic link ,and we make some code in the middle layer ,the middle layer is between program's dynamic link library and program .when some program is loaded the ld-elf will load the .so (i dont sure if this is right for freebsd) and put the some function address into user program addresss space .
user program:
libc : execv -> 0x50000 (loaded addresss)
interception layer : libc->execv 0x60000
user space execv=> 0x60000 (let the elf linker make a middle layer to prevent attacking)
in user code:
look like this : call 0x600000

interception(0x600000):
push rbx
mov rbx, [rsp+8]
cmp rb , xxxxxx (is it the rbx in .text and the last opcode must have to an address , because thi s is long call so the last opcode have an address which interception layer function address , so we can check the last opcode.address ==interception address? if they are not same that means the calling is invalid , may be the stack have been hacking by hacker , once we found the like this attack glue , we can abort execution)
pop rbx
jmp real_address


there is one important thins is that we must set this interception page attribut to x , it can't be read and write , only execute (to prevent hacker read it and change it , this methos can prevent the hacker guess the some function's address , because the program call the interception first and interception jmp into real function )
one more thing:
when we have a random stack pointer for each programs ,that means the attacking is invalid and just cause a core dump.
we have to use randome stack pointer for each programs, i mean that use dynamicly allocate an rando address stack pointer for each program , the hacker will have no idea , why because the have to guess the stack pointr address and use it to push a valide parameter into stack then they can run some function!
i really like the freebsd , i get a lot help from here , i just want the freebsd to be more safe , more and more.
 

Mjölnir

Daemon

Reaction score: 1,502
Messages: 2,114

execve(2) executes programs, not functions. Please search for the term ASLR and try to understand why it does not prevent some nasty buffer overflow attacks.
 
OP
R

Raffeale

Active Member

Reaction score: 35
Messages: 216

i just make an example for this,it's not important whether the execve is a function. this method could prevent stack from attacking. and it could check whether the calling is valid or not
 
OP
R

Raffeale

Active Member

Reaction score: 35
Messages: 216

readelf -a /lib/libc.so.7 |grep execv ,you can find it.
 

mark_j

Daemon

Reaction score: 682
Messages: 1,192

Honestly, I think this is a solution in search of a problem.

You should sign up to freebsd-arch and pose this question to them. All I can say is this is, if I understand you correctly, mostly covered with gcc/clang's stack-protector flag(s), the use of stackguard-type properties (see here), the settings in the system ( sysctl -da|grep stack) and so on.

Also, it wouldn't hurt for you to investigate how the build is done now and the protections performed when you build(7) the system.

I'm not discouraging you posting here, I just suggest you'll get more thorough feedback if you post to freebsd-arch. Join it here: freebsd-arch
 
OP
R

Raffeale

Active Member

Reaction score: 35
Messages: 216

i just give an idea to the team,i want to them to do it,thank your suggestion, i will register freebsd arch and post there
 
Top