07. juni 2003 - 05:03Der er
81 kommentarer og 1 løsning
Kan ikke få VirutalDocumentRoot til at virke ordenligt
Hejsa Eksperter
Jeg kunne godt tænke mig ikke at skulle genstarte apache, hver gang jeg laver et subdomæne, så da jeg i nat fandt mod_vhost_alias blev jeg glad - i sær fordi jeg ikke helt har kunne få mod_rewrite til at virke...
Men - Der er et lille problem
Jeg vil lige bemærke, at min server kører flere domæner (the-source.dk, fant.dk osv) men at jeg her ønsker funktionaliteten specifikt på skroeder.dk
min dir-struktur ser ud som følger d:\www\skroeder.dk\sites\ +_ +www +test
min VirtualHost opsætning for skroeder.dk er ## SKROEDER.DK <VirtualHost *> ServerAdmin webmaster@skroeder.dk ErrorLog logs/skroeder.dk/error.log LogFormat "%V %h %l %u %t \"%r\" %s %b" myLogFormat CustomLog logs/skroeder.dk/access.log myLogFormat VirtualDocumentRoot d:/www/skroeder.dk/sites/%-3 </VirtualHost>
Og derudover er NameVirtualHost * UseCanonicalName Off
Nu er det så bare at det kun er www.skroeder.dk der virker - ved resten får jeg bare en tom directory-listning :-( (men der står dog stadigvæk "Apache/2.0.43 Server at test.skroeder.dk Port 80" i bunden, så den må vel finde test.skroeder.dk eller ????)
Det værste er nu, at hvis jeg tilføjer ServerAlias skroeder.dk www.skroeder.dk test.skroeder.dk
så virker de forskellige sites!
Men hvis jeg nu gerne vil have endnu et subdomæne f.eks. http://foobar.skroeder.dk og jeg så opretter mappen d:\www\skroeder.dk\sites\foobar
så får jeg den samme tomme directory-listning, som før... Og hvad der så er nødvendigt for at få den til at virke er, at tilføje foobar.skroeder.dk i ServerAlias direktivet Og det betyder en genstart af serveren - præcis det, som jeg gerne ville undgå...
Mit spørgsmål er nu .... Hvordan får jeg den pokkers VirutalDocumentRoot til at virke, så jeg ikke skal genstarte hele tiden :-/ Er der et eller andet trick/hack, som man kan bruge ?
lidt i forlængelse : ... er der en eller anden måde,, hvormed jeg kan få skroeder.dk til at pege på www.skroeder.dk, så jeg ikke behøver en redirect d:\www\skroeder.dk\sites\_\index.html
På et tidspunkt i løbet af natten læste jeg et sted at man kunne bruge noget SymLinks eller sådan noget -- Er det også muligt på Win32 platform eller ?
ok ... Jeg har prøvet at ændre det til %1 - men stadigvæk er det kun www.skroeder.dk der virker -- skroeder.dk, test.skroeder.dk og foobar.skroeder.dk giver kun en tom directory-listning - og der bliver ikke lavet nogen optegnelse i access-logen :-/
1. Har du noget bibliotek der hedder test under skroeder.dk ?
Tror problemet ligger i at kombinere både standard virtual hosts og virtualdocumentroot! Prøv og lav det til en virtualhost, med virtualdocumentroot evt. ala
VirtualDocumentRoot d:/www/%2.0.%3.0/sites/%1
Du vil muligvis få problemer med hovedsiden med dette(skroeder.dk), men prøv lige og test
Jeg prøvede at fjerne de andre vhosts, og så virkede det - bortset fra skroeder.dk i det tilfælde ville d:/www/%2.0.%3.0/sites/%1 betyde at den skulle lede i d:/www/dk._/sites/skroeder
men det rettede jeg ved at skrive d:/www/skroeder.dk/sites/%-3 (%1 ville have givet et underbibliotek som hed skroeder i stedet for :-/)
Jeg forsøgte derefter at føje en anden vhost på - først the-source.dk
OG DET VIRKEDE - HURRA! ... Men glæden var dog kort - for jeg føjede også Fant.dk på - og så virkde det ikke mere...
Jeg har dog funde ud af, at det er rækkefølgen, som har betydning her (jeg har altid været vant til at indsætte vhost'ne i alfabetisk rækkefølge - men ligepræcis i dette tilfælde kommer det kun til at virke hvis vhost-definitionen for skroeder.dk (eller den vhost, som skal kunne lave alle disse alias'er) kommer først
Derfor bliver mine VHosts nu defineret i følgende rækkefølge ## SKROEDER.DK ## FANT.DK ## JEG-KOMMER-SNART.DK ## THE-SOURCE.DK ## ULLIBEAR.DK
htm >> har du et godt svar på, hvorfor jeg absolut _skal_ definere dem i den rækkefølge...
Grunden til at skroeder.dk skal være øverst er at denne er default i tilfælde af at der ikke sker nogen match på servernamet! I dette tilfælde har vi ikke noget servername på skroeder.dk og derfor vil denne ikke blive fanget af skroeder.dk - men den vil blive fanget som defailt host!
Det er derfor at jeg var inde på at du kun skulle have en virtualhost og så definere en virtualdocumentroot med hel domænet som parametre!
<< Det er derfor at jeg var inde på at du kun skulle have en virtualhost og så definere en virtualdocumentroot med hel domænet som parametre! >>
mener du det der %2.0.%3.0 ???
----- Ang %-3 >> Hmm .. Det ser ud til (fra min access.log) at forsøger man at få fat i skroeder.dk/mp1/mp2, så redirecter den til www.skroeder.dk/mp1/mp2
Først laver den et opslag på skroeder.dk, hvor den får redirect (301) skroeder.dk 194.255.169.191 - - [07/Jun/2003:16:05:02 +0200] "GET /mappe/mappe2 HTTP/1.1" 301 313
Derefter søger den igen - men på "www" subdomænet :-) og der får den FnF(404) www.skroeder.dk 194.255.169.191 - - [07/Jun/2003:16:05:02 +0200] "GET /mappe/mappe2 HTTP/1.1" 404 284
Men jeg har så heller ikke nogle planer om at ligge noget indhold i http://skroeder.dk - jeg har det fint med at man automatisk bliver forflyttet til http://www.skroeder.dk
Derfor skal der hellerikke andet indhold i "_" mappen end .htaccess filen :-)
nope - den tager kun det 3. sidste af domænenavnet - og hvis det ikke findes, returneres "_" dvs. www.skroeder.dk = "www" skroeder.dk = "_" foo.bar.skroeder.dk = "bar" (men jeg har så heller ikke tænkt mig at have sub-sub-domæner :-))
Det jeg gør nu er at jeg først kontakter coadmin for at høre om dette allerede er en kendt bug (det er den formentlig - da den ikke er særlig svær at opdage...)
Fordi jeg i nat stødte på dit navn i forbindelse med løsning af mit eget problem - men primært fordi din IP-adresse er penslet ud over hele min access.log :-))) - tro ikke at det ikke tager mig under 2 sekunder at lægge to og to sammen... *LOL*
PS : Hvilken browser bruger du -- Den synes meget aggressiv mht. GET requests
Mathias - Jeg laver lige endnu et forsøg (vil gerne vide - lige præcis _hvor stor_ kontrol jeg har med din profil ... Om lidt vil du se "bearhugx was here" på dit minisite
Det ser ud til at jeg har din profil i min hule hånd - Jeg har beføjelser til at oprette spørgsmål - svare på dine vegne - ændre hvilken som helst indstilling (f.eks. mail) eller helt at deaktivere din konto :-/
Det værste er dens enkelthed - Det er også derfor at jeg ikke pt. siger "hvordan" jeg gør det (for ellers ville der være en masse lamers som evt. begynde at udnytte hullet) ... Men samtidig kan jeg så sige, at man skal være meget heldig for at bruge hullet (vi taler om "small-window-of-opportunity" her!)
Hmm ... jeg har ikke hørt fra nogen coadmin endnu, så jeg formulerer en mail til admin@eksperten.dk
I mellemtiden, så skal jeg bede dig om at gøre noget Mathias >> du skal lukke alle dine browservinduer ned og først komme ind på eksperten igen kl. 2 minutter senere (så har jeg tid til også at disconnecte mig :-)
Jeg har fået snakket med en CoAdmin, som sagde at problemet er kendt af admin, og at et fåtal andre brugere kender denne usikkerhed. Hvordan admin vælger at prioritere lukningen af dette hul, ved jeg ikke - men der er faktore, som kunne tyde på at admin ikke sætter det højst på sin to-do liste.
Blandt andet på grund af, at man skal være utrolig heldig for, på nogen som helst måde, at kunne udnytte hullet. Der er tale om indikationer som skal reageres på meget hurtigt (et variabelt interval, som kan betyde alt lige fra under 1 minut til flere timer - men stadigvæk et såkaldt "Window of opportunity")
Exploiten virker på en måde, så man er passiv i udvælgelsen af offer - dvs. at jeg ikke specifikt kunne sætte f.eks. "htm" som mit mål. Hvis man skal bruge en metafor, så er det offeret, som kommer (uvidende) til jægeren - og ikke jægeren som specifikt går på jagt. (hvilket gør exploiten til et spørgsmål om tilfældighed snarere end udvælgelse, mht. offer)
Opsummeret kan følgende argumenter fremlægges, som gør exploiten har begrænset praktisk nytteværdi for en, som skulle ønske sig at overtage en anden bruger:
- Man har ikke kontrol over, hvornår mulighederne opstår - Man ved ikke, hvorlænge et vindue står åbent (eller om det allerede er for sent), når man opdager muligheden - Man har ikke mulighed for specifikt at udvælge en bruger - men er overladt til praktisk tilfældighed, når det gælder, hvilken bruger, man får kontrol over
Der er derfor en _meget lille_ sandsynlighed for at man har noget praktisk udbytte af exploiten dog bør man ikke undervurdere, at hvis man, på trods af ovenstående, lykkes at få kontrol over en bruger, så har man lige så meget kontrol over brugeren, som man har sin egen - man har rettigheder til at ændre email-adresse, svare/kommentere/afvise/uddele points i brugerens sted, ændre minisite-oplysninger, ændre kategori indstillinger - og ja - deaktivere konto'en
Sum Summarum >> Dette er en meget alvorlig exploit - men sandsynligheden for en praktisk, målrettet udnyttelse er _meget_ lav - derudover er der kun et fåtal af brugere som ved, hvordan exploiten virker (og derfor, hvordan den kan udnyttes)...
Derfor kan jeg fuldt ud forstå, hvis admin ikke placerer lukningen af denne exploit højest på sin to-do-liste - jeg er heller ikke selv klar over, hvor nemt det vil være at lukke hullet...
Men det er rart lige at få en opsumering! Jeg syntes at hullet er meget alvorligt, men kan godt at det forekomme noget spotant, men mon ikke en person med gode hackeregenskaer vil kunne bruge dette hul, som en desideret "jæger".
Jeg ville, hvis jeg sad som admin sætte sikkerhedshuller af denne kaliber med høj priotet, da det gælder brugernes sikkerhed, og i sidste ende ekspertens idegrundlag!
Dog har jeg også stadigvæk svært ved at se hvordan man kan tage kontrollen over en anden bruger, og hvilke handlinger der ligger til grund for dette! Men lad det nu ligge, det skal vi ikke snakke om hvordan det sker!
Så må vi bare spændt sidde tilbage og vente på at hullet bliver lukket!
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
