---

Jeg har fået noia over tripwire ...

Jeg startede med at installere tripwire-2.3.1-20.fdr.1.2.i386.rpm fra
rpm.pbone.net, som foreslået af Uffe i tråden ovenfor.
Det så fint ud også efter at jeg havde kørt "tripwire --check"
adskillige gange. Men efter den automatiske natkørsel, som rpm-pakken
havde lagt op kom den ud med en rapport om at de 4 tripwire binaries
(tripwire, twprint, twadmin og siggen) var ændret.

Det fik mig til at scratche maskinen og geninstallere fedora - surt men
nødvendigt, da jeg ikke ville tage nogen chancer ..

Nu har jeg så installeret tripwire-2.3.1-18.fdr.3.1.src.rpm fra
download.fedora.us. Igen så alt ud til at virke, jeg kørte tripwire
--check, og kørte natjobbet under cron.daily og alt OK.

Men nu efter den automatiske natkørsel kommer den igen ud med at de 4
tripwire binaries er ændret:

Her er et klip fra twr-filen:

-------------------------------------------------------------------------------
Rule Name: Tripwire Binaries (/usr/sbin/tripwire)
Severity Level: 100
-------------------------------------------------------------------------------
----------------------------------------
Modified Objects: 1
----------------------------------------



Modified object name: /usr/sbin/tripwire



Property: Expected Observed
------------- ----------- -----------
* Inode Number 1496334 1495498
* Size 1299716 1310392
* Blocks 2552 2568
* CRC32 AKzg5H BrSICE
* MD5 CzamYmlh92bvSrJXRixJ4m BxqhTs1Mc+FlPMLmoKQsvm




Og den har ret her er resultatet af sum og ls -l før natkørslen:

46326 1270 /usr/sbin/tripwire
42056 1120 /usr/sbin/twadmin
48271 1001 /usr/sbin/twprint
15848 920 /usr/sbin/siggen
-rwxr-xr-x 1 root root 1024228 Nov 23 20:39 /usr/sbin/twprint
-rwxr-xr-x 1 root root 1146628 Nov 23 20:39 /usr/sbin/twadmin
-rwxr-xr-x 1 root root 1299716 Nov 23 20:39 /usr/sbin/tripwire
-rwxr-xr-x 1 root root 941156 Nov 23 20:39 /usr/sbin/siggen

og sådan ser det ud nu:

sum /usr/sbin/tripwire /usr/sbin/twadmin /usr/sbin/twprint /usr/sbin/siggen
57980 1280 /usr/sbin/tripwire
05639 1131 /usr/sbin/twadmin
18027 1011 /usr/sbin/twprint
52046 930 /usr/sbin/siggen
[root@bjarne bjarne]# ls -l /usr/sbin/tripwire /usr/sbin/twadmin
/usr/sbin/twprint /usr/sbin/siggen
-rwxr-xr-x 1 root root 951592 Nov 23 20:39 /usr/sbin/siggen
-rwxr-xr-x 1 root root 1310392 Nov 23 20:39 /usr/sbin/tripwire
-rwxr-xr-x 1 root root 1157128 Nov 23 20:39 /usr/sbin/twadmin
-rwxr-xr-x 1 root root 1034904 Nov 23 20:39 /usr/sbin/twprint

Weird - er der nogen der har en forklaring ???

Kan man stole på tripwire ?

---

bvm wrote:
> Jeg har fået noia over tripwire ...
[...]
> Weird - er der nogen der har en forklaring ???
>
> Kan man stole på tripwire ?


Det ser godtnok underligt ud. Nu er det lang tid siden jeg har brugt
Tripwire og dengang gjorde den ikke den slags unoder. Jeg har dog
oplevet at der var en enkelt alarm som jeg ikke kunne få forklaret
databasen ikke var et problem, så den kom hver gang. ... men det var en
åbenlys bug.
Det du beskriver ser godtnok mærkeligt ud.

Peter

---

Peter Mogensen wrote:

