---

Skal man nu også til at have en rootkittjekker ?
http://www.pcworld.dk/art/8595?a=block&i=81

I forvejen har jeg
Antivirus
Antispyware
Firewall

---

Lars wrote:
> Skal man nu også til at have en rootkittjekker ?
> http://www.pcworld.dk/art/8595?a=block&i=81
>
> I forvejen har jeg
> Antivirus
> Antispyware
> Firewall

   http://sikkerhed-faq.dk

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Alex Holst <a@mongers.org> wrote:

> Lars wrote:
>
> > Skal man nu også til at have en rootkittjekker ?
> > http://www.pcworld.dk/art/8595?a=block&i=81
> >
> > I forvejen har jeg
> > Antivirus
> > Antispyware
> > Firewall
>
> http://sikkerhed-faq.dk

Der står heller ikke noget om rootkits.

Den type programmer som OP nu har på sin computer lider alle under den
begrænsning, at de er afhængig af det styresystem de arbejder under. Det
karakteristiske ved rootkits er, at de kan snyde selve styresystemet.

Så hvis det software fra Grisoft, der er omtalt på PC World (DK)
virkelig kan afslører og fjerne rootkits bør man selvfølgelig osse
overveje det.

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>Den type programmer som OP nu har på sin computer lider alle under den
>begrænsning, at de er afhængig af det styresystem de arbejder under. Det
>karakteristiske ved rootkits er, at de kan snyde selve styresystemet.

Hvilken forskel mener du, der er på antivirus- og antirootkit-
programmer i den sammenhæng?

Antirootkit-dimsen kører ikke under operativsystemet eller hur?

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> wrote:

> hlexa@hotmail.com (Axel Hammerschmidt) writes:
>
> >Den type programmer som OP nu har på sin computer lider alle under den
> >begrænsning, at de er afhængig af det styresystem de arbejder under. Det
> >karakteristiske ved rootkits er, at de kan snyde selve styresystemet.
>
> Hvilken forskel mener du, der er på antivirus- og antirootkit-
> programmer i den sammenhæng?
>
> Antirootkit-dimsen kører ikke under operativsystemet eller hur?

På begge spørgsmål; hvad forstår du med anti-rootkit programmer/dimser?

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>> Hvilken forskel mener du, der er på antivirus- og antirootkit-
>> programmer i den sammenhæng?
>>
>> Antirootkit-dimsen kører ikke under operativsystemet eller hur?

>På begge spørgsmål; hvad forstår du med anti-rootkit programmer/dimser?

Du skriver, at antivirus-programmer har det problem, at de kører
under operativsystemet. Det er helt rigtigt. Det betyder også, at
der er grænser for, hvad de kan se, hvis operativsystemet ikke er
rent for rootkits. Antivirus-programmerne kan køre saligt videre
i den tro, at alt er godt, for root-kittet gemmer verdens sande
tilstand.

Dernæst skriver du:

>Så hvis det software fra Grisoft, der er omtalt på PC World (DK)
>virkelig kan afslører og fjerne rootkits bør man selvfølgelig osse
>overveje det.

Mit spørgsmål er derfor: hvis antivirus-programmerne ikke kan se,
at der er noget galt, hvordan skulle den nye software fra Grisoft
så kunne?

Rent faktisk forsøger mange antivirus-programmer allerede at finde
rootkits - det er jo bare en anden type malware, der kan opdages
og elimineres som alle andre typer malware. Forudsat at antivirus-
programmet blev installeret, inden det første rootkit-agtige
malware kom forbi.

Den reelle nyhed fra PC World er derfor, at Grisoft har været
alvorligt bagud med deres anti-malware-produkter. Men at de nu er
ved at indhente noget af det forsømte.

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> wrote:

> hlexa@hotmail.com (Axel Hammerschmidt) writes:

<snip>

> Dernæst skriver du:
>
> >Så hvis det software fra Grisoft, der er omtalt på PC World (DK)
> >virkelig kan afslører og fjerne rootkits bør man selvfølgelig osse
> >overveje det.
>
> Mit spørgsmål er derfor: hvis antivirus-programmerne ikke kan se,
> at der er noget galt, hvordan skulle den nye software fra Grisoft
> så kunne?

Der stod "hvis". Jeg ved det heller ikke.

> Rent faktisk forsøger mange antivirus-programmer allerede at finde
> rootkits - det er jo bare en anden type malware, der kan opdages
> og elimineres som alle andre typer malware. Forudsat at antivirus-
> programmet blev installeret, inden det første rootkit-agtige
> malware kom forbi.

Som jeg har forstået det, leder de alle efter sekundære tegn på (spor
efter) rootkit. Det er de nød til. Hvordan de så fjerner det er da et
godt spørgsmål.

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>Som jeg har forstået det, leder de alle efter sekundære tegn på (spor
>efter) rootkit. Det er de nød til. Hvordan de så fjerner det er da et
>godt spørgsmål.

Forudsat antivirus-programmet kom først, er det "bare" rootkit'ets
installationsprogram, der skal findes. Det er mere kompliceret end
for vira og andre sager.

Hvis man først har fået noget grimt ind (f.eks. hvis der findes de
omtale sekundære spor), så er der efter min mening kun én ting at
gøre: forfra.

Der findes ikke noget anti-malware-program, der kan give en 100%
sikkerhed for, at alt det grimme er blevet fjernet. Der er mange
typer malware efterhånden, der opdaterer sig selv fra nettet. Det
første stykke malware er altså bare en "downloader", der i sig
selv ikke har nogen mission - andet end at installere noget andet.

Det betyder altså, at man ikke har fjernet det egentlige problem,
hvis man fjerner downloaderen.

Samtidig er det også mere "tricky" for anti-malware-folket at få
fat i de egentlige payloads, for de distribueres ikke på sædvanlig
vis.

Alt i alt betragter jeg anti-det-ene-og-det-andet som assistance
til at opdage ting, der IKKE er installeret, men som residerer på
pc'en som et installationsprogram. Indtil et virusfirma tilbyder
kunderne millioner af kroner, hvis de bliver inficeret, vil jeg
tage det som producenternes indrømmelse af, at de ikke virker.

