DLL-lek in Windows jaar geleden al gemeld - UPDATE
Het nieuwste lek in Windows dat ook enkele honderden apps raakt, is een jaar geleden al gemeld aan Microsoft. Malware kan meeliften op legitieme dll's die worden geladen door apps.
Het nieuwste lek in Windows dat ook enkele honderden apps raakt, is een jaar geleden al gemeld aan Microsoft. Malware kan meeliften op legitieme dll's die worden geladen door apps.
DLL-lek in Windows jaar geleden al gemeld - UPDATE
Het nieuwste lek in Windows dat ook enkele honderden apps raakt, is een jaar geleden al gemeld aan Microsoft. Malware kan meeliften op legitieme dll's die worden geladen door apps.
Het lek is in augustus vorig jaar ontdekt door onderzoeker Taeho Kwon van de Universiteit van Californië. Hij heeft de kwetsbaarheid toen ook aan Microsoft gemeld. Vervolgens heeft de wetenschapper begin dit jaar een paper (PDF) hierover uitgebracht, en de kwestie nogmaals aangekaart bij Microsoft.
Meeliften met dll's
Kwon heeft een jaar geleden vier kwetsbaarheden gemeld aan Microsoft. Hij heeft toen 1700 verschillende fouten gevonden in bijna 30 applicaties. Daaronder bevinden zich Office 2007 van Microsoft, de gratis Reader van Adobe en alle bekende browsers. Een deel van de door hem geteste apps zijn inmiddels verouderd, maar het is onbekend of de kwetsbaarheid is gedicht in de nieuwere versies.
Zijn paper hierover is in februari gepubliceerd en in juli gepresenteerd op het International Symposium on Software Testing and Analysis (ISSTA). Het probleem zit in applicaties die dll’s (dynamic link libraries) niet aanroepen met het volledige directory-pad, maar met alleen de bestandsnaam. Dit geeft hackers de kans om die applicaties kwaadaardige bestanden te voeren die de naam hebben van de juiste dll's.
'Pas weken mee bezig'
Woordvoerder Christopher Budd van het Microsoft Security Response Center (MSRC) kon tegenover de IDG Nieuwsdienst niet onmiddellijk bevestigen dat het bedrijf al sinds augustus vorig jaar op de hoogte was. Hij laat wel weten dat het bedrijf naar zijn weten pas sinds de afgelopen paar weken bezig is met dit probleem.
Ontdekker Kwon stelt in zijn paper van februari echter dat hij een bugrapport heeft ingediend bij het MSRC en dat die Microsoft-afdeling met hem en zijn collega, associate professor Zhendong Su, samenwerkt aan de noodzakelijke patches.
Exploitcode openbaar
Exploitcode om misbruik te maken van dit lek is nu ook openbaar gemaakt. Die code is direct toegevoegd aan de hackertoolkit Metasploit, door security-expert HD Moore. Hij heeft de lekken vorige week openbaar gemaakt en beschrijft nu duidelijk hoe de lekken in applicaties kunnen worden geïdentificeerd en misbruikt. In een uitgebreide post op het Metasploit blog beschrijft hij het hele proces. Er is slechts een auditing tool voor nodig en vervolgens Metasploit.
HD Moore meldt in een tweet nog dat de onderliggende kwetsbaarheid mogelijk tien jaar geleden al deels is ontdekt en gemeld. Daarbij linkt hij naar een melding van september 2000 over een kwetsbaarheid in de zoek- en laadmogelijkheid voor dll-bestanden door Windows. Een malafide dll kan meeliften en zo uitgevoerd worden. Alle Windows-versies van toen zijn kwetsbaar. Die bug is in april vorig jaar aangepakt door Microsoft.
Microsoft patcht niet
Inmiddels is ook bekend geworden dat Microsoft niet met een algemene Windows-patch komt om dit lek te dichten. Het is immers geen gat in Windows, verklaart woordvoerder Budd. Het patchen is dus een kwestie voor de diverse makers van applicaties die het meeliften mogelijk maken.
Naast Microsoft zelf is dat Adobe en Mozilla. Het is echter nog niet duidelijk welke programma's er precies kwetsbaar zijn. Eerst was er sprake van zo'n 40 applicaties, maar dat is later door HD Moore bijgesteld naar zeker 200 applicaties. Softwareproducenten krijgen van Microsoft wel hulp: het publiceert een reeks richtlijnen voor applicatie-ontwikkeling die gevrijwaard is van deze kwetsbaarheid.
Blokkeren
Het bedrijf biedt wel een blokkeringstool voor malware die via dit lek wil binnenkomen. Die tool is voor alle Windows-versies vanaf XP met service pack 3 (SP3) en Server 2003 met service pack 2 (SP2). Oudere Windows-versies, zoals XP SP2, worden niet meer ondersteund.
In een security advisory waarschuwt Microsoft voor dit beveiligingslek en adviseert het beheerders om WebDAV en WebClient uit te schakelen. Malafide dll's kunnen via die Windows-filesharingtechnieken namelijk worden geladen vanaf gedeelde schijven op zowel een lokaal netwerk als op internet. Daarnaast raadt Microsoft aan de tcp-poorten 139 en 445 te blokkeren.
Update:
Security evangelist Eddy Willems van beveiliger G Data, voorspelt dat nu de exploitcode openbaar is er over twee dagen massale aanvallen op dit lek komen. Hij denkt dat aanvallers er op af zullen komen als vliegen op een honingpot.
Het is wachten op patches van de diverse getroffen softwareproducenten. Apple heeft dit lek al gedicht in iTunes. Willems stelt dat het probleem eigenlijk geen bug is. “Het is meer een design ding. Er ligt een grote verantwoordelijkheid bij Microsoft, dat zeker niet vrijuit gaat. Maar een nog grotere verantwoordelijkheid ligt bij de softwareproducenten die lui programmeren”, vertelt hij aan Webwerelds zustersite Techworld.nl.
Geen reactie, maar wel heel stoer een minnetje... LOSER! :D
Beter opletten inderdaad. Ik had kunnen weten dat je weer de loser zou gaan uithangen. Als het niet zo gaat als je wil ontken je standaard ALLES. En dan begint het gedrein weer.
Je liegt hier glashard op twee punten. Linux heeft nooit een geheugen 'probleem' gehad. Die conclusie verzon jij erbij.
Punt twee, er waren geen langdradige discussies. Alleen hele lange trolls van ene SED die een probleem wat er niet was verzon. En die dat zelf verzonnen probleem te pas en te onpas in discussies kakte om de boel te ontregelen.
ooh zo. Bedankt voor de opheldering.
Ik dacht dat het dll zoek path was "path van exe", "system32", "system", "windows". Ik wist niet dat ie het huidige path ook mee pakte. Maar ook daar is vrij weinig aan te doen.
Je zou het huidige path weg kunnen halen als plek waar dll's worden gevonden... of nog een stap verder gaan en alleen maar dll's toestaan geladen te worden vanuit specifieke mappen (system32 etc.) of een path relatief aan waar de exe staat (je kan loadlibrary een relatief path meegeven). Dan kan je je windows mappen beveiligen (dan moet je natuurlijk niet altijd als administrator inloggen), en kan je wijzigingen detecteren als een dll overschreven wordt waar de exe staat. Sommige programma's zullen dan niet meer werken... en hebben een vrij simpele patch nodig. maar dat is niet zo erg lijkt mij
Er wordt niets aangepast.
Stel jij download een zipje met foto's. Je pakt het uit en het komt in een directory terecht. Nu ga je met verkenner naar die directory en je opent een foto in jouw favoriete foto applicatie, FotoApp.
Die applicatie heeft xyz.dll nodig. xyz.dll wordt gewoon met de foto applicatie meegeleverd en staat in c:\Program Files\FotoApp\dll.
Maar nu blijkt er in het zip bestandje met foto's ook een DLL genaamd xyz.dll te zitten. Welke wordt geladen? Logisch nadenken zegt: de DLL die bij de applicatie zit. De verrassing is: de DLL die wordt geladen zit in de map waar je naar toe bent genavigeerd om de foto's te bekijken.
't Is ook geen lek en het is ook een design keuze maar wel een die makkelijk misbruikt kan worden met wat social engineering of het exploiteren van een ander gat. Cruciaal is wel dat een applicatie in de code niet heeft staan dat het DLL's van het systeem of uit de installatie-directory gebruikt maar alleen de naam van de DLL. En dat bleek opvallend veel voor te komen.
Ik snap het probleem niet helemaal.. DLL's bevatten gewoon uitvoerbare code die dynamisch wordt ingeladen door applicaties. Het is toch niet meer dan logisch dat als een virus/malware deze dll's aanpast, alle applicaties die dit gebruiken deze code dan gewoon uitvoeren. Dit kan ik geen lek noemen.. eerder een design keuze. Ik vind het ook goed van Microsoft dat ze het erkennen maar er verder niks aan doen... er is niet veel dat ze kunnen doen.
he daar gaan we weer.. zelfverzonnen conclusie die ik moet gaan weerleggen. Veel plezier ermee ;)
Beter opletten lijkt me een goede tip...
Ook zo'n los eind. Je hebt nog nooit aangetoond waarom de manier van geheugen boeken zo gevaarlijk was. Je hebt het alleen in honderden verschillende varianten herhaald, maar nog nooit een heldere reden kunnen geven.
Ik kan me herinneren dat we waren blijven steken bij de conclusie dat het beter is op een Windows server dat bijvoorbeeld Exchange crashed omdat het te weinig geheugen heeft. En dat het slecht is op Linux dat een timeserver of zelfs compilatie van een medewerker wordt beëindigd omdat een ander proces met een hogere prioriteit meer geheugen nodig heeft.
Ik snep niet hoe jij dat logisch kan vinden, maar ik kan er vrede mee hebben.
Iets wat je nog steeds niet onderbouwd hebt. Wat maakt dit risicovoller dan het downloaden uit diverse bronnen? Daarbij in acht nemend dat je met die diverse bronnen helemaal niet weet of je updates krijgt?
nee, cli is voor de kenner vaak een snellere wijz eom iets te doen. ook scripting scoort daar hoog omdat het inzichtelijk is.. Maar gebruiksvriendelijk is het allerminsrt en de leercurve ligt dan ook erg stijl
Een gui is juist voor die zaken die je slechts soms doet een handige verbetering. Een goede gui is dan ook winst tov cli voor nieuwe gebruikers maar eigenlijk is dit hele verhaal een no brainer gezien de ontwikkelingen.
Nieuwe gebruikers loslaten op een temrinal met opdrachten die ze niet begrijpen maar nodig hebben om verder te komen is een groot beveiligingsgat. De noodzaak om repos toe te voegen als je wat meer wilt dan de beperkte distro repos is het volgende gat.
Kortom, potentieel gevaarlijke en kwetsbare opzetten die bij toename van het aantal nieuwe gebruikers een volgend probleem gaat worden.
Dat is het ook niet, maar je kan in een verleden besloten hebben om config bestanden en/of dependencies te laten staan omdat je dacht ze in de toekomst weer te gaan gebruiken.
Sommige mensen gooien niet graag wat weg. Dit soort tools kunnen je helpen herinneren wat je ook alweer niet weg wilde gooien.
Er zit een verschil tussen troep die spontaan achterblijft, en troep die alleen maar stof ligt te vangen omdat je vergeet waarom je het ook al weer wilde bewaren.
Zo heb ik op mijn privé laptop nog een XP partitie staan. Omdat het ooit misschien nog wel eens van pas zou kunnen komen. Eigenlijk gigabytes aan weggegooide (of liever weggooibare) ruimte.
Niet?
Of wel?
Het alternatief voor de CLI is een GUI en dat betekent menu's, vensters, tabbladen, knoppen, enz. Daarnaast wil de CLI niet zeggen dat je niet ook een GUI kunt gebruiken. De actie - respons - feedback van de CLI maakt het m.i. zeer gebruiksvriendelijk.
De CLI kent een leercurve, net als andere krachtige omgevingen zoals Photoshop en MS Word. Maar dat maakt het nog niet gebruiksonvriendelijk.
Volgens mij hadden we het over de PM, dat heeft vrij weinig met de cli te maken... Maar goed, ik hap wel.
De cli is idd niet erg gebruikersvriendelijk, maar de cli weghalen zal een hele hoop gebruikers frustreren :) Het voordeel van de cli is dat een probleem erg snel en gemakkelijk opgelost kan worden. Voor iemand die helpt is het gemakkelijker te zeggen dat ze 'sudo apt-get remove blabla --purge' moeten uitvoeren dan dat ze in System - Administration - Synaptic Package Manager moeten zoeken naar 'blabla' en vervolgens moeten verwijderen inclusief configuratie. Ik zeg niet dat ik het met deze manier eens ben, maar ik kan me het wel goed voorstellen dat het zo gebeurt.
Overigens, als ik mijn moeder als voorbeeld neem, weet ze net zo min wat ze doet in de cli als met een gui als ze een handleiding volgt :)
Je hebt alle recht om meer te willen, ik heb soms ook niet genoeg aan de repo's. Maar als je dingen buiten de repo installeerd ben je zelf verantwoordelijk. Wees blij dat er een repo is, in Windows ontbreekt dat in zijn geheel.
Dat klopt, dat gebeurt nog steeds in Ubuntu. Kies een andere distro zou ik zeggen... Doordat Ubuntu minder happig is op updates van OO.o zijn er ook minder bugs. Toen ik Ubuntu 9.10 had leek het me ook slim om de nieuwste OO.o zelf maar te installeren, het resultaat was dat ik te maken kreeg met bugs.
Als je hardware niet herkend wordt is dat niet de schuld van Linux. Linux geeft je tenminste nog de mogelijkheid om met de cli en configuratiebestanden je hardware draaiende te krijgen. In Windows heb ik zoiets nog niet gezien. Toegegeven, de gemiddelde consument zou zoiets niet doen... Hardware drivers ontbreken ook vaak in Windows overigens, dat is niet OS specifiek.
Als je hier beveiligingsgaten bedoelt heb ik geen idee waar die conclusie vandaan komt, want hij past niet bij de rest van de tekst.
Je noemt een aantal gebruikersongemakken van Linux, en komt tot de conclusie dat de dependancies een potentieel kwetsbaar geheel vormen? Ik ben je redenatie kwijt...
Tot slot:
Ik hoop een van je uitzonderingen te zijn, ik zou graag willen dat je je wat nader toelicht :)
Dat zal ik dan eens niet tegenspreken want dat is waar. Ik zou een mediacenter distro downloaden in dat geval. Zelf een distro inrichten als mediacenter is best een klus.
Hoe je van daar zo maar opeens op veiligheidsgaten komt is verrassend. Net als de wilde aanvallen op diverse mensen.
Ik dacht dat je wilde aantonen dat repo's een veiligheidsrisico vormden, maar volgens mij ga je nu een hele andere kant op. Je toont juist aan dat het mijden van repo's een veiligheidsrisico is. Wat ik gewoon met je eens ben.
Aangezien microsofts tegenhanger van de repo maar een zeer beperkte set software beheert, geef je daarmee in feite aan dat de risico's daar veel groter zijn.
Ik wil je best gelijk geven dat repo's een veiligheidsrisico vormen, maar je geeft tot op heden nog geen erg valide argumenten. Tenminste erg weinig dat uitnodigt tot meer dan een wellus nietus discussie.
Is dat waar? Is daar onderzoek naar geweest, of is dat een aanname?
Ik denk dat heel veel hobbyisten prima uit de voeten kunnen met de repo's die aangeboden worden.
Maar goed, misschien heb je gelijk. Maar dan vraag ik me toch af waarom dit bewijst dat repo's slecht zijn. Je geeft zelf aan dat je met Windows Update 'net zo veilig' zit. Met andere woorden, je zit met veel meer software net zo veilig op Linux.
Of je nu instructies natypt van een forum of software uit willekeurige bronnen download, wat maakt het eerste onveilig en het tweede minder onveilig?
Vooral omdat je door een goed gevulde repo minder reden hebt om te werken met zaken uit een niet vertrouwde bron zou ik verwachten dat werken met repo's de veiligheid juist zouden verhogen. Daar neem je echter nog steeds geen helder standpunt over in.
Toon nu gewoon eens aan waarom het onveilig zou zijn om repo's te gebruiken. Want je verhaal dat hobyisten meer risico's nemen snijd geen hout. Op Windows nemen zowel hobyisten als reguliere gebruikers meer risico door uit willekeurige bronnen van alles te installeren, waarbij ze maar mogen hopen dat er een update functie bij wordt geleverd.
Als je de windows update functie gebruikt.. De feitelijke tegenhanger van window die zich helaas Alden beperkt tot Microsoft programmatuur zit je net zo veilig. Maar je beperken tot repos is iets wat veel,vooral hobbyisten, niet willen.. Ergo ze zijn aangewezen op allerlei andere bronnen en daarmee instaan de door mij geschetste problemen en dus de daaruitvolgende onveiligheid.
Ps, kan iemand peter koopman even een blokje rond sturen, hij begint weer vervelend te worden en verpest de discussie met zijneeuwige gezuig.. Lijkt toiletpot wel ;)
Raar dat al dat soort apps nodig zijn om iets op te lossen wat volgens sommigen hier geen probleem is ;)
Vooruit dan we slaan de zuigende reacties van peter koopman even over en reageren op wel serieuze opmerkingen.
Ik neem nu bolletje even mee..
Cli voor nieuwe gebruikers is een nodeloss lastig gegeven. Dat laat onverlet dat nieuwe gebruikers met enige regelmaat gedwongen worden door hard en software problemen om hun heil in de forums te zoeken. Daar krijgen ze adviezen zoals.. Open een terminal en type het volgende in.. Bla bla... Dat doet men dan maar om tenslotte verder te kunnen. Dat zonder enig begrip of kennis van zaken, men zet de deur voor kwaadwillenden wijd open.
Ik en xmet mij velen lopen regelmatig tegen de beperkingen aan van de geïnstalleerde repos en willen meer. Dat alleen roept kennelijk al weerstand op hier, vreemd.
Het toevoegen van repos die wel hebben wat je ziekt( denk voor de gein eens aan de soms v er acerlopende meest gebruikte distro: Ubuntu waar tijdenland verwezen werd naar oude oo versies.
Het omzetten van een linuxdoos in een mediacenter vraagt soms complete typelessen aan de cli om verder te komen als je hardware niet herkend wordt. Kortom allemaal gaten die inderdaad toenemen met het aantal gebruikers.. Tenminste ehet misbruik ervan.
Ik lees hier nixxpro drie de naïviteit heeft te melden dat bij deinstallaties de zaken onder Linux altijd netjes opgeruimd worden omdat men weet wat men daar diet als ontwikkelaar... Kletskoek is het enige woord dat ik darvoor kan bedenken.
Terug even naar polemiek... Discussie over Linux loopt al snel op een welles nietes spelletje uit waarbij er totaal geen wil is om mee te denken, laat staan creatief bij te dragen. Ja daar zijn uitzonderingen op en die geef ik dan ook graag een reactie.
Ik kan me een langdradige discussie herinneren over. Het geheugenmanagement van Linux wat zo zijn zwakke punten heeft die inmidels redelijk opgelost zijn. Datzelfde gaat op voor dependensies die door pm aardig opgelost zijn maar die eigenlijk een rommelige en potentieel kwestbaar geheel vormen. De ketting is tenslotte net zo sterk als zijn zwakste schakel.
Dit vind ik buitengewoon interessant. Ik was namelijk van mening dat 'de command line' in jouw opinie Linux juist ongeschikt maakt voor 'nieuwe' gebruikers? Maar nu zeg je dat ze er vrolijk mee aan de slag gaan. Wat is het nou?
Jawel, want die uninstaller weet dat dan vaak niet. Het risico dat er iets vergeten wordt is gewoon veel groter. Vgl. met een applicatie even een eigen databaseje geven voor dat soort dingen, dan drop je die gewoon bij uninstall (indien door de gebruiker gewenst uiteraard).
Ik vermoed dat SED hier weer maanden mee vooruit kan, in de overtuiging dat hij iets aangetoond heeft. Terwijl de realiteit toch is dat hij heeft aangetoond dat je van de vrijdagmiddag borrel wartaal gaat uitslaan. Tenminste, ik hoop dat het hier de drank is die spreekt.
Je blijft verzanden in wat je mij verwijt..
Polemiek. Ik heb 'm even opgebroken om 'm 'n haiku-achtig karakter te geven want op zich is dit een kandidaat voor quote van het jaar.
Beperkingen die er niet zijn en al helemaal niet in vergelijking met andere operating systems.
Dit lijkt mij getuigen van een, vergeef mij, Windows mentaliteit. Je doet namelijk niets wat de repo je voorschrijft. Jij schrijft je package manager voor wat 'ie moet doen.
Verder willen komen? Wat typen ze na dan? Vertel mij jouw ervaringen. Tip van Tjalbo: heb je echt iets stompzinnigs gedaan weet dan dat een Linux distro als een volledige installatie CD of DVD komt zodat je met een schone lei kunt beginnen.
Ik probeer te bevatten of het veel zegt als ik iets ontken of dat ik weinig nieuwe gebruikers ken en of dat laatste dan op mij slaat of op die nieuwe gebruikers en als dat alleen al veelzeggend is, wat kan er dan nog meer besproken worden en *SEGFAULT*
Weer meen ik hier een spoortje Windows-denken te bespeuren: zo'n "beveiligingsgat" groeit niet met het aantal gebruikers. Een beveiligingsgat wat "dus" veroorzaakt wordt door gebruikers die "stompzinnig natypen wat op een willekeurige forum reactie gevonden via Google als oplossing werd aangedragen" is zelfs geen "levensgroot beveiligingsgat". Vraag maar na bij ome Bill en ome Steve.
De vraag is hoe lang het duurt voordat de kraak ontdekt en hersteld wordt, wat er aan ongein is uitgehaald en wie er iets van heeft geinstalleerd. Lees en huiver hier. Viel wel mee toch?
Google meldt vooral hacks voor de Iphone met 'Cydia'.
Package management is een tool om zeker op de lange termijn een systeem werkend en schoon te houden, ongeacht wat er geinstalleerd, verwijderd en ge-update wordt. Voor mij erg interessant omdat ik een rolling release distro gebruik en sinds 2:31 op 21 november 2007 geen nieuwe installatie heb gedaan. Up-to-date, piekfijn in orde en dat zonder registry cleaner, virusscanner of defragmentatie.
Zie het onderwerp van het artikel. FYI: DLLs werken niet op mijn systeem tenzij ik WINE installeer ofzo.
;)
Ik zie eigenlijk alleen maar een SED gigantisch trollen.
Je verhaal was intern al 180 graden tegenstrijdig. Wat wil of verwacht je dan dat anderen daarvan meenemen?
Pakketbeheer is een uitstekende oplossing voor zowel het afhankelijkhedenprobleem áls de veiligheids-issues die je onder Windows én MacOS hebt door downloads uit willekeurige bron als belangrijkste installatiebron te hebben.
Pakketbeheer lost dit op door een betrouwbare bron te creëren die met cryptografische handtekeningen betrouwbaar wordt gehouden. Wie er vervolgens voor kiest buiten de specs van de fabrikant te treden, door zelf repository's toe te voegen etc., brengt zélf de integriteit van zijn systeem in gevaar.
Een beginnende Linuxgebruiker die te achterlijk is om alle in gewone mensentaal gestelde waarschuwingen hieromtrent te lezen, heeft op elk systeem een probleem. Maar dat heeft 'ie ook bij het hanteren van een blikopener. Uitgaan van een dergelijk gebruikspatroon beledigt niet alleen de intelligentie van de gemiddelde mens, maar vertroebelt ook elke vorm van discussie.
Samenvattend on-topic: pakketbeheer, mits gebruikt conform specificatie van de distributiebouwer, is (veel) veiliger dan een systeem zonder pakketbeheer. Waarom? Omdat de packages in de officiële repository getest en cryptografisch ondertekend zijn, waardoor je altijd zeker weet dat je installeert wat de distributiebouwer bedoeld heeft. Het bewijs daarvoor kun je onder meer hier (hoofdstuk 7 met name maar de rest is ook zeker de moeite) terug vinden.
En nu dan graag ook jouw onderbouwing waarom pakketbeheer onveilig zou zijn, maar dan wel graag zonder terug te grijpen op onoordeelkundig gebruik.
Ik persoonlijk vind dat een understatement. Het is totaal niet onderbouwd.
Er zijn ooit wel eens repositories gehacked, dus is automatisch updaten via een vast adres onveilig? Updaten via vele sites met verschillende niveau's van beveiliging lijkt me een veel groter risico.
En het natypen van instructies op een webforum lijkt me niet onveiliger dan je laten verleiden tot het installeren van AntiSpyware XP. Op forums heb je nog iets van een peer review, iets wat je bij Windows vaak mist.
Ik vind niet dat je dit goed onderbouwd hebt. Laat me even een ander stuk quoten wat ik eerder heb gepost:
De PM is behoorlijk veilig. Wat je van buiten de PM installeert is potentieel onveilig, net zo onveilig als dat je een programma installeert in Windows. Linux bied iets wat veilig en onveilig is, Windows bied alleen iets wat onveilig is. Linux bied je nog een kluis aan, Windows niet. Dat is het verschil.
Maar beste nixpro, zie je niet dat ik jouw eigen zogenaamde argument tegen je gebruik?
Dat valt me van je tegen ;)
Jammer dat inhoudelijke discussies met je zo lastig zijn. Je blijft verzanden in wat je mij verwijt.. Polemiek.
Ja het is een prima oplossing mits je de beperkingen niet telt. Ik geef aan dat PM lekker loopt als je alleen datgenen doet wat de repo je voorschrijft. Ik zie heel wat gebruikers die zelf verder willen komen die inderdaad precies doen wa tik schets, stompzinnig natypen wat op een willekeurige forum reactie gevonden via Google als oplossing werd aangedragen. Als je dat dontkend dan ken je blijkbaar weinig nieuwe gebruikers van linux. Dat alleen is al veelzeggend lijkt me zo.
Pm is dus op termijn een levensgroot beveiligingsgat, zeker als het aantal gebruikers toeneemt. Er zijn trouwens al diverse keren repos gehacked met alle gevolgen van dien. Google daar maar even op ook op WW is daar het een en ander van te vinden.
Kortom, geen tegenspraak die je graag ziet maar onderbouwing van een gammel systeem op termijn.
Zeker is het onder Windows niet beter, maar daar gaat het niet over.. Blijf dus bij de discussie en wijk eens niet af om de zaak weer warrig te maken.
Er is toch een verschil. Het laden was hier specifiek voor alleen deze package, terwijl het op Windows een meer generiek probleem is, als gevolg van de standaard api voor het zoeken van een dll.
Dat een probleem ook op *nix kan voorkomen ben ik verder wel met je eens, alleen is in dit geval je voorbeeld niet heel goed.
En de wild west onder Windows stelt ook niets voor als je je beperkt tot met Windows meegeleverde apps en 3rd party apps alleen van professionele gerenomeerde leveranciers (bv. Adobe al is dat misschien niet het beste voorbeeld ;-) ) of min of meer betrouwbare kanalen (zoiets als download.cnet.com) betrekt.
Het aantal mogelijkheden dat tot je beschikking staat bij gesloten software is nu eenmaal beperkt, je bent afhankelijk van wat de leverancier je biedt. In het geval van een distro kan er een tweede leverancier komen: ik kan voor mijn proprietary video driver kiezen of ik de installer van Nvidia neem of 'm uit de repo via het package management installeer. Voor een aantal add-ons voor Firefox geldt bijvoorbeeld hetzelfde: ook die zitten mede in de repo. De belasting is dan natuurlijk voor de distro en de maintainers ervan maar het geeft wel aan hoever je het package management kunt toepassen.
Op Windows zit het ook in applicaties zoals iTunes (inmiddels gedicht).
Het gaat er meer om dat 'bepaalde' non-windowsgebruikers denken dat dit probleem zich alleen op windows voordoet terwijl hjet laden van arbitrary libraries vanuit de working directory dus ook op een *nix variant computer kan voorkomen en ook is voorgekomen.
Zelfs dat hangt af van de hoeveelheid tijd die je zelf wil investeren naar mijn idee.
Bijna alle projecten worden wel als source aangeboden met een make file erbij. Met wat inspanning zou je het dus best net zo 'wild west' kunnen maken als in Windows. Maar het wordt inderdaad niet gestimuleerd.
Verder kent ook Linux de mogelijkheid van losse installers. Partijen als Google en Vmware maken daar oa gebruik van. En zolang je daar bewust en matig gebruik van maakt, zijn de risico's goed te overzien lijkt me.
SED probeert een zwart-wit discussie te maken van vrij genuanceerde materie. Er zijn in Linux meerdere wegen die naar Rome leiden. Je kan daarbij kiezen tussen hoofdwegen en omwegen, met elk zo zijn eigenschappen.
Leuke link, maar je ziet 3 dingen over het hoofd:
Ik dacht dat we het eens waren dat het geen lek was, maar een feature.
Het lek zit niet in Debian maar in een package genaamd trickle.
Het lek is ruim een jaar geleden ontdekt *en* gedicht.
Hier nog even een voorbeeld van een zelfde lek maar dan in Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513456
Ik snap dat jouw reactie verkeerd is terechtgekomen en onder een hogerstaande reactie van mij moest staan die wel over 'PM' ging.
Package management en Linux distro's gaan hand in hand. De distro's zijn ontstaan omdat het zo lastig was om een systeem op te zetten en te onderhouden in de begindagen van Linux. Nu nog zijn de package managers zeer onderscheidende factoren tussen distro's.
Package management levert een gebruiker geen enkele beperking op, eerder het tegenovergestelde. Ook levert package management geen "illusie van veiligheid": er is sprake van een onafhankelijke laag van kwaliteitscontrole maar de illusie van veiligheid komt met het gebruik van andermans software en dat staat los van package management.
Jouw keuze wordt beperkt door de beschikbare software. Met beschikbare software bedoel ik algemeen beschikbare software en niet alleen wat er op een gegeven moment in de repository van je distro zit. Alles wat aan software beschikbaar is en aan de praat gekregen kan worden voor jouw OS en hardware kan je draaien, je bent niet verplicht om van enig package management gebruik te maken. Je bent vrij om software te draaien die zich niet in een repo bevindt.
Hier wreekt zich ook de gelijkstelling van Linux: de kernel en Linux: een compleet besturingssysteem met applicaties. Het is nog steeds mogelijk om van de grond af aan een systeem op te bouwen met als basis de Linux kernel en de GNU gereedschappen. Welke kernel je kiest en hoe je die configureert staat je vrij, net als de keuze voor bestandssysteem en bootloader. Vervolgens kan je daar bovenop de software installeren die je hebben wilt, desgewenst gecompileerd met je instellingen die alleen voor jou relevant zijn. Installeer maar wat je zelf uitkiest.
Een plusje voor het package management: ik gebruik mijn package manager ook voor het binnenhalen van dependencies om sources van development te compileren of voor het binnenhalen van source code zelf. 't Is mogelijk om verschillende versies van 1 programma naast elkaar te gebruiken.
Tja, ik vind het niet de moeite om hier inhoudelijk op in te gaan. Ik zal jouw stelling maar zo begrijpen: 'Zolang je niet allerlei testrepo's gebruikt is package management een goede oplossing'.
Snap dat package management alleen kan als je òf een exclusieve repo kunt controleren zoals Apple's Appstore òf werkt met vrije software. Er bestaat eigenlijk geen alternatief voor de applicatie wild west in Windows. Je hebt dan dus geen keuze.
Met andere woorden, een typische SED reactie.
Wat me eigenlijk het meeste stoort, is dat de draad verder vrij genuanceerd is. Dat lijkt niet toegestaan. Liever worden er oude koeien opgedregd en problemen verzonnen in de hoop de discussie te doen ontsporen. =P
Er zijn veel oplossingen verzonnen voor ellendige problemen. Zo vraag ik me bijvoorbeeld af of je van 8 gigabyte aan dll's in vele versies echt gelukkig wordt. En dat je met zoveel dll's nog steeds dll's in je current directory nodig hebt is eigenlijk al verbazend op zich.
Linux heeft een andere benadering gekozen waarbij afhankelijkheden gecontroleerd worden. Misschien is dat wat meer werk, maar naar mijn idee spaart het wel resources.
Generaliseren... Ultieme oplossingen bestaan niet. Elke oplossing heeft zijn nadelen.
Als je het vergelijkt met de oplossing van Windows waar iedereen 'setup.exe' download van 'het internet' en uitvoert met admin rechten waarna het alles mag doen wat het wil dan lijkt me een PM veiliger. Verstandige mensen blijven veilig binnen de PM, alleen mensen die weten wat ze doen zouden buiten de PM software moeten installeren.
Maar ik begrijp nog niet helemaal wat je bedoelt. Dus omdat mensen de mogelijkheid hebben om buiten de PM software te installeren is de PM een slechte oplossing? Als je op die manier redeneert kan je zeggen dat een kluis een slechte oplossing is omdat men het geld buiten de kluis kan leggen. Corrigeer me maar als ik het verkeerd begrepen heb.
Je moet niet aan de slag met testrepo's, de hypothetische gebruiker in je relaas kiest daar zelf voor.. en dat is niet verstandig voor wie een stabiel systeem wil, zoals je ook gewoon wordt verteld in de documentatie bij het pakketbeheer en meestal ook nog door de eigenaar van een dergelijke test-repository. Vervolgens projecteer je twee aannames zonder enige onderbouwing:
..en:
..op de gehele gebruikerspopulatie én generaliseer je pakketbeheer in zijn geheel als zou het complete fenomeen een "illusie van veiligheid bieden" op basis van de voorgaande aannames. Tot slot poneer je op basis van dat volstrekte drijfzand een stelling:
..en probeert op basis daarvan pakketbeheer weg te zetten als een slechte oplossing terwijl het aan het begin van je reactie nog "een goed werkende oplossing" was.
Buiten dat je jezelf in één en dezelfde reactie tegenspreekt, doe je hier precies waar je anderen (waaronder ondergetekende) graag van beschuldigt. Je talent voor polemiek is onmiskenbaar, maar wat is je drijfveer?
Ikm heb ooit in het verleden een registry-comparer gemaakt. Eerst runnen voor de installartie avn een applicatie en na de installatie nogmaals.
Je staat er versteld van hoeveel junk er bij een installatie meegeleverd wordt. Er is
sowieso een hoop scratch-info die je zonder meer kan verwijderen, maar zelfs van zaken die wel nodig lijken, is maar een deel echt nodig.
Ik kon applicaties moeiteloos van de ene PC naar de andere zetten met maar een fractie van de registry-keys en het leek weinig uit te maken.
Hetv lijkt wel DNA; 90% daarvan lijkt ook overbodig.
Maar laten we niet vergeten dat de PM een inmiddels (na heel veel ellende) goed werkende olossing is voor een ellendig probleem in Linux.
Men presenteert het hier nu als de ultieme oplossing (jij brengt gelukkig wat nuance aan) maar de PM is een wijze van aanbieden die veel gebruikers sterk beperkt en daarmee een illusie van veiligheid biedt.
Ik installeer graag wat ik zelf uitkies en niet wat de repo voor mij kiest. Je moet dan aan de slag met allerlei testrepo.'s en toestemming geven mbv keys die voor de meeste alleen maar slaafs natypen van wat de forums adviseren, zonder idee van wat je doet. Dat kan nooit veiligheid bieden op termijn voor veel gebruikers. Alleen daarom is een PM dus een slechte oplossing.
Het zijn oplossingen voor een probleem wat eigenlijk niet goed opgelost kan worden, een probleem wat min of meer inherent is aan de complexiteit van moderne computersystemen en menselijke verschillen. Wat daarnaast niet meehelpt is dat de daadwerkelijke implementaties ook nog eens minder goed zijn dan ze in principe hadden kunnen zijn; iets wat ook niet zomaar even gefixed kan worden.
Er zijn een boel GUI apps waarvan de werkelijke functionaliteit in een command line app zit (ImageMagick, CDParanoia, FFMPEG, etc.). Ik denk dat dit principe onder Linux meer voorkomt dan onder Windows al worden programma's als CDParanoia ook toegepast in Windows-apps. Daarnaast zullen er gewoon resources binnengehaald moeten worden als bibliotheken of programmeertalen, ook voor de onderliggende apps.
In de gewone distro's wordt dit centraal afgehandeld via de package manager. Ik gebruik een Debian systeem en als packagemanager gebruik ik apt. Geef ik opdracht om pakket X te installeren dan regelt apt dat pakket Y en Z meekomen als die nodig zijn en nog niet al geinstalleerd waren.
Een alternatief is decentrale afhandeling waarbij alle resources worden meegeleverd met de installatieroutine (bv. MSI in Windows) en geinstalleerd (voor zover ze nog niet beschikbaar zijn).
Het verandert niets aan het probleem op zich: de applicatie heeft de resources nodig. Misschien gebruik je een packagemanager die in een scherm toont wat die doet, misschien zie je een lijst van resources over je scherm vliegen in een shell of misschien zie je een installatie venster wat een balkje toont en een label waarop de namen van de resources voorbij flitsen.
Dat klinkt alsof je 100 experimentele repositories hebt toegevoegd aan je package manager, of je hebt het 10 jaar geleden voor het laatst getest, of je gebruikt helemaal geen package manager.
Er was een tijd dat dependecies best een probleem waren, maar de laatste jaren heb ik er geen probleem meer mee gehad. Tenzij ik de behoefte voelde om te gaan experimenteren met hobby repo's. En packages die ik van het web downloadde om los te installeren.
Als je gewoon het installatiemechanisme gebruik zoals dat bij het OS wordt geleverd, is er helemaal niets aan de hand. Echt al jaren niet meer. Doe eens een voorbeeld, zou ik zeggen.
Eigen resources? Als ik iets wil installeren op linux is het met enige regelmaat een ramp omdat de betreffende applicatie weer andere applicaties nodig en met pech heeft die ook weer applicaties nodig. En als je dan pech hebt werkt de applicatie die je dan wou gebruiken nog steeds niet.
En iedereen die het daarmee niet eens is, bezondigt zich aan verbazingwekkend gezeur. ;)
Nicely played :)
"Misschien"? "Waarschijnlijk"? Onbekend maakt onbemind, dat neem ik je niet kwalijk. Ik wil je ook best meer vertellen over het beheer van grote UNIX-infrastructuren in heterogene computerlandschappen vol vertrouwelijke informatie. UNIX werd namelijk al volop ingezet voor die taak toen MS-DOS 3.0 net in staat was de systeemdatum ook in een europees formaat te tonen. Een systeemconcept dat zo oud is, toont vanzelfsprekend zijn leeftijd. Onderschat echter niet de kracht van de CLI, de UNIX ontwerpfilosofie en bijbehorende tooling die in de loop van decennia alleen maar is verfijnd en doorontwikkeld.
In de hele discussie onder dit artikel heb ik nog helemaal niets gezien wat in een hedendaags UNIX-netwerk niet minstens even elegant zou kunnen als met Windows. Sterker nog: veruit het meeste kon je 25 jaar geleden ook al gewoon doen. Anders, dat wel, maar 'anders' is niet synoniem aan 'moeilijk'.
Als je niks tegen GUI's hebt dan is http://ubuntu-tweak.com ook een mooie. Met bruikbare clean-functies om naast oude packages ook de overgebleven .config files weg te halen.
Stel je voor dat Microsoft geen registry had bedacht, hoe langzaam was windows dan wel niet geworden? Is het dan niet heel erg bijzonder dat Linux zonder enige vorm van registry gewoon sneller opstart dan de zoveelste overerving van MS-Windows for workgroups (3.11)?
Verkeerde volgorde?? Sinds wanneer is dat een issue?
In het kader van 'behandel uw naaste gelijk uzelf', doe eens onderbouwing a.u.b.?
Relatief minder impact per toegevoegde key, maar per saldo alleen maar trager. Wie dit weet te doorbreken, heeft de heilige graal van database-ontwerp in handen.
Ik moet toegeven dat je daar een punt hebt :)
Er gaat me, met die quote erbij, ineens iets dagen ja. Ik had die link van jou destijds /wel/ gezien. Gelijk even downloaden en mee spelen, het idee spreekt me op zich wel aan. Maar ik ben wel nog even benieuwd hoe ze het package management dan hebben ingericht, want het zijn wel allemaal symlinks dus je kunt nog steeds met "dode" links te maken krijgen, overbodige bestanden waar niemand meer naar symlinkt etc. B.v., appA en appB gebruiken beiden shared.so. Die staat dan zelf in /Programs/Shared/1.0/lib/shared.so (oid), maar je moet nog steeds ergens aangeven dat-ie geinstalleerd moet worden als-ie er nog niet is. Spannend, leuk! :)
Ja precies ;-)
Je bereidheid om het ergste te vermoeden bij Linux begint wel heel erg op te vallen. Acht je de kans werkelijk zo uitgesloten dat ook daarvoor beheertools zijn?
Linux servers draaien al een tijdje mee. Aannemen dat in die tijd niemand op he idee is gekomen dat zoiets beheersbaar moet blijven lijkt me eigenlijk heel onlogisch.
Hooguit het beheer van desktops in zo'n netwerk zal misschien nog niet zo vergevorderd zijn, omdat desktops in de Linux wereld nog niet echt een speerpunt zijn.
Het bestaat zeker wel, getuige bijvoorbeeld de volgende pagina van Novell.
Waarom zou dat zo zijn volgens jou? Als het splitsen, kopiëren en/of hosten een beslissing van systeembeheer is, dan zie ik niet in waarom zoiets een risico moet zijn.
Je zegt: de vertraging per toegevoegde key wordt steeds kleiner. Of dat zo is en tot hoever dat opgaat weet ik niet maar het zal wel het argument zijn voor applicatiemakers om zoveel mogelijk waarden in de registry te pompen.
Dat zei ik ook maar daarmee doen we toch echt geen recht aan de permissie-, configuratie- en auditmogelijkheden, noch de refcount en remote connect faciliteiten die de registry ons biedt. In plaats daarvan benadrukte ik het single point of failure aspect, wat natuurlijk erg flauw is in vergelijking met zulke voordelen.
De permissie-, configuratie- en auditmogelijkheden van platte tekstbestanden, het package management door een packagemanager (die de 'refcount' doet) zijn ultiem inferieure oplossingen en voor straf dienen de simpele Linux admins voor hun 'remote connect' 20 open SSH consoles per applicatie te hebben.
Jij zou ze kwijt zijn als ze allemaal in /Programs/$appName stonden? :D
Door de traditionele structuur als directories met symlinks op te nemen in GoboLinux zou je op zich nog steeds uit de voeten moeten kunnen met jouw kennis, ervaring en scripts.
Ik heb wat vet gemaakt om aan te geven dat de quote heel erg on-topic is:
For each category of files, there is a directory under /System/Links grouping files from each application as symbolic links: Executables, Libraries, Headers, Shared and Manuals. For compatibility, each "legacy" directory is a link to a corresponding category. Therefore, /bin, /sbin, /usr/bin, /usr/local/bin (and so on) are all symlinks to /System/Links/Executables. Environment variables are also simplified: export PATH=/System/Links/Executables is enough.
In short, what he have is a database-less package management system: the directory structure itself organizes the system bron (uit 2003) en zie ook de faq.
Of er nog leven zit in Gobo, hoe het precies werkt en of het verder een interessante distro is weet ik niet, het concept spreekt me wel aan. Je kunt je uiteindelijk ook afvragen waarom we met directories als /etc, /bin(, /sbin, /usr/bin, /usr/sbin) werken, anders dan vanwege traditie.
In de Registry kan je per key permissies instellen, inclusief auditing etc. Je kunt er ook remote naar connecten via een service.
Met configbestanden in het filesysteem kan je mischien hetzelfde effect ook bereiken, maar als de configuratie complex wordt (bv in een groot netwerk met verschillende administrator groepen en centrale monitoring) dan krijg je het toch moeilijk met de simpele Linux oplossing. Windows systemen (zoals IIS, Exchange, SQL, OCS) hebben vaak handige administrator consoles hebben waarmee je vele machines vanuit één tool en op één plaats kunt configureren. Met de Linux oplossing zit je waarschijnlijk met 20 open SSH consoles je applicatie te configureren.
In de Registry wordt vaak een "refcount" bijgehouden op gedeelde objecten (Services, COM objecten, DLL's). Als die op 0 komt dan kan het gedeelde object weg. Op die manier kan een object zelfs worden opgeruimd als twee applicaties een gedeeld object gebruiken en in de "verkeerde" volgorde gedeinstalleerd worden.
Dat zijn nogal wat potentiële beveiligings issues die je zo even opsomt;)
aldus SECURITY.NL
Zo gemakkelijk is het wel als het binnen de software zo wordt ingericht. een Library hoort daar thuis, zet je hem ergens anders werkt de boel niet.
Dat dit momenteel niet makkelijk is, ligt meer aan de flexibiliteit van het OS of gebruikte compile software en "Mijn excuus" de luiheid van de programmeur.
Het grappige is juist dat als je een goede index hebt het groeien van de database steeds minder impact zal hebben op de snelheid. Performance is echter sterk afhankelijk van de gekozen index. Het ene type index presteert heel goed bij lezen maar minder goed bij schrijven (zou goed van toepassing zijn op de registry). Andere indexen presteren relatief minder bij lezen maar bieden relatief betere schrijf peformance.
Dat geeft toch niet ? Lijkt me prima dat een applicatie in de registry wegschrijft of ik een lijstje van A-Z gesorteerd wil zien of van groot naar klein.
Een uninstall is uitgebreider dan een hashtable van alles wat moet worden verwijdert. Over het algemeen (bij MSI van Microsoft of andere populaire installers) is het een script met instructies. Dit kan van allerlei instructies zijn met verwijder bestand, herstel dit, verwijderen registry key, etc... Echter vaak schieten de scripts te kort of werkt het gewoon niet en probeert het mappen of registry keys te verwijderen waar het nog handles naar open heeft en ja, dat werkt dan niet. Soms laten uninstallers ook bewust settings staan zodat als je het programma later weer installeert je de oude settings weer hebt.
Meuk als volstrekt onbegrijpelijke identifier-achtige strings waar je niet aan kunt zien of ze nu nog wel of niet nog ergens bijhoren of wie ze er ooit heeft neergezet. Meuk als configuratie van één pakket op weet ik hoeveel verschillende plaatsen. Meuk als bijvoorbeeld Apple (mag elke willekeurige vendor zijn, maar dit zag ik laatst toevallig), dat zichzelf 'Apple' maar ook 'Apple Computer' mag noemen en onder beide noemers informatie mag stallen over één en dezelfde applicatie. Meuk als de gewoonte van Microsoft om interne applicatienummers o.i.d. te gebruiken in de registry van gebruikers.. hoe moet ik nou weten wat MS bedoelt met een registry-key die bijvoorbeeld '2037' heet?
Verder wordt een database die niet van structuur verandert altijd trager doorzoekbaar naarmate deze groeit. Dat is wiskundig waterdicht bewijsbaar.
Misschien begrijp ik je niet goed, maar als je hiermee bedoelt dat er dan meerdere programma's van dezelfde DLL gebruik kunnen maken ben ik het niet eens. Dit was in principe een leuke vondst waarmee in het verleden toen schijfruimte nog duur was bespaard kon worden. De problemen kwamen echter al snel met de verschillende DLL-versies die allemaal wel dezelfde naam hadden.
Daarom lijkt mij tegenwoordig zeker de betere oplossing om voor elk pakket de eigen DLL's in de eigen directory op te bergen.
Ook indien een pakket ge-deinstalleerd moet worden ruimt dat wel zo makkelijk op zonder dat andere pakketten beïnvloed worden.
Heb het altijd een belachelijke instelling gevonden waarmee je gebruikers dom houdt en misbruik vergemakkelijkt. Ik zet het ook altijd uit (of "aan" :-) bij mensen die mij om hulp vragen (en leg uit waarom).
Dat opruimen is meestal optioneel omdat het pakketbeheer is ontworpen met het standpunt 'nooit iets verwijderen wat je er niet zelf hebt neergezet'. Door de beheerder aangepaste configuratiebestanden blijven normaliter dan ook staan, omdat die geen "eigendom" van het pakketbeheer (meer) zijn. Met een extra vlaggetje aan het deïnstallatiecommando kun je echter opgeven dat ook de configuratie verwijderd moet worden.
Een configuratiefile ook. Alleen kun je die wél vrijelijk splitsen, kopiëren, over het netwerk hosten etc.
Bedankt, daar ga ik even induiken.
De applicaties hoeven zich dus compleet geen zorgen te maken over dat opruimwerk, mits geinstaleerd via de packagemanager, gezien de PM deze opruimd als geen enkele applicatie ze meer nodig heeft
De registry is effectief gewoon een soort database met key-values.
Het disabelen van webdav wordt beschreven in de security advisory van Microsoft:
http://www.microsoft.com/technet/security/advisory/2269637.mspx
en de poorten 139 en 445 kun je blokkeren in je firewall.
Buiten dat lijkt het me niet nodig dat een 32-bits-applicaties (die dus van zichzelf weet geen 16-bits app te zijn) een 16-bits directory gaat doorzoeken.
Je hebt bij Microsoft XP een verschil tussen de Home edition en de Professional edition ( het verschil is twee bytes heb ik wel eens ergens gelezen, maar goed )
Volgens mij is dit nog uit het Win NT tijdperk (1996 omstreeks). Door twee settings uit de registry te verzetten, kon je een Workstation op laten starten als een server.
Dat betekent echter niet dat het een server is. Veel ondersteunende software zit gewoon niet bij de workstation-versie maar wel bij de server-versie.
Na Win NT zijn de beide versies wel een eigen weg gegaan en is het truukje niet meer uit te halen (overigens twijfel ik er niet aan dat een hoop subroutines common zijn voor beide platformen).
Dat hangt van de applicatie af natuurlijk, maar er wordt run-time naar geschreven voor allerlei (extra) instellingen. Een tekstbestand in /etc is in principe immutable, al kun je hem met configtooltjes of met de hand natuurlijk wel wijzigen.
Daar kan ik niet over oordelen zonder de kwaliteit van die indexes te kennen, maar in het algemeen worden ook indexes altijd trager naarmate een datasbase groeit.
Which brings me back to my point: rm -rf /etc/appName is altijd betrouwbaarder dan in een hashtable vanalles verwijderen, want ook /dat/ moet weer ergens bijgehouden worden (welke keys het zijn). En ik snap wel dat dat misgaat ja.
Die zal ik zeker eens checken, klinkt interessant. Dank voor de tip. Maar in het algemeen ben ik juist zeer content met het systeem waar alles juist in specifieke dirs staat in plaats van in een eigen dir, dan weet ik tenminste weer ik moet zoeken (config in /etc/appName, libs in /usr/lib/appName, binaries in /usr/bin/appName etc.). Maar goed, er zijn onder Linux-aficionados hele flamewars uitgevochten over of de /opt directory zin heeft of niet :)
Klopt, het is een eigenschap van aptitude dus komt uit Debian.
Ik heb wel eens eerder GoboLinux genoemd, een Linux die alle apps in hun eigen directories onderbrengt met hun resources. Betreffen het shared libs dan staan die in een aparte dir en komt er een symlink in de app dir.
Verder schijnt er een kernel module te zijn die het een en ander 'onzichtbaar' maakt voor de eindgebruiker en zo houd je als het goed is een heel clean systeem over.
En je hebt de mogelijkheid om configuratie bestanden te behouden ook al deïnstalleer je de applicatie.
Zolang het functioneert en als het breekt, dan breekt het hele OS. Wat het soms spontaan kan doen, als ik wat Windows klanten moet geloven. Inmiddels weet ik hoe ik het moet fixen.
Wat is er precies geavanceerd aan een database met key-value pairs? (begrijp me niet verkeerd, ik heb weinig tegen de registry maar ik zie geen reden om er erg enthousiast over te worden)
DLL is toch gewoon de standaard oplossing voor een bibliotheek onder Windows? Maw. zodra je logica en andere resources gaat afsplitsen naar bibliotheken kom je bij DLLs uit ongeacht of de logica voor meerdere programma's te gebruiken is. Applicatie-specifieke dingen mogen van mij bij de applicatie zelf staan.
Centrale beschikbaarheid is maar één oplossing, er zijn OSsen die het anders doen. En daarnaast is de applicatie directory opgenomen in het pad.
Het is zo op het eerste gezicht merkwaardig dat DLLs opgeslagen zouden kunnen staan bij data files maar dat is dan ook hetgeen we over praten.
Dan is het de vraag hoe vaak je een executable vanaf de commandline opstart en of de extensie ook in snelkoppelingen en menu items is opgenomen. 't Is wat verneukeratief dat de extensies wel een betekenis hebben maar default niet getoond worden in verkenner oid.
Als je had gezegd: je hebt "edlin" om de registry te editten vanaf de command line zou ik nog met je mee kunnen gaan.
Je kan de registry aanpassen met de REG command line tool. Type maar eens "REG /?" in een CMD prompt. Ook handig om het aanpassen van registry settings te automatiseren.
Meuk als ?
De registry is feitelijk gewoon een database (verdeeld over meerdere bestanden) met een hiërarchische structuur waar je settings in kan opslaan. In tegenstelling tot wat vele geloven / beweren is dat het groeien van de registry niet of nauwelijks gevolgen heeft voor de snelheid van de registry. Net als een database bevat de registry indexes zodat gegevens snel gevonden kunnen worden.
Het vervuild raken van de registry is dus eigenlijk geen issue. Maar eigenlijk moet een applicatie natuurlijk gewoon z'n rotzooi opruimen als het gedeïnstalleerd wordt. Helaas laat de kwaliteit van (un)installers nog wel eens te wensen over.
Ja Windows 7 doet dat ook. Windows 7 probeert eerste .COM, dan .EXE, .BAT en .CMD. Misschien zijn er nog wel meer maar deze worden volgens mij als eerste gezocht.
Je kan het path naar de System folder opvragen met de GetSystemDirecory API functie. Maar een applicatie moet eigen DLL's natuurlijk niet in de System folder zetten dus je zou dat eigenlijk niet nodig moeten hebben.
Ubuntu geeft al sinds een aantal versies de optie om niet langer vereiste bestanden eenvoudig te verwijderen.
..en klaar. Zit vast ook allang in Debian, maar dat heb ik alweer een tijdje niet meer gebruikt. Veel pakketbeheersystemen kennen reverse dependencies, dus zouden dit ook moeten kunnen.
Oh, en dan vergeet ik de belangrijkste: het registry is een bitch om aan te passen vanaf de commandline, waar de tekstbestanden in /etc met vi, pico, emacs of welke teksteditor ook prima te wijzigen zijn in geval van nood.
De admin hoeft alleen het pakketbeheer maar te gebruiken. De verantwoordelijkheid voor wat achterblijft in /lib, hangt af van de distributiemaker.. en die weet echt wel wat 'ie doet.
En de Windows registry? Een grote gecentraliseerde binaire blob die alleen maar groeit, fragmenteert op disk, talloze volstrekt onbegrijpelijke en ongedocumenteerde krochten kent en na verloop van tijd tot de nok vervuild raakt door talloze verschillende applicatiespecifieke deïnstallatieroutines.. Dat is écht een verbetering ten opzichte van een lichte /etc directory met daarin systeem configuratiebestanden die zich met elke live-CD eenvoudig laten redden als er eens wat misgaat met je hardware. In sommige BSD's vind je verder nog /usr/local/etc, waar applicatiespecifieke configuratie wordt opgeslagen. Ook allemaal weer in een vorm die met elke tekst-editor sinds de jaren '70 kan worden beheerd.
En "standaardoplossing"!? De registry!?!? Wahahaha!! Echt! Het is gewoon een hiërarchische DB waar je als applicatiebouwer in kunt verklooien zoveel je maar wil omdat installatie toch meestal als admin plaatsvindt. Ga voor de grap eens kijken wat Office allemaal uitbraakt over je registry en durf dan eens te ontkennen dat /usr/local/etc/Office2007 een elegantere oplossing is om applicatiesettings te bewaren.
Hier wil ik wel even wat extra uitleg verschaffen:
Als het goed is niet, het is nl. een kwestie van "rm -rf /etc/appName".
Het verschil is dat je gewoon een mapje kunt wegpleuren, ipv via een API een registry aan te spreken. Of dat beter of slechter is is grotendeels een kwestie van smaak (ik vind het beter).
Hier verschillen we van mening. De registry bevat niet alleen settings maar ook allerlei andere meuk. Bovendien is de hierboven beschreven methode van "verwijder alles" vele malen betrouwbaarder dan registry keys aflopen (dat blijkt, want de registry raakt onherroepelijk vervuild). Linux start ook op als een tierelier, dus het parsen van wat tekstfiles kan het probleem niet zijn (NB: je moet ook wel slim bedenken welke bestanden je wanneer wilt parsen tijdens het opstartproces). In het algemeen is het parsen van tekstfiles trouwens sneller dan welke binaire operatie dan ook, omdat daar altijd een extra applicatie tussenzit (stom voorbeeld, maar benchmark maar eens parse_ini_file vs. "select * from settings" in PHP).
Je kunt jezelf natuurlijk ook afvragen waarom (AFAIK) alleen Windows een registry heeft en alle andere OS'en het anders oplossen...
Onder Debian en afgeleiden in principe wel, maar dat kan aan de kwaliteit van Aptitude liggen.
Nee. Het opruimen van de applicatie verloopt beter dan bij de meeste Windows applicaties. Waar bij Windows nog wel eens troep achterblijft heb ik dat bij Linux nog niet meegemaakt.
Alleen dependencies worden volgens mij niet opgeruimd, maar dat gebeurt bij Windows volgens mij net zo min.
En of de Windows Registry zo goed is, en de Linux methode zo slecht, is denk ik vooral een kwestie van smaak.
De laatste keer dat ik Linux gebruikte had deze toch echt een directory /lib met gedeelde libraries. En een directory /etc vol met verschillende soorten configuratiebestanden.
Wat daarin achterblijft als je een applicatie de-installeert weet ik niet, waarschijnlijk is het opruimwerk daar helemaal aan de talenten van de admin overgelaten.
Ik zie niet hoe dat anders of beter is dan in Windows.
Ik verbaas me trouwens ook vaak over het gezeur over de Windows Registry: die biedt een geavanceerd, snel en veilig mechanisme voor configuratiesettings dat prima functioneert. De Registry werd lang geleden door Microsoft geintroduceerd toen bleek dat Windows 3.1 traag opstartte doordat zo veel lange .ini bestanden geparsed moesten worden. Voor dat probleem heeft Linux nooit een goede standaardoplossing gehad, iedere applicatie en service doet zijn configuratie op zijn eigen manier.
Dat is natuurlijk ook niet helemaal waar. Er zijn genoeg projecten die gedeelde bibliotheken gebruiken. In Linux noemen ze het dependencies.
Bekijk bijvoorbeeld maar eens de dependency list van een willekeurige OO.o en je ziet dat ook daar gedeelde resources zijn.
Edit: Nixpro en Bolleke zitten ook al als een bok op de haverkist. :D
Ehm... Linux-systemen hebben ook gewoon shared objects (.so), dat is eigenlijk hetzelfde concept als DLL's. Het grote verschil is dat door package management het ueberhaupt vrijwel nooit nodig is zoiets zelf te overriden als applicatie (vergt natuurlijk wel enige discipline bij de programmeurs, zoals interfaces gelijk houden enzo). Een applicatie die alleen werkt met een nieuwere versie van een DLL waarbij de nieuwe versie andere applicaties breekt, /dat/ is slecht nieuws en dat komt dan vermoedelijk omdat de DLL andere interfaces heeft (extra argument bij functie bijvoorbeeld).
Object-georienteerd programmeren, les 1: je verandert NOOIT (ik herhaal: NOOIT) een interface!
Verder verwijdert de PM als het goed is netjes ongebruikte .so's, dus dat is wel soort-van vergelijkbaar met het registry. Alleen bevat dat ook allerlei instellingen, dat was dan weer een minder goed idee.
Klinkt leuk, maar UNIX maakt ook gewoon gebruik van shared libraries en dat heeft zodanig veel voordelen dat het niet heel verstandig zou zijn om daarmee op te houden.
Die hele DLL-structuur is een zwaar achterhaalde methode van bibliotheken beschikbaar stellen. Beter is de methode waarop Unix, Linux, BSD werken: Elke applicatie zijn eigen resources. Geen gedoe met registries, dll's en andere rotzooi waar je altijd mee blijft zitten na een de-installatie. En ook geen vertraging van het systeem of het besmetten (virussen) van andere applicaties die van dezelfde library gebruik maken.
Een OS dient een OS te zijn, niet meer en niet minder. Alle extra features mogen op geen enkele wijze invloed uitoefenen op het OS of omliggen applicaties.
Volgens deze reactie niet (met quote van MSDN erbij). De PATH omgeving variabele wordt pas als laatste doorlopen op moderne systemen.
Wat mijn altijd even 'vriendelijke' collega reaguurder waarschijnlijk bedoelt, is dat een groot deel van die folder schijnt te bestaan uit hard links. Dus het systeem rapporteert wel dat de folder enorm is, maar het voor een belangrijk deel ruimte die elders ook al gebruikt wordt. Windows telt de ruimte van de hard links wel alsof het echte ruimte is, maar dat schijnt het niet te zijn.
Zie hier voor meer info.
Hoe blokkeer ik de 2 tcp poorten en hoe schakel ik webdav uit?
grootste probleem vroeguh was dat als je vergat een path setting te zetten, dat of het verkeerde programma of de verkeerde dll's gebruikt werden.
Dat probleem schijnt nu nog steeds aanwezig te zijn.
Path commando onder XP laat nog steeds de volgorde zien waarlangs gezocht wordt naar programma's.
Set path is dus al voldoende om jouw bat'je, exe of com file in de root te laten prefereren. Aan de ene kant slordig van MS, maar aan de andere kant kunnen de heren/dames ontwikkelaars natuurlijk het nodige afdwingen met 'eigen' ini files
Heb ook weer eens, sinds jaren het set commando eens gebruikt. Wist niet eens dat dat nog bestond :-)
Met SafeDllSearchMode lijkt het daar inderdaad op.
Het qualified laden van dll's is dan ook niet het grote probleem.
Het probleem is dat iemand je probeert te verleiden een (bijvoorbeeld) mp3 te starten vanaf een shared folder waar ook een geprepareerde dll staat. En dat de applicatie, die de mp3 dan afspeelt, dom genoeg is om de dll van die shared folder te laden.
Ik denk dat er maar heel weinig programma's zijn die dll's op de current directory nodig hebben, maar er zijn er wel een paar die het op die manier doen klaarblijkelijk.
Ik las dat iTunes voor Windows er last van heeft (of had).
Ik bedoelde ook meer dat het logischer is om dll's niet te zoeken in de current directory. het kwam alleen wat rot uit mijn toetsenbord. :)
Mozilla Firefox heeft eigen dll's in de root van het programma en de plugins hebben eigen dll's in de plugin directory.
Er zijn zat programma's die eigen dll's gebruiken die ook nog eens in de directory van hun eigen executables staan. Pathsetting wordt dan vaak afgedwongen door eigen ini files.
Zo gemakkelijk is dat niet Rokye.
Ik gebruik een builder van een derde om mijn applicatie te bouwen (py2exe). De tool die ik gebruik is opensource, dus aan te passen, maar dat is veel te veel werk is. Dan moet ik in de C-code duiken en dat is niet de bedoeling.
Gelukkig lijkt het erop dat mijn applicatie sowieso geen last van dit DLL-lek heeft. Ik zet de huidige directory expliciet, in een snelkoppeling, dus dan moet het volgens mij goed gaan bij het opstarten van mijn applicatie.
Dit lijkt me toch een misfeature van Windows, Ik kan me weinig voorstellen van een applicatie die op je lokale systeem geinstalleerd is, maar die DLL's laadt van een netwerkschijf.
Bestaan er überhaupt applicaties die afhankelijk zijn van dit gedrag??
Blijkbaar wel, want anders had MS het wel gefixt, nu moeten ze het er waarschijnlijk inlaten vanwege backward-compatibility.
Wat is er mis met een library directory, laten we zeggen /lib.
Duidelijk toch.
Heb je als software maker toch een aangepaste dll nodig maak je een subdir aan in je lib, met de naam van het programma?
Dat SafeDllSearchMode kende ik nog niet. Als dat zijn werk doet, wordt de impact van dit probleem in elk geval een stuk kleiner. Bedankt voor de link.
Je leeft nog in het verleden
Daarnaast heb je nog onder de Windows directory WinSxS. Een waar onbeheersbaar oerwoud van DLL's in verschillende versies.
Komende uit jou mond? ;-)
Is al 7 jaar de default instelling van Windows.
Op zich is dat juist maar "Safe DLL search mode is enabled by default" sinds XP SP2 en het is moeilijk een systeem te vinden waar de volgorde dus niet zo is dat de current directory pas de vijfde is op volgerode lijst.
Dit is niet een louter slechte eigenschap voor programmeurs. Je zou ze de kost moeten geven die 'even' zelf een cryptografische of sorteer routine schrijven in plaats van een bestaande functie van een ander te gebruiken.
Prachtig als het gaat om de API van Windows en er gewerkt wordt binnen een managed omgeving met namespaces (ik neem aan dat dat 'gewoon' goed gaat, ik ben ook liever lui dan moe).
Wat nu als er een programma gemaakt wordt waar functionaliteit in een eigen library is ondergebracht? Geen enkel punt als die library geladen wordt met /installatiepad/naam.dll maar nu blijkt het voor te komen dat het installatiepad-gedeelte weggelaten wordt. Die luiheid breekt ze nu op maar tot voor kort waren er maar weinigen die het echt als een probleem zagen.
Als jij met de verkenner naar een remote webdav directory gaat en daar op een mp3 klikt dan ziet iTunes die remote directory als de current directory bij het opstarten van de applicatie.
Overigens is iTunes inmiddels gepatched om eigen dll's gewoon te laden met pad en dus vanaf een zelf bepaalde locatie ipv een door Windows bepaalde locatie.
Volgens Microsoft hebben jullie allebei een beetje gelijk.
Zie hier: Dynamic-Link Library Search Order
Overigens stond de link waarin deze link staat keurig aangegeven in het artikel (complimentje voor de auteur; meestal ontbreekt dit).
Voor iedereen die niet wil doorklikken, samenvattend:
If SafeDllSearchMode is enabled, the search order is as follows:
1.The directory from which the application loaded.
2.The system directory. Use the GetSystemDirectory function to get the path of this directory.
3.The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5.The current directory.
6.The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If SafeDllSearchMode is disabled, the search order is as follows:
1.The directory from which the application loaded.
2.The current directory.
3.The system directory. Use the GetSystemDirectory function to get the path of this directory.
4.The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6.The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
En weer alles te lang open laten staan, waardoor Blink me ruim voor was. Mijn link is wel een andere, omdat de SafeDLLSearchMode invloed heeft op de volgorde van het lijstje.
Correcter is dat de applicatie gewoon weet waar de benodigde libraries staan en deze daarvandaan inlaadt.
Je kunt eigen applicatiespecifieke dll's gewoon het beste uit de (sub)directories laden waarin de applicatie geinstalleerd is.
Het issue heeft geen betrekking op systeem libraries.
Nu voor eens en altijd 'dichttimmeren' en een compatibaliteits mode maken voor de oude applicaties waar je dat onder admin rechten even in moet stellen (desnoods met bevestiging: mag deze applicatie dll's laden uit deze en deze directory). Hoe moeilijk kan het zijn.
Verder. Als je windows gebruikt installeer dan ook een virusscanner dat kan elke schoonbroer je vertellen. En dat dll's vanaf 'overal' te laden zijn is ook alom bekend, net als een handvol 'dll injection' technieken die sommige (oude?) netwerk-monitoring applicaties en een aantal pre-XP virusscanners ook gebruikten, en sinds vandaag (en wsl al veel langer) dus ook wat malware.
Oude wijn in nieuwe flessen dus, behalve dat nu iemand heeft ontdekt dat het ook opgaat als je een mp3'tje of docje laadt van een (gecompromitteerde!) netwerkschijf.
Nee, het genoemde lijstje was correct.
http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx
Nee, dat kan dus niet. Je kunt dus niet system libraries overrulen omdat die eerder worden opgehaald maar alleen libraries die via het PATH worden opgehaald en dan ook nog alleen als de applicatie bij de load van de library alleen de naam maar niet de locatie van die library gespecificeerd heeft (met locatie zou natuurlijk sowieso de te prefereren manier zou moeten zijn om een library aan te roepen).
Een belangrijk nut van een dynamic link library is om algemene code voor meerdere programma's beschikbaar te hebben (scheelt ruimte en laadtijd). Het is dus juist NIET logisch om een dll in een van de (vele) programma-directories te plaatsen.
Het is juist logisch om een dll te plaatsen in een dir die zich binnen het PATH bevindt.
Eh, deze functie is zelfs nog veel ouder.
Het is namelijk een functie die afkomstig is van de UNIX variant waarvan MS-DOS is afgeleid.
Hedentendage zit dit ook nog steeds in *nix, als je maar goed zoekt....
Nou ja, dat werd toch steeds twijfelachtiger.
En dat is dus de oplossing voor dit "lek".
Het probleem is dat de meeste app builders liever lui dan moe zijn. Als ze zoals de SDK voor Windows omschrijft de correcte functie aanroepen binnen de API van windows, dan kan er nooit een DLL vanaf een externe site worden gedownload.
Het gaat dus om een bekend "probleem" dat zeer goed is gedocumenteerd en in diverse advisories bekend is gemaakt aan developers, het zijn echter de developers die in grote getalen in gebreken zijn gebleven om de correcte procedure te volgen voor het inladen van DLL's in hun applicaties.
Ongetwijffelt zijn er ook MS applicaties die dit probleem niet correct hebben aangepakt, maar vooralsnog is alleen bekend dat applicaties van derden misbruikt kunnen worden voor dit zogenaamde lek.
oftewel inloggen als root op *nix en intypen rm -rf /
Wel leuk bedacht met die smurfen ;)
Toch ben ik benieuwd of iemand een app kent die daadwerkelijk vanaf de 'current working directory' DLL's laadt en dat ook echt nodig heeft.
Hmmm, het kan uiteraard zijn dat .The directory from which the application loaded het remote path is, maar dan vraag ik me wel af wat 4. The current directory dan is.
Helaas ben ik te lui om het geheel te testen, maar het lijkt mij dat punt 1 de folder is waarin de .exe staat, en punt 4 de folder is waarin de iTune staat.
Mocht bovenstaande kloppen, dan kan je ook nog eens stap 4 helemaal skippen door gebruik te maken van de CWDIllegalInDllSearch instelling. Zie [Link] met meer info hierover.
Maar ik zal er wel naast zitten, want anders had MS bovenstaande wel al genoemd hebben als mogelijke oplossing/workaround :)
Daar heb je gelijk in.
Wat ik mij afvraag is of Windows dan ook niet kwetsbaar is voor een andere DOS flaw, namelijk de manier waarop DOS omging met programma files.
Dos had een vaste order als het ging om het opstarten van programma's op de schrijf, deze ging als volgt.
De gebruiker wil een programma uitvoeren, bijvoorbeeld dbase.exe, als de gebruiker de naam van het programma invoerde op de DOS prompt maar zonder existentie dan deed DOS het volgende;
Is er een programma genaamd dbase.bat?
Is er een programma genaamd dbase.com?
Is er een programma genaamd dbase.exe? ja, opstarten, Nee foutmelding geven - klaar.
Dit werd misbruikt door virusschrijvers die zogenaamde compagnon virussen schreven, deze virussen maakten van elke .exe file een .com of .bat versie aan.
Misschien doet Windows 7 ook zoiets, zet het equivalent van een com file in een directory ergens in het path en deze malware wordt eerder opgestart dan het legale programma?
Mijn excuus voor het geval mijn opmerking nergens op slaat, het is een tijdje geleden dat ik met dos gewerkt heb en mijn geheugen is niet meer wat het nooit geweest is. :-)
Misschien is het een kwestie van iets wat nooit helemaal goed doordacht is totdat het als een mogelijk probleem werd ervaren. Zie het verschijnen van SafeDllSearchMode en de default-waarden door de verschillende versies van Windows heen.
Ik kan me een situatie voorstellen waarbij het een feature is als je data kunt leveren die in het oorspronkelijke programma niet voorzien is.
Een mal voorbeeld:
Bedrijf A levert een programma om een dansend smurfje te tonen. De gebruiker klikt op grote.smurf en krijgt een dansende Grote Smurf.
Bedrijf B levert een set smurfen met bananenrokjes die niet getoond kunnen worden in het oorspronkelijke programma omdat dat geen bananenrokjes kent en daarom wordt er een aparte DLL bijgeleverd. Gebruiker klikt op bril_br.smurf en krijgt een dansende Bril Smurf met bananenrokje, getoond via het oorspronkelijke programma met behulp van de aparte DLL.
XD ...wel van schapen kaas dan zeker, want dat geblaat slaat vaak nergens op ;)
...en dat komt uit jouw mond? Beetje zelfreflectie zou bij jou geen kwaad kunnen.
Maar volgens mij raadt Microsoft zelf dat juist weer af. Want dat geeft ze niet de vrijheid om straks de "System32" map in bijv Windows 9 "Dll folder 32 bit" te noemen.
Zo moeten 32bit dll's in Windows7 64 volgens mij in SysWow64 staan of iets dergelijks. Met alleen gekwalificeerde paden, wordt dat een stuk bewerkelijker.
Dat kan best, vernieuwd is niet hetzelfde als veranderd. Altijd goed om (makkelijk de mist in te gaan met) een analogie met auto's erbij te halen: een compleet vernieuwde auto kan nog steeds met wielen en een stuur uitgerust zijn.
Met path praat je over het direct uitvoeren van executables. Hier gaat het om het pad dat wordt gevolgd om de DLLs te vinden die de betreffende executable nodig heeft (LIBPATH volgens Linus4ever in een reactie op het voorgaande bericht). Wat de logica erachter is weet ik niet maar het is niet helemaal te vergelijken: je mag hopen (en er een beetje op vertrouwen) dat het PATH voor executables zo staat dat je het programma krijgt dat je meent aan te roepen. Hier gaat het erom dat er een risico is dat een correct programma een malafide DLL laadt zonder dat je het weet.
Daar kan ik me ook wel in vinden. Maar als microsoft dat klakkeloos veranderd dan verwacht ik dat er nog wel een paar applicaties onderuit gaan. Dit pas je dus niet zomaar aan.
De vaste werkplekken zijn over het algemeen niet het allergrootste probleem, dat klopt. Als het om laptops gaat, dan is het andere koek. Gebruikers van laptops zijn per definitie op meerdere netwerken actief, ook netwerken waarover je als bedrijf geen controle hebt.
Webdav houdt in dat je bestanden over Internet ter beschikking stelt, dat is belangrijk voor organisaties waarbij mensen in het veld werken. Als je dit uit moet zetten dan is dat rechtstreeks van invloed op het functioneren van dit soort organisaties.
Dus we zetten de fileserver ook maar even uit?
Je hebt bij Microsoft XP een verschil tussen de Home edition en de Professional edition ( het verschil is twee bytes heb ik wel eens ergens gelezen, maar goed ). De professional edition is voor professioneel gebruik in kantoren, door met name de extra netwerk functionaliteit. De kunt dan inloggen in een domein ( daar heb je poorten 139 en 445 voor nodig ) en dan ook gebruik maken van zaken als Webdav.
In professionele omgevingen moet je kunnen werken met shares over een netwerk, intern of extern. Als je dat allemaal niet meer kunt, dan blijft er van professioneel gebruik niets meer over.
Dus mijn vraag is:
Hoe bruikbaar is Microsoft Windows nu nog in professionele omgevingen?
Mijn stelling is:
Microsoft Windows is mede om bovenstaande redenen niet geschikt voor toepassing in professionele omgevingen. Vraag maar na bij de Londom Stock Exchange en nog een paar andere clubs.
Volgens mij moeten jouw punten 5 en 6 op een andere plaats in de prioriteit staan.
Eerst gekwalificeerd, daarna in de huidige directory, vervolgens path en dan pas de default plaatsen.
door die volgorde is het huidige probleem ontstaan. Je kan een soort override geven op een dll, waardoor het naar de huidige map verwijst in plaats van naar de system32.
Het lijkt me eerlijk gezegd nogal vreemd dat applicaties de kwetsbaarheid als feature gebruiken, dat applicaties dus expres DLL's laden vanaf de locatie vanaf waar de applicatie gestart is.
Correcter en logischer lijkt me om DLL's te zoeken in de directory waar de executable zelf geïnstalleerd is, naast de systeemdirectories natuurlijk. Wat mij betreft gewoon een stomme design flaw in Windows zelf.
Als ik het goed begrijp dan begrijp jij het niet goed (ed.: en vice versa natuurlijk ;) ).
...
2. In most cases, the user must first browse to the directory, then double-click the specific file for this exploit to trigger. ...Uit het Rapid7 blog artikel van HD Moore
Maw. "The directory from which the application loaded" is wel de remote share.
Wil je het weten dan zou je met Metasploit blijkbaar nu een test hebben om te zien of/hoe het werkt.
(Eerder dacht ik dat dit ook misbruikt kan worden door met een shortcut een bestand te laden maar dat schijnt dus niet het geval te zijn)
En Microsoft maar vol blijven houden dat Windows echt helemaal vernieuwd is.
Het Path commando waarmee je programma's kon opstarten die niet in de actieve directory stonden komt voor zover ik weet uit DOS 3.0
Dat was een command die normaal in de autoexec.bat file stond.
@Set path=C:\;C:\DOS;C:\Windows
Speel es de bal en niet de man.
De bal = MS-Windows en security in 1 zin, gaat nog altijd niet goed samen. DUIDELIJK!?!
Hij houdt niet van gatenkaas.
Ben ook benieuwd hoe Microsoft dit gaat aanpakken. Het is namelijk geen lek maar een feature. Als ze daarin gaan wijzigen dan kan dit problemen veroorzaken voor veel applicaties. Overigens vind ik het met name fout van de programmeurs van die applicaties. Zorg gewoon dat je weet waar je spullen staan en laad ze daar vandaan in.
Ben een beetje verbaasd over de ophef want volgens mij is dit al tijden bekend. Heb ook nooit begrepen waarom Microsoft zoveel directories afzoekt naar de te laden DLL. Hieronder de zoekvolgorde die gebruikt wordt:
1. Als een directory is opgegeven wordt die gebruikt.
2. De System directory (32 of 64 bits).
3. De 16-bits system directory.
4. De Windows directory.
5. De huidige directory.
6. Alle directories in de PATH environment variabele.
Persoonlijk zou ik 1, 2 en 4 genoeg vinden (en wellicht 3 maar wie draait er nou nog 16-bits software).
Ik begrijp de flaw niet helemaal denk ik.
This vulnerability is triggered when a vulnerable file type is opened from within a directory controlled by the attacker.
en een voorbeeld
In practice, this flaw can be exploited by sending the target user a link to a network share containing a file they perceive as safe. iTunes, which was affected by this flaw until last week, is associated with a number of media file types, and each of these would result in a specific DLL being loaded from the same directory as the opened file.
Het gaat mij voornamelijk over het stukje each of these would result in a specific DLL being loaded from the same directory as the opened file
Dus je dient de malafide DLL in dit voorbeeld op remote share te zetten. Dubbelklik op de file, en de DLL die daar staat wordt geladen.
Maar hoe zit het dan met de SafeDllSearchMode instelling?
Deze instelling staat op WinXP SP2 en hoger default enabled en zorgt ervoor dat DLL's als volgt geladen worden:
1.The directory from which the application loaded (dus niet de remote share, maar de lokatie van de applicatie (e.g. iTunes))
2.The system directory. Use the GetSystemDirectory function to get the path of this directory.
3.The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5.The current directory.
6.The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
Dan wordt de malafide DLL toch pas geladen als deze niet op de eerste 4 plaatsen staat?
Lees: als de fabrikant niet zelf de DLL geschreven heeft (en in dezelfde folder heeft staan als de applicatie zelf) en ook niet in de bekende Windows folders staat (win en sys)?
Mocht ik het goed begrijpen, moet er aan erg veel voorwaarden voldaan worden, om misbruik te kunnen maken van dit design issue.
Je praat wel tegen Linus4ever. Die heeft toch al keer op keer bewezen geen kaas te hebben gegeten van Windows netwerken. ;)
Dat wordt een hete na-zomer :)
Waarom denk je dat? In een goed beveiligd bedrijfsnetwerk is dit risico prima te beheersen lijkt me.
Sterker nog dan het stack probleem in Linux is dit een design beslissing. Het zal me dan ook erg benieuwen hoe Microsoft dit denkt te gaan 'dichten'.
Ik kan me tenminste herinneren dat ik dll's in een map had staan omdat er door een versieverschil problemen optraden met de versies in System. Dat dezelfde dll op 2 plaatsen staat hoeft dus zeker niet fout te zijn.
Toch heel erg netjes en responsible gehandeld door deze Taeho Kwon.
Ehhhh, wat bedoelt Microsoft nu eigenlijk precies met "Responsible Disclosure"?
Hier zakt mijn broek dus vanaf.
Dit lek is zo kritisch dat het Microsoft Windows platform in principe onbruikbaar is in professionele omgevingen. Wat een arrogantie om te denken dat ze hier puur door hun omvang mee weg kunnen komen.
Microsoft komt dus kennelijk pas in beweging als het echt niet anders kan en de lekken op straat komen te liggen en om dan vervolgens te gaan lopen rellen, gillen en janken over die criminelen die de belangen van de klanten beschadigen.
Dus Microsoft strijkt wel de centjes op, maar toont zich voor de belangen van de klanten buitengewoon onverantwoordelijk.
Wee Microsoft!
Reageer
Preview