salut
On Tue, 20 Nov 2001, Rijdnal Groeber wrote:
>
>
> > eu zic asa ca deocamdata i can settle with:
> > - nu exista vre-un executabil SUID root pe sistem (adica ori te logezi pe
> > root ori estu looser till logout)
> ..afara de cazul in care exploateaza ceva in agetty sau login.
> Simpatice sunt si vulnerabilitatile din kernel (ptrace() related), care
> desi aveau nevoie de ceva SUID, sunt o dovada ca nu este neaparat sanatos
> sa te astepti ca un kernel sa fie nevulnerabil.
>
normal ca nu ma bazez pe kernel, dar decat alte solutii e singurul lucru
care pot sa-l fac (in teorie fara o pietra de temelie nu poti construi
nici un sistem informatic relativ sigur)
> > - nu exista vre-un program care sa permita remote login (sshd, etc.., deci
> > consola baiete!!)
> ...sau un daemon pe care si-l agata pe UDP.
>
sau pe icmp
cunosc nu e problema doar ca asa cum se zice "scot ceea ce nu este
neaparat necesar"
> > - vreau sa am userii normali intr-un mediu chroot fara prea multe
> > programele (FARA gcc and stuff!)
> De gcc nu au neaparata nevoie. Daca pot primi mail isi pot trimite singuri
> ce au nevoie.
>
right.
> > - kernelul este cu ultimul openwall
> > - pentru a inlocui lids voi rula un tripwire periodic de pe un cd (si cu
> > database-ul initial pe cd)
> Personal, desi folosesc tripwire, consider ca nu e foarte frumos sa ma
> culc pe o ureche. La o masina cu uptime mare, userul isi poate rula
> sshd-ul trojanat in locul celui cunoscut de tripwire si sa rada apoi
> 'dovada' de pe disc.
> ...Si probabil ca daca se trezese in chroot cu rbash si openwall, careva
> cu ceva experienta ar putea banui ca folosesti tripwire & co..
>
degeaba ruleaza sshd-ul trojanat ca firewall-ul nu permite nici un SYN pe
input (iar UDP doar de la ip-ul nameserverului de la portul 53 catre
porturi destinatie 1024:)
se permite totusi ICMP (degeaba l-as taia lasand doar icmp echo and stuff
ca se pot folosi si acestea pentru un back door)
> > - un firewall ipchains foarte restrictiv (nu numai ca restrictioneaza tot
> > SYN pe INPUT dar si pe OUTPUT cu mici exceptii)
> _mici_ exceptii ? ;)
>
permite ca de pe masina sa te conectezi tcp catre 80,25;
> > - userii ruleaza rbash (restricted bash) si in afara sa lanseze comenzile
> > din cale nu pot face altceva (nu pot folosi cd, rescrie PATH-ul etc...)
> Solutie la ce ma gandesc eu acum (;)): pui rbashu in afara PATH-ului,
> si nu ii lasi sa execute din nici un director in care pot scrie. In fond,
> pot face un link la rbash care se numeste bash si gata cu restricted.
>
nu chiar:
Changing directories with the cd builtin.
Setting or unsetting the values of the SHELL or PATH variables.
Specifying command names containing slashes.
Specifying a filename containing a slash as an argument to the .
builtin command.
Importing function definitions from the shell environment at startup.
Parsing the value of SHELLOPTS from the shell environment at startup.
Redirecting output using the `>', `>|', `<>', `>&', `&>', and `>>'
redirection operators.
Using the exec builtin to replace the shell with another command.
Adding or deleting builtin commands with the `-f' and `-d' options to
the enable builtin.
Specifying the `-p' option to the command builtin.
Turning off restricted mode with `set +r' or `set +o restricted'.
cica nu permite asta
oricum mersi de idee cu path-ul
> > vulnerabilitati identificate pana acum:
> > 1. userii folosesc des pine, netscape DECI exista posibilitatea rularii cu
> > drepturile userului a unor comenzi trimise de cineva (nu vreau sa
> > comentez acum securitatea pine/netscape dar istoria se stie si mai stiu
> > ceva: istoria se repeta!)
> ...Si asta fara sa iei in considerare tampenia (fara margini, de altfel) a
> userului obisnuit. Individu' care executa orice attachement, din
> curiozitate.
> Cu PINE, ajungem la alte frumuseti: stie cineva daca pine se oboseste sa
> foloseasca shell-ul userului pentru a executa comenzi gen 'alternate
> editor'. By default system() foloseste /bin/sh, iar execve() isi baga
> picioarele in orice idee de restricted.
da, aici ar interveni o solutie kernel based pentru controlul executiei
(lids etc...)
>
> > 2. astfel intrat (presupunand ca face un telnet invers pe un port pe care
> > il las pe output catre o masina pe care asculta el) are rbash in chrooted
> > intr-un mediu complet fara SUID root
> Asta cu lipsa de SUID ar putea fi tricky dpdv al omului rau...
>
nu inteleg?
> > 3. ce poate face? isi poate "uploada" prin mail/wget/lynx ce soft vrea,
> > poate ca citeasca .bash_history si sa identifice comenzile care looserul
> > le da cel mai des, si CEL MAi NASHPA: poate redefini comenzile (ssh de
> > exemplu) deoarece rbash nu restrictioneaza si alias si el poate face un
> > alias ssh la un executabil care l-a downloadat si astfel iti ia parolele
> > !!
> Vezi aia cu exec unde are voie sa scrie... Si partea cu exec din pine.
>
din cate vad eu chiar asa este acum
declare -rx
PATH="/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:.:/usr/local/bin"
> > intr-adevar nu o sa ia root pe masina dar nici nu ii trebuie daca masina
> > este workstation si de pe ea intri pe servere and stuff :))
> ...Iar asta e mai bizar de blocat. Singura solutie ar fi sa iei un cleste
> si sa te joci pe la cablul de retea. ;)
>
nu. solutii sunt OTP cu generatoare "externe". problema ramane cu
inlocuirea programului client de autentificare la aplicatiile remote,
astfel poate sa insereze cod DUPA autentificarea care se considera sigura
folosind OTP.
> > posibila solutie: activat process accounting si monitorizat des din root
> > de pe consola si/sau modificat bash sa nu permita alias-uri si alte kestii
> > dubioase...
> ..sau modul care agata execve() si lanseaza nucleara daca incearca sa
> execute procese impure.
>
sau asa
>
> De fapt ce dracu de masina faci aici? Suna a ceva _extrem_ de public.
> Genul de "public" care ar exista pentru o masina lasata in hol la
> rectorat.. sau la Piata Universitatii.
>
masina mea, doar atat (in afara de contul meu care il consider la fel de
nesigur ca celelalte mai am si alte conturi pentru care nu garantez)
:)
----------------------------
Mihai RUSU
"... and what if this is as good as it gets ?"
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