Derfor er Alex' henvisning til "hold selv din pc ren" vigtigere
end at spilde penge og CPU-kraft på anti-det-ene-og-det-andet.

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> writes:

>Forudsat antivirus-programmet kom først, er det "bare" rootkit'ets
>installationsprogram, der skal findes. Det er mere kompliceret end
>for vira og andre sager.

D'oh. Det er IKKE mere end kompliceret end for vira og andre sager.

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> wrote:

> hlexa@hotmail.com (Axel Hammerschmidt) writes:
>
> >Som jeg har forstået det, leder de alle efter sekundære tegn på (spor
> >efter) rootkit. Det er de nød til. Hvordan de så fjerner det er da et
> >godt spørgsmål.
>
> Forudsat antivirus-programmet kom først, er det "bare" rootkit'ets
> installationsprogram, der skal findes. Det er mere kompliceret end
> for vira og andre sager.
>
> Hvis man først har fået noget grimt ind (f.eks. hvis der findes de
> omtale sekundære spor), så er der efter min mening kun én ting at
> gøre: forfra.

Eller man kan boote fra en CD med et "rent" OS og gå videre med at rense
sin computer derfra. Det findes faktisk allerede. Og der kan sikkert
bruges andre metoder; et virtuel OS på et fremmed værtsoperativsystem,
f.eks. Det findes osse allerede.

Men her var det Grisoft. Og et rootkit er væsentligt forskellig fra
virus, spyware og orme.

<snip>

> Derfor er Alex' henvisning til "hold selv din pc ren" vigtigere
> end at spilde penge og CPU-kraft på anti-det-ene-og-det-andet.

Nej, for spørgsmålet er netop, hvordan rootkit er forskelligt fra virus,
spyware og det en firewall beskytter mod. Det har henvisningen ikke
noget svar på.

Den henvisning har i det hele taget ikke svar på ret meget.

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>> Hvis man først har fået noget grimt ind (f.eks. hvis der findes de
>> omtale sekundære spor), så er der efter min mening kun én ting at
>> gøre: forfra.

>Eller man kan boote fra en CD med et "rent" OS og gå videre med at rense
>sin computer derfra.

Hvordan renser man sin computer for malware, der blev udgivet for
10 sekunder siden? Hvilken software på den CD kan detektere så ny
malware?

Husk på at malware netop downloades dynamisk nu. Så en antivirus-
opdatering, der er et par timer gammel, er håbløst forældet.

Bevares, hvis du har et referencesystem at sammenligne med (f.eks.
en tripwire-database), kan du komme langt. Men den kan ikke tage
højde for ubehageligheder, der gemmer sig i registry'et, så det
er faktisk heller ikke nogen god løsning.

>Det findes faktisk allerede. Og der kan sikkert bruges andre
>metoder; et virtuel OS på et fremmed værtsoperativsystem,
>f.eks. Det findes osse allerede.

Antag at jeg skifter 50 bytes ud i en vilkårlig fil på din pc.
Det er alt rigeligt til at give dig sikkerhedsmæssige problemer
i fremtiden.

Du aner ikke, hvad jeg har lavet. Programmet, der har pillet,
er ikke på din pc længere (den kører sig selv, og så sletter
den sig igen).

Hvad gør du for at rette op på skaden?

>Men her var det Grisoft. Og et rootkit er væsentligt forskellig fra
>virus, spyware og orme.

Nej, det er præcis den samme problematik. Der er absolut ingen
forskel overhovedet.

Eneste detalje er, at ens anti-rootkit-software er nødt til at være
på plads, INDEN man får et rootkit ind ad døren. Virus kan være
stort set umuligt at slippe 100% af med, hvis det kommer først.
Rootkit-konceptet *er* umuligt at slippe af med, medmindre dit
anti-rootkit-program kører i ring 0 og kun anvender egne drivere.

Det er i praksis umuligt på pc-platformen.

>Nej, for spørgsmålet er netop, hvordan rootkit er forskelligt fra virus,
>spyware og det en firewall beskytter mod. Det har henvisningen ikke
>noget svar på.

Der er ingen forskel.

Mvh.
   Klaus.

---

Axel Hammerschmidt wrote:
> Klaus Ellegaard <klausellegaard@msn.com> wrote:
>
>> hlexa@hotmail.com (Axel Hammerschmidt) writes:
>
> <snip>
>
>> Dernæst skriver du:
>>
>>> Så hvis det software fra Grisoft, der er omtalt på PC World (DK)
>>> virkelig kan afslører og fjerne rootkits bør man selvfølgelig osse
>>> overveje det.
>> Mit spørgsmål er derfor: hvis antivirus-programmerne ikke kan se,
>> at der er noget galt, hvordan skulle den nye software fra Grisoft
>> så kunne?
>
> Der stod "hvis". Jeg ved det heller ikke.

Jeg kender svaret. Som du kan se af Klaus' svar, kender han det også.
Men det tror du ikke på, vel?

Vores generelle råd er ubrugelige fordi vi ikke fabler om hijacker logs,
og nævner tilfældige anti-malware programmer der alligevel ikke virker?

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

---

Alex Holst <a@mongers.org> wrote:

> Axel Hammerschmidt wrote:
>
> > Klaus Ellegaard <klausellegaard@msn.com> wrote:
> >
> >> hlexa@hotmail.com (Axel Hammerschmidt) writes:
> >
> > <snip>
> >
> >> Dernæst skriver du:
> >>
> >>> Så hvis det software fra Grisoft, der er omtalt på PC World (DK)
> >>> virkelig kan afslører og fjerne rootkits bør man selvfølgelig osse
> >>> overveje det.
> >>
> >> Mit spørgsmål er derfor: hvis antivirus-programmerne ikke kan se,
> >> at der er noget galt, hvordan skulle den nye software fra Grisoft
> >> så kunne?
> >
> > Der stod "hvis". Jeg ved det heller ikke.
>
> Jeg kender svaret. Som du kan se af Klaus' svar, kender han det også.

Sikkert. Det viser bare din begrænsing. Jeg svarer på et spørgsmål, om
det nye software fra Grisoft.

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>> Jeg kender svaret. Som du kan se af Klaus' svar, kender han det også.