> bvm wrote:
>> Jeg har fået noia over tripwire ...
> [...]
>> Weird - er der nogen der har en forklaring ???
>>
>> Kan man stole på tripwire ?
>
>
> Det ser godtnok underligt ud. Nu er det lang tid siden jeg har brugt
> Tripwire og dengang gjorde den ikke den slags unoder. Jeg har dog
> oplevet at der var en enkelt alarm som jeg ikke kunne få forklaret
> databasen ikke var et problem, så den kom hver gang. ... men det var en
> åbenlys bug.
> Det du beskriver ser godtnok mærkeligt ud.

Jeg er helt enig, men hvis det var et _åbenlyst_ rootkit, ville den så ikke
lade være med at gøre opmærksom på filændringen... eller er det fordi den
vil have dig til at TRO at...o.s.v

Kunne det være en automatisk opgradering? Hvis nu up2date (eller lign.
system) mener der er en nyere version, så bliver den vel installeret?

--
M.V.H
Christian Iversen

---

Christian Iversen wrote:
> Jeg er helt enig, men hvis det var et _åbenlyst_ rootkit, ville den så ikke
> lade være med at gøre opmærksom på filændringen... eller er det fordi den
> vil have dig til at TRO at...o.s.v

Jeg tvivler på at der er tale om noget skummelt. Det skulle være
underligt, hvis en evt. skurk havde så meget fingeren på pulsen at han
var der igen straks efter en opgradering.
Men det er stadig noget jeg da også gerne ville have en god forklaring
på før jeg fortsatte.
Et program som Tripwire kræver jo lidt at man har fuldt styr på det fra
starten for at kunne bruge det til noget.

> Kunne det være en automatisk opgradering? Hvis nu up2date (eller lign.
> system) mener der er en nyere version, så bliver den vel installeret?

Jo. Men det ville jeg mene var ret uelegant for programmer med Tripwires
formål.

Peter

---

Peter Mogensen wrote:
> Men det er stadig noget jeg da også gerne ville have en god forklaring
> på før jeg fortsatte.

Det er præcis det der er mit problem, jeg vil ikke installere noget med
Internadgang uden at vide hvad der foregår.

Man kunne sef. let lave noget selv med sum, ls -lR og diff, men jeg kan
godt lide princippet med en krypteret baseline arkiveret
skrivebeskyttet. Og så har jeg brugt en ældre version gennem lang tid på
en RH8 og den har virket til min fulde til tilfredshed ..

/Bjarne

---

Christian Iversen wrote:
> Jeg er helt enig, men hvis det var et _åbenlyst_ rootkit, ville den så ikke
> lade være med at gøre opmærksom på filændringen... eller er det fordi den
> vil have dig til at TRO at...o.s.v

Jeg tvivler på at der er tale om noget skummelt. Det skulle være
underligt, hvis en evt. skurk havde så meget fingeren på pulsen at han
var der igen straks efter en opgradering.
Men det er stadig noget jeg da også gerne ville have en god forklaring
på før jeg fortsatte.
Et program som Tripwire kræver jo lidt at man har fuldt styr på det fra
starten for at kunne bruge det til noget.

> Kunne det være en automatisk opgradering? Hvis nu up2date (eller lign.
> system) mener der er en nyere version, så bliver den vel installeret?

Jo. Men det ville jeg mene var ret uelegant for programmer med Tripwires
formål.

Peter

---

Christian Iversen wrote:
> Peter Mogensen wrote:
>
>
>>bvm wrote:
>>
>>>Jeg har fået noia over tripwire ...
>>
>>[...]

>
> Jeg er helt enig, men hvis det var et _åbenlyst_ rootkit, ville den så ikke
> lade være med at gøre opmærksom på filændringen... eller er det fordi den
> vil have dig til at TRO at...o.s.v
>
> Kunne det være en automatisk opgradering? Hvis nu up2date (eller lign.
> system) mener der er en nyere version, så bliver den vel installeret?
>

Jeg tror ikke det er et rootkit, jeg har checket ls og sum, og de er OK.
Jeg kører ikke up2date automatisk, og det ville vel under ingen
omstændigheder omfatte tripwire, da jeg ikke har rettet i
/etc/sysconfig/rhn/sources ?

checkede lige /var/log/up2date - intet om tripwire ..

