Gepubliceerd: Maandag 21 september 2009
Een gat in SMB2 blijkt ernstig genoeg dat Microsoft adviseert om dat Windows-component uit te schakelen. Het is een noodmaatregel tot het bedrijf een patch af heeft.
Toon volledig artikel
Als je vanuit de IE browser een dergelijk onderdeel aan/uit kan zetten, maak ik me ook zorgen wat nog meer met IE browser mogelijk is.
Oorspronkelijk kon misbruik van dit lek alleen de betreffende computer laten vastlopen; een zogeheten BSOD (Blue Screen Of Death) opleveren. Nader onderzoek wees uit dat creatiever gebruik van het lek een hack mogelijk maakt om een systeem op afstand geheel over te nemen.
Twee dingen.
Ten eerste is het niet zo dat het 'oorspronkelijk' niet mogelijk was met dit lek de computer over te nemen, dat was natuurlijk altijd al mogelijk alleen kwam Microsoft er zogenaamd pas na 'nader onderzoek' achter.
Ten tweede. Als het via een bufferflow mogelijk is de computer van afstand te crashen is het in theorie ook mogelijk de computer van afstand over te nemen, al vergt dat natuurlijk (veel) meer tijd en (veel) meer kennis van zaken. Op hem moment dat iemand beweert dat het via een lek mogelijk is een BSOD te kunnen creëren en tegelijkertijd beweert dat het onmogelijk is via dit lek de computer over te nemen, dan is het standaard zaak om dit soort uitspraken met een korreltje zout te nemen (zeker als men dit soort uitspraken doet zonder technische onderbouwing).
Ten tweede. Als het via een bufferflow mogelijk is de computer van afstand te crashen is het in theorie ook mogelijk de computer van afstand over te nemen, al vergt dat natuurlijk (veel) meer tijd en (veel) meer kennis van zaken.
Dat is zeker lang niet altijd het geval.
Om code te kunnen uitvoeren moet de buffer overflow het mogelijk maken om te schrijven naar geheugen waar code wordt uitgevoerd. Dit is niet bij iedere buffer overflow zo. De buffer overflow kan ook in geheugengebied zitten waar alleen maar data staat. In dat geval kan misbruik van de buffer overflow nog steeds een crash veroorzaken vanwege onverwachte data (bijvoorbeeld delen door 0, NULL pointer, etc).
Buffers bevinden zich altijd in een 'datagebied' in het geheugen. Wat denk je dat een buffer is? Volgens jou redenatie zouden buffer overflows überhaupt niet mogelijk zijn. Dat is natuurlijk onzin. Ofwel je nopt je richting een plek waar de processor vroeg of laat een keer naar toe jmpt, ofwel je fopt de processor in een jmp naar een plek waar hij normaal gesproken niet zou komen.
Sterker nog, de specifieke pointer dereference waar we het hier over hebben zou volgens jouw theorie niet mogelijk zijn. Misschien moet je Microsoft even bellen dat ze in de war zijn?
Wat ik wil zeggen is dat als je de boel kunt crashen dat je waarschijnlijk ook controle over de computer kunt krijgen. Ik zeg niet dat dit dan perse zo super simpel zal zijn als een crash. In ieder geval, op het moment dat Microsoft aangeeft dat er wel een crash maar geen remote code execution mogelijk is (zonder steekhoudende onderbouwing ook nog) zou ik dat met een korreltje zout nemen.
Buffers bevinden zich altijd in een 'datagebied' in het geheugen.
Dat klopt. Een bufer overflow probeert alleen een datagebied te vullen dat groter is dan het datagebied, waardoor dat buffer terecht komt in het code-gebied. Daarna moet je er voor zorgen dat dat overschreven code-gebied wordt uitgevoerd voordat de software er achter komt dat ze corrupt is geraakt.
Ik denk dat Emilt dat bedoelt. Door een buffer overflow kan het gebeuren dat je andere delen van het datagebied beschadigd. Als daar iets mee gedaan wordt voor je corrupte code wordt uitgevoerd dan kan je al een BSOD krijgen voor je exploit wordt uitgevoerd.
Ik ben met je eens dat het theoretisch kan om een pc over te nemen, maar in de praktijk zijn er situaties waar de kansen op een daadwerkelijke exploit oneindig klein lijken te worden.
Dat klopt. Een bufer overflow probeert alleen een datagebied te vullen dat groter is dan het datagebied, waardoor dat buffer terecht komt in het code-gebied. Daarna moet je er voor zorgen dat dat overschreven code-gebied wordt uitgevoerd voordat de software er achter komt dat ze corrupt is geraakt.
Wel dat is _een_ manier, maar lang niet de enigste. In dit simpele geval zou je trouwens ook vaak een jmp uitvoeren naar je initiële buffer voor de shellcode.
Ik denk dat Emilt dat bedoelt. Door een buffer overflow kan het gebeuren dat je andere delen van het datagebied beschadigd. Als daar iets mee gedaan wordt voor je corrupte code wordt uitgevoerd dan kan je al een BSOD krijgen voor je exploit wordt uitgevoerd.
Wel als je andere gebieden van het 'datagebied' kunt beschadigen op een dusdanige manier dat je een crash kunt creëren, dan zou ik er voor het gemak maar eventjes vanuit gaan dat het in theorie ook mogelijk is shellcode te injecteren. Let hier ook op dat het gaat om een BSOD, dus niet een crash van een applicatie maar een crash van het systeem als geheel.
Ik ben met je eens dat het theoretisch kan, maar in de praktijk zijn er situaties waar de kansen op een daadwerkelijke exploit oneindig klein lijken te worden.
Natuurlijk. Er zijn hacks die in theorie mogelijk zijn, maar praktisch gezien een brug te ver. De vraag is waar de grens ligt.
Wel dat is _een_ manier, maar lang niet de enige.
Hmm, misschien ligt dat dan aan mij. Het is de enige manier die ik mij kan voorstellen om, via het vullen van een datagebied, uitvoerbare code te bereiken. Maar ik beken, ik ben geen volleerd hacker op dit gebied.
Maar aangezien we het in grote lijnen verder wel eens zijn zal ik er verder geen halszaak van maken. :)
Is er uberhaupt iemand in deze thread aan het posten die weet waarover hij praat? ;-)
Code segmenten zijn readonly en dus niet beschrijfbaar. Wat een buffer overflow probeert te bereiken is de stack om zeep helpen.
Is de stack om zeep, dan zal de applicatie crashen, of als dit in een driver gebeurt, het OS zelf.
Het idee is om de stack op een gedefinieerde manier om zeep te helpen zodat bij het verlaten van de functie een door de attacker gespecificeerde functie aangeroepen wordt op het systeem.
Code segmenten zijn readonly en dus niet beschrijfbaar.
Hoe kom je daar in hemelsnaam bij? In het geheugen van je computer bestaat 'read only' alleen bij de gratie van het fatsoen van de programmeur.
En voor mij is de stack trouwens een onderdeel van de code en de heap een onderdeel van de data. Of dat technisch correct is weet ik niet.
Het gaat er bij een buffer overflow niet alleen om dat je de stack om zeep helpt, maar ook dat je een returnwaarde van een subroutine (of exception handler) op de stack kan overschrijven. Die returnwaarden onthouden namelijk waar de code was gebleven, op het moment dat een subroutine werd aangeroepen. Door het overschrijven van deze returnwaarde, heb je controle over de instruction pointer (EIP), op het moment dat de subroutine een return (RET) tegenkomt, en kun je eigen shellcode uitvoeren. Die shellcode was al binnen geloodst toen je allerlei rommel op die buffer op de stack zette.
Trouwens: sommige gebieden zijn wel degelijk aan te wijzen als Read only. Het code gebied is over het algemeen ook gewoon standaard read only, tenzij de programmeur iets wil gaan doen met code, die zichzelf aanpast. Denk aan trucjes die executable packers uithalen.
En voor mij is de stack trouwens een onderdeel van de code en de heap een onderdeel van de data. Of dat technisch correct is weet ik niet.
Zowel stack als heap bevatten data. Zowel buffers op de stack als op de heap zijn exploitable. 6851 beschrijft de simpelste vorm van een stack-based aanval, al schrijft hij het wel verschrikkelijk onduidelijk op. Daar moet ik gelijk bij zeggen dat ik in mijn voorgaande posts ook niet bepaald in topvorm was qua duidelijkheid.
Er zijn inderdaad apparaten waar code in ROM zit, maar ook deze code wordt bij het opstarten naar het snellere RAM gepompt.
Writing buffer overflow exploits - a tutorial for beginners ;-)
Waar ik op doelde is dat het vaak erg moeilijk en in sommige gevallen onmogelijk om buffer overflows in de heap of het static data segment te misbruiken. Het gros van de exploits vind plaats via stack smashing. Dit zijn over het algemeen de makkelijkste exploits.
Het kunnen laten crashen van een applicatie zegt echt nog niks over of je ook code kan uitvoeren. Het kan zijn dat je een buffer met megabytes aan geprepareerde data moet vullen voordat je de gewenste code overschrijft of een collision met de stack krijgt. Die megabytes aan data moet je wel in die buffer kunnen krijgen. De kans is erg groot dat je daarmee andere "schade" aanbrengt wat de exploit lastiger kan maken.
Waar ik op doelde is dat het vaak erg moeilijk en in sommige gevallen onmogelijk om buffer overflows in de heap of het static data segment te misbruiken. Het gros van de exploits vind plaats via stack smashing. Dit zijn over het algemeen de makkelijkste exploits.
Ik betwijfel of het gros van de exploits tegenwoordig plaats vindt via stack smashes. Maar ze zijn inderdaad meestal wel het eenvoudigst. Waarbij eenvoudig een relatief begrip is.
Het kunnen laten crashen van een applicatie zegt echt nog niks over of je ook code kan uitvoeren.
Sorry, is het je opgevallen dat er hier geen applicatie crasht maar de kernel?
Op hem moment dat iemand beweert dat het via een lek mogelijk is een BSOD te kunnen creëren en tegelijkertijd beweert dat het onmogelijk is via dit lek de computer over te nemen, dan is het standaard zaak om dit soort uitspraken met een korreltje zout te nemen
Het ergste hieraan vind ik dat de uitspraken van Microsoft ook niet meer te vertrouwen zijn. Je kunt er niet meer van op aan dat ze de waarheid vertellen als er een serieus probleem met hun software is.
De kwetsbaarheid zit in Windows Vista, Windows Server 2008 en in proefversies van Windows 7.
Het zat toch ook in XP en Windows 2000?
Het ergste is natuurlijk de kwetsbaarheid van Windows 2008 server. Je zult toch maar een IT manager zijn en een Microsoft strategie hebben omarmd, dan zit je nu in het nachtmerrie scenario. Heb je een beetje flink bedrijf met ook nog vpn toegang tot de servers, dan slaap je voorlopig geen nacht meer rustig.
Misschien moet je het volgende dan maar eens overwegen voor Server Message Block: SaMBa.
Samba is goedkoop, open, rocksolid en veilig. Het is ook nog eens twee tot drie keer zo snel als Windows 2003 en Windows 2008. Waar het bij Windows gewoon ophoudt bij zo'n 30 gebruikers, kan een samba bak met gemak een dikke 100 gebruikers aan.
Wij hebben net een succesvolle Windows 2003 -> Samba migratie uitgevoerd. Ik was verbijsterd over de ellende waar deze mensen vandaan kwamen.
Het zat toch ook in XP en Windows 2000?
Voor zover mij en Wikipedia bekend is, werd SMB2 pas in Vista geïntroduceerd. De fout in SMB2 zal dus logischerwijs geen impact kunnen hebben voor Windows XP en Windows 2000.
Het ergste is natuurlijk de kwetsbaarheid van Windows 2008 server.
Klopt, maar gelukkig hoef je SMB niet in zijn geheel uit te zetten. Je moet alleen terug vallen naar versie één van het protocol.
Het is zeker een vervelende fout, maar je moet het ook weer niet buiten proportie opblazen.
gelukkig hoef je SMB niet in zijn geheel uit te zetten. Je moet alleen terug vallen naar versie één van het protocol.
Dan kom ik toch weer terug op het eerdere bericht van een tcp/ip lek waarvoor je poortjes 139 en 445 (SMB) moest dichtzetten. Dat ging erover dat Microsoft dit lek niet meer gaat patchen voor XP en 2000 omdat het te moeilijk is. Het hele ontwerp schijnt daarvoor op de schop te moeten.
Als je SMB2 uitzet, dan ben blijf je toch kwetsbaar voor dat andere lek. Het was voor Vista niet en voor een volgende release van Windows 7 wel gepatched.
Ik denk dat dit voor de meeste geheerders allemaal vreselijk ingewikkeld is. Je moet namelijk niet vergeten dat er met Windows ook nog zoiets is als de harde werkelijkheid. Op elke Windows heb je zo'n fijne registry en ga dan maar eens iets veranderen. Je krijgt sommige instellingen gewoon niet gewijzigd, dus zo maar wisselen is er in de praktijk niet bij.
Dan kom ik toch weer terug op het eerdere bericht van een tcp/ip lek waarvoor je poortjes 139 en 445 (SMB) moest dichtzetten.
dat zijn er een paar waar ook andere os'en mogelijk ook last van hebben. Die hele materie is nog behoorlijk ondoorzichtig, maar ik heb het gevoel dat die problematiek nog wel een poosje blijft rondzingen.
Edit: Het probleem is in Windows ook na patchen niet opgelost. Het os is alleen beter bestand tegen de aanvallen. Het is dus geen oplossing maar een lapmiddel tot er een betere oplossing gevonden wordt. En voor je daar op door gaat... Volgens mij heeft Red Hat nog helemaal geen oplossing, anders dan het aantal connecties tegelijk te beperken.
Je krijgt sommige instellingen gewoon niet gewijzigd, dus zo maar wisselen is er in de praktijk niet bij.
Als je het artikel met enige aandacht had gelezen dan was je er achter gekomen dat Microsoft daar al hulpmiddelen voor aanbiedt. Dus zomaar wisselen is er in dit geval wel bij.
Dus zomaar wisselen is er in dit geval wel bij.
Als je maar een machientje hebt, dan zal dat allicht lukken.
Ik weet niet of jij wel eens rondgelopen hebt in een grotere server omgeving met meer dan 100 van die Windows servers, maar in dat soort toko's liggen de kaarten echt anders.
Op een Windows machine loop je snel tegen conflicten aan. Bijvoorbeeld: je moet een patch installeren, alleen als je dat doet dat werken de applicaties niet meer. Al die dingen in combinatie met de voortdurende security issues maken het leven in zo'n omgeving met budgettten en licentie kwesties tot een hel.
Het oplossen van zo'n SMB2 issue sluit gewoon aan achter in de rij, er zijn doorgaans nog tientallen andere dringende issues op te lossen. Het probleem is technisch misschien oplosbaar, maar in de weerbarstige praktijk is het razend moeilijk.
Natuurlijk... je hebt gelijk. Bedrijven hebben elke maand geen idee hoe ze hun patches moeten uitrollen. Echt een dolle boel. =P
Als een bedrijf dit aanmerkt als een daadwerkelijk probleem dan zien ze echt wel mogelijkheden om SMB2 uit te schakelen. Je kan wel doen alsof Windows netwerken onbeheersbaar zijn, maar dat is natuurlijk onzin.
En ja ik weet dat prioriteiten kunnen schuiven. Dus als ze het uitschakelen van SMB2 uitstellen, dan is dit lek klaarblijkelijk geen dringend probleem, anders krijgt het wel prioriteit.
Je kan wel doen alsof Windows netwerken onbeheersbaar zijn, maar dat is natuurlijk onzin.
Ik vind windows netwerken om verschillende redenen ook onbeheersbaar.
Ik heb het jaren geprobeerd (ook met ervaren MCSE´s), maar ik ben er klaar mee. Thuis op de desktop is het nog wel enigszins te behappen als je alles dicht zet. Maar in een professionele omgeving; nee
Policy settings die zo maar veranderen, licentie databases die corrupt raken waardoor niemand meer kan inloggen, windows virussen die er tussen door glippen met up2date antivirus shield en ook nog eens je UNIX netwerk platleggen, servers die niet meer opkomen na een patch, windows applicaties die op eens niet meer werken terwijl gebruikers alleen read/execute rechten hebben. Ik zei het al, ik ben er klaar mee, voor mij nooit meer windows. Exit, Af, Adieu
Je verwoordt het uitstekend.
Dit is precies de weerbarstige werkelijkheid die ik bedoel, al die onvoorspelbare echt gekke dingen die je in zo'n omgeving tegenkomt. De zaak raakt corrupt en je kunt maar een ding doen: poetsen.
Of:
Je bijt een keer door de zure appel heen en je gaat breed over op Linux met een terminal server oplossing voor een paar onmislbare Windows applicaties.
Policy settings die zo maar veranderen, licentie databases die corrupt raken waardoor niemand meer kan inloggen, windows virussen die er tussen door glippen met up2date antivirus shield en ook nog eens je UNIX netwerk platleggen,
Ik ken vrij veel grote netwerken en we hebben hier zelf een netwerk van ca 1000 stations waar geen van deze problemen ooit opgetreden is. Ik sluit niet uit da tje incidenten hebt maar je overdrijft aanzienlijk hier.
Dat je nox netwerk platgaat ligt nu ook al aan windows zie ik...zegt waarschijnlijk meer over het inzetbare kennisniveua van de beheerders zowel aan Win als aan Nix zijde.
We zitten een een hoog riscico omgeving en nog nooit is er een virus doorgekomen met normale contracten met Symantec ( SEP sinds een jaar)
Beheer is gemakkelijk, snel en zeer uitgebreid. De mogleijkhedne die AD kan bieden in combinatie met de werkstations zijn zeer gelaagd en zeer breed en zonder enige probleem.
Policys die niet doorkomen hebben meestal met netwerk problematiek te maken of nog vaker, met onvoldoende kennis van policys tijdens het opzetten. Men maakt dan conflicterende policys of begrijpt het doorerven niet goed.
Ik ken vrij veel grote netwerken en we hebben hier zelf een netwerk van ca 1000 stations waar geen van deze problemen ooit opgetreden is
Er zijn ook mensen die 90 jaar worden met dikke sigaren
Dat je nox netwerk platgaat ligt nu ook al aan windows zie ik...zegt waarschijnlijk meer over het inzetbare kennisniveua van de beheerders zowel aan Win als aan Nix zijde.
Ja hoor, dat ligt aan windows servers die geïnfecteerde pakketjes als ICMP-verkeer op het lan loslaten. Je wil niet weten hoe mooi de kerstboomverlichting was in de switch-kasten (elk ledje was steady). Oplossing was een extra firewall tussen het Windows en Linux netwerk.
Oorzaak was een geinfecteerde laptop van de baas, geinstalleerd door een externe omdat zijn eigen IT groep volgens hem er niks mee te maken had.
We zitten een een hoog riscico omgeving en nog nooit is er een virus doorgekomen met normale contracten met Symantec ( SEP sinds een jaar)
Dan heb je geluk gehad, want een anti-virus omgeving is zo goed als de zwakste schakel is. Ik heb nog nooit mee gemaakt dat alles up2date was of conform update policy. Vooral bij XP werkstations is er altijd wel wat. Antivirus software zit namelijk ook vol met bugs.
Laptops die lang buiten zijn geweest, zijn ook vaak niet up2date, omdat het updaten niet is gelukt (gaat ook een beetje langzaam met een gprs verbinding). Geinfecteerde memorysticks van thuis, Infectie via URL´s etc. M.a.w. het kost heel veel beheer om alles up2date te hebben, dan nog zijn er ook nog misconfiguraties (daar heb je een beetje gelijk in, je hebt een universitaire opleiding nodig voor een juiste configuratie. MSCE is niet genoeg. )
Beheer is gemakkelijk, snel en zeer uitgebreid. De mogleijkhedne die AD kan bieden in combinatie met de werkstations zijn zeer gelaagd en zeer breed en zonder enige probleem.
Behalve als ze corrupt raken en ook niet meer repliceren. Laat het woord gemakkelijk ook maar weg. Slecht overzicht en veel te veel clicks nodig. Waren het maar platte files dan kan je het met notepad veranderen. Al eens een AD gerestored?
Policys die niet doorkomen hebben meestal met netwerk problematiek te maken of nog vaker, met onvoldoende kennis van policys tijdens het opzetten. Men maakt dan conflicterende policys of begrijpt het doorerven niet goed.
Ja dom he. Als een policy niet doorkomt omdat een windows server effe niet snel genoeg reageert, krijgt de gebruiker ook opeens een lokaal profiel op de server en geen policy. Met de kennis zit het wel snor hoor. Als het eenmaal is bijgesteld werkt het juist. Probleem is alleen het blijft niet werken. Het verandert terwijl je er alleen maar naar kijk! M.a.w. geen applicatie updates, geen windows updates, alleen mogelijk een antivirus update. Daar hebben we onder linux geen last van. Zou dat dan de reden moeten zijn waarom het onder Linux wel stabiel blijft? of is Windows gewoon niet geschikt als multi-user systeem?
Corruptie van Licentie databases heb je niet genoemd. Gelukkig hebben we onder Linux hier ook geen last van, want die zijn er niet!
"We zitten een een hoog riscico omgeving en nog nooit is er een virus doorgekomen met normale contracten met Symantec ( SEP sinds een jaar)"
Dan heb je geluk gehad
Als er _wel_ een virus was doorgekomen zonder dat de virusscanner alarm had geslagen hoe hadden ze had dan uberhaupt geweten?
Ik begrijp jouw vraag niet, maar ik zag het aan het ongewone gedrag (kerstboomverlichting) van de ledjes in de switch rack
Ok, voor ieder virus dat er niet doorkomt slaat de virusscanner alarm. Maar hoe kun je op basis daarvan zeker weten dat er geen enkel virus is doorgekomen? Immers, voor een virus dat er _wel_ is doorgekomen zal de virusscanner _geen_ alarm slaan.
Met andere woorden, hoe kun je weten hoeveel virussen je niet ontdekt hebt? Onder Windows kun je dat niet weten.
voor een virus dat er _wel_ is doorgekomen zal de virusscanner _geen_ alarm slaan.
aha, weer Nola nonsens.. zie ik..
Je hebt duidelijk geen kaas gegeten van de huidige generatie scanners en beveiligingslagen.
Stel even dat een virus door de scanner komt in eerste instantie. dan zal het vrijwel zeker zo zijn dat bij activiteit het virus op basis van gedragskenmerken alsnog wordt gedetecteerd.
Je bent in de war met Apple bijv, waar gebruikers roepen dat er geen besmettingen zijn terwijl ze dat niet kunnen weten aangezien ze volkomen onbeveiligd zijn.
Nola nonsens derhalve weer.. en weer... en weer..
awkward ;)
aha, weer Nola nonsens.. zie ik..
Je hebt duidelijk geen kaas gegeten van de huidige generatie scanners en beveiligingslagen.
Stel even dat een virus door de scanner komt in eerste instantie. dan zal het vrijwel zeker zo zijn dat bij activiteit het virus op basis van gedragskenmerken alsnog wordt gedetecteerd.
Je bent in de war met Apple bijv, waar gebruikers roepen dat er geen besmettingen zijn terwijl ze dat niet kunnen weten aangezien ze volkomen onbeveiligd zijn.
Nola nonsens derhalve weer.. en weer... en weer..
awkward ;)
Apart. Laten deze 'argumentatie' eens splitsen in beledigingen en de rest. Dit zijn de beledigingen:
aha, weer Nola nonsens.. zie ik..
Je hebt duidelijk geen kaas gegeten van de huidige generatie scanners en beveiligingslagen.
Je bent in de war met Apple bijv, waar gebruikers roepen dat er geen besmettingen zijn terwijl ze dat niet kunnen weten aangezien ze volkomen onbeveiligd zijn.
Nola nonsens derhalve weer.. en weer... en weer..
awkward ;)
En dan is dit de rest van je reactie:
Stel even dat een virus door de scanner komt in eerste instantie. dan zal het vrijwel zeker zo zijn dat bij activiteit het virus op basis van gedragskenmerken alsnog wordt gedetecteerd.
Ja volgens jou is dat 'vrijwel zeker'. Zo 'vrijwel zeker' zelfs dat je het blijkbaar niet nodig vind dat verder te onderbouwen. Maar dat is helemaal niet 'vrijwel zeker', dat is nu juist het punt.
Jij claimt op basis van de virussen die je _wel_ hebt gevonden dat er geen virussen zijn die je _niet_ hebt gevonden. Dat is anti-logica.
Jij hebt geen enkele wetenschap van de virussen die _niet_ hebt gevonden en kunt op geen enkele wijze onderbouwen dat ze niet bestaan. De 'onderbouwing' die je geeft is dat je zegt dat het 'vrijwel zeker' is, maar dat is helemaal geen onderbouwing. Dat is een redenatie van het niveau 'het is zo omdat het zo is'.
Vergelijk dit nu eens met dit:
Stel even dat een virus door de scanner komt in eerste instantie. dan zal het vrijwel zeker zo zijn dat bij activiteit het virus op basis van gedragskenmerken alsnog wordt gedetecteerd.
Geen enkel logisch verband tussen jouw reactie en hetgeen wat je suggereert te 'weerleggen'. Geen enkel.
Nola nonsens derhalve weer.. en weer... en weer..
klik klik klik klik klik klik klik klik klik
Met windows weet je nooit zeker of je beschermt bent. Het is ook logisch dat het voor de nieuwste virussen (die natuurlijk geen voorspelbaar gedrag vertonen) eerst een tijdje duurt voordat er een vaccin beschikbaar is. Je loopt dus altijd achter de feiten aan.
Sommige windows servers hebben geen on access scanning aanstaan, anders wordt exchange b.v. veel te traag of crasht gewoon, maar wel een ge-schedulede scan en dat is natuurlijk veel te laat, want dan heeft het virus zich al genesteld en kan het weer niet geremoved of in quarantaine geplaatst worden. Kortom hopeloze situatie.
Met windows weet je nooit zeker of je beschermt bent.
Dat is precies wat ik bedoel. Op Windows is er geen manier om met volledige zekerheid te kunnen achterhalen of een machine schoon is. Scanners vinden alleen de virussen die ze kunnen vinden. Virussen die te nieuw, te klein of te specialistisch zijn om in de virus database opgenomen te zijn/worden kunnen niet door een scanner gedecteerd worden. Het draaien van een scanner op Windows is zeker nuttig, maar het geeft zeker geen zekerheid dat je volledig virus vrij bent.
@Vinylat45:
Nu overdrijf je toch echt. Het gaat hier gewoon om een Windows Installer Package die je kan downloaden en uitvoeren.
Het oplossen met 1 klik lijkt me dan ook niet helemaal realistisch. Je moet sowieso je download bevestigen. Evt daarna het uitvoeren ook. Je krijgt op Vista (en hoger) UAC meldingen en wellicht ook nog eens dialogen in het programma zelf.
Het doet me wat dat betreft denken aan het 1-Click Install verhaal van OpenSUSE. Daar krijg je toch echt nog autorisatie- en bevestigingsschermen voor de kiezen. :)
* Edit: Verkeerde reactieknop gebruikt denk ik.
Welk effect heeft dit op windows machines die achter een linux-server zitten met Samba? Is het hierdoor niet meer mogelijk om window's machines in een samba netwerk te hangen?
En toch lees ik dat als propaganda voor de nieuwe Windows 7. 'Deze heeft het niet' Normaal worden dit soort lekken stilletjes weggewerkt. Maar nu juist volledige artikelen aan toegewijd.
En toch lees ik dat als propaganda voor de nieuwe Windows 7. 'Deze heeft het niet'
Die had het natuurlijk ook. Alleen weet Microsoft natuurlijk al langer van dit probleem en hebben ze het daar alvast stilletjes kunnen repareren omdat het toch nog niet in de winkel lag.
dus als je een beta gaat repareren dan is dat stilletjes en stiekum?
Misschien dat iemand je uit kan leggen hoe een betatest proces werkt, in jouw eigen jip en janneke stijl dan natuurlijk ;)
Je hoeft niet aan de boom te hangen, om ...
Je niveau wordt met de dag lager. Vroeger deed je in elk geval nog net alsof je argumenteerde.
beste mensen na enig bellen heb ik een email adres voor mensen die ook die patch willen voor windows xp microsoft is inderdaad verplicht om te updaten tot 2012 iedereen stuur een email hoe meer mensen hoe beter microsoft moet ook xp gaan repareren met deze fout hierbij de email adres van de consumentenbond alarmlijn@consumentenbond.nl die zullen de meldingen in behandeling nemen hoe meer hoe beter
Pff, jij hebt echt teveel tijd...
Dit gaat over SMB2. Het heeft dus helemaal niets te maken met Windows XP.
Of is dit een spambot? ;)
En waar kan ik een e-mail naartoe sturen om mensen die geen leestekens gebruiken van het web te weren?
Sorry hoor, maar je verhaal wordt er compleet onleesbaar van! Verder: dit artikel gaat inderdaad over SMB2. En heeft dus niets van doen met Windows XP. Laat de Consumentbond zich lekker bezig houden met zaken waar ze wel verstand van hebben.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