>Sikkert. Det viser bare din begrænsing. Jeg svarer på et spørgsmål, om
>det nye software fra Grisoft.

Og som vi lige er blevet enige om, så virker det ikke. Det kan være,
at det virker mod dårligt implementerede rootkits, men det gør bare
situationen værre: Så får man ikke en advarsel, hvis der kommer et
"ordentligt" rootkit forbi. Falsk sikkerhed med andre ord.

Hvilket gør, at vi er tilbage ved Alex' oprindelige pointe: det
eneste, der duer, er at bruge det mellem ørerne. Og at læse OSS'en.

Mvh.
   Klaus.

---

On Sun, 2007-04-29 at 11:57 +0200, Axel Hammerschmidt wrote:
> > http://sikkerhed-faq.dk
>
> Der står heller ikke noget om rootkits.

Erstat virus med rootkits.

Det generelle råd er at bruge tiden på præventive løsninger, i stedet
for reaktiv løsninger.

---

Christian E. Lysel <christian@examples.net> wrote:

> On Sun, 2007-04-29 at 11:57 +0200, Axel Hammerschmidt wrote:
>
> > > http://sikkerhed-faq.dk
> >
> > Der står heller ikke noget om rootkits.
>
> Erstat virus med rootkits.
>
> Det generelle råd er at bruge tiden på præventive løsninger, i stedet
> for reaktiv løsninger.

De råd der står der er så generelle at de ikke kan bruges til ret meget
om overhovedet noget som helst. Og det er rent ud sagt pisse irriterende
at han hele tiden poster sit link. Jeg opfatter det efterhånden som
spam.

---

On Sun, 2007-04-29 at 13:54 +0200, Axel Hammerschmidt wrote:
> De råd der står der er så generelle at de ikke kan bruges til ret meget
> om overhovedet noget som helst.

Det mener jeg ikke er rigtigt. Følgende adresser vil jeg ikke kalde
generelle:

http://sikkerhed-faq.dk/auto/
http://sikkerhed-faq.dk/w2k_workstation
http://home18.inet.tele.dk/madsen/windows/tjenester/
http://sikkerhed-faq.dk/brugere#outlook (kik også på afsnittene om
Internet Explore, Netscape Navigator, Mozilla Firefox).

> Og det er rent ud sagt pisse irriterende
> at han hele tiden poster sit link. Jeg opfatter det efterhånden som
> spam.

Det er 14 skribenter, plus det løse fra gruppen du snakker om...ikke én..

---

Christian E. Lysel <christian@examples.net> wrote:

> On Sun, 2007-04-29 at 13:54 +0200, Axel Hammerschmidt wrote:
>
> > De råd der står der er så generelle at de ikke kan bruges til ret meget
> > om overhovedet noget som helst.
>
> Det mener jeg ikke er rigtigt. Følgende adresser vil jeg ikke kalde
> generelle:

<snip>

Så er vi uenige.

> > Og det er rent ud sagt pisse irriterende at han hele tiden poster sit
> > link. Jeg opfatter det efterhånden som spam.
>
> Det er 14 skribenter, plus det løse fra gruppen du snakker om...ikke én.

Det er den ene, der spammer.

Hvis diskussionen skal forsætte, bør den flyttes til misbrug.

---

On Sun, 2007-04-29 at 14:47 +0200, Axel Hammerschmidt wrote:
> Så er vi uenige.

Hvad mener du der er generelt ved de links jeg postede?

---

On Sun, 2007-04-29 at 20:06 +0200, Axel Hammerschmidt wrote:
> Eller man kan boote fra en CD med et "rent" OS og gå videre med at rense
> sin computer derfra.

Det lyder som en dårlig strategi.

Et rootkit kan være skjult meget godt...selv et "rent" OS behøver ikke
at kunne finde det.

Du er igang med endnu et våbenkapløb.

> Men her var det Grisoft. Og et rootkit er væsentligt forskellig fra
> virus, spyware og orme.

Nej.

Et rootkit er en metode at skjule sig på. Ovenstående kan godt bruge
rootkit's

---

Den Sun, 29 Apr 2007 21:26:48 +0200 skrev Christian E. Lysel:
> On Sun, 2007-04-29 at 20:06 +0200, Axel Hammerschmidt wrote:
>> Eller man kan boote fra en CD med et "rent" OS og gå videre med at rense
>> sin computer derfra.
>
> Det lyder som en dårlig strategi.
>
> Et rootkit kan være skjult meget godt...selv et "rent" OS behøver ikke
> at kunne finde det.

Et OS der ikke er inficeret af root-kittet vil kunne finde det lige
så nemt som ethvert andet skjult program.

Fidusen i et root-kit er ikke at det skjuler sig, men at det laver
indgreb i OS'et så det selv bliver usynligt. Det kan såmænd ligge
som C:\ROOTKIT.EXE uden at man kan se det, så derfor behøver det
under normale omstændigheder slet ikke skjule sig.

> Du er igang med endnu et våbenkapløb.

Det kommer an på hvordan det gøres. Har man noget i retning af rpm eller
dpgk's md5-databaser, med mulighed for at checke det online, er det
sådanset bare at checke at alt er som det skal være (alt inkluderer
naturligvis bootloader), og fjerne eventuelle opstarts-filer hverken
systemet eller brugeren vil kendes ved.

For windows gælder det naturligvis ikke kun filer men også reg-keys.

Known-good vs. known-bad.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>Det kommer an på hvordan det gøres. Har man noget i retning af rpm eller
>dpgk's md5-databaser, med mulighed for at checke det online, er det
>sådanset bare at checke at alt er som det skal være (alt inkluderer
>naturligvis bootloader), og fjerne eventuelle opstarts-filer hverken
>systemet eller brugeren vil kendes ved.

Jep. Men tjekket skal også inkludere dokumenter og andre bruger-
filer, der kan have en form for aktivt indhold. Specielt i systemer,
hvor der er meget lille afstand mellem bruger og superbruger. Det
gælder især Windows (før Vista UAC). Ubuntus sudo-koncept gør den
også til et teoretisk offer, omend Linux traditionelt set er sikrere
i kraft af den større afstand mellem system og brugergrænseflade.

