/ Forside / Teknologi / Internet / Sikkerhed / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Sikkerhed
#NavnPoint
stl_s 37026
arlet 26827
miritdk 20260
o.v.n. 12167
als 8951
refi 8694
tedd 8272
BjarneD 7338
Klaudi 7257
10  molokyle 6481
accton som IDS
Fra : Socketd


Dato : 01-07-03 21:40

Hey group

Sad lidt og kiggede på diverse sikkerheds features i FreeBSD og fandt
frem til en ikke helt dum ide. Jeg har aldrig hørt andre forslå det før
og vil derfor lige spørge jer hvad I synes om det, det kan jo nemt være
jeg har overset noget.

Ok, mange buffer overflow exploits (de fleste vel?) benytter execve()
til at få en shell frem, så vil det ikke være muligt at:

1. Disable accounting i default login class'en (ellers får du en ret
stor log)

2. Opret en login class med accounting. Denne class skal alle dine
daemons, som ikke bruger execve, være medlem af.

Hvis du så nogensinde, med "sa", ser at en daemon har brugt execve() kan
du vel være ret sikker på at det er en buffer overflow, der er blevet
exploited?

Oder was?

mvh
socketd

 
 
Kasper Dupont (01-07-2003)
Kommentar
Fra : Kasper Dupont


Dato : 01-07-03 22:57

Socketd wrote:
>
> Hey group
>
> Sad lidt og kiggede på diverse sikkerheds features i FreeBSD og fandt
> frem til en ikke helt dum ide. Jeg har aldrig hørt andre forslå det før
> og vil derfor lige spørge jer hvad I synes om det, det kan jo nemt være
> jeg har overset noget.
>
> Ok, mange buffer overflow exploits (de fleste vel?) benytter execve()
> til at få en shell frem, så vil det ikke være muligt at:
>
> 1. Disable accounting i default login class'en (ellers får du en ret
> stor log)
>
> 2. Opret en login class med accounting. Denne class skal alle dine
> daemons, som ikke bruger execve, være medlem af.
>
> Hvis du så nogensinde, med "sa", ser at en daemon har brugt execve() kan
> du vel være ret sikker på at det er en buffer overflow, der er blevet
> exploited?

Der er mange daemons, som bruger execve ved normal brug.
F.eks. vil sshd naturligvis have brug for execve, httpd
vil bruge den til CGI scripts, og xinetd vil bruge execve
til næsten alt. I nogle af tilfældene vil der ske setuid
kald inden execve, så man kunne måske tro, det var nok
at kigge efter uid. Men setuid kan kun kaldes hvis det
oprindelige id var root, og du vil jo ikke logge hver
gang en root process kalder execve.

Hvis du endelig kan se, at en given daemon aldrig mere
får brug for execve, hvorfor så logge det? Det ville da
være bedre at helt forhindre det. De ville nok kun kræve
en minimal ændring af kernen for at tilføje et system
kald, som vil forbyde execve for processen selv og dens
fremtidige børn.

En anden idé (som måske ikke har ret meget med dit
forslag at gøre) vil være, når nu du er i gang, at
forhindre brug af ptrace system kaldet. Jeg ved ikke
lige, om FreeBSD har haft nogen huller der, men en
sikker implementering af ptrace er langt fra triviel.
I mange produktionsmiljøer har man alligevel ikke noget
at bruge ptrace til.

--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
It is NOT portable (Linus Benedict Torvalds 1991)

Socketd (01-07-2003)
Kommentar
Fra : Socketd


Dato : 01-07-03 23:51

On Tue, 01 Jul 2003 23:57:27 +0200
Kasper Dupont <kasperd@daimi.au.dk> wrote:

> Der er mange daemons, som bruger execve ved normal brug.
> F.eks. vil sshd naturligvis have brug for execve, httpd
> vil bruge den til CGI scripts, og xinetd vil bruge execve
> til næsten alt. I nogle af tilfældene vil der ske setuid
> kald inden execve, så man kunne måske tro, det var nok
> at kigge efter uid. Men setuid kan kun kaldes hvis det
> oprindelige id var root, og du vil jo ikke logge hver
> gang en root process kalder execve.

jeg vil som sagt kun bruge accounting på daemons som ikke bruger execve
(dog ok til opstart).

> Hvis du endelig kan se, at en given daemon aldrig mere
> får brug for execve, hvorfor så logge det?

Vil mene noget af det vigtigst er at opdage et indbrud (intet kan jo
blive 100% sikkert), så derfor logger jeg alt hvad jeg kan komme til
(overdrivelse++).

>Det ville da
> være bedre at helt forhindre det. De ville nok kun kræve
> en minimal ændring af kernen for at tilføje et system
> kald, som vil forbyde execve for processen selv og dens
> fremtidige børn.

Mener Poul Henning Kamp engang snakket om noget ala det ved
LinuxForum!?!?

> En anden idé (som måske ikke har ret meget med dit
> forslag at gøre) vil være, når nu du er i gang, at
> forhindre brug af ptrace system kaldet. Jeg ved ikke
> lige, om FreeBSD har haft nogen huller der, men en
> sikker implementering af ptrace er langt fra triviel.
> I mange produktionsmiljøer har man alligevel ikke noget
> at bruge ptrace til.

Ved faktisk ikke hvordan det ser ud i FreeBSD, måske nogen BSD folk
herinde ved det?

mvh
socketd

Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408938
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste