| |
| |
| |
|
Comments:
<0> LOL
<0> yeh what
<0> OpenBSD on my new laptop.
<1> nice
<2> yo rip
<3> poor yo
<3> rest in peace, homie
<2> resisio
<2> reisio you up ?
<2> hm
<3> t1: ?
<4> hmm
<3> someone ban Rails- :p
<5> I read that shell scripts can not sanatize properly so they cant setuid
<5> but If I run it though a simple c wrapper first then no problem
<5> hat would defeat my purpose
<5> I am trying to recreate an example of IFS attack
<5> so when user runs a setuid script say thats does /usr/bin/date
<5> i can export PATH=/tmp:$path
<5> put a shell file in /tmp called bin
<5> when they run the setuid script the /tmp/bin is executed
<5> but does not setuid
<5> any suggestions please?
<6> nstary: what are the perms on the file?
<5> I found my problem
<5> the problem was that /bin/su was not setuid root
<6> it normally is not setuid root
<5> oh man, the setuid still doesnt owrk but atleast su does now
<6> su doesnt use setuid to execute a root shell
<6> its a login shell spawn not an interactive one
<5> on all nix?
<6> im only talking *bsd=
<6> because thats what i know :)
<5> right =)
<6> i suggest using sudo instead of su or your own wrapper
<6> you'll spend less time and it'll be more secure
<6> but if you are determined to set your own wrapper up
<6> i suggest writing a c program that reads something like /etc/secret
<6> that has a list of usernames
<6> and spawns a root shell if the username matches a regex through the file
<6> setuid it
<6> and then chmod the file to read only and raise the securelevel
<6> call it rtsh or something obscure
<6> also you dont even have to worry about those type of attacks if you chroot everyone to their home dir
<6> :)
<5> I want to show them an IFS attack
<6> show who?
<5> Im just building a demo box where they can test there hacker skills
<5> customers
<6> heh
<6> give me a crack at it :P
<5> I have already done buffer/heap/stack overflows, hidden files, race conditions
<5> IFS is causing the most issues
<6> well IFS wont happen if you are running the right chmod permissions
<6> and chrooting everyone to their home dir
<6> the os wont even let them dig into other files unless you lower the securelevel
<6> and you cannot lower the securelevel without rebooting the machine
<6> is this for a shell server, webserver, what?
<5> I want the attack to be allowed
<5> then after say no fear
<5> do this to fix it
<5> ie chroot, or do not put . in there path
<5> #define REAL_PATH "/bin/bash"
<5> main(ac, av)
<5> char **av;
<5> {
<5> execv(REAL_PATH, av);
<5> }
<5> im using that for now
<5> run that as setuid
<5> so I do not have to change bash
<5> only problem is I want the user to create the file
<5> if I presetup the box for this and can be vulnerable to anything heh
<6> well what ver of bsd is it?
<5> another cool one similar to your idea
<6> hit me
<5> that was the one
<5> :)
<5> I was thinking too of creating one to gather statistics and use log files, then create some sort of format string in a log file
<5> then when they run the states they get to the next level
<5> whats your suggestion on this?
<6> how many levels?
<6> like uids?
<6> or your wrapper?
<6> heh
<6> or are you just talking about the 'layered-onion' approach to security in general?
<6> you dont want a box to be TOO secure because then you have no forensics
<6> but if you are setting up the box for the purpose of root sploits, well.... linux would be easier
<6> more buffer overflows
<6> you can be like rip and run obsd w/ stack squashing :)
<6> heh
<7> MORNING
<7> **** cap
<7> o **** gucci in da hizzouse
<7> hiden rewtz cuz he will tell on u LOL
Return to
#bsd
or
Go to some related
logs:
normal to be nude
axthrower harhen
#computers
protestitution
trolltopia
meglomainiac
#hardware
#absolutepunk channel
#sex
#beginner
|
|