Så vi er tilbage i noget à la tripwire, og det er ikke specielt
morsomt at holde sådan en fætter opdateret.

Mvh.
   Klaus.

---

Den Sun, 29 Apr 2007 20:05:00 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>Det kommer an på hvordan det gøres. Har man noget i retning af rpm eller
>>dpgk's md5-databaser, med mulighed for at checke det online, er det
>>sådanset bare at checke at alt er som det skal være (alt inkluderer
>>naturligvis bootloader), og fjerne eventuelle opstarts-filer hverken
>>systemet eller brugeren vil kendes ved.
>
> Jep. Men tjekket skal også inkludere dokumenter og andre bruger-
> filer, der kan have en form for aktivt indhold. Specielt i systemer,
> hvor der er meget lille afstand mellem bruger og superbruger.

Både og. Er det installeren eller selve root-kit'et vi leder efter?

Et root-kit kan ikke gemme sig i dokumenter, for at falde i root-kit
kategorien, skal det nødvendigvis køre som en del af OS'et, og
dermed starte sammen med OS'et.

Installeren er en hel anden sag, den kan være gemt i alt der (enten
tilsigtet eller via et exploit) kan køre et program eller script der
har adgang til filsystemet.

Men hvis det er tilfældet, hjælper strategien med at tage backup af
sine dokumenter og genisntallere OS'et ikke engang - backup'en vil
sandsynligvis også indeholde det dokument installeren er gemt i.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Sun, 2007-04-29 at 20:22 +0000, Kent Friis wrote:
> Et root-kit kan ikke gemme sig i dokumenter, for at falde i root-kit
> kategorien, skal det nødvendigvis køre som en del af OS'et, og
> dermed starte sammen med OS'et.

Jeg forstår ikke de "regler" du "opfinder" for hvad et rootkit kan og
ikke kan.

Hvad forhindre et rootkit i at starte fra et word dokument, der ligger i
start folderen på windows, og som udnytter et bufferoverflow i word?

---

Den Sun, 29 Apr 2007 22:44:16 +0200 skrev Christian E. Lysel:
> On Sun, 2007-04-29 at 20:22 +0000, Kent Friis wrote:
>> Et root-kit kan ikke gemme sig i dokumenter, for at falde i root-kit
>> kategorien, skal det nødvendigvis køre som en del af OS'et, og
>> dermed starte sammen med OS'et.
>
> Jeg forstår ikke de "regler" du "opfinder" for hvad et rootkit kan og
> ikke kan.

Det er ikke hvad det kan og ikke kan, det er definitionen af et
rootkit. Et rootkit ændrer funktionaliteten af OS'et for at skjule
sig, og for at gøre det, skal det være aktivt sammen med OS'et. Det
vil normalt betyde det skal starte sammen med OS'et, der er ikke
meget pointe i først at være skjult når brugeren har åbnet et bestemt
dokument, for så kunne han jo finde rootkit'et inden.

> Hvad forhindre et rootkit i at starte fra et word dokument, der ligger i
> start folderen på windows, og som udnytter et bufferoverflow i word?

Jeg har allerede nævnt start-folderen. Det fremgik måske ikke tydeligt,
men alt deri (og alle andre autostart features) skal enten verificeres
eller fjernes derfra. Da word-dokumentet ikke kan verificeres, skal
det dermed fjernes derfra, hvorved det er uskadeliggjort indtil videre.
Brugeren må så selv vurdere om det er et af hans dokumenter.

Hvis root-kit'et inficerer eksisterende dokumenter (som en macro-virus),
har vi et problem, i og med at der ikke eksisterer en known-good at
sammenligne med.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Sun, 2007-04-29 at 19:58 +0000, Kent Friis wrote:
> > Et rootkit kan være skjult meget godt...selv et "rent" OS behøver ikke
> > at kunne finde det.
>
> Et OS der ikke er inficeret af root-kittet vil kunne finde det lige
> så nemt som ethvert andet skjult program.
>
> Fidusen i et root-kit er ikke at det skjuler sig, men at det laver
> indgreb i OS'et så det selv bliver usynligt. Det kan såmænd ligge
> som C:\ROOTKIT.EXE uden at man kan se det, så derfor behøver det
> under normale omstændigheder slet ikke skjule sig.

Et rootkit kan udmærket skjule sig og lave indgreb i OS'et.

> Det kommer an på hvordan det gøres. Har man noget i retning af rpm eller
> dpgk's md5-databaser, med mulighed for at checke det online, er det
> sådanset bare at checke at alt er som det skal være (alt inkluderer
> naturligvis bootloader), og fjerne eventuelle opstarts-filer hverken
> systemet eller brugeren vil kendes ved.

Det forudsætter der kun er disse filer på maskinen og boot sectoren også
gennemgåes.

Hvad er checksummen på følgende filer på fedora?

/sbin/zfcpconf.sh, /sbin/udev-stw,
udev-stw, /fsckoptions, /etc/sysconfig/readonly-root
+ /etc/rc.readonly, /etc/rc.serial. Hvad bruges de til?

Filerne eksistere ikke i min installation af fedora, men hvis jeg
opretter /sbin/zfcpconf.sh vil indholdet blive kørt som root under
opstarten. Ligeledes for de andre filer.


Er det ikke mere reglen at OS'et fylder mindst i en installation, men
det derimod er data og 3. parts programmer der fylder?



Endvidere forudsætter det også at angriberen ikke mappe et netværksdrev,
eller bruger ligende strategier....find selv på flere metoder hvor
ovenstående ikke holder...

> For windows gælder det naturligvis ikke kun filer men også reg-keys.

Ja og .ini filer og ADS filstrukturen og mappet drev ved fx daemon
tools, krypteret kataloger af brugeren, 3. parts software man ikke har
checksum af.... find selv på mere.

---