btw det er to forskellige maskiner, jeg har set tilfældet på, men begge
FC2 og begge patchet op med up2date -uf

Men du har sef. ret i det kunne være et andet program, der foretager en
automatisk opgradering:

tripwire --version
Tripwire(R) 2.3.1.2 built for i686-pc-linux-gnu

Meget interessant, det er jo ikke den version, jeg mener at have
installeret (tripwire-2.3.1-18.fdr.3.1.src.rpm), og

rpm -q tripwire
tripwire-2.3.1-18.fdr.3.1

Underligt at kun størrelsen og ikke tidsstemplet er ændret på filerne ??

Nogen der har en idee om hvad der kunne lave en automatisk opdatering ??

/Bjarne

---

bvm wrote:
>
> Nogen der har en idee om hvad der kunne lave en automatisk opdatering ??

Det er forhåbentligt bare prelink. Den kører et dagligt
cron job som linker nyinstallerede executables. Dermed
kan programmer startes lidt hurtigere og bruge lidt
mindre RAM. Alternativet er at linke executables når de
startes. Jeg har selv et cron job, som holder øje med
checksum af alle mine filer, og prelink giver anledning
til mange falske positiver.

Der er både godt og skidt at sige om prelink. Jeg prøvede
engang at slette prelink pakken på et FC1 system, og det
kan ikke anbefales. Filer ændret af prelink blev ikke
ændret tilbage, og eftersom prelink ikke mere var
installeret kunne rpm ikke checke om det bare var prelink,
der havde ændret dem. Der gemmes oplysninger som kan
bruges til at verificere, om en given programfil kun er
ændret af prelink. Hvis du kan finde en tripwire version
med support for prelink burde du få nogle mere troværdige
rapporter.

--
Kasper Dupont

---

Kasper Dupont wrote:
> bvm wrote:
>
>>Nogen der har en idee om hvad der kunne lave en automatisk opdatering ??
>
>
> Det er forhåbentligt bare prelink. Den kører et dagligt
> cron job som linker nyinstallerede executables. Dermed
> kan programmer startes lidt hurtigere og bruge lidt
> mindre RAM. Alternativet er at linke executables når de
> startes. Jeg har selv et cron job, som holder øje med
> checksum af alle mine filer, og prelink giver anledning
> til mange falske positiver.
>
> Der er både godt og skidt at sige om prelink. Jeg prøvede
> engang at slette prelink pakken på et FC1 system, og det
> kan ikke anbefales. Filer ændret af prelink blev ikke
> ændret tilbage, og eftersom prelink ikke mere var
> installeret kunne rpm ikke checke om det bare var prelink,
> der havde ændret dem. Der gemmes oplysninger som kan
> bruges til at verificere, om en given programfil kun er
> ændret af prelink. Hvis du kan finde en tripwire version
> med support for prelink burde du få nogle mere troværdige
> rapporter.
>

Det lyder som en god forklaring.

Prøver lige at installere en gang mere og så starte med at køre
cron.daily/prelink inden jeg initialiserer baseline.

Mange tak for hjælpen

/Bjarne

---

bvm wrote:
>
> Prøver lige at installere en gang mere og så starte med at køre
> cron.daily/prelink inden jeg initialiserer baseline.

Der er vist et eller andet med at prelink relinker igen
hver anden uge. Det argument jeg har hørt for den opførsel
er, at det dermed skulle være sværere at udnytte buffer
overløb ol., da man ikke ved, hvor koden ligger. Jeg ved
ikke, om der er andre (og bedre) grunde til denne relinking.

--
Kasper Dupont

---

On Thu, 25 Nov 2004 13:26:55 +0100, Kasper Dupont wrote:

> Jeg ved
> ikke, om der er andre (og bedre) grunde til denne relinking.

Jeg mener også, at der er et performance-argument vedr. prelinking: At
visse typer software - vistnok særligt C++-baseret - såsom KDE starter
hurtigere efter prelinking.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:
>
> On Thu, 25 Nov 2004 13:26:55 +0100, Kasper Dupont wrote:
>
> > Jeg ved
> > ikke, om der er andre (og bedre) grunde til denne relinking.
>
> Jeg mener også, at der er et performance-argument vedr. prelinking: At
> visse typer software - vistnok særligt C++-baseret - såsom KDE starter
> hurtigere efter prelinking.