Den Sun, 29 Apr 2007 23:11:25 +0200 skrev Christian E. Lysel:
> On Sun, 2007-04-29 at 19:58 +0000, Kent Friis wrote:
>> > Et rootkit kan være skjult meget godt...selv et "rent" OS behøver ikke
>> > at kunne finde det.
>>
>> Et OS der ikke er inficeret af root-kittet vil kunne finde det lige
>> så nemt som ethvert andet skjult program.
>>
>> Fidusen i et root-kit er ikke at det skjuler sig, men at det laver
>> indgreb i OS'et så det selv bliver usynligt. Det kan såmænd ligge
>> som C:\ROOTKIT.EXE uden at man kan se det, så derfor behøver det
>> under normale omstændigheder slet ikke skjule sig.
>
> Et rootkit kan udmærket skjule sig og lave indgreb i OS'et.

*Behøver* ikke. As in "spild af tid at skrive koden til at gøre det".

>> Det kommer an på hvordan det gøres. Har man noget i retning af rpm eller
>> dpgk's md5-databaser, med mulighed for at checke det online, er det
>> sådanset bare at checke at alt er som det skal være (alt inkluderer
>> naturligvis bootloader), og fjerne eventuelle opstarts-filer hverken
>> systemet eller brugeren vil kendes ved.
>
> Det forudsætter der kun er disse filer på maskinen og boot sectoren også
> gennemgåes.
>
> Hvad er checksummen på følgende filer på fedora?
>
> /sbin/zfcpconf.sh, /sbin/udev-stw,
> udev-stw, /fsckoptions, /etc/sysconfig/readonly-root
> + /etc/rc.readonly, /etc/rc.serial. Hvad bruges de til?
>
> Filerne eksistere ikke i min installation af fedora, men hvis jeg
> opretter /sbin/zfcpconf.sh vil indholdet blive kørt som root under
> opstarten. Ligeledes for de andre filer.

Mener du en anden mappe? /sbin indeholder normalt programmer der kun
er interessante for root, det kunne fx være /sbin/shutdown, så at
køre alt hvad der ligger i /sbin under opstart virker ikke realistisk.

Men bortset fra det, så hører de under "eventuelle opstartsfiler",
og vi har allerede konstateret at systemet ikke vil kendes ved dem.

Så enten må brugeren sige god for at han har lavet dem (jaja, kæmpe
hul, stole på brugeren...) eller også skal de væk.

> Er det ikke mere reglen at OS'et fylder mindst i en installation, men
> det derimod er data og 3. parts programmer der fylder?

Det interessante er ting der bliver loadet under opstarten. Ting der
først bliver loadet når et tilfældigt program startes tre timer efter
er ikke specielt brugbart for et rootkit, der så først vil blive
aktiveret da. Med risiko for at rootkittet bliver opdaget inden.

> Endvidere forudsætter det også at angriberen ikke mappe et netværksdrev,
> eller bruger ligende strategier....find selv på flere metoder hvor
> ovenstående ikke holder...

Der skal stadig være et sted det netværksdrev mappes under opstarten,
og det script har vi allerede checket...

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Sun, 2007-04-29 at 21:07 +0000, Kent Friis wrote:
> der er ikke
> meget pointe i først at være skjult når brugeren har åbnet et bestemt
> dokument, for så kunne han jo finde rootkit'et inden.

Dokumentet kan startes af andre end brugeren, fx OS'et.

> Jeg har allerede nævnt start-folderen. Det fremgik måske ikke tydeligt,
> men alt deri (og alle andre autostart features) skal enten verificeres

Ligger start folderen det samme sted for det inficeret OS som for det OS
der undersøger maskinen?

Hvordan gennemgår man alle autostart features?

Er et baggrunds jepg med bufferoverflow, en del af autostart?

---

Den Sun, 29 Apr 2007 23:22:22 +0200 skrev Christian E. Lysel:
> On Sun, 2007-04-29 at 21:07 +0000, Kent Friis wrote:
>> der er ikke
>> meget pointe i først at være skjult når brugeren har åbnet et bestemt
>> dokument, for så kunne han jo finde rootkit'et inden.
>
> Dokumentet kan startes af andre end brugeren, fx OS'et.

Ikke når vi har checket hvad OS'et starter.

>> Jeg har allerede nævnt start-folderen. Det fremgik måske ikke tydeligt,
>> men alt deri (og alle andre autostart features) skal enten verificeres
>
> Ligger start folderen det samme sted for det inficeret OS som for det OS
> der undersøger maskinen?

På det tidspunkt hvor OS'et skal loade rootkit'et har rootkit'et ikke
haft mulighed for at ændre hvor OS'et henter det fra, og dermed er det
den placering der står i registry på disken der vil gælde. Det kan
sagtens checkes.

> Hvordan gennemgår man alle autostart features?

Det kræver naturligvis grundigt kendskab til OS'et.

> Er et baggrunds jepg med bufferoverflow, en del af autostart?

Ikke-kendte sikkerhedshuller kan du aldrig gardere dig imod, rootkit
eller ej.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Apr 29, 1:54 pm, h...@hotmail.com (Axel Hammerschmidt) wrote:
> De råd der står der er så generelle at de ikke kan bruges til ret meget
> om overhovedet noget som helst.

Nej, uha da - at lære folk at bruge den lille fedtklump mellem ørerne
i stedet for at installere the latest greatest fra spywarefri.dk, det
er søreme for generelt og ubrugeligt.

> Og det er rent ud sagt pisse irriterende at han hele tiden poster sit link.
> Jeg opfatter det efterhånden som spam.

Det skyldes jo kun at du ikke fatter en bjælde af det der står på de
sider. Det har vi fået demonstreret i mange tråde efterhånden.

\\kristian

---

Den 29-04-07 23.36 skrev Kristian Thy følgende:
> On Apr 29, 1:54 pm, h...@hotmail.com (Axel Hammerschmidt) wrote:
>> De råd der står der er så generelle at de ikke kan bruges til ret meget
>> om overhovedet noget som helst.
>
> Nej, uha da - at lære folk at bruge den lille fedtklump mellem ørerne
> i stedet for at installere the latest greatest fra spywarefri.dk, det
> er søreme for generelt og ubrugeligt.

Lad os lige lægge uenigheden om det fornuftige i diverse
beskyttelsesprogrammer til side og se på Alex' første indlæg i denne tråd.

Hvad signalerer det indlæg?

1. Jeg vil gerne hjælp spørgeren med at vurdere det brugbare i en
rootkit-tjekker ved at henvise ham til en tekst om rootkit.

2. Jeg kom til at klikke på Send, efter jeg havde skrevet linket,
hvorfor min forklaring ikke kom med i indlægget.

3. Jeg ved så meget om det her, at der ikke er nogen grund til at spilde
min tid med at forklare spørgeren, hvorfor jeg bringer et link til en
side, der ikke nævner rootkit. Det må så være op til spørgeren selv at
finde det relevante på siden.

--
Mvh. Kim Ludvigsen
Læs om de nye funktioner i Internet Explorer 7
http://kimludvigsen.dk

---

Kim Ludvigsen <usenet@kimludvigsen.dk> writes:

>Hvad signalerer det indlæg?

4. OSS'en dækker fint hvordan man sikrer sin pc. Men der mangler
lidt generel information om rootkit som koncept. Desværre har
ingen meldt sig til at skrive det endnu.

Mvh.
   Klaus.

---

On Sun, 2007-04-29 at 21:27 +0000, Kent Friis wrote:
> > Hvordan gennemgår man alle autostart features?
>
> Det kræver naturligvis grundigt kendskab til OS'et.

Hvem har det?

> > Er et baggrunds jepg med bufferoverflow, en del af autostart?
>
> Ikke-kendte sikkerhedshuller kan du aldrig gardere dig imod, rootkit
> eller ej.

http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx

---

Den Sun, 29 Apr 2007 23:40:23 +0200 skrev Christian E. Lysel:
> On Sun, 2007-04-29 at 21:27 +0000, Kent Friis wrote:
>> > Hvordan gennemgår man alle autostart features?
>>
>> Det kræver naturligvis grundigt kendskab til OS'et.
>
> Hvem har det?

Alle der er kvalificerede til at lave programmet.

>> > Er et baggrunds jepg med bufferoverflow, en del af autostart?
>>
>> Ikke-kendte sikkerhedshuller kan du aldrig gardere dig imod, rootkit
>> eller ej.
>
> http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx

Jamen så er den jo simpel... Man godkender naturligvis ikke en
checksum for en version med kendte huller.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Sun, 2007-04-29 at 21:22 +0000, Kent Friis wrote:
> > Et rootkit kan udmærket skjule sig og lave indgreb i OS'et.
>
> *Behøver* ikke. As in "spild af tid at skrive koden til at gøre det".

Standarden på UNIX er at at kalde ens rootkit for ".rootkit" herved er
det skjult for brugeren, og det tager ikke lang tid :)

På windows er ADS praktisk til formålet, da ikke mange kikker i denne
struktur.

> > Filerne eksistere ikke i min installation af fedora, men hvis jeg
> > opretter /sbin/zfcpconf.sh vil indholdet blive kørt som root under
> > opstarten. Ligeledes for de andre filer.
>
> Mener du en anden mappe? /sbin indeholder normalt programmer der kun
> er interessante for root, det kunne fx være /sbin/shutdown, så at
> køre alt hvad der ligger i /sbin under opstart virker ikke realistisk.

/etc/rc.sysinit bliver kaldt under opstarten. Dette script og mange
mange flere er fyldt med masser af "fejl", endvidere afvikles de som
root.

Se fx disse linier (taget fra rc.sysinit):

# configure all zfcp (scsi over fibrechannel) devices before trying to
mount them
# zfcpconf.sh exists only on mainframe
[ -x /sbin/zfcpconf.sh ] && /sbin/zfcpconf.sh

"Genialt" når man skal gemme et rootkit.

Hvis du keder dig kan du søge /etc/rc* igennem for "-x" og "-f".

> > Er det ikke mere reglen at OS'et fylder mindst i en installation, men
> > det derimod er data og 3. parts programmer der fylder?
>
> Det interessante er ting der bliver loadet under opstarten. Ting der
> først bliver loadet når et tilfældigt program startes tre timer efter
> er ikke specielt brugbart for et rootkit, der så først vil blive
> aktiveret da. Med risiko for at rootkittet bliver opdaget inden.

Jeg snakker ikke om 3 timer efter, ovenstående kan startes root
re-mountes, kik efter /etc/sysconfig/readonly-root i rc.sysinit


Hvem har overblikket over hvad der startes?

Hvad sker der hvis man ligger sit rootkit i /etc/sysconfig/httpd (er det
ikke bare en konfigurationsfil, eller er det i virkeligheden et shell
script?)

> > Endvidere forudsætter det også at angriberen ikke mappe et netværksdrev,
> > eller bruger ligende strategier....find selv på flere metoder hvor
> > ovenstående ikke holder...
>
> Der skal stadig være et sted det netværksdrev mappes under opstarten,
> og det script har vi allerede checket...

Men vi har ikke checket netværksdrevet.   

---

Den Mon, 30 Apr 2007 00:00:46 +0200 skrev Christian E. Lysel:
> On Sun, 2007-04-29 at 21:22 +0000, Kent Friis wrote:
>> > Et rootkit kan udmærket skjule sig og lave indgreb i OS'et.
>>
>> *Behøver* ikke. As in "spild af tid at skrive koden til at gøre det".
>
> Standarden på UNIX er at at kalde ens rootkit for ".rootkit" herved er
> det skjult for brugeren, og det tager ikke lang tid :)

Det ændrer ikke på at det er spild af tid.

> Se fx disse linier (taget fra rc.sysinit):
>
> # configure all zfcp (scsi over fibrechannel) devices before trying to
> mount them
> # zfcpconf.sh exists only on mainframe
> [ -x /sbin/zfcpconf.sh ] && /sbin/zfcpconf.sh

Så er det jo en del af boot-scriptet, og skal naturligvis checkes.

> "Genialt" når man skal gemme et rootkit.
>
> Hvis du keder dig kan du søge /etc/rc* igennem for "-x" og "-f".

Næ tak, det tager garanteret lige så lang tid som at kigge dem igennem
for unødvendige "sleep 1" og "sleep 5".

>> > Er det ikke mere reglen at OS'et fylder mindst i en installation, men
>> > det derimod er data og 3. parts programmer der fylder?
>>
>> Det interessante er ting der bliver loadet under opstarten. Ting der
>> først bliver loadet når et tilfældigt program startes tre timer efter
>> er ikke specielt brugbart for et rootkit, der så først vil blive
>> aktiveret da. Med risiko for at rootkittet bliver opdaget inden.
>
> Jeg snakker ikke om 3 timer efter, ovenstående kan startes root
> re-mountes, kik efter /etc/sysconfig/readonly-root i rc.sysinit