Nu gik kommentaren på om det kunne betale sig at prelinke
igen hver anden uge. At programmer starter hurtigere efter
en prelinking har jeg allerede nævnt, og det skal nok passe,
at det gavner mest for C++ programmer. (Det er nu ikke den
eneste grund til at KDE programmer kan være langsomme til
at starte).

Men er programmet først blevet prelinket en gang, så bliver
det jo ikke hurtigere ved at blive prelinket igen. Så er
der nogen gode argumenter for at gentage prelink hver anden
uge.

--
Kasper Dupont

---

Kasper Dupont wrote:
> bvm wrote:
>
>>Prøver lige at installere en gang mere og så starte med at køre
>>cron.daily/prelink inden jeg initialiserer baseline.
>
>
> Der er vist et eller andet med at prelink relinker igen
> hver anden uge. Det argument jeg har hørt for den opførsel
> er, at det dermed skulle være sværere at udnytte buffer
> overløb ol., da man ikke ved, hvor koden ligger. Jeg ved
> ikke, om der er andre (og bedre) grunde til denne relinking.
>

Det lyder uheldig i tripwire sammenhæng.

Jeg har en anden maskine, der kører tripwire og der har jeg ikke oplevet
det som et problem, så jeg gir den lige en chance ..

---

---

Michael Knudsen wrote:
> OpenBSD's ld.so(1) goer noget tilsvarende, med mindre man saetter
> LD_NORANDOM. Idéen er, at man linker koden ind forskellige steder, saa
> en angriber faar svaerere ved at saette returadressen korrekt, naar han
> smadrer stakken. Ca.
>
> Maaske er tanken bag gentagne prelinks, at man beskytter mod lokale
> brugere, der efter noget tid kan lure link-sekvensen af?

Det er vel for at fange nye programmer som bliver installeret? Lam
metode. Runtime er bedre.

--
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 wrote:
>
> Michael Knudsen wrote:
> >
> > Maaske er tanken bag gentagne prelinks, at man beskytter mod lokale
> > brugere, der efter noget tid kan lure link-sekvensen af?

Det argument køber jeg ikke. Har man et exploit, som virker hvis
man kender layoutet er to uger mere end rigelig tid til at udnytte
det. Og i det helt ekstreme tilfælde kan man forestille sig, at
nogle huller ikke kan udnyttes på en vilkårlig adresse. Så vil en
gentagelse af linkningen bare gøre det nemmere at angribe, da der
er en bedre chance for at der før eller siden opstår et layout,
som er gunstigt for exploitet.

>
> Det er vel for at fange nye programmer som bliver installeret? Lam
> metode. Runtime er bedre.

Det primære formål med prelinking er performance. At det samtidig
bliver lidt sværere at udnytte huller er bare en ekstra gevinst.
Det har ikke noget at gøre med nye programmer. Cron jobet kører
dagligt og linker alle nyinstallerede executables og executables
som ikke er blevet ændret i to uger. Og at randomisere på
runtime ville gå ud over performance. Du vil miste alle fordelene
ved prelinking, og måske enda få lidt dårlige performance, da
tilfældige tal ikke er gratis.

--
Kasper Dupont

---

---

Michael Knudsen wrote:
>
> Har nogen i oevrigt nogle tal, der viser forbedringen opnaaet med at
> prelinke? Umiddelbart ville jeg tro, at et program skal startes _mange_
> gange eller linke op mod 2000 ting, foer man kan maerke (ikke maale)
> nogen forskel.

Jeg har ingen målinger, og jeg har ikke observeret nogen forskel.
Jeg har oplevet at nogle KDE programmer kunne startes op fire gange
hurtigere ved at ændre lidt på font instillingerne. Så linkning er
bestemt ikke den vigtigste faktor. Det burde også hjælpe lidt på
hukommelsesforbrug, det er måske nemmere at observere.

--
Kasper Dupont

---

Kasper Dupont wrote:

> Michael Knudsen wrote:
>>
>> Har nogen i oevrigt nogle tal, der viser forbedringen opnaaet med at
>> prelinke? Umiddelbart ville jeg tro, at et program skal startes _mange_
>> gange eller linke op mod 2000 ting, foer man kan maerke (ikke maale)
>> nogen forskel.
>
> Jeg har ingen målinger, og jeg har ikke observeret nogen forskel.
> Jeg har oplevet at nogle KDE programmer kunne startes op fire gange
> hurtigere ved at ændre lidt på font instillingerne. Så linkning er
> bestemt ikke den vigtigste faktor. Det burde også hjælpe lidt på
> hukommelsesforbrug, det er måske nemmere at observere.

Du ville måske lige dele hvilke font-indstillinger du taler om? 4x lyder jo
af meget!

--
M.V.H
Christian Iversen

---

Christian Iversen wrote:
>
> Kasper Dupont wrote:
>
> > Michael Knudsen wrote:
> >>
> >> Har nogen i oevrigt nogle tal, der viser forbedringen opnaaet med at
> >> prelinke? Umiddelbart ville jeg tro, at et program skal startes _mange_
> >> gange eller linke op mod 2000 ting, foer man kan maerke (ikke maale)
> >> nogen forskel.
> >
> > Jeg har ingen målinger, og jeg har ikke observeret nogen forskel.
> > Jeg har oplevet at nogle KDE programmer kunne startes op fire gange
> > hurtigere ved at ændre lidt på font instillingerne. Så linkning er
> > bestemt ikke den vigtigste faktor. Det burde også hjælpe lidt på
> > hukommelsesforbrug, det er måske nemmere at observere.
>
> Du ville måske lige dele hvilke font-indstillinger du taler om? 4x lyder jo
> af meget!

Det er et stykke tid siden jeg observerede det, og fænomenet
er ikke så udpreget i de nyeste KDE versioner. Jeg mener det
var antialiasing, jeg slog fra. Og opstartstiden for flere
mindre KDE programmer (blandt andet terminal emulatoren) blev
reduceret fra otte sekunder til to sekunder.

--
Kasper Dupont

---

Kasper Dupont wrote:

> Christian Iversen wrote:
>>
>> Kasper Dupont wrote:
>>
>> > Michael Knudsen wrote:
>> >>
>> >> Har nogen i oevrigt nogle tal, der viser forbedringen opnaaet med at
>> >> prelinke? Umiddelbart ville jeg tro, at et program skal startes
>> >> _mange_ gange eller linke op mod 2000 ting, foer man kan maerke (ikke
>> >> maale) nogen forskel.
>> >
>> > Jeg har ingen målinger, og jeg har ikke observeret nogen forskel.
>> > Jeg har oplevet at nogle KDE programmer kunne startes op fire gange
>> > hurtigere ved at ændre lidt på font instillingerne. Så linkning er
>> > bestemt ikke den vigtigste faktor. Det burde også hjælpe lidt på
>> > hukommelsesforbrug, det er måske nemmere at observere.
>>
>> Du ville måske lige dele hvilke font-indstillinger du taler om? 4x lyder
>> jo af meget!
>
> Det er et stykke tid siden jeg observerede det, og fænomenet
> er ikke så udpreget i de nyeste KDE versioner. Jeg mener det
> var antialiasing, jeg slog fra. Og opstartstiden for flere
> mindre KDE programmer (blandt andet terminal emulatoren) blev
> reduceret fra otte sekunder til to sekunder.

Ok, så klarer jeg mig. Konsole starter på ca 1 sekund her :)

Jeg har derimod set _store_ forskelle på håndkompilerede programmer, og dem
der kommer fra Debian. Hverken Mandrake eller Redhat har den "schnellneß"
der er i Debians KDE. Jeg er endnu ikke sikker på hvorfor, men jeg gætter
på at det er nogle compiler-switche. Jeg har om-kompileret KDE-pakkerne fra
unstable til testing, og de er stadig hurtige. (og så kan de jo bruges på
alle mine debian-maskiner.. :)

--
M.V.H
Christian Iversen

---