Stadig en del af opstarten, og skal dermed checkes.

> Hvem har overblikket over hvad der startes?

Alle der er kvalificerede til at lave sådan et program.

>> > Endvidere forudsætter det også at angriberen ikke mappe et netværksdrev,
>> > eller bruger ligende strategier....find selv på flere metoder hvor
>> > ovenstående ikke holder...
>>
>> Der skal stadig være et sted det netværksdrev mappes under opstarten,
>> og det script har vi allerede checket...
>
> Men vi har ikke checket netværksdrevet.   

Kun referencerne til det. Et netværksdrev starter ikke bare programmer
af sig selv.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Apr 29, 11:58 pm, Kim Ludvigsen <use...@kimludvigsen.dk> wrote:
> Hvad signalerer det indlæg?

4. Som så mange andre steder på nettet er der nogle spørgsmål der
bliver stillet ofte. Derfor har vi en liste med Ofte Stillede
Spørgsmål. Almindelig netikette på Usenet foreskriver at man tager sig
tid til at læse den først.

\\kristian

---

On Mon, 2007-04-30 at 17:19 +0000, Kent Friis wrote:
> >> Det kræver naturligvis grundigt kendskab til OS'et.
> >
> > Hvem har det?
>
> Alle der er kvalificerede til at lave programmet.

Som kender fremtidige ændringer, som kender 3. parts programmer.

Hvem kan det?

> > http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
>
> Jamen så er den jo simpel... Man godkender naturligvis ikke en
> checksum for en version med kendte huller.

Tilføj en byte til filen, og nu er checksummen en anden.

Det vil da kræve en *del* checksummer.

---

Den Mon, 30 Apr 2007 19:55:42 +0200 skrev Christian E. Lysel:
> On Mon, 2007-04-30 at 17:19 +0000, Kent Friis wrote:
>> >> Det kræver naturligvis grundigt kendskab til OS'et.
>> >
>> > Hvem har det?
>>
>> Alle der er kvalificerede til at lave programmet.
>
> Som kender fremtidige ændringer,

Producenten af OS'et er nok den der har bedst chance.

> som kender 3. parts programmer.

Hvad skal 3. parts programmer være en del af opstarten for?

>> > http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
>>
>> Jamen så er den jo simpel... Man godkender naturligvis ikke en
>> checksum for en version med kendte huller.
>
> Tilføj en byte til filen, og nu er checksummen en anden.
>
> Det vil da kræve en *del* checksummer.

Ikke flere end der er "known good" versioner af filen.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

"Christian E. Lysel" <christian@examples.net> writes:

>> Jamen så er den jo simpel... Man godkender naturligvis ikke en
>> checksum for en version med kendte huller.
>
>Tilføj en byte til filen, og nu er checksummen en anden.

>Det vil da kræve en *del* checksummer.

Det er jo en gammel, afprøvet ide. For længe siden kørte jeg
"tripwire" på nogle SunOS-maskiner, der stod et eksponeret
sted.

Konceptet i tripwire (fra Spaffords berømte afdeling på
Purdue og dengang var freeware) var, at man havde programmet
og den tilhørende checksum-database på en skrivebeskyttet
floppy.

Så kunne man hver nat køre dette relativt sikre program - og
få en liste over ændrede checksums. Det er selvfølgelig ikke
en perfekt løsning, men det var i 1995, og alverdens hackere
var ikke særligt sofistikerede. Alt i alt var det Godt Nok(tm)
inden for en given mængde maskiners risikoprofil.

Selvfølgelig ændrede en del filer checksum, og selv relativt
centrale filer som sendmail.cf blev bygget igen og igen. Det
forårsagede, at den daglige liste over mismatches blev længere
og længere.

Når man ikke gad prøve at overskue den længere, var det tid
til at bygge en ny database. Den kunne så leve et par uger,
inden den også var ved at være gal.

At lave det samme i dag vil være vanvittigt meget sværere,
fordi sikkerheden (og måder at omgå den på) er blevet mere
kompleks og på nogle punkter i praksis mere sårbar.

Men altså - checksums på filer er hverken umuligt i teorien
eller i praksis. Det har faktisk været anvendt yderst meget
i praksis.

Mvh.
   Klaus.

---

On Mon, 2007-04-30 at 18:03 +0000, Kent Friis wrote:

> Hvad skal 3. parts programmer være en del af opstarten for?

For at starte.

Et 3. parts program kan være en Oracle database, eller et netværkskorts
driver (mit windows netværkskort bruger apache til den administration).
Det kan også være et skærmkort, de fylder nemt 30MB. Eller en Sony
"driver" til at lytte til CD-Audio ligende skiver.

Groft sagt, der er omkring uendelige 3. part programmer, jeg kan ikke se
hvordan man får overblik over hvordan de kan udnyttes af et rootkit.

Ej kan jeg se hvordan man kan undersøge om en konfigurationsfil der
tolkes som et shell script er et rootkit eller ej.

> >> > http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
> >>
> >> Jamen så er den jo simpel... Man godkender naturligvis ikke en
> >> checksum for en version med kendte huller.
> >
> > Tilføj en byte til filen, og nu er checksummen en anden.
> >
> > Det vil da kræve en *del* checksummer.
>
> Ikke flere end der er "known good" versioner af filen.

"Known good" af et tilfældigt billed brugeren selv har taget, lyder
svært at implementere.

JPEG var kun ét eksempel, der er masser af problemer med datafiler.

---

Den Mon, 30 Apr 2007 20:19:25 +0200 skrev Christian E. Lysel:
> On Mon, 2007-04-30 at 18:03 +0000, Kent Friis wrote:
>
>> >> > http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
>> >>
>> >> Jamen så er den jo simpel... Man godkender naturligvis ikke en
>> >> checksum for en version med kendte huller.
>> >
>> > Tilføj en byte til filen, og nu er checksummen en anden.
>> >
>> > Det vil da kræve en *del* checksummer.
>>
>> Ikke flere end der er "known good" versioner af filen.
>
> "Known good" af et tilfældigt billed brugeren selv har taget, lyder
> svært at implementere.

Konklusion: Du læser overhovedet ikke hvad jeg skriver.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

---

Den Mon, 30 Apr 2007 22:33:08 +0200 skrev Christian E. Lysel:
> On Mon, 2007-04-30 at 18:39 +0000, Kent Friis wrote:
>> >>>> > http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
>> >>>>
>> >>>> Jamen så er den jo simpel... Man godkender naturligvis ikke en
>> >>>> checksum for en version med kendte huller.
>> >>>
>> >>> Tilføj en byte til filen, og nu er checksummen en anden.
>> >>>
>> >>> Det vil da kræve en *del* checksummer.
>> >>
>> >> Ikke flere end der er "known good" versioner af filen.
>> >
>> > "Known good" af et tilfældigt billed brugeren selv har taget, lyder
>> > svært at implementere.
>>
>> Konklusion: Du læser overhovedet ikke hvad jeg skriver.
>
> Jo, men det kan være jeg ikke forstår hvad du skriver.
>
> Det jeg forstår er at du vil lave en liste af checksum af "godkendte"
> datafiler?

Hvilke datafiler kender du der har en bufferoverflow i jpg-
implementationen? Det var det vi snakkede om.

Hvis jpg-dll'en / programmet ikke har kendte exploits[1], er det ikke
muligt få udført kode skjult i en jpg. Så når dll'en er verificeret
som "known good", er jpg'en irrelevant.

Mvh
Kent

[1] Jeg ser stadig bort fra ukendte exploits, da ingen kan gardere
sig imod disse.
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

---

Den Mon, 30 Apr 2007 23:23:48 +0200 skrev Christian E. Lysel:
> On Mon, 2007-04-30 at 20:39 +0000, Kent Friis wrote:
>> Den Mon, 30 Apr 2007 22:33:08 +0200 skrev Christian E. Lysel:
>> > On Mon, 2007-04-30 at 18:39 +0000, Kent Friis wrote:
>> >> >>>> > http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
>> >> >>>>
>> >> >>>> Jamen så er den jo simpel... Man godkender naturligvis ikke en
>> >> >>>> checksum for en version med kendte huller.
>> >> >>>
>> >> >>> Tilføj en byte til filen, og nu er checksummen en anden.
>> >> >>>
>> >> >>> Det vil da kræve en *del* checksummer.
>> >> >>
>> >> >> Ikke flere end der er "known good" versioner af filen.
>> >> >
>> >> > "Known good" af et tilfældigt billed brugeren selv har taget, lyder
>> >> > svært at implementere.
>> >>
>> >> Konklusion: Du læser overhovedet ikke hvad jeg skriver.
>> >
>> > Jo, men det kan være jeg ikke forstår hvad du skriver.
>> >
>> > Det jeg forstår er at du vil lave en liste af checksum af "godkendte"
>> > datafiler?
>>
>> Hvilke datafiler kender du der har en bufferoverflow i jpg-
>> implementationen? Det var det vi snakkede om.
>
> Ja, men jpg var ét eksempel blandt mange.

Svaret er det samme.

>> Hvis jpg-dll'en / programmet ikke har kendte exploits[1], er det ikke
>> muligt få udført kode skjult i en jpg. Så når dll'en er verificeret
>> som "known good", er jpg'en irrelevant.
>
> Ok, jeg læste filen som billedet ikke som jpeg biblioteket.

"en version med kendte huller", refererende til et link til et
sikkerhedshul du selv havde postet... Hvordan kan det nogensinde
blive til billedet?

> Hvis du bruger den strategi kan rc.sysinit ikke bruges!!

Fordi den har kendte huller? I så fald, hvorfor er $hostname
på nettet før der er installeret en update der lukker hullerne?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

---

Den Tue, 01 May 2007 01:14:58 +0200 skrev Christian E. Lysel:
> On Mon, 2007-04-30 at 21:37 +0000, Kent Friis wrote:
>> "en version med kendte huller", refererende til et link til et
>> sikkerhedshul du selv havde postet... Hvordan kan det nogensinde
>> blive til billedet?
>
> Det var nu engang det jeg læste det som, beklager..
>
> Hvordan vil du styre hvad der ikke længere er godkendt, og fjerne dette
> fra listen, således det nu er et rootkit? Kan et rootkit bruge den samme
> metode til at komme på listen?

Samme system som fx Windows Update. Når opdateringen ryger ud, opdateres
checksummen.

Hvis root-kit'et kan komme på listen, kan det også komme på Windows
Update og blive installeret automatisk.

>> > Hvis du bruger den strategi kan rc.sysinit ikke bruges!!
>>
>> Fordi den har kendte huller? I så fald, hvorfor er $hostname
>> på nettet før der er installeret en update der lukker hullerne?
>
> Der er ingen update der lukker hullerne, eller retter designet.
> Hvis de ændret designet vil flere installationer ikke kunne boote.

"Broken by design"

> Boot processen fortages af en lang række shell scripts, der evt. kalder
> flere scripts, alt efter hvad der er installeret og efter hvilke filer
> der er oprettet.

De scripts kan enten være installeret af distro'en (checksum forefindes)
eller oprettet / rettet af brugeren (brugeren skal selv tage ansvaret for
sine egne ændringer).

Som sådan ser jeg ikke noget problem.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

---

On Mon, 2007-04-30 at 18:24 +0000, Klaus Ellegaard wrote:
> Selvfølgelig ændrede en del filer checksum, og selv relativt
> centrale filer som sendmail.cf blev bygget igen og igen. Det
> forårsagede, at den daglige liste over mismatches blev længere
> og længere.

Selv køre jeg rdiff mellem den sidste version der blev checket ind i rcs
og den som ligger på maskinen.

> Men altså - checksums på filer er hverken umuligt i teorien
> eller i praksis. Det har faktisk været anvendt yderst meget
> i praksis.

Jeg har fuld forståelse for det på et Operativ system, dog ikke på et
system med data, hvor data kan bruges til at starte et program (via et
bufferoverflow).