Microsoft helpt bij het bugfixen van third party software

ms

Gepubliceerd: Vrijdag 8 augustus 2008
Auteur: Martin Gijzemijter

Het beveiligingsteam van Microsoft zal externe ontwikkelaars van programma's voor Windows helpen bij het opsporen en verhelpen van bugs.

Toon volledig artikel

Anonymous Coward op Vrijdag 8 Augustus 2008 14:30

image

Straks worden ze nog een distro...

Anonymous Coward op Vrijdag 8 Augustus 2008 15:48

image

Inderdaad, dat zou een behoorlijke sprong voorwaarts zijn. Maar ik gok dat Microsoft nooit zo ver gaat komen dat ze een packagemanager idee omarmen. Het zou wat zijn, Microsoft die patches voor Firefox en Opera uitrolt.

Anonymous Coward op Vrijdag 8 Augustus 2008 14:42

image

Lijkt mij dat het vooral Microsoft zelf is dat hulp nodig heeft.

Anonymous Coward op Vrijdag 8 Augustus 2008 15:45

image

Bij mij kwam ook als eerste dat spreekwoord met die balk en die splinter boven.

toiletpaper op Vrijdag 8 Augustus 2008 17:36

image

Het nieuws van alon is echter nieuw NIEUWS:


Windows Vista security 'rendered useless' by researchers
By Dennis Fisher 07 Aug 2008

citaat:
By taking advantage of the way that browsers, specifically Internet Explorer, handle active scripting and .NET objects, the pair have been able to load essentially whatever content they want into a location of their choice on a user's machine.

En zoals dat gaat met dit soort hot news, het vliegt de wereld rond
Resultaten 1 - 10 van circa 45.300 voor Windows Vista security 'rendered useless' by researchers (0,26 seconden)

toiletpaper op Vrijdag 8 Augustus 2008 17:36

image

www.google.nl/s...+by+researchers

ArjenB op Zondag 10 Augustus 2008 19:54

image

Resultaten 1 - 10 van circa 76.100 voor Windows Vista security 'rendered useless' by researchers De teller loopt...

ArjenB op Vrijdag 8 Augustus 2008 18:05

image

Wat een afgrijselijke manier om het weekeinde in te gaan.

Anonymous Coward op Vrijdag 8 Augustus 2008 18:29

image

Ja, rottig voor degenen die Vista omarmen, maar waarom verbaasd het me eigenlijk niet?

U4iA op Zaterdag 9 Augustus 2008 01:05

image

Nog rottiger wordt de volgende quote:

Dai Zovi stressed that the techniques Dowd and Sotirov use do not rely on specific vulnerabilities. As a result, he said, there may soon be similar techniques applied to other platforms or environments.

Denk je dus veilig te zitten met andere OS-en, dan heb je het dus kennelijk mis. Het gaat hier om een nieuwe techniek en die is niet Vista specifiek. Ben benieuwd naar het PoC. :)

U4iA op Zaterdag 9 Augustus 2008 01:07

image

Oops die stond er al... :)

toiletpaper op Zaterdag 9 Augustus 2008 01:11

image

en wordt vervolgens niet verklaard......
want tevens staat er (in contradictie) dat de fundamentele Vista architectuur de gelegenheid geeft.....

Anonymous Coward op Zondag 10 Augustus 2008 12:43

image

Dat zinnetje verbaasde mij ook zeer. De quote "take advantage of Vista's fundamental architecture and the ways in which Microsoft chose to protect it." strookt niet met deze uitspraak. Ik moet het nieuws maar eens wat beter in de gaten houden. Misschien werken Steve Jobs en Linus Torvalds toch stiekem voor Microsoft.

Anonymous Coward op Zondag 10 Augustus 2008 13:02

image

Inderdaad, ik had de link gemist. Bedankt.

SED. op Vrijdag 8 Augustus 2008 21:01

image

en volgens diverse reacties niet allen MS blijkbaar oa.

Dai Zovi stressed that the techniques Dowd and Sotirov use do not rely on specific vulnerabilities. As a result, he said, there may soon be similar techniques applied to other platforms or environments.

Ziet er uit als een potentieel wijdverbreide zwakheid die eerst diepgaand onderzocht moet worden voordat precies duidelijk is ""wat"" men nu precies doet.

toiletpaper op Vrijdag 8 Augustus 2008 21:57

image

Maar het is wel gek, omdat er toch ook in dit zelfe artikel duidelijke en link wordt gelegd tussen IE en de manier waarop deze vulnerabiltiy kan worden uitgebuit.

By taking advantage of the way that browsers, specifically Internet Explorer, handle active scripting and .NET objects, the pair have been able to load essentially whatever content they want into a location of their choice on a user's machine.

Ook een interessant citaat is:

The attacks themselves are not based on any new vulnerabilities in IE or Vista, but instead take advantage of Vista's fundamental architecture and the ways in which Microsoft chose to protect it.


Het kan zijn dat de vulnerability op meerdere platformen voorkomt, maar dan moeten er overeenkomsten zijn met de speciale Vista architectuur die zit mogelijk maakt, en er is een bepaalde applicatie (IE) nodig om hem te triggeren.
Het lijkt me heel goed om nadere details af te wachten voordat we tot vergaande uitspraken komen.

Wat ik vooral typisch vindt is hoe zo'n artikel binnen 2 dagen tot 45.000 hits op het Internet kan leiden. (Vreemd overigens dat het webwereld wel is ontgaan.)

In de wetenschap is het een graadmeter voor het belang van je ontdekkingen/theorieën. Hoe vaker je wordt geciteerd, hoe hoger de status van de plaats van het citaat, hoe belangrijker je bent.

Op Internet werkt het ook zo. Als een artikel dat je schrijft binnen twee dagen 45.000 keer wordt geciteerd, dan zegt dat nog al wat.

Helaas blijft het bij citeren. Een artikel dat uitlegt wat er precies aan de hand is, en waarom andere platformen, juist wel, of juist niet vulnerable zijn, dat is niet terug te vinden.

Het beste is afwachten totdat er een artikel verschijnt dat niet de bron nauwkeurig nakletst, maar waar de schrijver zelf ins taat is om te begrijpen wat er aan de hand is, en in staat is om ons uit te leggen wat er klopt van de bewering dat andere OSsen ook vatbaar zijn, en van de bewering dat de vulnerability niet of zeer moeilijk gerepareerd kan worden, en is Windows Server 2008 ook kwetsbaar, want het artikel noemt het wel, maar glibbert rondom een stellige uitspraak heen.

Daarnaast heb ik geen zin meer in een discussie zoals enkele dagen gelede waarin een NYT artikeltje tot op het bot moest worden ontleed. Dat vind ik niet zo verheffend, en daarbij, behoorlijk afleidende van het tot hoogst verontrustende nieuws.

toiletpaper op Vrijdag 8 Augustus 2008 21:58

image

Op dit moment is het gebeuren rondom deze vulnerability wel weer een extra aanwijzing dat Internet journalistiek toch wel een zaakje is van papegaaien, regelmatig zonder veel kennis van zaken.

toiletpaper op Vrijdag 8 Augustus 2008 22:21

image

Inmiddels de beschrijving gevonden door de twee ontdekkers

taossa.com/arch...tirovdowd.pdf

Bypassing Browser Memory Protections
Setting back browser security by 10 years
Alexander Sotirov <alex@sotirov.net>
Mark Dowd <markdowd@au1.ibm.com>

53 pagina's hightech.

happy reading (zondag regent het)

toiletpaper op Vrijdag 8 Augustus 2008 22:21

image

taossa.com/arch...sotirovdowd.pdf

toiletpaper op Vrijdag 8 Augustus 2008 22:24

image

code

Anonymous Coward op Maandag 11 Augustus 2008 12:01

image

code

Alleen werkend op al meer dan een jaar ongepachte Vista machine.

toiletpaper op Maandag 11 Augustus 2008 12:12

image

inmiddels is het ook verwijderd

toiletpaper op Maandag 11 Augustus 2008 12:17

image

misschien wilden ze mensen niet op ideeën brengen. Maar hoe weet jij dat het alleen werkt op een jaar lang niet gepatchte machine, uit eigen bevinding? Zo, ja, hoe heb je dat ervaren? Heb je een machine die een jaar niet gepatcht was getest met deze code?

Welke patch heeft ervoor gezorgd dat deze code nu niet meer werkt?

Anonymous Coward op Maandag 11 Augustus 2008 13:17

image

Gepatched in april 2007.
www.microsoft.c...n/MS07-017.mspx

toiletpaper op Maandag 11 Augustus 2008 13:25

image

het in het artikel genoemde voorbeeldprogrammaatje is inderdaad gepatcht in 2007, maar dat dient om iets uit te leggen. Het achterliggende probleem is niet in 2007 gepatcht, maar is substantieel en komt mogelijker wijze zelfs in Windows 2008 voor, want het is geen exploit dat gepatcht kan worden maar een probleem met ASLR en DEP. Het is een concept-fout, geen bug.

Anonymous Coward op Maandag 11 Augustus 2008 14:01

image

Het achterliggende probleem is niet in 2007 gepatcht,

Er is geen achterliggend probleem te patchen.
De essentie van het hele verhaal is jusit dat er gewoon een bufferoverflow vunerability voor nodig is om het te latne werken.
Het verhaal betreft zelf geen vunerability maar een vrij generieke methode om een bufferoverflow vunerability in een browser te exploiteren.


toiletpaper op Maandag 11 Augustus 2008 14:06

image

Ik denk dat we eht eens zijn

het verhaal bevat een slechte conceptuele eigenschap van ASLR en DEP die waarschijnlijk niet gepatcht kan worden. Het verhaal bevat uitleg over hoe bufferoverflows nog steeds mogelijk zijn, ondanks de veiligheidsmaatregelen die in Vista (en andere OSsen) zijn getroffen.
De manier waarop IE7 werkt en Firefox2 versterken deze vector, want deze gebruiken niet DEP, in de huidige Vista SP1 versie.

In Firefox3 en IE8 is dit verholpen.

Ik denk dat we het eens zijn, maar de toonzetting wil niet overeenkomen.

ArjenB op Vrijdag 8 Augustus 2008 22:00

image

Ik hoop dat Dai Zovi geen gelijk krijgt, en dat het tot Windows beperkt blijft. Dat lijkt me al erg genoeg. Het artikel klinkt onheilspellend.

Anonymous Coward op Zondag 10 Augustus 2008 12:59

image

Mee eens. De conclusie van het pdf artikel legt uit dat het voor een deel ook te maken heeft met design keuzes in browsers in het algemeen. Dus daarmee zou het groter dan Windows kunnen worden. Maar goed dan heb je een expoit die uit de browser weet te breken. In Windows vaak een ramp, op andere platforms vaak niet meer dan een major anoyance.

Ik geef toe ik begrijp geen hout van het artikel, dus ik kan er volledig naast zitten natuurlijk.

ArjenB op Zondag 10 Augustus 2008 16:29

image

Het artikel van Sotirow en Dowd beschrijft vooral kwetsbaarheden voor IE in Windows XP en Vista. Ik begin me pas privé zorgen te maken als in een volgend artikel de verbinding met FF, Opera en linux gelegd wordt. Op het werk moet de whitelist nog maar eens geinspecteerd worden.

toiletpaper op Zondag 10 Augustus 2008 21:23

image

Het is natuurlijk heel ver velend wanneer een OS onveilig is, en dat er niks aan is te doen. Zeker wanneer dit een populair OS is, dan zullen we er allemaal last van hebben. Denk aan botnets die DDOS aanvallen uitvoeren of spam versturen.

Anonymous Coward op Maandag 11 Augustus 2008 07:46

image

Ziet er uit als een potentieel wijdverbreide zwakheid die eerst diepgaand onderzocht moet worden voordat precies duidelijk is ""wat"" men nu precies doet.

Volgens mij heeft het te maken met te exploiteren van stack en buffer overflows.
Dat zou op Vista moeilijker moeten zijn dan op XP door extra voorzieningen als het randomiseren van adressering in executables.

Deze methode vertrouwd dan blijkbaar op het laden van de executable code in memory bijvoorbeeld dmv een java applet wat dan de browser voor je doet. Het betreft dan dus niet java code zelf maar exploit code verpakt in een java applet (bv in een string).

En dan is het de bedoeling door middel van een andere bufferoverflow exploit proberen die executable code aan te roepen. Je hebt dus sowieso een andere exploit nodig om hier gebruikt van te maken en je moet exploitable code in het browser memory weten te laden (dus iemand overhalen naar je webpagina te gaan).

Het lijkt dus eigenlijk een methode om aanvallen die op Vista heel moeilijk waren geworden (bufferoverflow attacks) weer mogelijk te maken mits je die bufferoverflow kan exploiteren vanuit de browseromgeving en je de gebruiker naar je website weet te lokken.

Anonymous Coward op Maandag 11 Augustus 2008 09:10

image

Dat zou op Vista moeilijker moeten zijn dan op XP door extra voorzieningen als het randomiseren van adressering in executables.
In het artikel staat juist dat het om het VISTA os gaat:
Two security researchers have developed a new technique that essentially bypasses all of the memory protection safeguards in the Windows Vista operating system
En er staat dat het tecnieken als ASLR en DEP kan omzeilen:
In a presentation at the Black Hat briefings, Mark Dowd of IBM Internet Security Systems (ISS) and Alexander Sotirov, of VMware Inc. will discuss the new methods they've found to get around Vista protections such as Address Space Layout Randomization(ASLR), Data Execution Prevention (DEP) and others by using Java, ActiveX controls and .NET objects to load arbitrary content into Web browsers.
Dus het zou moeilijker moeten zijn, maar dat is het klaarblijkelijk niet.

Om eerlijk te zijn heb ik vanaf het begin niet zoveel vertrouwen gehad in ASLR omdat het voor mijn gevoel een vorm van security by obscurity is.

Het is wel jammer, erg jammer. Ik had gehoopt dat na al het marketinggeweld in elk geval iets van Vista zou blijven staan, maar zo te horen gaat ook Vista de standaard Windows weg. Leuk aan de buitenkant, maar gaar van binnen.

Anonymous Coward op Maandag 11 Augustus 2008 09:24

image

In het artikel staat juist dat het om het VISTA os gaat:
Dat komt omdat Vista zover ik weer het enige OS is dat Data Execution Prevention en Address Space Layout Randomization bevat.

Het gaat er dus om dat juist Vista normaliter heel moeilijk aan te vallen is met dergelijke aanvalsvectoren. Bufferoverflow aanvallen zijn vweel makkelijker op andere OS'sen zoals windows XP (zeker voor SP2) of OS X.

p.s. Onder linux wordt ook wel wat met ASLR gewerkt en DEP wordt ook in eerdere windows versies al toegepast.

Anonymous Coward op Maandag 11 Augustus 2008 10:34

image

Dat ASLR ook onder Linux wordt gebruikt doet niets af aan mijn mening. DEP heb ik het verder niet over gehad. Dat lijkt mij een uitstekende techniek. Executable code heeft tenslotte niets te zoeken in een data segment.

En als ik het artikel goed begrijp moet je je mening bijstellen. "... moeilijk aan te vallen is ..." moet worden "... moeilijk aan te vallen was ..."

Ik hoop werkelijk van harte dat Microsoft hier een oplossing voor kan verzinnen, want echt gelukkig word ik er niet van.

Anonymous Coward op Maandag 11 Augustus 2008 11:36

image

Ik denk dat jij je mening moet bbijstellen.
Het gaat hier om extra beveiliging lagen in vista (en soms ook in andere OS'sen) die nu op een bepaalde manier omzeild kunnen worden.

Dat jij ASLR vergelijkt met security trough obscurity is vreemd want daar heeft het niks meet te maken. Het gaat er bij ASLR om dat elke instance van een OS net iets anders functioneert qua adressering van executables waardoor geen gebruik gemaakt kan worden van een vast patroon. Via een bufferoverflow exploiteerbare code staat niet altijd op dezelfde plaats waardoor het vrijwel onmogelijk is om daarop exploits te doen.

Het omzeilen van de beveilinging door het injecteren van exploitable code in een browser betekent nog niet dat beveiligingsmethode methode volledig onbruikbaar zijn. Het is echter wel zo dat mogelijk bufferoverflows alleen in bepaalde browsergerelateerde software weer exploiteerbaar worden in specifieke gevallen waar dat op Vista potentieel door ASLR en DEP al veel moeilijker geworden was dan op XP.

Het gaat dus niet om exloiteerbare vunerabilities zelf, maar om mogelijkheden om bepaalde vunerabilites die op Vista juist niet meer exploiteerbaar waren door extra beveiliging toch weer exploiteerbaar te maken.

Maar ASLR beveiliging bijvoorbeeld werkt natuurlijk wel nog altijd buiten de browser en is bedoeldt voor alle mogelijke executables op een OS.

Je kunt dus met deze methode bijvoorbeeld bijvoorbeeld niet bufferoverflows in bijvoorbeeld MS Office of willekeurige andere applicaties exploiteren omdat daar de ASLR beveiliging nog steeds werkt. Je hebt zover ik kan zien specifiek bufferoverflows nodig die je toegang geven tot het geheugen dat door een browser gecontroleerd wordt en je moet in staat zijn om data in dat geheugenblok te injecteren (bijvoorbeeld door het laden van een java applet) en dus de gebruiker die een dergelijke bufferoverflow vunerability heeft naar je site lokken.

Zo werkt in het stuk geschreven door deze onderzoekers met een reeds critical geachte vunerability (CVE-2007-0038) die al bijna anderhalf jaar geleden is gepatched in Vista. Zij geven dus testresutaten van een volledig ongepatchte Vista. Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al critical vunerabilities voor nodig hebt om deze methode toe te passen. Het lijkt erop dat het wel zo is dat het makkelijker wordt om een bufferoverflow te exploiteren (wat op vista dus relatief heel moeilijk is) maar het is hiermee niet makkelijker om aan dergelijke bufferoverflows te komen.









Anonymous Coward op Maandag 11 Augustus 2008 11:55

image

Aanvullend nog
Deze heren gebruiken een methode om het browsergeheugen te vullen met enorme blokken repeteerbare uitvoerbaare data data zodat de ASLR methode niet werkt omdat je ook bij een anders in het geheugen versprongen geheugenadres toch in de executeerbare code terecht komt.
Hier overigens een redelijk goed technische beschrijving van deze bevindingen:
http://www.heise.de/newsticker/Die-Rueckkehr-der-Pufferueberlaeufe--/meldung/114054

Overigens lijkt me een oplossing richting de toekomst dat de DEP protectie die MS toepast op normale executable ook toegepast wordt binnen bijvoorbeeld een java virtual machine of .net.

toiletpaper op Maandag 11 Augustus 2008 12:09

image

Goed artikel van Heise, (zoals gewoonlijk).

toiletpaper op Maandag 11 Augustus 2008 12:11

image

Betekent overigens wel dat DEP en ASLR niet afdoende zijn, en misschien wel verkeerd

Anonymous Coward op Maandag 11 Augustus 2008 15:34

image

Niet afdoende is correct.
Deze beveiligingsmethodes controleren geen volledige executie / geheugen binnen bijvoorbeeld een Java VM en ASRL is potentieel kwetsbaar voor bufferoverflows in een specifieke situatie waarbij je het het grootste deel van het applicatie geheugen vooraf aan het exploiteren van de bufferoverflow weet vol te plempen met identieke uitvoerbare code.

Je inschatting dat het dan meteen maar verkeerd is lijkt me voorbarig. Het is nog steed een aanzienlijk stap vooruit op de traditionele werking van bijvoorbeeld XP en in mindere mate OS X en Linux die dergelijke beveiligs methodediek niet kennen of in minder geavanceerde mate. Het geeft nog steeds beveiliging tegen bufferoverflows in andere applicaties dan browsers.

toiletpaper op Maandag 11 Augustus 2008 15:42

image

Ik zei dat het misschien verkeerd is, omdat het in runtime-omgevingen zoals .NET die meer en meer opkomen niet werkt, en geïmplementeerd moet worden binnen die runtime-omgeving, waardoor er redundante code-functionaliteit ontstaat

toiletpaper op Maandag 11 Augustus 2008 15:51

image

Het is nog steed een aanzienlijk stap vooruit op de traditionele werking van bijvoorbeeld XP en in mindere mate OS X en Linux die dergelijke beveiligs methodediek niet kennen of in minder geavanceerde mate.
Wat je zegt is niet waar.

Linux kent ASLR sinds 2000 en dus al veel langer dan Windows.
Het is begonnen met het ontwikkelen en stapsgewijs implementeren in de kernel van een soortgelijke techniek rond 2001. Reeds in 2000 was er PaX dat als kernel-patch ASLR kon implementeren.

Linux kent het DEP concept sinds 2002
Het is sinds 2002 door RedHAT uitgebracht. het heet Exec-Shield, en werkt conceptueel hetzelfde als DEP.

Anonymous Coward op Dinsdag 12 Augustus 2008 00:02

image

Dat de methodes bestaan is duidelijk.
Worden deze echter linux breed geimplementeerd ?
Ofwel gebruiken alle distro's deze?
Zover ik kan lezen zijn het optionele kernel patches.

toiletpaper op Woensdag 13 Augustus 2008 12:44

image

Dat de methodes bestaan is duidelijk.
Dat wist je even geleden nog niet, toen was je nog aan het ontkennen dat er DEP/ASLR bestand voor Linux bestond, of in minder geavanceerde mate (naar keuze, wat is het nou, niet, mindere mate, fud?).
Ik citeer:
Het is nog steed een aanzienlijk stap vooruit op de traditionele werking van bijvoorbeeld XP en in mindere mate OS X en Linux die dergelijke beveiligs methodediek niet kennen of in minder geavanceerde mate
Worden deze echter linux breed geimplementeerd ?
Hier heb je een punt, Redhat implementeert het, al jaren voordat Windows het deed (sinds 2002), van Redhat afgeleide distro's dus ook. Dat zijn tientallen distro's.
Exec-shield is echter niet een product, het is een marketing term van Redhat, het is een serie van routines die ASLR en DEP implementeren.
De mainstream kernel heeft de concepten sinds dit jaar geïmplementeerd, dus andere distro's zullen snel volgen.

Samengevat: Het wordt al jaren in Linux volledig geïmplementeerd, in veel, maar niet in alle distro's.
Die kunnen echter een kernel-patch draaien (contact opnemen met distributeur voor aanwijzingen), of even wachten totdat hun distro de kernel verstrekt waarin het wel is geïmplementeerd, wat niet lang zal duren voor verreweg de meeste distro's

toiletpaper op Maandag 11 Augustus 2008 12:32

image

Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al critical vunerabilities voor nodig hebt om deze methode toe te passen.
Dit lijkt mij struisvogel-gedrag, de onderzoekers willen de kat niet op het spek binden, en geen exploitable code publiceren voor een niet gepatcht lek, en ze worden gelijk door een Vista fan-boy verdacht gemaakt omdat ze GEEN momenteele xploitable code presenteren.

kwalijk, kwalijk. Ze kunnen het nooit goed doen, als ze wel een exploitable voorbeeld hadden gepubliceerd was het ook niet goed geweest.

Anonymous Coward op Maandag 11 Augustus 2008 13:20

image

Het lijkt mij dat er nu op geen enekele manier bewezen is dat dit meer is dan slechts een vereenvoudiging is van het exploiteren van wat reeds kritieke lekken zijn.
Geen nieuwe lekken dus maar een alternatieve methode om deze te kunnen exploiteren.

toiletpaper op Maandag 11 Augustus 2008 13:26

image

Het gaat helemaal niet om lekken maar om een conceptuele fout in ASLR en DEP.

Anonymous Coward op Maandag 11 Augustus 2008 14:12

image

Dan begrijp je niet hoe het werkt.
Als ASRL ook zou werken op het niveau van java applet dan zou de java VM zelf de code niet meer goed kunne adresseren en niet meer werken.
Het gaat hier juist om applicaties zoals java die in een brwoser zelf hun executable code in het geheugen laden en bijvoorbeeld een eigen virtuele stack hebben die niet met DEP protected kan worden omdat ook dan de Java VM niet meer functioneert. ASRL en DEP werken prima zolang het OS zelf de executable code lanceert en de executie controleert.

toiletpaper op Maandag 11 Augustus 2008 14:21

image

Als ASRL ook zou werken op het niveau van java applet dan zou de java VM zelf de code niet meer goed kunne adresseren en niet meer werken.
Ik snap niet waar jij op doelt, je zegt dat ik "het" niet goed begrijp, en begint als uitleg te bazelen over Java. Misschien kun je even uitleggen waar ik het over Java heb gehad.

Anonymous Coward op Maandag 11 Augustus 2008 13:56

image

Ach kijk, de ontkenningsfase. Dat herken ik bij sommige Apple gebruikers ook. Dit zal het teken zijn dat het religieus fanatisme nu de kop gaat opsteken. Ik denk dat ik de discussie maar eens moest verlaten.

toiletpaper op Maandag 11 Augustus 2008 14:25

image

Ik ga mee, ik heb welg ezegd wat ik wilde zeggen, en weer honderden reacties om letter voor letter een ontkennende ontkenning te ontcijferen zoals hier (zoek naar woord: intel gebeurde, daar heb ik niet elke week zin in.

Anonymous Coward op Maandag 11 Augustus 2008 14:47

image

Ik herinner me die nu al legendarische discussie.

Anonymous Coward op Maandag 11 Augustus 2008 12:59

image

Dat jij ASLR vergelijkt met security trough obscurity is vreemd want daar heeft het niks mee te maken.
Is dat zo? Niks? Nou dan zal dat wel zo zijn, als jij het zo stellig zegt. In vind dat je door de adressering te randomizen een soort van verstoppertje speelt, maar goed wie ben ik.

Het verbaast me dat je niet ook nog fijntjes wijst op het feit dat één van de lagen niet is gebroken, waardoor de exploit op dit moment, god zij dank, (nog) niet uit het rechtensysteem kan ontsnappen. Dus als je je browser netjes onder lage rechten houdt blijft de schade enigszins beperkt. Dat vond ik veel belangrijker nieuws op Heise.

En dat de onderzoekers een oude exploit gebruiken om hun theorie te illustreren lijkt me niet meer dan logisch. Of had je liever gezien dat ze hun POC hadden geschreven op een nieuw lek in de browser? Hoe het gestart wordt doet niet eens terzake. Er zullen altijd gaten in software blijven zitten, anders had Microsoft geen kunstgrepen verzonnen om het misbruiken ervan te voorkomen. Daar gaat het over! Niet over het zwart maken van onderzoekers.

Anonymous Coward op Maandag 11 Augustus 2008 13:30

image

In vind dat je door de adressering te randomizen een soort van verstoppertje speelt

Toch is dat niet zo. Bij een bufferoverflow moet je over het algemeen door aan ingelezen input extra code toe te voegen code injecteren op een exacte plaats in geheugen om executable code in het geheugen te overschrijven met je eigen code. Als je niet precies weet hoe de executable code in het geheugen geladen wordt en of dat op elke instance of zelfs elke keer dat een executable wordt opstart anders is dat dan wordt een dergelijk manier van exploiteren erg lastig. Het gaat dus niet om het verstoppen maar om het verkoemn van een herkenbaar en daardoor makkelijk exploitabel patroon.

Anonymous Coward op Maandag 11 Augustus 2008 13:48

image

Als mijn vriendin de autosleutels ergens anders neer legt dan waar ik ze verwacht, dan zijn ze voor mij verstopt. Ik ben een eenvoudig mens met een eenvoudige gedachtewereld. Dus je kunt het uren krom proberen te argumenteren. Maar mijn gevoel dat het een vorm van security by obscurity is ga je niet om lullen.

Ik weet dat het iets anders is, maar het gevoel blijft bestaan.

ArjenB op Maandag 11 Augustus 2008 13:53

image

Daar is dus heap-spraying voor bedacht, dat je ondanks het ontbreken van een precies adres alsnog de gewenste instructies binnen het bereik van een proces brengt. Omdat het geheugen in een repeterend patroon volgepompt is met die instructies.

En je keert terug bij het probleem dat een browser in geheugenruimte schrijft waar die absoluut niet zou moeten schrijven.

Anonymous Coward op Maandag 11 Augustus 2008 14:26

image

En je keert terug bij het probleem dat een browser in geheugenruimte schrijft waar die absoluut niet zou moeten schrijven.

Dat is de Java VM die het geheugen beschrijf door de applet te laden.
Daarnaast heb je dan nog een extra bufferroverflow in de browswergerelateerde software nodig om in dat stuk geheugen te komen.
Het is dus
A) krijg de gebruikers zo ver een applet te laden die het geheugen van de browser waarin de java VM draait volpompt met exucutable data
B) Exploiteer een reeds bestaande bufferoverflow in de browsergeralteerde software om die executable data uit te voeren.

Dat is niet evident. In de meeste situaties is op zich een dergelijke bufferoverflow namelijk al een voldoende krtitke lek om binnen te komen. In Vista is dat niet altijd zo omdat daar bufferoverflows moeilijker te exploiteren zijn (met name als de executable code waarin de bufferoverflow zit bijvoorbeeld ASRL geschikt is). Dus aanvullend heb je dan nog die methode nodig om het browsergeheugen vol te dumpen met code.

Voor bijvoorbeeld XP of OS X heb je een dergelijke omslachtige methode niet nodig omdat je daar meestal direct de bufferoverflow kunt exploiteren en daarbij direct bij de overflow zelf de executable code injecteert en niet nog een ander stuk geheugen moet opzoeken omdat te doen.

Afgezien (en ongerelateerd) begrijp ik je opmerking sowieso niet helemaal want is het verder gewoon heel normaal dat een browser geheugen beschrijft om daarin bijvoorbeeld de website elementen op te slaan.

toiletpaper op Maandag 11 Augustus 2008 14:29

image

Voor bijvoorbeeld XP of OS X heb je een dergelijke omslachtige methode niet nodig
Wat heet omslachtig, het zijn computers die eht werk doen, een aantal regels code, en Vista is gewoon gevoelig voor bufferoverflows ondanks ASLR of DEP. Ook Java is daar niet voor nodig.

Anonymous Coward op Maandag 11 Augustus 2008 16:14

image

[quote]Wat heet omslachtig, het zijn computers die eht werk doen, een aantal regels code, en Vista is gewoon gevoelig voor bufferoverflows ondanks ASLR of DEP.[quote]

Sommige bufferoverflows. Alleen voor buffer overflows waarmee je binnen de browsergeheugen reedsgeladen executable code kan uitvoeren. Dat is geen generiek mechnisme.

Maar Windows XP is nog voor veel meer soorten bufferoverflows kwetsbaar en ook linux en OS X zijn gewoon kwetsbaar voor bufferoverflows. Dat is dus niet speciaal voor Vista. Vista is er nog steeeds minder gevoelig voor dan die andere OS'sen.

toiletpaper op Maandag 11 Augustus 2008 16:24

image

Dat is dus niet speciaal voor Vista. Vista is er nog steeeds minder gevoelig voor dan die andere OS'sen.
Dat is onzin. Het gaat ook niet om het OS, het gaat om de applicaties, die zijn gevoelig (of niet) voor bufferoverflows. Het OS kan alleen bepalen of die bufferoverflow tot een exploitable situatie kan leiden.

Ik zou niet weten waarom Vista minder gevoelig is voor exploits voort komend uit bufferoverflows dan Linux? Dat toon je nergens aan. Want net zoals Vista heeft Linux DEP en ASLR, en is het al jaren eerder geïmplementeerd en doorontwikkeld.

Het is niet voor niets dat de onderzoekers zoveel de nadruk leggen op Vista in combinatie met IE7 en eerder. Dat is de gevaarlijke situatie. Ook omdat IE7 zonder de NX-switch (DEP-switch) gecompileerd is en dus geen DEP heeft aanstaan.

Firefox3 is wel met de NX-switch gecompileerd, en IE8 ook, maar is IE8 nu al op de markt of nog steeds beta?

Anonymous Coward op Maandag 11 Augustus 2008 16:48

image

Linux heeft volgens mij geen DEP en volledig ASLR is dacht ik ook geen standaard linux feature.
Daarom is dus linux in therie meer kwetsbaar bij bufferoverflows dat Vista

Aan de andere kant heeft linux als geheel mogelijk meer protectie doordat elke distro anders wordt gecompileerd. Dat maakt een bufferoverflow exploit minder generiek toepasbaar. Je hebt eigenlijk voor bijna elke distro een andere variant nodig.


toiletpaper op Maandag 11 Augustus 2008 16:59

image

Linux heeft volgens mij geen DEP
je weet niet waarover je eht hebt, of je wil een welles/nietes spelletje doen
Exec Shield
Exec Shield is a project started at Red Hat, Inc in late 2002 with the aim of reducing the risk of worm or other automated remote attacks on Linux systems.....
....The first Exec Shield patch attempts to flag data memory as non-executable and program memory as non-writeable...
...The patch additionally increases the difficulty of inserting and executing shellcode, rendering most exploits ineffective....
....Other features that came out of the Exec Shield project were the so-called Position Independent Executables (PIE), the address space randomization patch for Linux kernels, a wide set of glibc internal security checks that make heap and format string exploits near impossible, the GCC Fortify Source feature, and the port and merge of the GCC stack-protector feature......
en volledig ASLR is dacht ik ook geen standaard linux feature.
Daarom is dus linux in therie meer kwetsbaar bij bufferoverflows dat Vista

Zoals je ziet, ExecShield is ASLR en DEP in een keer. Dus waar heb je het over. ExecShield is beoordeeld door de NSA en verbeterd, en het bestaat al veel langer, nog voordat de ontwikkeling aan Vista was begonnen.
Aan de andere kant heeft linux als geheel mogelijk meer protectie doordat elke distro anders wordt gecompileerd. Dat maakt een bufferoverflow exploit minder generiek toepasbaar. Je hebt eigenlijk voor bijna elke distro een andere variant nodig.
Doekje voor het bloeden voor die arme Linux jongens, nou, dat hebben ze niet nodig, zoals ik hierboven al schreef.

toiletpaper op Maandag 11 Augustus 2008 14:30

image

Afgezien (en ongerelateerd) begrijp ik je opmerking sowieso niet helemaal want is het verder gewoon heel normaal dat een browser geheugen beschrijft om daarin bijvoorbeeld de website elementen op te slaan.
Geen wonder dat je het niet snapt, want je leest helemaal niet goed wat hij schrijft, lees het maar opnieuw.

toiletpaper op Maandag 11 Augustus 2008 14:31

image

je citeert het ook nog, en toch lees je het niet goed

ArjenB op Maandag 11 Augustus 2008 14:41

image

Ik heb Sotirov en Dowd's artikel hier niet bij de hand (whitelist, tja), maar die beschrijven juist een methode om, ondanks ASLR, toch via recursief volpompen van het geheugen de kwaadaardige instructies op een plek neer te zetten waar die instructies uitgevoerd zullen worden: op een plek waar zonder overflow iets had gestaan wat wel te vertrouwen was.
Afgezien (en ongerelateerd) begrijp ik je opmerking sowieso niet helemaal want is het verder gewoon heel normaal dat een browser geheugen beschrijft om daarin bijvoorbeeld de website elementen op te slaan.Ja, dat is normaal. Wat zo'n normale actie in een schadelijke actie verandert is als het te vullen deel van het geheugen aan een andere activiteit is toegewezen.

Anonymous Coward op Maandag 11 Augustus 2008 15:11

image

[quote]Ik heb Sotirov en Dowd's artikel hier niet bij de hand (whitelist, tja), maar die beschrijven juist een methode om, ondanks ASLR, toch via recursief volpompen van het geheugen de kwaadaardige instructies op een plek neer te zetten waar die instructies uitgevoerd zullen worden: op een plek waar zonder overflow iets had gestaan wat wel te vertrouwen was.[quote]

Het volpompen van het geheugen moet worden gedaan door een applicatie zoals de Java VM waarin je dynamisch geheugen kunt alloceren binnen een browseromgeving.

[quote]Ja, dat is normaal. Wat zo'n normale actie in een schadelijke actie verandert is als het te vullen deel van het geheugen aan een andere activiteit is toegewezen. [/quote]

Dat is dus niet het probleem. Het te vullen gedeelte wordt gewoon door de Java VM gealloceerd en gevuld. Dat is dus ook het applicatie geddelte dat dit stukje geheugen onder controle heeft. Daardoor kan je browser waarin die VM draait een enorme bulk geheugen volplempen.
Normaal zal je browser zelf niet in dat geheugen deel komen dat door de Java VM is gealloceerd. De essentie is echter dan om via een reeds bestaande bufferoverflow je browser executie niet normaal te laten verlopen maar om die juist een willekeurig stukje van dat volgepompte geheugen te laten gebruiken.

ArjenB op Maandag 11 Augustus 2008 15:23

image

1) De Java VM is niet de enige factor, (bijvoorbeeld) browser-plugins kunnen ook voor problemen zorgen.
2) Het doet er niet toe of de overflow zich beperkt tot de voor de Java VM gereserveerde ruimte, er wordt geheugen overschreven dat al voor een andere activiteit is toegewezen. Dat zou niet mogelijk moeten zijn. Overigens volgt uit Sotirov en Dowd's artikel dat de overflow zich niet beperkt tot de voor de Java VM toegewezen ruimte.

ArjenB op Maandag 11 Augustus 2008 15:29

image

Overigens volgt uit Sotirov en Dowd's artikel dat de overflow zich niet beperkt tot de voor de Java VM toegewezen ruimte....of de voor .NET toegewezen ruimte, dat ook eigen geheugenbeheer-regels kent.

Anonymous Coward op Maandag 11 Augustus 2008 16:40

image

2) Het doet er niet toe of de overflow zich beperkt tot de voor de Java VM gereserveerde ruimte, er wordt geheugen overschreven dat al voor een andere activiteit is toegewezen. Dat zou niet mogelijk moeten zijn. Overigens volgt uit Sotirov en Dowd's artikel dat de overflow zich niet beperkt tot de voor de Java VM toegewezen ruimte

Volgens mij gaat het juist wel volledig om aan de Java VM toegewezen ruimte. Juist omdat de java VM deze kan uitbreiden en daardoor vrijwel al het gealloceerde browsergeheugen kan volstoppen met executable data. De kans is daardoor heel groot dat een bufferoverflow waarbij de browser naar een willekeurig plek in het browsergeheugen leidt deze terechtkomt in dit gemanipuleerde geheugen.

toiletpaper op Maandag 11 Augustus 2008 16:47

image

De kans is daardoor heel groot dat een bufferoverflow waarbij de browser naar een willekeurig plek in het browsergeheugen leidt deze terechtkomt in dit gemanipuleerde geheugen.
Een bufferoverflow in een java-applet? lijkt mij onzin, want java-applets hebben geen code-constructies om bufferoverflows te schrijven.

Lees in het document ook de paragraaf met titel: "Statically positioned DLLs and executables" maar eens, daar wordt het spraying probleem duidelijk gelinkt aan native executables, er staan ook verschillende manieren tot "spraying" beschreven.

Anonymous Coward op Maandag 11 Augustus 2008 17:05

image

Lees nou toch eens mijjn berichten.
Ik zeg toch nergens "bufferoverflow in een java applet".
Waarom probeer jij dat dan te conlcuderen.

Ik heb al op verschillende plaatsen aangegeven dat je 1 deel nodig hebt om het geheugen van de browser te sprayen/volalloceren met executable code. Bijvoorbeeld de Java VM die daar heel geschikt voor is. daarnaast heb je een anderdeel nodig. namelijk een bestaande bufferoverflow in een browsergerelateerde software waarmee je toegang krijgt tot dat volgesprayde geheugen.
De beschreven methode is een twee traps raket. Eerst geheugen van de browser volkalken met exucutable malcode. Daarna de browser dmv van een exploiteerbaar bufferoverflow lek in dat geheugen leiden om daar code uit te voeren.

Op computers zonder ASRL beveiliging heb je geen tweetrapsraket nodig omdat je daar de bufferoverflow veel directer kan targetten. Het is dus juist nog steeds moeilijker om op Vista als de bufferoverflow in een met ASLR beveiligde executable zit om deze te exploiteren omdat je dan eerst het browsergeheugen moet voldumpen.

toiletpaper op Maandag 11 Augustus 2008 17:14

image

Het is dus juist nog steeds moeilijker om op Vista als de bufferoverflow in een met ASLR beveiligde executable zit om deze te exploiteren omdat je dan eerst het browsergeheugen moet voldumpen.
Helemaal niet, een native executable kan een spraying mechanisme in werking zetten. (ik hou het kort, herhaling verveelt). Vertreweg de meeste executables zijn niet met ASLR switch gecompileerd, IE7 is zelfs zonder DEP switch gecompileerd, Firefox3 heeft wel de DEP switch

ArjenB op Maandag 11 Augustus 2008 17:02

image

Overigens volgt uit Sotirov en Dowd's artikel dat de overflow zich niet beperkt tot de voor de Java VM toegewezen ruimteIk herhaal het maar. Verder: Heise beweert ook dat zelfs native excutables uit de toegewezen ruimte kunnen springen.

Het thema wat keer op keer terugkomt: applicaties kunnen schrijven in delen van het geheugen waar ze niet zouden moeten kunnen schrijven. Dat ze netjes beginnen in het hun toegewezen deel van het geheugen is fijn, dat ze vervolgens doorgaan met schrijven op plekken waar dat beter niet gebeurde is niet zo fijn.

Het ontbreekt me aan de kennis om te beoordelen in hoeverre Sotirov, Dowd en Heise gelijk hebben, maar het gaat om twee onafhankelijke bronnen die mechanismen beschrijven die mij aannemelijk lijken. Ze hebben het specifiek over Vista. Je geeft zelf al aan dat XP minder veilig is dan Vista. Met een marktaandeel van ~90% voor MS is dat slecht nieuws voor internet-gebruikers.

Anonymous Coward op Maandag 11 Augustus 2008 17:06

image

Verder: Heise beweert ook dat zelfs native excutables uit de toegewezen ruimte kunnen springen

Nee dat doen ze niet.

ArjenB op Maandag 11 Augustus 2008 17:16

image

Welles nietes.
Eine weitere Technik soll in Vista die Ausnutzung von Buffer Overflows erschweren: Die Address Space Layout Randomisation (ASLR). Beim Laden eines Prozesses wählt Vista sowohl für den Code als auch für DLLs und Datenobjekte wie Stack und Heap nach Möglichkeit zufällige Adressen. Angriffstechniken, bei denen man Pufferüberläufe ausnutzt, um bestimmte bekannte Adressen anzuspringen, laufen so ins Leere. Dem begegnen die Hacker mit "Spraying"-Techniken: Sie duplizieren ihren Schadecode einfach über einen Speicherbereich von Hunderten von Megabyte. Auch wenn die Anfangsadresse zufällig ist, so gibt es doch nur einen gewissen Bereich, in dem sie liegen kann. Springt man ein paar Megabyte dahinter, dann wird man schon eine der Kopien des Schadcodes erwischen.
Ik haak af.

Anonymous Coward op Maandag 11 Augustus 2008 17:57

image

Daar staat niet dat vista executables uit hun toegewezen ruimte kunnen springen zoals jij beweerde.
Daar staat namelijk dat Vista executables door ASRL willekeurige plaatsen in het beschikbare geheugen worden toebedeeld voor uitvoerbare en data elementen. En dat is een correcte beschrijving.

toiletpaper op Maandag 11 Augustus 2008 17:58

image

daar staat ook dat men de locatie van data uit een bufferoverflow kan voorspellen indien men gebruik maat van spraying

toiletpaper op Maandag 11 Augustus 2008 17:59

image

Sie duplizieren ihren Schadecode einfach über einen Speicherbereich von Hunderten von Megabyte. Auch wenn die Anfangsadresse zufällig ist, so gibt es doch nur einen gewissen Bereich, in dem sie liegen kann.

toiletpaper op Maandag 11 Augustus 2008 18:01

image

For example, the heap randomization on Windows Vista shifts the base of the heap by up to
2MB. If the attacker can allocate more than 2MB of data on the heap, they will be able to guess a
valid pointer into their data, regardless of the heap randomization.

taossa.com/arch...sotirovdowd.pdf

Anonymous Coward op Dinsdag 12 Augustus 2008 00:09

image

msdn.microsoft....705(VS.85).aspx

"Enables the terminate-on-corruption feature. If the heap manager detects an error in any heap used by the process, it calls the Windows Error Reporting service and terminates the process...Windows Server 2003 and Windows XP: This value is not supported until Windows Vista"

De heap overloaden is er dus niet meer bij in executables die deze setting aan hebben staan. Heap werkt dus met name als je een bufferoverflow vunerability vindt in een voor XP gecompileerde executables die deze setting niet hebben of in applicaties die een eigen heap beheren.

toiletpaper op Maandag 11 Augustus 2008 15:25

image

Het volpompen van het geheugen moet worden gedaan door een applicatie zoals de NET-omgeving waarin je dynamisch geheugen kunt alloceren binnen een browseromgeving.
Alweer wijs je naar iets wat buiten MS ligt, terwijl de .NET omgeving exact hetzelfde probleem heeft.
Doe je oogkleppen eens af en zie dat ook MS hier een probleem heeft.

Anonymous Coward op Maandag 11 Augustus 2008 15:41

image

Alweer wijs je naar iets wat buiten MS ligt, terwijl de .NET omgeving exact hetzelfde probleem heeft.

Dit komt omdat de onderzoeker dat gebruiken als voorbeeld.
In java is het dus zeker mogelijk om op die manier het geheugen van de browsers vol te alloceren en is er voorbeeld code beschikbaar.

Het is bovendien veel gebruikerlijker om java applets te gebruiken op het internet. .NET objecten worden meer gebruikt binnen lokale (intranet) applicaties. Het is daarom kansrijker dat je van een gebruiker toestemming krijgt om een java applet uit te voeren dan een .net object. (en ja, daar moet de gebruiker in Vista standaard permissie voor geven).

toiletpaper op Maandag 11 Augustus 2008 16:48

image

Het is bovendien veel gebruikerlijker om java applets te gebruiken op het internet. .NET objecten worden meer gebruikt binnen lokale (intranet) applicaties.
Ooit gehoord van Silverlight (=.NET), wordt massaal gebruikt door de NOS.

Anonymous Coward op Maandag 11 Augustus 2008 18:26

image

Weet jij hoe silverlight werkt ?
Het is niet pure executable code zoals java maar een XAML script dat componenten uit .NET's windows presentation foundation kan gebruiken. Ik weet niet of het eenvoudig is om op basis van een scripttaal met gebruik van WPF/E componenten memory vol te sprayen met executable code. Hetzelfde voor flash en Java FX

Ik wil het gebruik van dergelijke tools zeker niet uitsluiten maar Java wat volledig uitvoerbare code is die alle mogelijkheden die de VM biedt kan aanspreken ligt toch wel een stukkie meer voor de hand als keuze voor het benaderen van het browser geheugen

Anonymous Coward op Maandag 11 Augustus 2008 18:53

image

Ik heb het nieuws het eerst hier gelezen. Het volgende citaat valt daarbij op:
Researchers who have read the paper that Dowd and Sotirov wrote on the techniques say their work is a major breakthrough and there is little that Microsoft can do to address the problems.
Er is dus schijnbaar een soort van peer-review op het werk geweest. Deze onderzoekers bevestigen dat de bevindingen ernstig van aard zijn.

Nu blijft voor mij maar één vraag over. Hoe ongelooflijk intelligent ben jij dat je zonder inzicht in de materie toch zoveel lijkt te weten? Wat doe jij op zo'n lullig Telegraaf stijl site als WebWereld? Waarom ben jij niet in Redmond om Microsoft uit te leggen hoe ze zich kunnen wapenen? Want jij weet duidelijk meer dan al die onderzoekers bij elkaar.

Kortom, ga wat doen met dat torenhoge IQ van je! En laat het Microsoft bashen gewoon aan het domme klootjesvolk over waar jij duidelijk mijlenver boven staat.

toiletpaper op Maandag 11 Augustus 2008 19:31

image

Ja, wij onderschatten hAl, hij zou het verdienen een wereldberoemde computer geleerde te zijn, hij weet voor ieder vista probleem de beste oplossing

NEGEREN en als dat niet helpt ONTKENNEN, en als dat niet helpt MITIGEREN, en als dat niet helpt, de webwereld discussie volplempen met zichzelf herhalende muggezifterijen tot dat niemand meer weet waarover de discussie nog ging. Daarmee lijkt hij nu ook bezig te zijn, dat betekent dan dat negeren, ontkennen en mitigeren niet geholpen hebben.

Anonymous Coward op Dinsdag 12 Augustus 2008 00:14

image

Er is dus schijnbaar een soort van peer-review op het werk geweest. Deze onderzoekers bevestigen dat de bevindingen ernstig van aard zijn.

Op zich is het ook vervelend dat bufferoverflows in bepaalde situaties weer exploiteerbaar zijn omdat bepaalde nieuwe security methodes kunne worden omzeild in de browserprocessen. En daar is vermoedelijk inderdaad op dit moment weinig aan te doen. Dat is echter niet meteen een security ramp. Je hebt dan nog steeds de ongepatchte bufferoverflows nodig die ook al gebruikt werden om XP te compromiteren.

toiletpaper op Dinsdag 12 Augustus 2008 00:26

image

Op zich is het ook vervelend dat bufferoverflows in bepaalde situaties weer exploiteerbaar zijn omdat bepaalde nieuwe security methodes kunne worden omzeild in de browserprocessen. En daar is vermoedelijk inderdaad op dit moment weinig aan te doen. Dat is echter niet meteen een security ramp. Je hebt dan nog steeds de ongepatchte bufferoverflows nodig die ook al gebruikt werden om XP te compromiteren.
Ik ben het bijna helemaal met je eens, behalve dat je zegt dat het geen security ramp is, want dat is het wel, het blijkt dat Vista beveilginsmethoden niet werken voor executables die voor XP zijn gecompileerd, wat toch heel veel voorkomt, zelfs IE7 heeft de DEP switch niet aan.

Alsof er niets aan de hand zou zijn met het Windows platform....

Anonymous Coward op Dinsdag 12 Augustus 2008 07:05

image

Om de discussie met Theodoor en ArjanB niet verder aan te gaan over de essentie dat het hier gaat om issues waarbij de browser betrokken is en om het snesatie nieuwe gehalte waar Peter nogal voor is gevallen enigzins te temperen zal ik de woorden van de onderzoeker zelf aanhalen:

I am one of the authors of the paper referenced in the post above. First of all, I'd like to apologize for the sensationalism of the press coverage. Most of the articles about our work are completely inaccurate and full of ridiculous statements. Mark and I had nothing to do with these articles and were not contacted by their authors.

Please read our slides and paper (available from http://taossa.com/) before making any judgements about their content.

What we've done is show that the exploitation prevention mechanisms implemented in Windows Vista (including DEP and ASLR) are ineffective at preventing the exploitation of browser memory corruption vulnerabilities, due to the following factors:

1) the amount of contol an attacker has over the state of the browser process

2) the plugin architecture that allows third party plugins (Java, Flash, Acrobat) which often weaken these protections

3) the architecture of the browsers which run all code in the same process and have no isolation between different components

Our research is focused only on browsers. The protection mechanisms in Vista are still effective at preventing the exploitation of vulnerabilities in server processes, which is why I believe that Vista is still more secure than any previous version of Windows.

Posted by: Alexander Sotirov at August 11, 2008 6:59 PM


Zoals ik dus al meerdere keren heb aangegeven is het in essentie een stuk dat uitlegt dat de bufferoverflow mogelijk maakt in de browser context en de onderzoeker zelf zegt dus lettelijk dat Vista veiliger is dan alle voorgaande versies van Windows.

@ Peter
Wil dat door die verschrikkelijk dikke oogkleppen dringen!? Geloof je nou werkelijk dat die mannen alleen maar een pakkende openingszin zochten!?

Misschien de volgende keren mat minder hoog van de toren blazen. Ik denk dat dus inderdaad over de vette koppen in pers berichten en bovendien geeft de bewuste onderzoeker zelf mij gewoon heel duidelijk gelijk.



toiletpaper op Dinsdag 12 Augustus 2008 08:01

image

Zoals ik dus al meerdere keren heb aangegeven is het in essentie een stuk dat uitlegt dat de bufferoverflow mogelijk maakt in de browser context en de onderzoeker zelf zegt dus lettelijk dat Vista veiliger is dan alle voorgaande versies van Windows.
Hij zegt inderdaad dat de vulnerabilities alleen in browser context van belang zijn,
en dat de berichten die anders beweren onzin zijn, en niet van hun hand.

Hij zegt ook inderdaad dat Vista beveiligingsmechanismen heeft die andere Windwos-versies niet hebben,
maar hij zegt ook dat die beveiligingsmechanismen in de browsercontext niet werken,
dat Vista in de browser context niet veiliger is dan andere Windows-versies.

Dit zegt hij niet in jouw citaat, maar het feit dat IE7 zonder de noodzakelijke switches gecompileerd is zal hier zeker van belang zijn.
IE8 zal echter, net als Firefox3 wel met deze switches worden gecompileerd.

Misschien de volgende keren mat minder hoog van de toren blazen. Ik denk dat dus inderdaad over de vette koppen in pers berichten en bovendien geeft de bewuste onderzoeker zelf mij gewoon heel duidelijk gelijk.
Natrappen vind ik niet nodig, en ik vraag me af waarom je dat nodig ehbt.
De onderzoeker zegt nergens dat hAl gelijk heeft, dat zou een actie richting jou suggereren.
Het feit is dat jij dezelfde mening bent toegedaan als hij, en dat jij daardoor gelijk hebt. Jammer dat dit zulke vreemde emoties bij je oproept, maar goed, dat is jouw probleem.

Ik denk dat we de dicussie nu wel kunnen afsluiten.

Anonymous Coward op Dinsdag 12 Augustus 2008 09:42

image

het snesatie nieuwe gehalte waar Peter nogal voor is gevallen
Sorry waar ben ik voor gevallen? Meestal kan ik met moeite wel destilleren wat je bedoelt, maar nu ben ik je echt kwijt. ik gok dat snesatie sensatie moet zijn, maar dan?

Waar beweert die onderzoeker nu dan dat DEP and ASLR niet gebroken zijn? Het is gebroken en het blijft gebroken hAl. Daar kan je dagen omheen lullen, maar het feit ligt er. De schaal maakt niet uit. Met dit als basis gok ik dat het niet lang duurt of het hele skala van beveiligingsprotocollen van Vista gaat op zijn reet.

Microsoft heeft bij het ontwerp weer gekozen voor gemakzucht, dus de zwakste schakel ligt al bloot.

ArjenB op Dinsdag 12 Augustus 2008 10:45

image

Om de discussie met Theodoor en ArjanB niet verder aan te gaan over de essentie dat het hier gaat om issues waarbij de browser betrokken isWijs me mou eens waar ik dat geschreven heb.

Je gaat me toch geen woorden in de mond leggen?

Ik heb ook nooit beweerd dat Vista niet veiliger is dan XP. Wat ik wel beweer: als Sotirov en Dowd gelijk hebben - Dino Dai Zovi is één van de mensen die dat denkt - dan hebben ze een lek in Vista gevonden. En is Vista veiliger dan XP, maar minder veilig dan de meesten tot nu toe dachten. Dat is slecht nieuws.

ArjenB. Met een e. Ik herhaal het nog maar eens.

toiletpaper op Maandag 11 Augustus 2008 19:27

image

Het is niet pure executable code zoals java maar een XAML script dat componenten uit .NET's windows presentation foundation kan gebruiken. Ik weet niet of het eenvoudig is om op basis van een scripttaal met gebruik van WPF/E componenten memory vol te sprayen met executable code. Hetzelfde voor flash en Java FX
Silverlight kan gewoon .NET code uitvoeren wanneer dat in een object zit.

Het belangrijke probleem met runtimes zoals .NET of Java was niet het sprayen, maar dat DEP niet meer werkt in de betreffende processcontext, remember? Want de DEP uitschakelen konden native executables niet (mits gecompileerd met de DEP-switch, IE7 is dat niet), dat was een typisch probleem van de runtime-omgevingen

Je haalt de dingen nu wel een beetje door elkaar.

Maar nu ben ik er wel een beetje moe van.

Laat ik het zo zeggen, ik stop met deze discussie, voor een tijdje, want we blijven in kringetjes draaien, en ik heb inmiddels alles al drie keer gezegd.

Dat ik stop betekent niet dat ik vind dat jij gelijk hebt, het betekent dat ik er moe aan ben, want ik vind nog steeds dat jij voor bepaalde onderdelen van de discussie ongelijk hebt, en een paar keer heb ik al gezegd het min of meer met je eens te zijn.

Dus, doei

Ik moet nu bij mijn schoonzus een vastgelopen Vista computer aan de gang helpen, dat is de vloek van mensen zoals ik, een aantal mensen belt mij om hun problemen op te lossen, ik krijg er wel bijna altijd een fles single malt voor, meestal Bowmore, dat is neit te duur.

Anonymous Coward op Dinsdag 12 Augustus 2008 00:20

image

Het belangrijke probleem met runtimes zoals .NET of Java was niet het sprayen, maar dat DEP niet meer werkt in de betreffende processcontext, remember? Want de DEP uitschakelen konden native executables niet (mits gecompileerd met de DEP-switch, IE7 is dat niet), dat was een typisch probleem van de runtime-omgevingen

Volgens mij was toch vitaal dat gebrek aan DEP in een process ervoor zorgde dat binnen de browser het geheugen niet op no-execute gezet kan worden. Daardoor kan een systeem als de java VM het geheugen vullen met repeterende blokken executable code en kan vervolgens een buffer overflow naar het betreffende geheugen gedirigeerd worden en die code in het geheugen uitvoeren. Buiten de browser kan dat niet want daar wordt geheugen wel door DEP als noexecute gemarkeerd.

toiletpaper op Dinsdag 12 Augustus 2008 00:28

image

Buiten de browser kan dat niet want daar wordt geheugen wel door DEP als noexecute gemarkeerd.
Alleen als de NX (lees DEP) compiler switch aanstaat (dit is allemaal al zo vaak gezegd in deze discussie)

toiletpaper op Maandag 11 Augustus 2008 12:26

image

Het lijkt dus eigenlijk een methode om aanvallen die op Vista heel moeilijk waren geworden (bufferoverflow attacks) weer mogelijk te maken mits je die bufferoverflow kan exploiteren vanuit de browseromgeving en je de gebruiker naar je website weet te lokken.
De gebruiker hoef je niet te lokken, die kan ook naar je website gestuurd worden (of zelfs een webpagina opstarten vanuit een gemanipuleerde executable), zelfs zonder een zichtbaar IE-venster (want IE kan ook als onzichtbaar COM-object worden geladen).

Anonymous Coward op Maandag 11 Augustus 2008 13:45

image

De gebruiker hoef je niet te lokken, die kan ook naar je website gestuurd worden (of zelfs een webpagina opstarten vanuit een gemanipuleerde executable), zelfs zonder een zichtbaar IE-venster (want IE kan ook als onzichtbaar COM-object worden geladen).

Dan moet je dus de gebruiker verleiden eerst nog een executable bestand op te starten zonder dat ze op je site geweest zijn. via email of zo ? Dat is volgens mij veel nog lastiger omdat je dan in het bereik van de anti-virus software bent.
Een gebruiker richting een link manipuleren is vermoedelijk eenvoudiger. Dan nog blijft over dat je moet beschikken over een geschikte exploiteerbare bufferoverflow en een daartegen niet gepatchte OS versie.
Dat is nu al geen sinecure meer. 5 jaar geleden waren dergelijke bugs erg populair met name bij vunerabilities XP maar sinds die tijd wordt daar ook zorgvuldiger op gelet bij het programmeren en zijn dergelijke bugs een stuk zeldzamer.

Recentelijk bleek uit een onderzoek van een Amerikaanse consumentenorganisatie trouwens al dat Vista bezitters veel minder last hadden van malware dan bijvoorbeeld XP gebruikers dus voorlopig ziet het er nog prima uit qua beveiliging van Vista vergeleken met XP.

toiletpaper op Maandag 11 Augustus 2008 13:56

image

Dan moet je dus de gebruiker verleiden eerst nog een executable bestand op te starten zonder dat ze op je site geweest zijn. via email of zo ? Dat is volgens mij veel nog lastiger omdat je dan in het bereik van de anti-virus software bent.
Nog meer struisvogel? Kijk eens om je heen, wat gebeurt er op de wereld?

Dit is een normale route van malware om op systemen te komen, daarbij hoeft de code zelf niet door een virusscanner gedetecteerd te worden, want de malicieuze code kan geïmporteerd worden, en het gebruiken van IE als COM-object is geen malicieuze actie.

Nogmaals, heel veel malware komt op een dergelijke manier op een systeem, ik heb zelf al veel niet functionerende virusscanners gezien (bijvoorbeeld de update-URL's waren in de hostfile omgeleid naar local host, waardoor virusscanners zichzelf niet updaten, etc, etc.
Dan nog blijft over dat je moet beschikken over een geschikte exploiteerbare bufferoverflow en een daartegen niet gepatchte OS versie.
Dit klopt niet, de conceptuele fouten in ASLR en DEP zijn niet gepatcht, en het is maar de vraag of ze gepatcht kunnen worden. Volgens mij heb ik dit al drie keer gezegd in deze thread, daarover gaat het allemaal.

Niet over een bug van een jaar geleden zoals jij abusievelijk nog steeds schijnt te denken.
Recentelijk bleek uit een onderzoek van een Amerikaanse consumentenorganisatie trouwens al dat Vista bezitters veel minder last hadden van malware dan bijvoorbeeld XP gebruikers dus voorlopig ziet het er nog prima uit qua beveiliging van Vista vergeleken met XP.
Het is een zwak verweer in deze diucussie, want deze discussie gaat niet over wat gebruikers ervaren, maar over exploitable conceptuele missers in ASLR en DEP, en die zullen in de toekosmt zeker gebruikt gaan worden.


Je zou echt minder struisvogel moeten zijn, in dit geval. Het helpt niet.

Anonymous Coward op Maandag 11 Augustus 2008 14:41

image

[quote]Dit is een normale route van malware om op systemen te komen, daarbij hoeft de code zelf niet door een virusscanner gedetecteerd te worden, want de malicieuze code kan geïmporteerd worden, en het gebruiken van IE als COM-object is geen malicieuze actie.[quote]

De code kan niet geimporteerd worden vanuit de ruimte. Je hebt een site nodig en daarvoor moet je de mensen naar die site lokken

En als je al in staat bent om iemand naar je site te halen en je hebt al de beschikking over een exploiteerbare bufferoverflow in de browser dan is deze methode waarschijnlijk helemaal niet meer nodig tenzij de bufferoverflow ander niet exploiteerbaar is door de ASRL beveiliging.

Het is bijvoorbeeld op XP veel makkelijker om de exploitable code direct in bufferoverflow te injecteren.

Bufferoverflows zijn tegenwoordig al vrij zeldzaam aan het worden doordat softwareontwikkeling er tegenwoordig veel beter rekening mee houdt en als ze er al zijn dan kun je ze meestal soweiso wel exploiteren. Alleen bij ASRL enabled executables op vista kun je dergelijke bufferoverflow niet exploiteren door direct code te injecteren en is deze omweg waarbij je code in het geheugen laadt via bijvoorbeeld een applet noodzakelijk.

toiletpaper op Maandag 11 Augustus 2008 14:56

image

De code kan niet geimporteerd worden vanuit de ruimte. Je hebt een site nodig en daarvoor moet je de mensen naar die site lokken
je kan mensen ook pushen (lees jij wel wat anderen schrijven? ik begin er aan te twijfelen)
tenzij de bufferoverflow ander niet exploiteerbaar is door de ASRL beveiliging.
het hele eieren eten is dat ASLR niet met zekerheid kan beveiligen tegen bufferoverflow. (lees jij wel wat anderen schrijven? ik begin er aan te twijfelen)
Bufferoverflows zijn tegenwoordig al vrij zeldzaam aan het worden doordat softwareontwikkeling er tegenwoordig veel beter rekening mee houdt en als ze er al zijn dan kun je ze meestal soweiso wel exploiteren.
ASLR was er om bufferoverflows te voorkomen, daardoor zijn ze zeldzaam, maar ze kwamen toch zo veel voor dat ASLR als een belangrijke Vista feature verkocht werd (anders zou het een leeg argument zijn geweest).
Ik zal het nog maar een keer zeggen, ASLR kan nu wel geëxploiteerd worden, het kost een beetje extra programmeren, maar het valt nog wel mee, en exploitable code zal zeker niet lang op zich laten wachten.
Alleen bij ASRL enabled executables op vista kun je dergelijke bufferoverflow niet exploiteren door direct code te injecteren en is deze omweg waarbij je code in het geheugen laadt via bijvoorbeeld een applet noodzakelijk
Hier heb jij toch een deel van het verhaal niet begrepen, ook .NET/Silverlight kan gebruikt worden om tot een exploit te komen, en Flash, en andere runtime-omgevingen met een eigen geheugenbeheer, en dat worden er steeds meer.

Anonymous Coward op Maandag 11 Augustus 2008 16:32

image

Lees jij wel wat andere menzsen schrijven.
Je comments slaan helemal niet op wat ik zeg.
Ik kan er verder niks meer mee. Je wilt het gewoon niet gebrijpen denk ik.

[quote]ASLR was er om bufferoverflows te voorkomen, daardoor zijn ze zeldzaam, [quote]
Nee ,dat is niet waar.
Bufferoverflows zijn namelijk ook al zeldzaam in Windows XP vergelkene met 5 jaar geleden. En Windows XP heeft helemaal geen ASLR.

[quote]Hier heb jij toch een deel van het verhaal niet begrepen[/quote]

Nee, ik denk dat jij het niet begrijpt. Je kunt bufferoverflows sowieso explioiteren bij niet ASRL enabled executables. Veel 3rd party software is nog helemaal niet ASRL enabled en dan is deze methode waarbij je bijvoorbeeld met een java VM het browser geheugen volsprayed helemaal niet nodig.

toiletpaper op Maandag 11 Augustus 2008 16:45

image

[quote]Lees jij wel wat andere menzsen schrijven.
Je comments slaan helemal niet op wat ik zeg.
Ik kan er verder niks meer mee. Je wilt het gewoon niet gebrijpen denk ik.[/quote]
Sorry, maar hier kan ik geen bier van brouwen, als je niet zegt wat ik niet begrijp kan ik er onmogelijk op ingaan.
[quote][quote]ASLR was er om bufferoverflows te voorkomen, daardoor zijn ze zeldzaam, [quote]
Nee ,dat is niet waar.
Bufferoverflows zijn namelijk ook al zeldzaam in Windows XP vergelkene met 5 jaar geleden. En Windows XP heeft helemaal geen ASLR.
[/quote]
OK, bufferoverflows zijn minder dan vijf jaar geleden. Wat is zeldzaam, een exploitable bufferoverflow op je computer, en je hangt. Ook al is het zeldzaam.
[quote][quote]Hier heb jij toch een deel van het verhaal niet begrepen[/quote]
Nee, ik denk dat jij het niet begrijpt. Je kunt bufferoverflows sowieso explioiteren bij niet ASRL enabled executables. Veel 3rd party software is nog helemaal niet ASRL enabled en dan is deze methode waarbij je bijvoorbeeld met een java VM het browser geheugen volsprayed helemaal niet nodig.[/quote]
Ik ben het alweer met je eens, het is inderdaad zo dat third parties vaak niet gecompileerd hebben met de ASLR switch. Maar dat is een ander spraying-probleem dan bij de runtime omgevingen voorkomt, het verdient ook een apart hoofdstuk in het document, zie
webwereld.nl/co...#comment_343189

Anonymous Coward op Maandag 11 Augustus 2008 17:44

image

Wat is zeldzaam, een exploitable bufferoverflow op je computer, en je hangt

Nee, dat is op niet Vista OS'sen wel zo. Met name XP is daar een bekende exponent van.
Voor exploitatie op XP is dan bovendien nog nodig dat deze bufferoverflow je naar het browsergeheugen kan leiden dat door een andere browsercomponent gebruikt gealloceerd is en dat de gebruiker verleid kan worden om eerste de component te laden die het geheugen vol-alloceerd en vervolgens de component die de bufferoverflow exploiteert.
De meeste bufferoverflows zijn bijvoorbeeld vaak pas exploiteerbaar als je een gebruiker zover krijgt om een specifieke file te openen. Voor de meer voor de handliggende files files die de browser standaard download en opent opent zoals jpeg's en gif's is het zoekwerk naar nieuwe bufferoverflows denk ik al jaren geleden opgegeven.
De door de onderzoeker gebruikte exploit uit 2007 was dacht ik in de al een stuk minder voor de hand liggende animated cursor files. Ik weet niet of er sinds die tijd nog wel 1 bufferoverflow is ontdekt die eenvoudig te exploiteren was (behalve dan die in OS X).

Anonymous Coward op Maandag 11 Augustus 2008 17:45

image

Voor exploitatie op XP is dan bovendien nog nodig

dat moest natuurlijk Vista zijn ipv XP.

toiletpaper op Maandag 11 Augustus 2008 17:54

image

Nee, dat is op niet Vista OS'sen wel zo.
Jawel
Lees in het document ook de paragraaf met titel: "Statically positioned DLLs and executables" maar eens, daar wordt het spraying probleem duidelijk gelinkt aan native executables, er staan ook verschillende manieren tot "spraying" beschreven.
De meeste bufferoverflows zijn bijvoorbeeld vaak pas exploiteerbaar als je een gebruiker zover krijgt om een specifieke file te openen.
Er zijn veel manieren om een bufferoverflow te creëren, een file openen is een manier, een bulk gegenereerde data naar een te kleine buffer sturen een andere.
De term bufferoverflow betekent dat een buffer gekoppeld aan een pointer meer data verkrijgt dan er in past, en dan gaan de data overlopen naar een plaats in het geheugen, deze situatie kan exploitable worden indien er dan malicieuze executable data terecht komen in het geheugen
De door de onderzoeker gebruikte exploit uit 2007 was dacht ik in de al een stuk minder voor de hand liggende animated cursor files.
Dat was alleen maar een voorbeeld om de techniek uit te leggen.
Ik weet niet of er sinds die tijd nog wel 1 bufferoverflow is ontdekt die eenvoudig te exploiteren was (behalve dan die in OS X).
Wat is eenvoudig?

Deze eenvoudig genoeg, er zijn er stapels, het is gewoon onzin wat je kletst, en iedere keer wat meer.

January 9, 2008, 3:58 pm, Microsoft Windows XP, Windows Vista IGMP Buffer Overflow
of deze?
April 20, 2008, 12:06 am, Advisory: Subtitle Parsing Buffer Overflow Vulnerability in DivX Player

Honderden bufferoverflows, in MS applicaties, third parties applicaties, die allemaal in Vista kunnen optreden, en middels de nieuwe ontdekkingen ook schade code kunnen executeren, een kwestie van een ASLR omleiding routine schrijven

Anonymous Coward op Maandag 11 Augustus 2008 18:12

image

Je noemt wel voorbeelden van bufferoverflows die niet in het browser proces plaatsvinden en dus niet op de beschreven methode van de onderzoekers kunnen worden geexploiteerd.

Juist dergelijke bufferoverflows beschermen ASRL en DEP je nog wel tegen omdat dergelijke bufferoverflows onder de executie controle vallen van Vista zelf.

toiletpaper op Maandag 11 Augustus 2008 19:20

image

Juist dergelijke bufferoverflows beschermen ASRL en DEP je nog wel tegen omdat dergelijke bufferoverflows onder de executie controle vallen van Vista zelf.
Ik heb juist 25 keer uitgelegd dat je hier ongelijk in hebt.
Het is allemaal zo betrekkelijk. Maar ik zou zeggen lees, dat document nou, met dat hoofdstuk wat ik al 25 keer heb aangewezen. Als je nou zegt dat er iets fout staat in dat document ben ik erg benieuwd. Maar je negeert het gewoon volledig en blijft daarna bij je misverstand hangen.

Afgezien daarvan, de DivX speler kan middels een ActiveX best in het browserproces komen, in feite kan iedere executable via een ActiveX aangeroepen als child van de ActiveX, die als child van de Browser in het browser proces komt. Je weet toch wel dat de meeste ActiveX als inprocess draait?

Zelfde kan ook ook IGMP routines aanroepen via een activeX.

Natuurlijk telt dit alleen voor IE (andere browsers doen niet aan ActiveX), en speciaal voor IE7, omdat dit niet aan DEP doet.

Anonymous Coward op Maandag 11 Augustus 2008 21:54

image

Volgens mij verwar jij met een stuk uit het document genaamd "Statically positioned DLLs and executables" dat juist specifiek situaties beschrijft waarbij de ASRL bescherming van Vista niet actief is. Ofwel de sitatie in Windows XP of in Vista als er executables geladen zijn die niet ASRL enabled zijn.
Dat is dus juist een klassieke bufferoverflow situatie en niet een situatie waarin geheugen volgesprayd wordt.


Anonymous Coward op Maandag 11 Augustus 2008 23:22

image

Het document telt plusminus 50 pagina's hAl. Is het al bij je opgekomen dat die pagina's misschien OOK informatie bevatten? Of denk je dat je nu de vereenvoudigde samenvatting hebt?

Het is één van de aanvalsvectoren. Zoek maar eens in Google cache. Er gaat een wereld voor je open.

Anonymous Coward op Dinsdag 12 Augustus 2008 00:27

image

Het is één van de aanvalsvectoren.

Ja maar dat is geen nieuws. Er zijn altijd methoden om beveilingen te omzeilen.

Het nieuws aan het betreffende document met is een methode om bepaalde bufferoverflows te exploiteren ondanks DEP en ASRL technieken die bedoeld zijn om exploitatie van bufferoverflows te bemoeilijken.

toiletpaper op Dinsdag 12 Augustus 2008 00:30

image

bemoeilijken
Juist dat bemoeilijken is mislukt, want het wordt weer voorspelbaar waar de data uit de bufferoverflow staan, een kwestie van een routine schrijven en huplakee

Anonymous Coward op Dinsdag 12 Augustus 2008 08:25

image

Samengevat: Twee beveiligingspeilers van Vista zijn gekraakt! En dan is één van de twee nog wel één waar Microsoft zo trots op was.

Hopelijk is in Windows 7 het biggetje (Microsoft) eindelijk zo wijs om zijn huisje van stenen te bouwen. Ik ben het spuugzat dat de eerste de beste wolf het elke keer weer omblaast.

Anonymous Coward op Dinsdag 12 Augustus 2008 18:05

image

Samengevat: Twee beveiligingspeilers van Vista zijn gekraakt! En dan is één van de twee nog wel één waar Microsoft zo trots op was.

Ten eerst zijn de beveilings technieken niet gekraakt maar bestaan er situaties waarin ze omzeild kunnen worden. In die specifieke situaties waarbij bufferoverflows in een browsercontext aanwezig zijn werken ze niet maar daarbuiten werken ze nog wel.

Verder zijn beveiligingstechnieken die niet enkel specifiek zijn voor Vista maar ook in andere OS'sen worden toegepast.
DEP zit al enigzins in XP SP2 en de technieken gebruikt in ASRL en DEP zijn blijkbaar ook al in vergelijkbare vorm in bepaalde linux kernel patches aanwezig.

toiletpaper op Dinsdag 12 Augustus 2008 18:19

image

Ten eerst zijn de beveilings technieken niet gekraakt maar bestaan er situaties waarin ze omzeild kunnen worden.
omzeilen, kraken, what's the diff

Anonymous Coward op Woensdag 13 Augustus 2008 13:47

image

omzeilen, kraken, what's the diff
Dat de beveiling gewoon aanweizg is en correct functioneert.
De beveiling kan bijvoorbeeld nog omzeild worden omdat niet alle applicaites deze beveilingmethodes al gebruiken.
Dat is echter iets wat op Vista steeds minder wordt.
En bijvoorbeeld de 64 bits verise van Vista laat dat al helemaal niet toe.

Je kunt nu bijvoorbeeld DEP nog omzeilen als je in de browseromgeving van IE7 op Vista 32 bits een bufferoverflow hebt maar straks in IE8 kan dat ook al niet meer.

En dat is dan nog steeds dezelfde bevilinging. Als een beveiling gekraakt is dan zou het beveilingsmechnisme vervangen moeten worden. Dat is hier dus niet het geval. Het beveilingmehcanisma functioneert en naar mate het meer wordt toegepast wordt het steeds effectiever.

toiletpaper op Woensdag 13 Augustus 2008 14:07

image

De voordeur is op slot en kan niet gekraakt worden ( maar de achterdeur staat wagenwijd open, en iedereen kan vrij in en uit lopen (de gesloten voordeur omzeilen, dus) ).
Dan kan je wel zeggen dat de voordeur goed beveiligd is, maar je kan niet zeggen dat het huis goed beveiligd is, en ik neem aan dat het op slot doen van de voordeur is om het huis goed te beveiligen.


Anonymous Coward op Dinsdag 12 Augustus 2008 19:49

image

DEP zit al enigzins in XP SP2 en de technieken gebruikt in ASRL en DEP zijn blijkbaar ook al in vergelijkbare vorm in bepaalde linux kernel patches aanwezig.
Oh ja natuurlijk, als het in een ander OS zit is het niet meer erg als het in Vista omvalt. Die logica kan ik maar niet onthouden. =P

toiletpaper op Woensdag 13 Augustus 2008 14:13

image

ASRL en DEP zijn blijkbaar ook al in vergelijkbare vorm in bepaalde linux kernel patches aanwezig.
Onwaar, lees deze reactie: vrhn Thdr (-_-) 13-08-2008 12:44 (zoek op exec-shield)

Anonymous Coward op Maandag 11 Augustus 2008 14:52

image

Dit klopt niet, de conceptuele fouten in ASLR en DEP zijn niet gepatcht, en het is maar de vraag of ze gepatcht kunnen worden. Volgens mij heb ik dit al drie keer gezegd in deze thread, daarover gaat het allemaal.

Dat is niet noodzakelijk omdat er niets te patchen valt. Er is ook geen sprake van fouten die gepatched kunnen worden.
ASLR en DEP werken goed op het niveau waarbij het OS de executie controleert maar niet als het OS de executie van executable software overgeeft aan bijvoorbeeld een VM in een browser. Dat is een architecturele beperking van deze beveiligingsmethodes. Als Vista ook dan het geheugen beheer volledig zou controleren en dat niet aan Java over zou laten dan zou de virtual machine niet kunnen functioneren.

Het is wel oplosbaar maar dan moeten de applicaties als Java VM en misschien ook wel .net of flash worden gepatched of het OS moet dergelijke applicaties niet meer vrijwelijk gebruik laten maken van geheugen (waardoor met name java meteen waardeloos zou worden).


toiletpaper op Maandag 11 Augustus 2008 15:10

image

Dat is niet noodzakelijk omdat er niets te patchen valt. Er is ook geen sprake van fouten die gepatched kunnen worden.
Zo kun jhe het ook zeggen, ik zei al dat we het eens waren.
ASLR en DEP werken goed op het niveau waarbij het OS de executie controleert maar niet als het OS de executie van executable software overgeeft aan bijvoorbeeld een VM in een browser.

of .NET/Silverlight, of Flash, of een andere runtime met eigen geheugenbeheer, waardoor de protectiemechanismen van ASLR en DEP niet kunnen werken. Nu wil het geval dat dit soort runtime omgevingen steeds populairder worden, omdat dit veel voordelen heeft.
Platform-onafhankelijkheid, garbage-collection, geen pointers, etc. Hierdoor ontstaat veiliger software, die minder vaak crasht. programmeurs kunnen zich ook meer met de conceptuele architectuur bezighouden, en hoeven minder te "bytefucken".
Dat is een architecturele beperking van deze beveiligingsmethodes. Als Vista ook dan het geheugen beheer volledig zou controleren en dat niet aan Java over zou laten dan zou de virtual machine niet kunnen functioneren.
Je wijst wel zo handig naar Java de hele tijd, want dat is niet van MS (je laat jezelf kennen), we zullen gewoon ook .NET lezen elke keer dat je Java schrijft.
Het is wel oplosbaar maar dan moeten de applicaties als Java VM en misschien ook wel .net of flash worden gepatched of het OS moet dergelijke applicaties niet meer vrijwelijk gebruik laten maken van geheugen (waardoor met name java meteen waardeloos zou worden).
e zou eens het probleem in volle omvang moeten kunnen zien, want dat doe je nog steeds neit. Nog steeds beschouw je het als iets dat niets met MS te maken heeft, maar met Sun. het is gewoonweg vervelend om voortdurend jouw oogkleppen te moeten zien.
.NET en Flash en andere runtime omgevingen hebben allemaal dezelfde eigenschap, ze willen hun geheugen beheren voor hun deel-proces-prioriteit, thread-beheer, class-beheer, garbage-collection andere dingen.

Wanneer deze runtime omgevingen hun eigen procesruimte niet mogen indelen zoals ze dat willen, worden ze neit gelijk waardeloos, maar zullen ze wel stevig aan performance moeten inleveren, wat eventueel wel weer gerepareerd kan worden, dat kan ik niet overzien.

Ik neem aan dat deze runtime omgevingen zelf ASLR en DEP kunnen implementeren in hun proces-omgeving, en zo dit probleem voor hun eigen proces kunnen oplossen.
-------------
Maar ook buiten deze runtime omgevingen om kan ASLR worden uitgeschakeld door een malicieus proces, door de speelruimte van ASLR zo klein te maken dat geraden kan worden waar een bepaalde volgende geheugenlocatie wordt beschreven.

Anonymous Coward op Maandag 11 Augustus 2008 15:50

image

of .NET/Silverlight, of Flash, of een andere runtime met eigen geheugenbeheer, waardoor de protectiemechanismen van ASLR en DEP niet kunnen werken. Nu wil het geval dat dit soort runtime omgevingen steeds populairder worden, omdat dit veel voordelen heeft.
Platform-onafhankelijkheid, garbage-collection, geen pointers, etc. Hierdoor ontstaat veiliger software, die minder vaak crasht. programmeurs kunnen zich ook meer met de conceptuele architectuur bezighouden, en hoeven minder te "bytefucken".


Helaas is deze software dus maar zo veilig als de omgeving waarin het draait.
Als vista protectemechnismes zo veilig zijn dat juist dergelijke runtime omgevingen de belangrijkste aanvalvectoren bevatten zal dat heel slecht zijn voor dergelijk platforms. Normale executables krijgen nu dus al betere protectie dan webbased applicaties.
Deze aanvalsvectoren zijn juist zo gevaarlijk omdat ze eigenlijk aan de basis zitten van het cloud computing idee. Je valt niet meer het OS aan maar zoekt de grens waar de Os controle ophoudt en de controle in de cloud zit.
De malware gaat van het OS specifieke platform naar het OS onafhankelijke platform omdat de OS'sen steeds meer dichtgetimmerd zijn.

toiletpaper op Maandag 11 Augustus 2008 16:09

image

Dat klopt niet helemaal, want ook native executables kunnen bufferoverflows effectueren middels spraying-techniek. Zie citaat van Heise:
Eine weitere Technik soll in Vista die Ausnutzung von Buffer Overflows erschweren: Die Address Space Layout Randomisation (ASLR). Beim Laden eines Prozesses wählt Vista sowohl für den Code als auch für DLLs und Datenobjekte wie Stack und Heap nach Möglichkeit zufällige Adressen. Angriffstechniken, bei denen man Pufferüberläufe ausnutzt, um bestimmte bekannte Adressen anzuspringen, laufen so ins Leere. Dem begegnen die Hacker mit "Spraying"-Techniken: Sie duplizieren ihren Schadecode einfach über einen Speicherbereich von Hunderten von Megabyte. Auch wenn die Anfangsadresse zufällig ist, so gibt es doch nur einen gewissen Bereich, in dem sie liegen kann. Springt man ein paar Megabyte dahinter, dann wird man schon eine der Kopien des Schadcodes erwischen.

Dus de runtimes hebben last van niet functionerende DEP, en de native executables van ASLR die nutteloos wordt door "spraying"
------------
Ik denk dat het probleem van de runtimes kan worden opgevangen door dat ze zelf een soort van DEP implementeren. het probleem van de native executables (dit kunnen ook ActiveX zijn) lijkt mij moeilijker, want dat is iets wat binnen het OS moet worden opgelost, en ik zie niet zo snel een oplossing om ASLR te beschermen tegen "spraying". maar goed, er zijn duizenden anderen die hier ook over nadenken (sommigen om exploits te schrijven, anderen om het op te lossen)

Anonymous Coward op Maandag 11 Augustus 2008 16:25

image

want ook native executables kunnen bufferoverflows effectueren middels spraying-techniek

Dat lijkt me dus niet. Je kunt namelijk niet spontaan de geheugen tuimte van een applicatie vol sprayen. In het voorbeeld wordt dat juist specifiek gedaan door een VM binnen een applicatie. Deze VM heeft dynamisch geheugenallocatie en kun je vanbuiten af zover krijgen dat het geheugen van de browser volgesprayed wordt. Bij native applicaties kun je van buitenaf niet het Vista geheugen sprayen met executable code zoals je dat wel kan bij de browser als je die toestemming geeft om een java applet te laden.

Het is echter niet zo maar mogelijk om het regulier RAM geheugen van Vista of een andere OS te benaderen van buiten af. Native applicaties die het reguliere geheugen gebruiken hebben dus volstrekt geen last hiervan.
Juist die spraying methode werkt alleen door dat de runtime VM code in de browser het geheugen van de browser kan alloceren en vullen.

toiletpaper op Maandag 11 Augustus 2008 16:34

image

Dat lijkt me dus niet. Je kunt namelijk niet spontaan de geheugen tuimte van een applicatie vol sprayen
Deze menig komt niet voereen met wat de specialisten van Heise hierover zeggen. Ze spreken over: "Beim Laden eines Prozesses wählt Vista...."
Bij een java-applet spreek je niet over een proces, want het JavaVM is het proces, de applet is code die het proces uitvoert. Ook staat dit in een andere alinea dan die het probleem met runtime omgevingen bespreekt.

Lees in het document ook de paragraaf met titel: "Statically positioned DLLs and executables" maar eens, daar wordt het spraying probleem duidelijk gelinkt aan native executables, er staan ook verschillende manieren tot "spraying" beschreven.

Dus jouw mening staat dus wel een beetje eenzaam te midden van andere deskundigen

Anonymous Coward op Maandag 11 Augustus 2008 17:21

image

Ze spreken over: "Beim Laden eines Prozesses wählt Vista...."
Dat is in het Heisse artikel de beschrijving van ASLR en beschrijft niet van het volgooien van het geheugen
Er staat niet dat de spray techniek op willkeurige processen werkt. Dat is jou interpretatie.

De beschreven technieken in de PDF werken alleen in browser memory.
En er staat ook heel duidelijk in het stuk van Heisse dat een browsercomponent door middel van een bufferoverflow in het door java gealloceerde geheugen moet worden geleid.

toiletpaper op Maandag 11 Augustus 2008 17:44

image

Er staat WEL dat de spray techniek op native executables werkt. Het staat ook in het document.

Lees in het document ook de paragraaf met titel: "Statically positioned DLLs and executables" maar eens, daar wordt het spraying probleem duidelijk gelinkt aan native executables, er staan ook verschillende manieren tot "spraying" beschreven.

Anonymous Coward op Maandag 11 Augustus 2008 17:47

image

Ik heb het document niet meer en het is ook niet meer downloadbaar lijkt het.
Zovel ik me herinner waren de spraying technieken allen in het browserapplicatieproces gebaseerd.

Anonymous Coward op Maandag 11 Augustus 2008 17:51

image

Aangezien jij het document wel hebt kun jij misschien met een voorbeeld scenario uitleggen hoe je vanuit een remote situatie het geheugen volsprayt en hoe je dan daarachteraan een bufferoverflow in een native applicatie weet te generenen.

ArjenB op Maandag 11 Augustus 2008 20:11

image

Document gevonden. Extract onderaan de thread, ivm leesbaarheid.

toiletpaper op Maandag 11 Augustus 2008 16:38

image

Het is echter niet zo maar mogelijk om het regulier RAM geheugen van Vista of een andere OS te benaderen van buiten af
Voor een OS bestaat geen RAM, althans, dat zit heel diep, en dat speelt hier geen rol. We hebben het over proces-ruimte, die is virtueel toegekend aan een proces, en die hoeft zich fysiek niet in het RAM te bevinden, die hoeft fysiek zelfs niet eens te bestaan, dat ontstaat pas bij opvragen van een geheugenruimte.

ArjenB op Maandag 11 Augustus 2008 20:23

image

De bewuste paragraaf.

Statically positioned DLLs and executables

ASLR is only fully effective if everything in the process address space is randomized. If somecode or data remains at constant locations in memory, it become an appealing target when building exploits. The first and perhaps most obvious technique is to look for images that are mapped at their preferred image base in the address space. As detailed earlier in this paper, in the default configuration on Vista, only executables and DLLs that have the IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE flag set in the optional header will be randomized. In order for this flag to be set, the binaries must be built with Visual Studio 2005 SP1 and have the /DynamicBase option passed to the linker. Microsoft are quite diligent about doing so in the binaries shipped with the Vista operating system and most of their other products. However, Independent Software Vendors (ISVs) have been slower to adopt this option and as a result, many third-party binaries on a typical desktop are not protected by ASLR.
This style of attack is particularly attractive when targeting browsers, due to their plugin architecture. When a user visits a potentially malicious web page, there are quite a lot of opportunities to load a wide range of DLLs by employing techniques such as:
Instantiating ActiveX controls or plugins that the user is likely to have installed.
Utilizing specific features of the browser or its extensions that result in DLL loading - such as using specific scripting languages, or using specific features of these languages.
Specifying URL schemes that require protocol handlers that load in-process within the browser to deal with those special URLs.
Supplying input data that results in library loading to do some sort of special handling of a specific Content-Type.
Requiring associated metadata handling, such as dealing with security signatures/hashes within a mobile code package.
Requiring user authentication with an authentication mechanism that has its own library.
Embedding media of various types that require loading of specific libraries to parse the data (such as an image parser or a video codec).

Practically static objects

A slight variation of statically located objects is when data objects do not have a fixed location per se, but they can effectively be relied upon to exist in a certain region of memory. This situation is often a potential issue when a growable object exists in memory that can be grown to an arbitrarily large size by the user. This technique has been very popular in the last few years when dealing with heaps that exist in the process address space. Commonly referred to as "heap spraying" or "growing the heap", this technique essentially involves exhausting the regular space available and forcing the heap to grow to be much larger. Providing that allocations are somewhat linear and the the virtual address space is limited (such as in 32-bit processes on x86), it is possible to guess where some of that data will be mapped.
For example, the heap randomization on Windows Vista shifts the base of the heap by up to 2MB. If the attacker can allocate more than 2MB of data on the heap, they will be able to guess a
valid pointer into their data, regardless of the heap randomization.

Partial overwrites

A partial overwrite is a memory corruption technique where only the least significant 1 or 2 bytes of the pointer are modified. Performing overwrites of this nature can be effective in an ASLR
environment, since the attacker is not required to know the real address of an object in memory, but rather just the relative location of the new target from what the pointer pointed to originally.
Since all image randomization in Vista is performed only on the high bytes of an image address, the low two bytes will be the same regardless of where in memory the image is loaded.
This style of attack is a well-known and often utilized technique among security researchers and hackers, and has been in wide use for quite some time. It tends to be a particularly effective technique on little-endian platforms, since contiguous memory overwrites (such as standard buffer overflows) will corrupt the least significant bytes before the more significant bytes. One of the most well-known scenarios where this has been used in the past is when a single-byte ("offby-one") buffer overflow is discovered in an application that is writing to a stack buffer. This particular scenario is quite unlikely to be exploitable in many cases now due to security enhancements in compiler technology such as the /GS protection in the Visual Studio compiler.
In practice, the ability to perform partial ovewrite attacks is very dependent on the nature of the vulnerability - what is being overwritten, whether the attacker has precise control over how many bytes can be overwritten, whether the overwrite is contiguous, and what pointers are available to corrupt.

Memory information leaks

Finally, there are information leaks. An information leak vulnerability is one that allows the attacker to glean some useful information about the memory layout or some useful state
information about the target process. In the context of bypassing ASLR, ideally the attacker will want to obtain a pointer value. These are immensely useful for the following reasons:
A pointer can be used to determine where an object is mapped in memory. For example, a pointer to a stack gives away at least a portion of where a thread stack is in memory.
Also, a pointer to a static variable will betray the image base of a particular DLL or executable.
Additional information can be inferred from such a pointer. For example, a frame pointer to a stack frame not only tells the attacker where a thread stack resides, but if the attacker knows what function the stack frame is for, they are able to determine a great deal more about that thread's stack. They will know what data elements surround that frame pointer, as well as those from previous stack frames. For a data section pointer, they are able to determine where that image resides in memory, not just where a single data element is. Heap pointers will be useful in pinpointing exactly where a specific data
block was allocated, which could be useful for an application-specific attack.
In the context of Vista's ASLR, information leaks have an additional advantage. If an attacker is able to learn the location of an image in memory, then it follows that they will know the location of that DLL in not just that process, but for all processes running on the target system. Recall that a DLL's position in memory is initially determined by searching the _MiImageBitMap variable for an appropriate location, and this bitmap is used for all processes. So, finding a DLL in one
process effectively allows you to locate it in all processes.

Anonymous Coward op Maandag 11 Augustus 2008 21:49

image

Statically positioned DLLs and executables

Dat zijn dus specifiek objecten die niet beschermd zijn door ASRL omdat het OS geen ASRL kent of omdat de executables niet ASRL enabled zijn.
Zeg maar het klassieke bufferoverflow scenario.
En dat is inderdaad aantrekkelijk als je een browser zo ver krijgt automatisch een stuk uitvoerbare code weet te laden waarin zo'n overflow zit.
Met name in XP voor SP2 een favoriet aanvalsvector

Practically static objects
Dat beschrijft een een spray methode. Je moet dus eerst op een bepaalde manier een stuk geheugen volschrijven en dan moet je vervolgens nog zorgen dat je de applicatie dat stuk geheugen gaat gebruiken bijvoorbeeld dmv een bufferoverflow.





Anonymous Coward op Maandag 11 Augustus 2008 22:19

image

Commonly referred to as "heap spraying" or "growing the heap", this technique essentially involves exhausting the regular space available and forcing the heap to grow to be much larger.

Mooi voorbeeldje. Heap corruptie is mogelijk in exe files (niet in Dll's of activex objecten) en kan bijvoorbeeld worden gecreerd bij bufferoverflows als daarme toegang tot de heap wordt verkregen.
Dit is een techniek die echter juist op Vista en w2k8 makkelijk kan worden voorkomen. Vista 32 bits applicaties kunnen dit voorkomen door de HeapEnableTerminationOnCorruption aan te zetten. Het wordt ook door MS geadviseerd aan alle ISV's om dit aan te zetten aan te zetten voor vista executables.
In 64 bits applicaties (dus op 64 bits Vista) is dit trouwens default enabled en kun je dus niet de heap overschrijven want dan crashed een applicatie als de heap toch wordt overschreven.
Deze functies om een applicatie te termineren als er heap corruptie optreedt bestaan pas in Vista en w2k8. Applicaties kunnen zich daarmee beveiligen tegen de effecten van bijvoorbeeld bufferoverflows die de heap proberen te corrumperen en 64 bits applicaties op Vista 64 bits zijn daar dus sowieso tegen beveiligd.

Het gaat wel een beetje diep maar het omdat je het voorbeeldje uit het document toch tevoorschijn haalde was het misschien wel relevant om even aan te geven dat deze methode van applicatiecorruptie JUIST op Vista en w2k8 voor het eerst kan worden afgevangen door het OS.

Anonymous Coward op Maandag 11 Augustus 2008 23:16

image

Het gaat wel een beetje diep maar het omdat je het voorbeeldje uit het document toch tevoorschijn haalde was het misschien wel relevant om even aan te geven dat deze methode van applicatiecorruptie JUIST op Vista en w2k8 voor het eerst kan worden afgevangen door het OS.
Houd toch eens op met dit ontzettend domme gezwets! Heb je de titel van het artikel gelezen waar deze discussie is begonnen!? "Windows Vista security 'rendered useless' by researchers"

Wil dat door die verschrikkelijk dikke oogkleppen dringen!? Geloof je nou werkelijk dat die mannen alleen maar een pakkende openingszin zochten!?

Ik weet dat het je hobby is om Microsoft te verdedigen. Maar op deze manier? Denk je nu werkelijk dat er nog iets van je geloofwaardigheid over blijft? hAl die de wereld wel even in een paar uurtjes zal vertellen dat twee onderzoekers, die hier heel lang aan gewerkt hebben, het toch echt mis hebben?

Je bent het stadium lachwekkend voorbij. Ik begin nu echt het stadium plaatsvervangende schaamte te naderen. Wie wil er nu geassocieerd worden met de plaatselijke dorpsmaloot.

Zolang Microsoft concessies blijft doen aan veiligheid om iedereen maar blij te houden, blijft het een valse gatenkaas. Het feit dat ze nu weer DEP en ASLR hebben ingebouwd en het weer eens niet afdwingen. Kansloos! De kracht van de ketting zit in de zwakste schakel en Microsoft heeft dat na wat? 20 jaar? Ze hebben het nog steeds niet door!

Anonymous Coward op Maandag 11 Augustus 2008 23:56

image

Sorry hoor maar waar heb je het over.
Deze personen hebben gewoon een manier aan gegeven om bepaalde types buffer overflows te exploiteren in een browser ondanks dat de browser geladen is op Vista met ASLR en DEP.

Dat is wat deze researchers hebben gepubliceerd. Dat maakt een aanvalsvector die op Vista bijna was uitgeschakeld, namelijk de bufferoverflow, bijvoorbeeld in de browseromgeving nog steeds potentieel interressant om te exploiteren.

Is je dat niet duidelijk ?
Ik zeg dus helemaal niet dat deze mensen het mensen het mis hebben maar geeft ze juist gelijk dat dit een exploit methode is om bepaalde bufferoverflownog te kunne exploiteren.

Daarnaast staan in hun document nog talloze reeds bestaande technieken genoemd om bijvoorbeeld bufferoverflows te exploiteren
Bovenstaand voorbeeld van een heap overflow is een niet door deze reseachers ontdekte methode maar een reeds oude methode gebruikt als voorbeeld voor het vullen van grote geheugenblokken met specifieke exploit code. Voor het specifiek gekozen voorbeeld echter, de heap overflow, is juist een nieuwe setting geintroduceerd waardoor applicaties getermineerd worden als je over de heap heenschrijft. Een setting nieuw voor Windows vanaf Vista en w2k8 en afgedwongen op Vista 64 bits.

Ik heb overigens wel het artikel gelezen met de vette kop maar ik had ook al het heise artikel gelezen dat veel genuanceerder weergeeft was de echte situatie is. Jammer dat jij je door een dergelijk kop laat verleiden tot een dergelijk emotionele uitval.

De belangrijkste bevinding van de researchers namelijk de exploit methode van bufferoverflows vereist logischerwijs nog steeds makkelijk te exploiteren bufferoverflows in de browseromgeving om effectief een grote rol te spelen in securityproblemen. 5 jaar geleden een eitje omdat er elke week wel 1 gevonden werd maar tegenwoordig zijn ze een stuk zeldzamer of ze zijn niet automatisch te exploiteren maar vereisen extra userhandelingen.

Zolang Microsoft concessies blijft doen aan veiligheid om iedereen maar blij te houden, blijft het een valse gatenkaas. Het feit dat ze nu weer DEP en ASLR hebben ingebouwd en het weer eens niet afdwingen

Boeiende opmerking maar DEP breekt JIT compilerende applicates en kun je dus eigenlijk niet afdwingen en ASRL kun je theoretisch wel afdwingen maar dan werken bijvoorbeeld XP applicaties niet meer op Vista. Dat is echter verder niet zo boeiend tav dit onderwerp want de onderzoekers geven juist een methode om ASRL te omzeilen (dus als het wel wordt gebruikt op Vista). Als ASRL uitstaat of op windows XP kun je heb je statische dll en executables en heb je een dergelijk methode niet nodig en werken de conventionele bufferoverflow methoden.

Anonymous Coward op Dinsdag 12 Augustus 2008 08:20

image

Samengevat: ZWETS!

Anonymous Coward op Dinsdag 12 Augustus 2008 09:36

image

tuurlijk joh.
Je geeft blijk er zelf geen zak van te snappen en achter wat sensatiekoppen aan te rennen maar wat anderen zeggen kun je wel afdoen als gezwets.
Wat een zwakte bod dat je niet op argumenten wilt discussieren.

Andere keer beter dan maar.

Anonymous Coward op Dinsdag 12 Augustus 2008 11:12

image

Als ik argumenteer dan luister je niet. Als ik niet argumenteer is het een zwaktebod. Hoe dan ook ik kan het niet goed doen, omdat jij alle wijsheid in pacht hebt. Waarom moet ik discuteren als jij toch niet open staat voor andere argumenten dan die van jezelf?

toiletpaper op Dinsdag 12 Augustus 2008 00:10

image

activex objecten
Eena ctoiveX object kan een exe-file zijn, bijvoorbeeld, IE is ook een activeX-object

toiletpaper op Dinsdag 12 Augustus 2008 00:10

image

acrobat reader ook

Anonymous Coward op Dinsdag 12 Augustus 2008 07:22

image

Speciaal voor Theodoor en ArjanB die het idee hebben dat de onderzoekers bevindingen niet specifiek zijn voor de browseromgeving maar voor heel Vista en voor Peter die denkt dat ik niet begrijp waar ik het over heb, wat aanvullende informatie van een van de researcher zelf.

am one of the authors of the paper referenced in the post above. First of all, I'd like to apologize for the sensationalism of the press coverage. Most of the articles about our work are completely inaccurate and full of ridiculous statements. Mark and I had nothing to do with these articles and were not contacted by their authors.

Please read our slides and paper (available from http://taossa.com/) before making any judgements about their content.

What we've done is show that the exploitation prevention mechanisms implemented in Windows Vista (including DEP and ASLR) are ineffective at preventing the exploitation of browser memory corruption vulnerabilities, due to the following factors:

1) the amount of contol an attacker has over the state of the browser process

2) the plugin architecture that allows third party plugins (Java, Flash, Acrobat) which often weaken these protections

3) the architecture of the browsers which run all code in the same process and have no isolation between different components

Our research is focused only on browsers. The protection mechanisms in Vista are still effective at preventing the exploitation of vulnerabilities in server processes, which is why I believe that Vista is still more secure than any previous version of Windows.

Posted by: Alexander Sotirov at August 11, 2008 6:59 PM


De onderzoeker zelf zegt dus zelf dat de berichtgeving vooral sensatie is veelal niet correct en zegt ook nog eens letterlijk dat hij nog steeds vind dat VIsta veiliger is dan alle voorgaan windows versies. Die uitspraak zal ik de volgende keer in de eindeloze discussies nog wel een paar keer moeten aanhalen denk ik.

@Peter
Wil dat door die verschrikkelijk dikke oogkleppen dringen!? Geloof je nou werkelijk dat die mannen alleen maar een pakkende openingszin zochten!?

Inderdaad, ik vind de vette koppen puur overdreven en de onderzoeker zelf geeft mij gewon gelijk

Je bent het stadium lachwekkend voorbij. Ik begin nu echt het stadium plaatsvervangende schaamte te naderen. Wie wil er nu geassocieerd worden met de plaatselijke dorpsmaloot.

Dat mijn woorden in bovenstaand discussie vrijwel lettelijk bevestigd worden door de betreffende onderzoeker zelf vind ik wel ok en niet lachwekkend dus ik negeer je uitval maar als zijnde een vlaag van verstandsverbijstering.
Misschien moet je perskoppen over Vista wat minder letterlijk nemen en wat meer zelf nadenken om tot een wat meer genuanceerd beeld te komen ipv van te proberen mij belachelijk te maken omdat ik het niet met die vette koppen eens ben om er dan achter te komen dat mijn beeld van de situatie echt volledig wordt bevestigd door de betreffende onderzoeker zelf.

Anonymous Coward op Dinsdag 12 Augustus 2008 08:18

image

DAAR GAAT HET NIET OVER!!!

Het zal me roesten of Vista veiliger is! Het is niet veilig genoeg!

De titel van het artikel is: "Windows VISTA security 'rendered useless' by researchers"

Jij doet niet anders dan dat met gelul en afleidingsmanoeuvres proberen af te zwakken. Het kan me niet schelen of Vista veiliger is dan mijn eigen moeder. Het is niet veilig genoeg omdat twee peilers van die beveiliging gebroken zijn.

Inderdaad, ik vind de vette koppen puur overdreven en de onderzoeker zelf geeft mij gewon gelijk
Hij geeft jouw helemaal niet gelijk. Jij beweert hier bijna ijskoud dat die onderzoeker uit zijn nek staat te kletsen. Ik gok toch echt dat hij dat niet met je eens is. Al moet ik bekennen dat hij bij het lezen van de onzin die jij uitkraamt waarschijnlijk alleen maar meewarig zijn hoofd zal schudden.

En hAl laat duidelijk zijn dat IK je niet belachelijk probeer te maken. Ik heb iemand die dat veel beter kan. Iemand die jouw elke ochtend aankijkt in de badkamer als je je tanden staat te poetsen. Ik acht je zeer capabel om jezelf belachelijk te maken, daar heb je echt mijn hulp niet bij nodig.

... volledig wordt bevestigd door de betreffende onderzoeker zelf.
Dus die onderzoeker heeft een mooi stukje fictie schreven voor 'Black hat'? En jij durft nog steeds te beweren dat je niet uit je nek kletst?

Anonymous Coward op Woensdag 13 Augustus 2008 11:15

image

Jij beweert hier bijna ijskoud dat die onderzoeker uit zijn nek staat te kletsen.
Nee, ik beweer dat hij volkomen gelijk heeft over zijn exploit methodes die in bepaalde situaties bufferoverflows vereenvoudigen maar ik nuanceerd dat door te zeggen dat wat hij zegt niet meteen de Vista onveilig maakt.


Jij beweert hier bijna ijskoud dat die onderzoeker uit zijn nek staat te kletsen.

Degene die uit zijn nek staat te kletsen ben jij.

Binnenkort komt IE8 uit met DEP enabled en dan is deze nieuwe methode in 1 keer al weer een stuk minder nuttig. En dat is dan nog steeds door de hier genoemde beveilingsmechnismen in Vista.
En naar mate meer en meer applicaties deze beveiligingsmechanisames bij het compileren aanzetten zal de omgeving van Vista ook nog iets veiliger worden.

Anonymous Coward op Woensdag 13 Augustus 2008 12:41

image

Ik ga maar weer eens hameren:
Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al critical vunerabilities voor nodig hebt om deze methode toe te passen.
Voor mij is dit zo dichtbij als je kunt komen bij het in diskrediet proberen te brengen van de onderzoekers.

Het feit dat je IE8 alweer inzet om de aandacht af te leiden, toont aan dat je weet dat je discussie verloren hebt. Het bijstellen van de parameters is weer begonnen.

Anonymous Coward op Woensdag 13 Augustus 2008 14:02

image

Hoezo breng ik iets in diskrediet als ik kritisch kijk naar wanneer deze nieuw gevonden exploitatie methode eigenlijk daadwerklijk toegepast kan worden.

Suggereer je nou dat ik daarin geen gelijk heb ?
Kun je volgens jou deze methode effectief toepassen zonder te beschikken over een remote exploiteerbare bufferoverflow in de browseromgeving ?

Ik vind het juist heel valide om kritisch dergelijk analyses te benaderen.



toiletpaper op Woensdag 13 Augustus 2008 14:17

image

Hoezo breng ik iets in diskrediet als ik kritisch kijk naar wanneer deze nieuw gevonden exploitatie methode eigenlijk daadwerklijk toegepast kan worden.
Twijfel je daaraan?
Dat is dan een nieuw standpunt in de discussie, wat in tegenspraak is met vele andere uitspraken van je zelf
Want dan twijfel je dus ook aan de tekst van Sotirov en Dowd ("de onderzoeker"), diez eggen dat een dergelijke aanval wel mogelijk is.

Anonymous Coward op Woensdag 13 Augustus 2008 20:54

image

Nee, ik twijfel er niet aan maar als deze methode in de praktijk weinig toegepast kan worden is het risico dat er gebruikt van gemaakt wordt beperkt.
Zeker als je bedenkt dat ook de beveiling van excutables op Vista nog steeds toeneemt.

toiletpaper op Woensdag 13 Augustus 2008 22:45

image

wishful thinking, ik zie geen enkele reden waarom je gelijk zou hebben. iedere aanvalsvector is er een, en dit is er een, en ook nog een krachtige. De complexiteit is makkelijk te overwinnen, Sourcefiles hiervoor zullen nu al in de kringen circuleren.

Anonymous Coward op Woensdag 13 Augustus 2008 14:35

image

Het is een feit dat bufferoverflow exploits gevonden worden, daar hoeven we niet over te discuteren. Jij kan dat ontkennen, maar de praktijk wist keihard anders uit. Het is niet een vraag van 'of' maar van 'wanneer'.

In dat licht is de twijfelen aan het toepasbaar zijn van de gevonden methoden heel twijfelachtig. Maar ik begrijp het alweer, zo heb jij het nooit gezegd. De punt die je er aan zuigt wordt steeds dunner.

toiletpaper op Dinsdag 12 Augustus 2008 08:23

image

de onderzoeker zelf geeft mij gewon gelijk
Jij bent zijn mening toegedaan, niet andersom.

Of hij jou gelijk geeft is maar de vraag, want dan zou je alles wat je hier ehbt gezegd aan hem moeten voorleggen en vragen of hij het daar mee eens is.

Ik vraag me af waarom je dat zo persoonlijk formuleert, en niet gewoon kunt laten bij het feit dat je in bepaalde opzichten in deze discussie gelijk hebt, zonder de persoon van de onderzoeker in een niet bestaande relatie tot jou erbij te betrekken?

Vergeet immers niet dat je in bepaalde andere opzichten in deze discussie ook ongelijk hebt.

Dus laat de persoon van de Sotirov buiten beschouwing en heb het over de argumenten.

SED zei het gisteren nog, discussie gaat over argumenten niet over personen.

Anonymous Coward op Dinsdag 12 Augustus 2008 08:34

image

Sorry maar voor nij gaat deze discussie vrij duidelijk wel om personen.

Een persoon die probeert de discussie te verzieken met stompzinnigheden als "Het ANI lek is al lang gepatched, dus zal het hele onderzoek wel onzin zijn."

Om zich aan het einde trots op de borst te kloppen als de onderzoeker in één regeltje in elk geval nog iets beweerd wat in zijn kraampje past.

De totale stupiditeit die hAl aan de dag legt bij zijn verdediging van Microsoft is ronduit stuitend.

Webwereld zal in de loop van de dag deze reacties wel als ongewenst betitelen, maar voor mij is de grens bereikt. Ik wil het gezegd hebben.

toiletpaper op Dinsdag 12 Augustus 2008 08:51

image

Rustig maar, rustig maar. Ik schreef ook al dat wanneer Sotirov hem gelijk wil geven, hij eerst kennis moet nemen van alle argumenten die hij gebezigd heeft. Maar of Sotirov ooit kennis daarvan zal willen nemen waag ik ernstig te betwijfelen.

Feit is dat hAl in bepaalde opzichten dezelfde mening is toegedaan als Sotirov, en in andere opzichten niet. Maar dat had ik op die momenten al gezegd, over dat ANI-lek bijvoorbeeld.

Anonymous Coward op Dinsdag 12 Augustus 2008 09:06

image

De aanval is niet op jouw gericht, je stond alleen toevallig vooraan. Sorry.

toiletpaper op Dinsdag 12 Augustus 2008 09:18

image

zo had ik het ook niet opgevat

Anonymous Coward op Dinsdag 12 Augustus 2008 09:18

image

Een persoon die probeert de discussie te verzieken met stompzinnigheden als "Het ANI lek is al lang gepatched, dus zal het hele onderzoek wel onzin zijn

Ik heb dat zeker niet gezegd.
Wel relevant is dat de bevindingen dan het onderzoek zijn gebaseerd op misbruiken van ongepachte bufferoverflows in browsergerelateerde elementen en dat men daar voor een oud lek heeft gebruikt om te demonstreren.
Dat is reelvant in die zin dat de suggestie gewekt door de toonzetting bepaalde artikelen suggereert alsof je nu zo maar Vista zou kunnen aanvallen op basi va de uitgewrkte bevindingen van het betreffende onderzoek. Dat is een onjuiste veronderstelling want je hebt dus wel degelijk aanvullend nog een groot kritisch lek in bepaalde via de browser bereikbare software nodig. En dat is niet zo evident.

Volgens mij ben jij de persoon die op de man speelt door met de sensatie koppen te gaan in het rondslaan en nu ik laat zien dat ook de onderzoeker zelf deze koppen flauwekul vindt kan ik rustig aangeven dat ik jou vertrouwen in dergelijke sensatie journalistiek vindt getuigen van zwakheid. Je hebt blijkbaar zelf onvoldoende kennis van het onderwerpt maar vertrouwt volledig op de zwaar overdreven sensatie headlines en beschouwt dat vervolgens maar als een reden om mij persoonlijk te beledigen. Nu je gewezen ben op hoe fout die headlines eigenlijk zijn probeer je het op een andere boeg door te suggereen dat ik dingen heb gezegd die die ik duidelijk niet heb gezegd. Een discussie stijl waar ik sowieso al ernstige bezwaren tegen heb.

toiletpaper op Dinsdag 12 Augustus 2008 09:37

image

"Een persoon die probeert de discussie te verzieken met stompzinnigheden als "Het ANI lek is al lang gepatched, dus zal het hele onderzoek wel onzin zijn"

Ik heb dat zeker niet gezegd.
Wel relevant is dat de bevindingen dan het onderzoek zijn gebaseerd op misbruiken van ongepachte bufferoverflows in browsergerelateerde elementen en dat men daar voor een oud lek heeft gebruikt om te demonstreren.


ik citeer hAl, van eerder uit de discussie

Zo werkt in het stuk geschreven door deze onderzoekers met een reeds critical geachte vunerability (CVE-2007-0038) die al bijna anderhalf jaar geleden is gepatched in Vista. Zij geven dus testresutaten van een volledig ongepatchte Vista.

Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al critical vunerabilities voor nodig hebt om deze methode toe te passen.

toiletpaper op Dinsdag 12 Augustus 2008 09:39

image

Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al critical vunerabilities voor nodig hebt om deze methode toe te passen.
let op de grammaticale fouten en vergissingen die de zin meerdere betekenissen geven. Ik denk dat dit bedoeld was

Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al gepatchte critical vunerabilities voor nodig hebben om deze methode toe te passen.

toiletpaper op Dinsdag 12 Augustus 2008 10:03

image

hAl plaatste het commentaar van Sotirov 2 maalin deze thread, zonder bronvermelding. Hij was natuurlijk bang dat het anders gemist zou worden in de discussie, want discussies op Webwereld zijn vaak onleesbaar vanwege de lengte, en de onplezierige toon die wordt gebezigd.

Slechts weinig mensen lezen de commentaren, wanneer deze het aantal van pakweg 25 overtreffen. Enkelen zullen snel er doorheen scrollen en hier en daar wat oppikken, en drie of vier lezen alles.

Maar om die enkelen te raken is het goed om je reactie twee keer te plaatsen, dat is wat hAl dan ook doet. Leuk, maar eigenlijk worden de discussies hierdoor nog meer onleesbaar, want wie gaat een lange thread lezen, als die ook nog vol herhalingen staat?


Ik dwaal af, ik was nieuwsgierig naar de bron van hAl's citaat van Sotirov die hij consequent "de onderzoeker" noemt.
Het kostte wat googelen, maar ik heb het gevonden
http://www.schneier.com/blog/archives/2008/08/bypassing_micro.html#comments

Waarschijnlijk zal Sotirov dit elders herhalen, want anders is het wel dunnetjes, om ergens verstopt op een blog een belangrijke mededeling te doen. Op hun eigen website is sinds gisteren niets veranderd, en wordt er geen poging gedaan, om de volgens Sotirov overspannen reagerende pers te weerspreken.

Ik heb daarna de slides gelezen, ze zijn zeker interessant, de conclusie :

Vista memory protections are ineffective at preventing browser exploitation
– Large degree of control attacker has to manipulate process environment
– Open plugin architecture
– Single point of failure

Anonymous Coward op Dinsdag 12 Augustus 2008 11:13

image

Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al gepatchte critical vunerabilities voor nodig hebben om deze methode toe te passen.

Met die verduidelijking kan ik wel leven ja.

Ik vind dat erzeer overdreven gereageerd op het betreffende ondezoek. Bufferoverflows zijn zelfs op het niet met ASLR beveiligde XP in de laatste jaren al veel minder belangrijk geworden.

toiletpaper op Dinsdag 12 Augustus 2008 11:21

image

Eentje is genoeg om een computer onderdeel van een botnet te laten worden, vergeet niet dat verouderde doch "signed and legal" activeX objecten vulnerabilities kunnen hebben, en veel mensen weigeneren een ActiveX niet als deze van MS afkomt, of van Adobe, en signed by Verisign of Microsoft.

Veel mensen hebben aanstaan dat ActiveX van een bepaalde provider altijd vertrouwd mogen worden, want anders werkt je Windows Update bijvoorbeeld niet zo lekker (om maar een dwarsstraat te noemen)

toiletpaper op Dinsdag 12 Augustus 2008 11:24

image

Ik vind dat erzeer overdreven gereageerd op het betreffende ondezoek. Bufferoverflows zijn zelfs op het niet met ASLR beveiligde XP in de laatste jaren al veel minder belangrijk geworden.
Nu ja, veel mensen denken dat ze veilig zijn in Vista, met al die beveiligingspeilers, maar dat is dus niet altijd waar. Ik vind die aandacht niet overdreven, er is gewoon een complete aanvalsvector bijgekomen, een die niet zomaar valt te stoppen met een lapmiddeltje. Er is wel degelijk iets ernstigs aan de hand. Ontkennen is struisvogeltactiek, in mijn opinie.

toiletpaper op Dinsdag 12 Augustus 2008 11:31

image

Twee voorbeeldjes, bij de allereerste links op Google:
Resultaten 1 - 10 van circa 298.000 voor activex bufferoverflow (0,35 seconden)

Microsoft SQL Server sqldmo.dll ActiveX Buffer Overflow Vulnerability
To exploit this issue, an attacker must entice an unsuspecting user to access a malicious webpage.

Trend Micro OfficeScan ActiveX Buffer Overflow Issue
A temporary workaround has been identified for this issue. Administrators may set the kill bit to prevent the objRemoveCtrl from running in Internet Explorer.
For more information, please read the following information from Microsoft:
How to stop an ActiveX control from running in Internet Explorer
Om je te beschermen moet je de registry bewerken, dat zie ik mijn zus nog niet doen.

Anonymous Coward op Dinsdag 12 Augustus 2008 17:53

image

Vreemd, ik disable activex controls gewoon in de add-on manager van IE7.
maar als je lekeer in de registry wilt prutsen is dat ook goed hoor.

En verder lijk me een bufferoverflow in een sql server activex object nauwelijk een zinvol doen om te exploiteren.
Het lijkt me een knappe prestatie al je willekeurige bezoekers van je site zover krijgt mensen zover krijgt om deze Activex SQL control te laden.

Wat je nodig hebt voor massa exploitatie is een bufferoverflow in ofwel een browsercomponent zelf ofwel in een browser plugin die bijna iedereen heeft die iedereen heeft zoals flash of acrobat reader.

Je hebt eigenlijk vrijwel niets extra's aan bufferflows in componenten of plugins waarvoor een gebruiker eerst toestemming moet geven voor installatie/gebruik. Als je gebruikers zover krijgt om je software te downloaden/draaien dan heb je geen bufferoverflow aanvallen nodig maar gebruik je toch gewoon een kant en klare trojan.

toiletpaper op Dinsdag 12 Augustus 2008 18:21

image

Vreemd, ik disable activex controls gewoon in de add-on manager van IE7.
maar als je lekeer in de registry wilt prutsen is dat ook goed hoor.

Ik heb het over een advies van MS.

Anonymous Coward op Dinsdag 12 Augustus 2008 18:34

image

Ik zou kiezen voor het advies in de windows help voordat ik een knowledge base artikel zou raadplegen
windowshelp.mic...7e1033.mspx#EZG

toiletpaper op Dinsdag 12 Augustus 2008 19:46

image

Maakt me niet uit wat jij doet, het gaat erom wat MS op zijn web aanbeveelt, er zullen duizenden mensen dit klakkeloos opvolgen

toiletpaper op Dinsdag 12 Augustus 2008 19:54

image

trouwens, de meeste mensen weten niet eens wat een ActiveX control is, en zullen ze gewoon doorlaten, zeker als ze van MS of Adobe of een ander groot bedrijf zijn. En daarin zit de onveiligheid, want zo kan er een buferoverflow ontstaan die tot executable code kan leiden onder de rechten van de current-user, als dat administrator is dan is dat zo.

Anonymous Coward op Dinsdag 12 Augustus 2008 23:12

image

Maakt me niet uit wat jij doet, het gaat erom wat MS op zijn web aanbeveelt

Inderdaad. Maar jij beschouwt blijkbaar een knowledge base artikel als een aanbeveling.
Ik niet. Het beschrijft inderdaad een generieke oplossing om activex opjecten in Internet Explorer te disablen die werkt op meerdere versies van IE en op meerdere versies van windows. Feitelijk is er dus niks mis mee maar het een knowledge base artikel is niet een artikel met aanbevelingen voor normale gebruikers maar een informatie bron voor ICT'ers

Het is echter in IE7 en hoger mogelijk om dat in de browser add-on doen en de Windows help (ja windows help vindt ik wel voor normale gebruikers) geeft dat ook aan als methode.

toiletpaper op Woensdag 13 Augustus 2008 00:11

image

Inderdaad. Maar jij beschouwt blijkbaar een knowledge base artikel als een aanbeveling.
Helemaal niet, ik heb het niet over mij, maar over mensen in het algemeen.
De meeste mensen weten niet wat een ActiveX is, en zullen nooit op het idee komen deze te deleten of disablen.
Laat maar zitten, ik heb er niks aan toe te voegen aan wat ik reeds heb gezegd

toiletpaper op Woensdag 13 Augustus 2008 00:11

image

Dit is wat ik bedoel:
En daarin zit de onveiligheid, want zo kan er een buferoverflow ontstaan die tot executable code kan leiden onder de rechten van de current-user, als dat administrator is dan is dat zo.

Anonymous Coward op Dinsdag 12 Augustus 2008 20:17

image

Op zoek naar de add-on manager in de Nederlandse versie van Internet Explorer 7. Ik denk dat mijn arme buurvrouw nog liever regedit start omdat die hulppagina in elk geval in het Nederlands is.

En dan zoekt zij natuurlijk naar: "Uitvoering van ActiveX in Internet Explorer stoppen" want "Uitvoering van invoegtoepassing in Internet Explorer stoppen" levert zoals wel vaker bij Microsoft niets begrijpelijks op.

Anonymous Coward op Woensdag 13 Augustus 2008 00:24

image

Als ik in Nederlandse vista versie in de help "Uitvoering van invoegtoepassing in Internet Explorer stoppen" intik dan krijg ik wel degelijk een behoorlijk aantal hits over IE en invoegtoepassingen waar bij ook de juist info aanwezig is in de veelgestelde vragen mbt invoegtoepassingen.

Wat jij dus precies doet is me onduidelijk.

flauwe opmerking over de engelstalige link. Dat ik een Engelstalige help pagina link gaf komt omdat ik de tekst vanuit de engelstalige helppagina uit de Vista help in google heb gebruikt om de betreffende on line help pagina erbij te zoeken. De helppagina's van Vista staan namelijk ook gewoon on line.

In je Nederlandse vista versie is de helppagina natuurlijk in het nederlands.
Ik kijk nu eerst even in de Vista help en zoek even op "invoegtoepassingen uitschakelen" en zie dan een veelgestelde vragen pagina waar alle nodige info opstaat. (on line versie van de vista help pagina)

Anonymous Coward op Woensdag 13 Augustus 2008 08:20

image

Google hAl.

Anonymous Coward op Woensdag 13 Augustus 2008 14:07

image

Wat jij wil.
Ik denk dat normale gebruikers misschien eerst in hun help functie zullen kijken.
Maar google werkt ook redelijk hoor:
www.google.nl/s...n&meta=

toiletpaper op Woensdag 13 Augustus 2008 14:21

image

Ik heb nog nooit iemand over "invoegtoepassingen" horen praten, behalve die Zuid Afrikaan die MS teksten naar het Nederlands vertaalt.

Mijn neef weet het al helemaal niet, en die is toch een beetje het model waarvoor het gebruiksvriendelijke Windows is bedacht.

Zij is dan ook een potentieel slachtoffer van bufferoverflows die tot executable code kunnen leiden, waardoor een computer in enkele seconden onderdeel wordt van een botnet, alleen door een bepaalde website te bezoeken, waar hij op zoek gaat naar warez en dergelijke ongein.

toiletpaper op Woensdag 13 Augustus 2008 14:24

image

en nu kun je WareZ wel afkeren omdat het illegaal is, ik doe dat ook, maar als je dan bedenkt dat de meest fanatieke MS-fanboys zonder enige schaamte toegeven illegaal MS software te draaien, dan krijgt een dergelijke afkeuring bij sommigen toch wel iets hypocriets over zich heen.

Ik denk dan ook dat veel mensen die illegale Office-versies draaien geen morele bezwaren tegen WareZ hebben en dus potentiële slachtoffers zijn van een bufferoverflow op een of andere duistere website waar CrackZ worden aangeboden

Anonymous Coward op Woensdag 13 Augustus 2008 14:40

image

Ik denk dat de meeste gebruikers inderdaad eerder naar Google grijpen ja.

Anonymous Coward op Dinsdag 12 Augustus 2008 20:03

image

Inderdaad het eerste resultaat op Google. En nog wel een advies van Microsoft zelf. Dat hAl daarop kritiek durft te hebben. Het komt rechtstreeks van de hoogste instantie.

Anonymous Coward op Dinsdag 12 Augustus 2008 09:49

image

Goh, het staat er, maar dat heeft hAl vast niet gezegd. dat was vast zijn slechte alter ego.

Anonymous Coward op Dinsdag 12 Augustus 2008 11:23

image

Dat het ANI lek geptached is in 2007 is een feit. daar kunne we niet omheen en ik wil daar zeker wel bevesitgen dan ik at heb gezegd en ook de link met daarin het security bulletin van MS hieboven hebt geplaatst
Echt jou volgende interpretatie
dus zal het hele onderzoek wel onzin zijn
is onzin. Dat heb ik niet gezegd. Dat zijn jou woorden.
Ik heb zelfs het onderzoek bevestigd en resultaten proberen te verduidelijken.



Anonymous Coward op Dinsdag 12 Augustus 2008 11:54

image

Oei, sneaky... We gaan met woordjes goochelen.

Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen.

Je zegt het niet letterlijk. Maar die suggestieve woordkeuze... Dat neerbuigende toontje... Wat weet die onderzoeker nou, of niet hAl?

Maar ik begrijp dat ik je vanaf nu letterlijk moet quoten. Want de algehele strekking, dat heb je nooit gezegd.

Anonymous Coward op Dinsdag 12 Augustus 2008 17:10

image

ik ziou het niet letterlijk en er was ook geen sprake van een neerbuigend toontje.
Ik zei namelijk wel letterlijk toen ik aangaf dat de onderzoekers een oude bug hadden gebruikt:
Zo werkt in het stuk geschreven door deze onderzoekers met een reeds critical geachte vunerability (CVE-2007-0038) die al bijna anderhalf jaar geleden is gepatched in Vista. Zij geven dus testresutaten van een volledig ongepatchte Vista. Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al critical vunerabilities voor nodig hebt om deze methode toe te passen. Het lijkt erop dat het wel zo is dat het makkelijker wordt om een bufferoverflow te exploiteren (wat op vista dus relatief heel moeilijk is) maar het is hiermee niet makkelijker om aan dergelijke bufferoverflows te komen

Ik bevestig dus duidelijk dat het onderzoek exploitatie van bepaalde bufferoverflow makkelijker maakt en zei dus niet dat het hele onderzoek onzin is zoals jij beweerd.
Ook zie ik in de reactie geen neerbuigend toontje.

Anonymous Coward op Dinsdag 12 Augustus 2008 19:58

image

Het is dus dus maar de vraag of deze methode ook inderdaad enig significant extra risico gaat betekenen qua veiligheid als de onderzoekers er nu al critical vunerabilities voor nodig hebt om deze methode toe te passen.
Dan zal het aan je belabberde taalbeheersing liggen dat ik niet meer tussen de spelfouten door kan lezen. Wat betekent het bovenstaande kunststukje dan volgens jouw? Ik lees daar dat jij de onderzoeksresultaten bagatelliseert omdat de onderzoekers er nu al "critical vunerabilities voor nodig hebt." In mijn woordenboek betekent dat, dat je het onderzoek probeert af te doen als een flutonderzoekje.

Anonymous Coward op Woensdag 13 Augustus 2008 00:41

image

Je vind het niet relevant dat de methode die deze onderzoekers presenteren volledig afhankelijk is van de aanwezigheid/beschikbaarheid van ongepatchte remote exploiteerbare bufferoverflow vunerabilites.
Zonder dergelijk beschikbaare bufferoverflow in een browsergerelateerde toepassing geen toepassing van de nieuwe exploit methode.

Ik vind dat geen kinderachtige voorwaarde.

Ik bagatelliseer helemaal de methode van deze onderzoekers niet. Ik onderschrijf deze.
Maar ik geef wel aan dat de randvoorwardes die je nodig hebt om deze exploit methode toe te passen niet zo maar wat zijn. Je kunt niet zo maar remote exploiteerbare buffer overflows op Vista uit je mouw toveren en het wordt nog veel lastiger als je er een nodig hebt die explioteerbaar is in de browsers van willekeurig websurfers.

toiletpaper op Woensdag 13 Augustus 2008 00:57

image

Je kunt niet zo maar remote exploiteerbare buffer overflows op Vista uit je mouw toveren en het wordt nog veel lastiger als je er een nodig hebt die explioteerbaar is in de browsers van willekeurig websurfers.
Het woord willekeurig is in deze context zonder betekenis en kan gewoon worden weggelaten.
Dat is vrij eenvoudig, je valt er tienduizend aan, en je krijgt er honderd op wie het lukt, en zo verzamel je je botnet bij elkaar en verkoopt dan aan belanghebbenden voor goed geld.
Zo gaat het al jaren. Je hoeft dus geen methode te hebben die bij iedereen werkt om een botnet op te richten.

toiletpaper op Woensdag 13 Augustus 2008 01:00

image

En die tienduizend of honderdduizend zijn ook makkelijk te vinden.

Steekwoorden: gratis porno, gratis warez, links naar torrents, software-keys......

een hoge Google-ranking, en de slachtoffers stromen massaal binnen.

Anonymous Coward op Dinsdag 12 Augustus 2008 12:07

image

Ik heb zelfs het onderzoek bevestigd en resultaten proberen te verduidelijken.
Later ja. Toen heb je het bevestigd en de resultaten voor je eigen bokkenwagen proberen te spannen. Alleen jammer voor je dat zo langzamerhand echt niemand die bull meer slikt. Het is echt iedereen zo langzamerhand wel duidelijk dat je de discussie net zo lang aanpast totdat het lijkt dat je een punt hebt. En als je dan een punt hebt op dat laatste afgekloven bitje info, dan roep je de victorie uit voor de hele discussie.

Dat zie je hier ondermeer op het punt dat één van de onderzoekers aangeeft dat Vista van alle Windows versies de minst slechte is. Dan blaas ik plotseling hoog van de toren en begrijp ik niets van het onderwerp, want 'de onderzoeker' is het 'volledig' met jouw eens.

toiletpaper op Dinsdag 12 Augustus 2008 12:43

image

Inderdaad heel erg vreemde zinsconstructie, die voor een psycholoog wel interessant zijn
Inderdaad, ik vind de vette koppen puur overdreven en de onderzoeker zelf geeft mij gewon gelijk
in plaats van:
Inderdaad, ik vind de vette koppen puur overdreven en ik geef de onderzoeker gewon gelijk

bovendien geeft de bewuste onderzoeker zelf mij gewoon heel duidelijk gelijk.
in plaats van
bovendien geef ik de bewuste onderzoeker gewoon heel duidelijk gelijk.

Anonymous Coward op Dinsdag 12 Augustus 2008 17:31

image

Wat jij wil.
Ik ben het met hem eens als hij zegt dat veel media artikelen sensationalism zijn en de feiten niet correct weergeven.
En ik ben het ook met hem eens als hij zegt dat Vista een veiliger OS is dan alle voorgaande windowsversies.

toiletpaper op Dinsdag 12 Augustus 2008 18:22

image

was dat nou zo moeilijk?

Anonymous Coward op Dinsdag 12 Augustus 2008 15:51

image

Dat zie je hier ondermeer op het punt dat één van de onderzoekers aangeeft dat Vista van alle Windows versies de minst slechte is. Dan blaas ik plotseling hoog van de toren en begrijp ik niets van het onderwerp, want 'de onderzoeker' is het 'volledig' met jouw eens.

Volgens mij was de onderzoeker het met mij juist ook vooral eens dat de berichtgeving met sensatieverhalen waaraan juist jij meermaals refereert als zijnde een bron dus sensatiegevuld is en niet correct de werkelijkheid weergeeft. Bronnen die jij gebruikte om mij persoonlijk aan te vallen omdat die het wel beter zouden weten. Blijkt nu dus dat de onderzoeker zelf deze verhalen naar de prullebak verwijst als sensatie en bovendien is het geen wat hij aangeeft als de essentie van zijn verhaal ook overeenkomend met datgene wat ik hierboven ook al in talloze berichten hebt aangegeven.

toiletpaper op Dinsdag 12 Augustus 2008 15:59

image

Volgens mij was de onderzoeker het met mij juist ook vooral eens dat de berichtgeving met sensatieverhalen waaraan juist jij meermaals refereert als zijnde een bron dus sensatiegevuld is en niet correct de werkelijkheid weergeeft.

in plaats van

Volgens mij was ik het met de onderzoeker juist ook vooral eens dat de berichtgeving met sensatieverhalen waaraan juist jij meermaals refereert als zijnde een bron dus sensatiegevuld is en niet correct de werkelijkheid weergeeft.

Ik zou werkelijk willen dat jij je plaats op de wereld beter kent, want dit is onverdraaglijk

toiletpaper op Dinsdag 12 Augustus 2008 16:02

image

of de onderzoeker het eens is met jou hoor ik liever van hem

Anonymous Coward op Dinsdag 12 Augustus 2008 17:02

image

Aha, nu snap ik het. Dus omdat ik het het eerst hoor hier in deze discussie, hier in deze discussie een link krijg aangereikt en die link volg concentreer ik me alleen op de sensatie koppen?

En ik heb niet gelezen op bijvoorbeeld: Ars Technica: The sky isn't falling: a look at a new Vista security bypass.
En natuurlijk heb ik de link van jouw naar Heise ook niet gevolgd.
Ik heb zelfs geen kennis genomen van het orginele bestand via bijvoorbeeld Google Cache. Ik heb trouwens wel de hele PDF gevonden via wat omwegen, jij ook?

Nee hAl, ik heb inderdaad alleen maar de sensatie koppen gevolgd en verder niets.

En toch is de onderzoeker het volledig met mij eens.
Vista memory protections are ineffective at preventing browser exploitation
– Large degree of control attacker has to manipulate process environment
– Open plugin architecture
– Single point of failure

Hoe komt het toch dat hij het met ons beide tegelijk eens is?

In Vista staat de poort naar de wereld (IE7) op drie veilige peilers, waarvan er twee zijn aangevreten door houtworm. Hierdoor blijft IE7 in Vista misschien wel iets veiliger dan in XP, maar het is niet meer iets om over te pochen.

Maar wat ik nog het ergste vind, is dat deze twee aangevreten peilers misschien een indicatie zijn dat nummer drie ook aangetast is. We hebben alleen nog geen zaagsel gevonden waarmee we het kunnen aantonen.

Anonymous Coward op Dinsdag 12 Augustus 2008 17:27

image

Hoe komt het toch dat hij het met ons beide tegelijk eens is?

Ik denk dat we het blijkbaar wel over een aantal feiten eens maar over de interprestatie duidelijk niet.

Jij staat achter de kretelogie van bepaalde artikelen van journalisten waarin wordt bweweerd dat de bevindingen van de onderzoeker de beveiliging van Vista nutteloos maken.

Ik ben het met de betreffende onderzoeker eens dat dergelijk uitspraken sensatiezucht zijn van de media en dat dit niet overeenstemt met de werkelijkheid en met zijn uitspraak dat dat Vista veiliger is dan alle voorgaande windows versies.

Het onderzoek maakt een exploit methode van bufferoverflows mogelijk als deze in een browser memory plaatvinden. Echter bufferoverflows op Vista blijven nog steeds moeilijker te exploiteren op Vista dan op XP, bufferoverflows lekken zijn sowieso minder vaak voorkomend dan enkele jaren geleden (zeker in de browseromgeving) en de getoonde exploit methode rekent dan ook nog niet eens af met de verlaagde privileges van de browser binnen Vista.
Er is dus wel sprake van een bevinding die bepaalde exploits in browser memory vereenvoudigt maar niet van een exploit die alle Vista beveiligingen nutteloos maakt of die ineens een golf van exploits zal opleveren.

Anonymous Coward op Dinsdag 12 Augustus 2008 19:45

image

Ik denk dat we het blijkbaar wel over een aantal feiten eens maar over de interprestatie duidelijk niet.
Ik denk ook dat we het blijkbaar wel over een aantal feiten eens maar wat een interprestatie is weet ik inderdaad duidelijk niet.

Bijvoorbeeld jouw kretologie dat ik denk dat heel Vista is omgevallen, is gelul in de ruimte. Ik zeg dat hiermee de zwakste schakel van Vista is blootgelegd en dat de kans bestaat dat de rest van het OS er achteraan gaat. Als Microsoft met ruim 13 jaar ervaring nog steeds niet in staat is een fatsoenlijke browser te bouwen die wel dicht zit, geeft dat weinig hoop voor de rest van het OS.

Zelfs jij zal toch moeten erkennen dat de browser een van de meest geliefde doelwitten op aarde is? Waarom heeft Microsoft dan toch besloten domme concessies te doen? Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.

Het wachten is op de kleinste kier in het rechtensysteem en Vista is weer gewoon het zoveelste onveilig stukje brodelwerk. Elke versie van Windows is tot op heden als het veiligste/beste ooit aangekondigd, waarom zou Vista anders zijn dan al die andere versies?

Het grote verschil tussen ons is, dat ik cynisch ben en jij een kwispelende labrador.

Anonymous Coward op Dinsdag 12 Augustus 2008 23:04

image

Ik zeg dat hiermee de zwakste schakel van Vista is blootgelegd en dat de kans bestaat dat de rest van het OS er achteraan gaat. Als Microsoft met ruim 13 jaar ervaring nog steeds niet in staat is een fatsoenlijke browser te bouwen die wel dicht zit, geeft dat weinig hoop voor de rest van het OS.

Wat heeft dit met de browser zelf te maken.
De methodiek die door de onderzoekers wordt beschreven is niet browserspecifiek.

Ik begrijp je dus interpretatie niet.


Anonymous Coward op Woensdag 13 Augustus 2008 08:22

image

Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.
Alleen al het feit dat IE7 gewoon niet met DEP werkt vind ik onbegrijpelijk.

Ik zal het een paar keer herhalen. Misschien komt er één door je firewall heen. =P

Anonymous Coward op Woensdag 13 Augustus 2008 10:09

image

DEP is lang niet compatibel met alle applicaties die draaien in de browser.

Bij de introductie van IE7 waren en nog populaire addons zie zorgden voor crashes en is dus voor compatibiliteitredenen het niet aangezet.
Dit was met name voor COM objecten gebouwed met oude versie van de ATL libraries in visual studio.
blogs.msdn.com/...protection.aspx
Omdat een aantal populaire add-ons niet werkten met DEP en daardoor leiden tot het onverwacht afsluiten van IE was er een risico dat het enabelen van DEP zou leiden tot miljoenen browsercrashers. Dat was logischerwijs niet acceptabel geweest. Met name in de 64 bits versie van Vista waarin DEP wel voor alle processen enabled is waren er daardoor in het begin ook meer problemen met IE add-ons.

Het niet compatible zijn van 3rd party plugin/addon/extensie software in de browser is niet uniek voor IE. Er zijn zat [url="http://www.google.nl/search?hl=nl&q=firefox+data+execution+prevention&meta="]crashes bekend van bijvoorbeeld Firefox 3[url] met data execution prevention enabled en die zullen ook vaak door verouderde extensies worden veroorzaakt.

In IE8 (deze maand beta 2) staat DEP default aan maar bij het testen van hun ssytemen zullen nog behoorlijk veel organisaties ook erachter komen dat ze nog oudere applicaties hebben die daar niet mee werken.

Anonymous Coward op Woensdag 13 Augustus 2008 10:20

image

Waarom werkt het dan wel in bijvoorbeeld Firefox 3? Zou het kunnen zijn omdat IE7 gewoon weer brodelwerk is?

Anonymous Coward op Woensdag 13 Augustus 2008 11:23

image

En omdat Firefox niet bang is om de goede beslissingen te nemen?

Anonymous Coward op Donderdag 14 Augustus 2008 09:53

image

Waarom werkt het dan wel in bijvoorbeeld Firefox 3? Zou het kunnen zijn omdat IE7 gewoon weer brodelwerk is?

Omdat Firefox 3 twee jaar recenter is dan IE7 en bijvoorbeeld de compatibiliteit van de browser plugins met DEP nu veel beter is. Sowieso is Micrsoft releatief voorzichtig met het releases van software die compatibiliteit kan breken.Blijkbaar is de compatibiliteit nu trouwesn ook voor MS goed genoed en zit DEP dus ook default toegepast in IE8, waarvan de tweede beta deze maand wordt gereleased.

toiletpaper op Woensdag 13 Augustus 2008 10:49

image

Er zijn zat [url="http://www.google.nl/search?hl=nl&q=firefox+data+execution+prevention&meta="]crashes bekend van bijvoorbeeld Firefox 3[url] met data execution prevention enabled
Waarschijnlijk werkte DEP in die tijd nog niet helemaal koosjer in Visual Studio. Er waren problemen met ATL als je DEP/NX compileerde. Daar had Firefox mee te maken wanneer bepaalde API-calls werden gedaan. Maar het probleem lag dus duidelijk bij de MS compiler. Dit is ook volmondig toegegeven.

...ATL relied upon dynamically generated code in a way not compatible with DEP/NX....
...Fortunately, new DEP/NX APIs have been added to Windows Server 2008 and recent Windows Service Packs to enable use of DEP/NX while retaining compatibility with older ATL versions....

(van de IE8 blog, die ik ook lees)

Dus een beetje vreemd dat je begin problemen met Firefox 3 niet relateert aan de oorzaak, een slechte synchronisatie van MS zijn eigen compiler-libraries en de standaarden.
Nu zijn dit soort problemen veel voorkomend, en begrijpelijk. en overkomelijk. Ik mopper dan ook niet al te hard op MS vanwege dit. Het valt me alleen op dat jij hier volledig aan voorbij gaat, end at geeft toch wel iets van je intentie weer in deze discussie.
Inmiddels zijn deze problemen dan ook al enige tijd verholpen en functioneert Firefox 3 gewoon erg goed op Vista, en heeft het in de drie maanden opd e markt een marktaandeel van bijna 6% gehaald, wat helemaal niet slecht is als je bedenkt dat het moet concurreren met een product dat de mensen al default geïnstalleerd hebben.

Anonymous Coward op Woensdag 13 Augustus 2008 10:12

image

Ik zal het een paar keer herhalen. Misschien komt er één door je firewall heen. =

Ik weet gewoon waarom DEP niet enabeled was in IE7 want ik ben al jarenlang geabboneerd op de IE blog feeds en heb me opgegeven als beta tester voor het testen van IE8.
Ik heb het hierboven even voor je uitgelegd.

ArjenB op Woensdag 13 Augustus 2008 10:15

image

Zullen we dan met z'n allen over op Firefox of Opera? Die werken wel met DEP.

ArjenB op Woensdag 13 Augustus 2008 10:16

image

Waarom die wel en IE7 niet? Ze smoelen nog beter ook.

toiletpaper op Woensdag 13 Augustus 2008 10:20

image

Ik heb die stap al vele jaren geleden genomen, en dat zal je niet verbazen.
En eigenlijk heb ik er nooit spijt van gehad.

ArjenB op Woensdag 13 Augustus 2008 10:38

image

Verbaast me inderdaad niks :-)

toiletpaper op Woensdag 13 Augustus 2008 10:19

image

Omdat een aantal populaire add-ons niet werkten met DEP en daardoor leiden tot het onverwacht afsluiten van IE was er een risico dat het enabelen van DEP zou leiden tot miljoenen browsercrashers.
Dat is slecht nieuws voor IE8, want het zal dan niet snel geaccepteerd kunnen worden, want ik neem, aan dat de populaire add-ons van een jaar geleden, nog steeds vaak populair zijn.

Dus dan blijft Vista opgescheept met een browser die de deur heeft open staan voor bufferoverflows.

Anonymous Coward op Woensdag 13 Augustus 2008 10:26

image

Ik begrijp je dus interpretatie niet.
Dan was dit vast een typefoutje? Als je weet dat IE7 brodelwerk is, waarom verdedig je het dan?

Maar gelukkig verschijnt in de vorm van IE8 alweer een nieuwe afleidingsmanoeuvre aan de horizon. dat is natuurlijk ook een methode. Versienummer ophogen en beweren dat het nu allemaal goed komt. Het zal me benieuwen of IE8 eindelijk de eerste is die de belofte wel waar maakt.

ArjenB op Woensdag 13 Augustus 2008 10:13

image

Leuke poging.

Anonymous Coward op Woensdag 13 Augustus 2008 00:57

image

Bijvoorbeeld jouw kretologie dat ik denk dat heel Vista is omgevallen, is gelul in de ruimte.

Volges mij zei ik
Jij staat achter de kretelogie van bepaalde artikelen van journalisten waarin wordt bweweerd dat de bevindingen van de onderzoeker de beveiliging van Vista nutteloos maken.

En dat was gebaseerd op jou lettlerijke uitspraak
Houd toch eens op met dit ontzettend domme gezwets! Heb je de titel van het artikel gelezen waar deze discussie is begonnen!? "Windows Vista security 'rendered useless' by researchers"

Wil dat door die verschrikkelijk dikke oogkleppen dringen!? Geloof je nou werkelijk dat die mannen alleen maar een pakkende openingszin zochten!?


En ik geloof indaardaad dat deze journalisten een pakkende openingszin zochten en jij vind dat dus blijkbaar niet.
Je hebt nu inmiddels zie ik ook het minder heethoofdigde artikel van Ars technica gelezen
arstechnica.com...ity-bypass.html
Eindelijk nog een artikel dat echt ingaat op de inhoud van de bevindingen

En ik zal daar ook nog een nette quote uit halen:
but not , as was reported in the immediate aftermath of the presentation, evidence that Vista's security is useless, nor does this work constitute a major security issue. And it's not game over, either. Sensationalism sells, and there's no news like bad news, but sometimes—particularly when covering security issues—it would be nice to see accuracy and level-headedness instead. Alarmism helps no one. Responsible vulnerability disclosure is a big concern in the security industry; it would be good to see it coupled with responsible reporting.

Om het nog eens duidelijk te maken. Jij holt achter sensatie koppen aan en valt mij al kop citerend aan dat ik daar geen geloof aan hecht.
Moet ik je nu echt serieus nemen omdat jij klakkeloos die sensatie koppen citeert.
Ik ging op de inhoud en dan is die sensatie snel voorbij.
Misschien een goede tip voor jou de volgende keer om ook even je hoofd koel te houden.


Anonymous Coward op Woensdag 13 Augustus 2008 08:25

image

En ik geloof indaardaad dat deze journalisten een pakkende openingszin zochten en jij vind dat dus blijkbaar niet.
Ah we gaan weer bitn**ken. Die opmerking was naar aanleiding van jouw gelul dat Vista "juist veel veiliger" was. Wat in ALLE artikelen ontkent wordt. Vista is iets veiliger, niet veel veiliger.

Ik zou tenminste niet durven beweren dat een OS met een valse gatenkaas als browser veilig is.

Anonymous Coward op Woensdag 13 Augustus 2008 10:23

image

Die opmerking was naar aanleiding van jouw gelul dat Vista "juist veel veiliger" was

Weer iets wat ik hier niet zo gezegd heb als jij het presenteer.
Maar vooruit. Ik wil wel iets in die richting zeggen hoor.

Ik vind Vista veiliger dat XP.
Veel veiliger ook.

En ik ben zoals ik wel al eerder zie het eens met de security onderzoeker Sotirov dat Vista veiliger is dan alle voorgaande windows versies.

toiletpaper op Woensdag 13 Augustus 2008 10:25

image

Weer iets wat ik hier niet zo gezegd heb als jij het presenteer.
Maar vooruit. Ik wil wel iets in die richting zeggen hoor.

Ik vind Vista veiliger dat XP.
Veel veiliger ook.

Slakken? Zout?

Anonymous Coward op Woensdag 13 Augustus 2008 10:33

image

Sorrie. Ik ben zo gewend aan je standaard uitspraken dat ik er blind vanuit ging dat je er hier ook wel weer een paar had laten vallen. Ik moet toegeven, deze keer niet.

Jij vind Vista het veiligst van de Windowsen, ik vind Vista het minst onveilig van de Windowsen. Dus wat emmer je nou? We zijn het toch gewoon eens?

ArjenB op Woensdag 13 Augustus 2008 10:41

image

Niet helemaal. In het engels heb je de uitdrukking 'damning with faint praise'. Persoonlijk denk ik dat Vista ook niet meer verdient.

Anonymous Coward op Woensdag 13 Augustus 2008 08:42

image

Eindelijk nog een artikel dat echt ingaat op de inhoud van de bevindingen
Als er ooit een arikel was was sensatie belust was, dan was dat er wel één.

Het viel me op dat dat artikel de zelfde hooghartige neerbuigendheid tentoonspreidde als jij altijd doet. Familie van je?

Ze noemen de originele presentatie: How to Impress Girls with Browser Memory Protection Bypasses.

En de overige schrijvende pers wordt afgeserveerd als: Chicken Little runs amok

Door dat soort gekleurde bull had ik nogal moeite om het gebral serieus te nemen. Wat is dat toch met kwispelende Microsoft fans, dat ze denken anderen te moeten beledigen?

Zou het zo zijn dat de hooghartige 'WOW' arrogantie van Microsoft besmettelijk is, en dat het zich verspreidt via Vista installaties? Ik weet het niet, maar ik denk dat ik voor de zekerheid toch de laptop maar eens moet gaan downgraden naar XP. Bedankt voor de waarschuwing hAl. Zonder jouw was ik er niet opgekomen.

Anonymous Coward op Woensdag 13 Augustus 2008 10:41

image

[quote]Als er ooit een arikel was was sensatie belust was, dan was dat er wel één.[/quote]

Oh ja ??

[quote]Het viel me op dat dat artikel de zelfde hooghartige neerbuigendheid tentoonspreidde als jij altijd doet. Familie van je?

[quote]Ze noemen de originele presentatie: How to Impress Girls with Browser Memory Protection Bypasses.[/quote]

Hahaha, wat ben jij een domme zak zeg. Je denkt dat Ars technica dat verzonnen heeft ?
Dat is hoe de betreffende onderzoekers zelf hun werk noemen in de blogpost waarin ze hun bevindingen aankodigen. Die had je dus niet eens gelezen.
taossa.com/inde...ction-bypasses/
Echt lachwekkend dat jij hier nog commentaar durft te leveren en nu nog even de ARS Technica redactie hooghartig noemt voor het lettelijk gebruik van de terminologie die de onderzoekers zelf gebruiken.

[quote]Door dat soort gekleurde bull had ik nogal moeite om het gebral serieus te nemen. Wat is dat toch met kwispelende Microsoft fans, dat ze denken anderen te moeten beledigen?[/quote]

Jij bent degene die hier als eerst begonnen ben met beledigen en bovendien hele domme opmerkingen door letterlijk citerende personen hooghartig te noemen terwijl je zelf allerlei sensatie koppen zit te citeren en teksten die niet gezegd zijn probeert te suggereren. Als zelfs 1 van de onderzoekers zelf persoonlijk aangeeft dat hij die media verhalen sensatiezucht vind dan nog blijf je er blind achteraan lopen. Dat is gewoon zielig.

[quote]Zou het zo zijn dat de hooghartige 'WOW' arrogantie van Microsoft besmettelijk is, en dat het zich verspreidt via Vista installaties?[/quote]

Vind jij dat de originle onderzoeker WOW arrogantie heeft ?
Die vind namelijk ook de overdreven media artikelen waar jij je op baseert 'sensationalism'.
Je maakt jezelf volstrekt belachelijk met je opmerkingen.

ArjenB op Woensdag 13 Augustus 2008 10:52

image

HahahaPilletje?

Anonymous Coward op Woensdag 13 Augustus 2008 10:57

image

Hahaha, wat ben jij een domme zak zeg. Je denkt dat Ars technica dat verzonnen heeft ?
Zeg ik dat? Dat heb ik nooit letterlijk zo gezegd volgens mij. Nu leg je me alweer woorden in de mond. Ik zeg alleen maar dat ze het letterlijk zo quoten en niet direct recht zetten. Ik mag nou nooit eens op zijn hAl's generaliseren. Jammer.

En dat ik een domme zak ben, dat is alleen gerekend naar jouw torenhoge intellect. Hoe kan ik ooit de illusie hebben me daar aan te kunnen spiegelen.

Ik ben in elk geval blij dat je nu je masker hebt laten vallen. Ik zat al te wachten op de ware hAl. Waar je eerst alleen de belediging insinueerde kom je er nu eindelijk openlijk voor uit. Dat moet een bevrijdend gevoel zijn. :)

Anonymous Coward op Woensdag 13 Augustus 2008 10:58

image

"Chicken Little runs amok" krijgt met deze reactie wel een grappige dimensie trouwens. ;)

Anonymous Coward op Woensdag 13 Augustus 2008 08:55

image

En dan nog eens wat: "Windows Vista security 'rendered useless' by researchers"

Als je het artikel gelezen had, dan had je kunnen weten dat dat over de browser gaat. Er staat echt letterlijk: "The protection mechanisms in Windows Vista are not very effective at preventing browser exploits." Dat was toch de conclusie waar jij en je onderzoeker het zo roerend over eens waren?

Waarom mag jij eigenlijk wel generaliseren met kreten als "Vista is juist VEEL sneller, beter, veiliger, mooier, beter verkopend", terwijl jij ALTIJD mensen denkt te moeten aanvallen als ze ook maar ergens één komma nuance vergeten?

Sterker nog, als ik je er op aanspreek dan beweer je glashard dat ik lieg, want dat heb jij 'niet zo gezegd'.

Anonymous Coward op Woensdag 13 Augustus 2008 01:00

image

[quote]Het grote verschil tussen ons is,...[quote]

Dat jij elk negatief berichtje Vista klakkeloos overneemt en
en dat ik gewoon voor mezelf denk.

toiletpaper op Woensdag 13 Augustus 2008 01:06

image

Dat jij elk negatief berichtje Vista klakkeloos overneemt en
en dat ik gewoon voor mezelf denk.

Dat jij elk positief berichtje over Vista klakkeloos overneemt en
en dat ik gewoon voor mezelf denk

Anonymous Coward op Woensdag 13 Augustus 2008 08:27

image

Jij denkt niet voor jezelf hAl, dat doet Microsoft voor je. Je weet het alleen nog niet. Wat niet jouw torenhoge IQ wel verrassend is, dat geef ik toe.

Anonymous Coward op Woensdag 13 Augustus 2008 09:42

image

Blijkbaar denkt Micrsoft dan ook voor Ars Technica en Heisse ?
Ik heb in deze disccussie eigen input gebracht op basis van wat ik uit het stuk van de onderzoekers las.
Ik heb zover ik heb gezien geen commentaar van een Microsoft medewerker geciteerd (en er over dit onderwerpt trouwens ook geen gezien.

Jij bent degene die de sensatie kretelogie uit de artikele cviteert en daar andere op aanvalt overneemt en zelf eigenlijk inhoudelijk niks aan de discussie hebt toegevoegd. Prima hoor maar ga niet zeggen dat ik niet voor mezelf denk. Ik kan namelijk wel een opinie vormen op basis van informatie.
Misschien is mijn opinie gekleurd maar ik heb wel een eigen opinie.



Anonymous Coward op Woensdag 13 Augustus 2008 09:56

image

Als ik de neerbuigende bewoording op Ars Technica zie, dan zou het door je broer geschreven kunnen zijn. Dus die auteur is waarschijnlijk ook iemand die Microsoft laat denken. En die van Heise, ach duitsers...

toiletpaper op Woensdag 13 Augustus 2008 10:12

image

Hier staat nog een artikel van dezelfde schrijver, hij geeft perfect aan wat er allemaal mankeert aan IE7.
arstechnica.com...y-on-vista.html
Een en ander sluit aan bij de bevindingen van Sotirov en Dowd, het duo dat consequent "de onderzoeker" wordt genoemd door hAl (misschien omdat Dowd bij IBM werkt?).

In elk geval worden in IE8 enkele security maatregelen genomen,
- compileren met DEP-switch aan (is in Firefox 3 ook gedaan), daarmee wordt IE wat betreft DEP net zo veilig als Firefox
- niet meer globaal installeren van ActieX objecten (zodat alleen de current user, die ze installeerde getroffen kan worden door een bufferoverflow in een verouderd ActiveX (helaas zal deze feature niet onder XP (75% van de markt) werken).
- Blokkeren/activeren van individuele ActiveX objecten per site (nu an dat alleen voor alle ActiveX objecten per site worden ingesteld.

Gezien het rapport van Sotirov en Dowd ("de onderzoeker") heeft Microsoft grote haast met het uitbrengen van IE8, want IE7 is eigenlijk amper verantwoord om te gebruiken.
Want het simpel laden van een ActiveX object van bijvoorbeeld MS zelf, maar ook honderden andere kan leiden tot een bufferoverflow en executie van code onder rechten van de current user. Als die current user toevallig administrator is, dan is dat zo. Deze onveiligheid bestaat in alle Windows versies.

Anonymous Coward op Woensdag 13 Augustus 2008 10:56

image

Het is inderdaad zo dat IE7 veiliger zou zijn geweest als MS DEP had enabeled in IE7.
Er staat echter ook heel duidelijk waarom in IE7 DEP nog niet enabled was.

the principal reason for this was that for many years after the introduction of DEP, Sun persistently failed to produce Java plugins that worked correctly with DEP enabled. With DEP turned on, IE7 would (safely) crash every time the Java plugin tried to load; secure, but irritating. Recent Sun Java plugins do work correctly with DEP enabled, so IE8 enables this protection by default.

Als MS in IE7 al DEP enabled had dan waren mogelijk tientallen miljoenen browsercrashes het gevolg geweest. Dat was een onacceptabel groot probleem.
MS gaat nu in IE8 DEP wel enabelen.
Dat gaat nog heel wat problemen opleveren zeker in bedrijven die soms stokoude java programmatuur gebruiken en die daardoor gewoon niet op IE8 kunnen overgaan.
Vooral dat IE8 nog op XP beschikbaar zal zijn waar nog vele miljoenen oude meuk plugins/addon rondzweven zullen er nog steeds zeer veel browsercrashes zijn. Ik hoop dat bij de uiteindelijke uitrol van IE8 de problemen enigzins beperkt blijven maar ik zie nu al de sensatiekoppen weer over browsercrashes die Peter dan weer kan citeren...

toiletpaper op Woensdag 13 Augustus 2008 11:00

image

Dat gaat nog heel wat problemen opleveren zeker in bedrijven die soms stokoude java programmatuur gebruiken en die daardoor gewoon niet op IE8 kunnen overgaan.
Bedrijvend ie stokoude Java runtimes gebruiken zullen ook niet eraan denken om op IE8 over te gaan. Ze zullen zelfs Vista niet eens gebruiken, en in DEP geen voordeel zien.
Als Microsoft het als haar taak ziet om haar beveiligingsniveau omlaag te schroeven naar dit soort bedrijven (zoals het met IE7 gedaan heeft) dan zegt dat veel.

Anonymous Coward op Woensdag 13 Augustus 2008 11:55

image

Bedrijvend ie stokoude Java runtimes gebruiken

Het hoeven toch geen stokoude runtimes te zijn.
Volgens het Ars article uit maart 2008 dat jij zelf inbracht had Sun nog maar 'recent' hun java plugins correct werkend gemaakt met DEP.
Ik neem dus aan dat iets minder recente Sun java plugins bijvoorbeeld uit 2005/2006 gewoon niet zullen werken en leiden tot crashes in IE8.

toiletpaper op Woensdag 13 Augustus 2008 16:48

image

Het is ook erg dom om JVM's uit 2005/2006 te gebruiken, gelukkig heeft SUN zelf een update-mechanisme. De nieuwe JVM's zijn backwards compatile, er is dus ook geen reden om bij het oude te blijven hangen.

toiletpaper op Woensdag 13 Augustus 2008 11:01

image

maar ik zie nu al de sensatiekoppen weer over browsercrashes die Peter dan weer kan citeren...
je bedoelt, zoals jij ons fijntjes wees op de crahses van Firefox?

Anonymous Coward op Woensdag 13 Augustus 2008 11:05

image

Nee Theodoor, het is de waarheid als hAl het doet. Alleen als iemand anders het doet heet het sensatiekoppen citeren. Dat moet nu toch duidelijk zijn.

Anonymous Coward op Woensdag 13 Augustus 2008 12:01

image

Ik zit hier niet te beweren dat firefox useless is.
Dat het aanzetten van DEP in een browser tot crashes kan leiden is het beste te tonen door te laten zien dat dat feitelijk ook het geval is bij firefox.
Ik voorspel daarbij ook crashes in IE. Dat lijkt me dus heel niet sensatiezucht maar een reeele inschatting.

Anonymous Coward op Woensdag 13 Augustus 2008 11:02

image

He ja, fijn weer op anderen wijzen. Het kan toch niet waar zijn dat Microsoft eens schuld heeft.

toiletpaper op Woensdag 13 Augustus 2008 11:05

image

Sun persistently failed to produce Java plugins that worked correctly with DEP enabled.
De reden waarom Sun hierin niet slaagde staat in de IE8 blog, die jij toch ook leest?

Het was gewoon omdat MS haar Visual Studio niet iop tijd update, waardoor third parties geen beshikking over DEP hadden, maar MS via andere weggetjes wel (getuige eht feit dat MS wel DEP kon gebruiken)
Precies de reden waarom MS miljoenen boetes moet betalen aan de EU, nu weer een feitje erbij.

citaat:
Several popular add-ons were not compatible with DEP/NX and would crash when Internet Explorer loaded them with DEP/NX enabled. The most common problem was that these add-ons were built using an older version of the ATL library. Before version 7.1 SP1, ATL relied upon dynamically generated code in a way not compatible with DEP/NX. While developers of many popular add-ons have since released updated extensions compatible with DEP/NX, some add-ons may not be updated before Internet Explorer 8 becomes available.

Fortunately, new DEP/NX APIs have been added to Windows Server 2008 and recent Windows Service Packs to enable use of DEP/NX while retaining compatibility with older ATL versions.

Anonymous Coward op Woensdag 13 Augustus 2008 11:46

image

Het was gewoon omdat MS haar Visual Studio niet iop tijd update

Het betreft libraries die vanaf Visual studio 2003 worden gebruikt.
Dat lijkt me toch wel een tijdje terug.

Het lijkt erop dat Sun de java plugins nog bouwde met behulp libaries uit Visual Studio 6.0


Anonymous Coward op Woensdag 13 Augustus 2008 12:15

image

Damn! Ik moet toegeven, scherp.

toiletpaper op Woensdag 13 Augustus 2008 12:16

image

De problemen met DEP/NX in ATL werden in november 2006 via SP1 van Visual Studio 2003 opgelost. Zoals je ook kunt lezen in de IE8 blog. Als je iets van versies weet, dan weet je dat Visual Studio 2003 gelijk is aan versie 7.1
Het zal heus zijn dat er JVM versies zijn die met deze versie zijn gecompileerd, en ook met voorgaande versies. ik weet niet wat je precies hiermee wilt aangeven.

Bedoel je dat de laatste JVM versie hiermee is gecompileerd? Is dat wat je wil zeggen?

Nu zou ik graag een helder Ja of Nee van je krijgen (+ bron vermelding).

Anonymous Coward op Woensdag 13 Augustus 2008 12:34

image

En ik moet toegeven. Nog scherper.

Anonymous Coward op Woensdag 13 Augustus 2008 14:26

image

De problemen met DEP/NX in ATL werden in november 2006 via SP1 van Visual Studio 2003 opgelost

Zeker al eerder want Visual studio 2005 werd al in oktober 2005 gereleased zover ik weet.

Ik weet niet precies wanneer de java plugins geschikt zijn geraakt voor DEP. Het staat nergens in hun release notes maar ik zie nog wel meldingen dat java versie 6 in 2007 na de release van Vista, nog DEP fouten op leverde.

toiletpaper op Woensdag 13 Augustus 2008 14:49

image

maar ik zie nog wel meldingen dat java versie 6 in 2007 na de release van Vista, nog DEP fouten op leverde.
Was dat dat in IE7? Dat ondersteunt toch geen DEP, juist vanwege de compatibiliteit naar oudere JVM's zoals je zei. ook Firefox 3 bestond toen nog niet.
Ook zelfstandige java-applicaties zouden geen probleem mogen zijn, want Vista ondersteunt executables zonder DEP.

Dus het lijkt mij een tegenstrijdig verhaal, of van mensen die het niet goed hebben begrepen.

Misschien kun je bronnen aanreiken, dan zal ik ze zelf bestuderen.

Anonymous Coward op Donderdag 14 Augustus 2008 23:23

image

[quote]Was dat dat in IE7? Dat ondersteunt toch geen DEP,[quote]

Dat is een misvatting.
Ik weet niet hoe je daar bij komt.
Ik heb het voor de zekerheid nog eens nagezocht.
DEP staat default weliswaar uit in IE7 maar je kunt DEP wel gewoon weer aanzetten in IE7.
En omdat je zo van linkjes houdt heb ik voor deze keer een linkje erbij gedaan (maar ik verwahct in de toekomst dat je dat zelf maar bij elkaar googled).

blogs.msdn.com/...e-software.aspx

toiletpaper op Vrijdag 15 Augustus 2008 09:03

image

Je hebt gelijk, je kunt DEP aanzetten in IE7, maar het staat standaard uit, de rest van mijn reactie blijft dus gewoon staan, even als de vraag die ik erin stelde.

toiletpaper op Vrijdag 15 Augustus 2008 09:11

image

maar ik verwahct in de toekomst dat je dat zelf maar bij elkaar googled
Ik kan mensen die hun beweringen niet onderbouwen meestal niet serieus nemen.
Dus wat jij verwacht moet je zelf weten.
Je plaatst je linkjes ook niet om mij een plezier te doen, maar voor je eigen geloofwaardigheid.

je mopperde nog, ik geloof twee week geleden, ik citeer:

Ik heb het idee dat er vaak maar wat geroepen wordt
Regelmatig wordt ook gewoon de waarheid ernstig geweld aangedaan. Enorme eigen interpretaties niet gebaseerd op enigerlei betrouwbare bron of zelfs pure verzinsels.

(hAl 03-08-2008 01:04)

Dus gaan je nu zelf bij die mensen horen waar je nog zo boos op was?

Anonymous Coward op Woensdag 13 Augustus 2008 11:25

image

maar ik zie nu al de sensatiekoppen weer over browsercrashes die Peter dan weer kan citeren...
Ik smul al bij de gedachte. :D

toiletpaper op Woensdag 13 Augustus 2008 09:57

image

Prima hoor maar ga niet zeggen dat ik niet voor mezelf denk. Ik kan namelijk wel een opinie vormen op basis van informatie.

Jij zei dat Peter niet voor zichzelf denkt, en Peter speelt de bal terug.
Misschien is mijn opinie gekleurd maar ik heb wel een eigen opinie.
Waarom zou Peter die dan niet hebben, een (eventueel gekleurde) eigen opinie?

Jij bent degene die arrogant is, en Peter reageert, kijk maar eens terug op welke reactie jij concludeerde dat Peter geen eigen opinie betreffend Vista had. Je vindt hem onder dit kopje: Peter Koopman 12-08-2008 19:45

Vermoedelijk was het de labrador die jouw in je wiek geschoten deed voelen.

Anonymous Coward op Woensdag 13 Augustus 2008 11:05

image

[quote]Waarom zou Peter die dan niet hebben, een (eventueel gekleurde) eigen opinie?[quote]

Dat had hij die maar eerst moeten tonen en niet meteen moeten gaan hakken met de opinie van de sensatieartikelen zoals in zijn berichten en met name deze
Peter Koopman 11-08-2008 23:16
als vervolgens blijkt dat zelfs 1 van e onderzoekers zelfs deze media artikelen'asl 'sensationlism' beschouwd gaat hij die sensatiekoppen koppen nog eens gebruiken om zijn gelijk te krijgen.
Het citeren van sesnatie artikel koppen vind ik niet erg tone van je eigen opinie tenzij hijzelf ook geschaard moet worden in de sensatiezucht categorie.
En dat is misschien ook wel zo.

Dat hij vervolgens probeert het wel veel inhoudelijker gerichte ARS technica artikel belachelijk probeert te maken en daarbij eigenlijk zichzelf belachelijk maakt is dan alleen nog maar zielig te noemen.

toiletpaper op Woensdag 13 Augustus 2008 11:10

image

Dat hij vervolgens probeert het wel veel inhoudelijker gerichte ARS technica artikel belachelijk probeert te maken en daarbij eigenlijk zichzelf belachelijk maakt is dan alleen nog maar zielig te noemen.
Over belachelijk maken en zielig te noemen, dat zou ik nou niet exclusief aan peter toekennen, maar ik heb er geen interesse in om persoonlijke aanvallen van jouw kant uit te gaan verzamelen. Ik let het erbij dat er tientallen zijn, waaronder dit bericht waar ik nu op reageer.

Anonymous Coward op Woensdag 13 Augustus 2008 11:10

image

Hè, 'Peter' heeft een nuance foutje gemaakt. Hoelang ga je het uitmelken? Ik melk het toch ook niet uit dat je (onder andere) het woord 'sensatie' niet kan typen?

Anonymous Coward op Woensdag 13 Augustus 2008 12:06

image

Als het slechts een nuance foutje was dan had je er niet zo op door hoeven hameren maar rustig kunnen toegeven dat de koppen waarin staat dat de Vista security useless is erg zwaar overdreven zijn.

Of gewoon kunnen erkennen dat Vista duidelijk beter beveiligd is dan de voorgaande windows versies.

Anonymous Coward op Woensdag 13 Augustus 2008 12:23

image

Ik heb nergens ontkent dat Vista veiliger was. Ik heb ontkent dat Vista VEEL veiliger is.

Ik heb dat zelf nog duidelijk uitgelegt:
...waardoor de exploit op dit moment, god zij dank, (nog) niet uit het rechtensysteem kan ontsnappen. Dus als je je browser netjes onder lage rechten houdt blijft de schade enigszins beperkt. Dat vond ik veel belangrijker nieuws op Heise.

Ik herhaal het nog maar eens. Jij vind Vista het veiligst van de Windowsen, ik vind Vista het minst onveilig van de Windowsen. Dus wat emmer je nou? We zijn het toch gewoon eens?

Anonymous Coward op Woensdag 13 Augustus 2008 12:28

image

En dat hameren was omdat jij aan het hameren was hoe veilig Vista toch is, terwijl het artikel van de twee onderzoekers keihard aantoont dat DEP en ASLR in Internet explorer 7 op Microsoft Windows Vista inclusief Servicepack 1 te omzeilen zijn. (En nu maar hopen dat ik geen nuance foutje heb gemaakt) Je ging zelfs zover om te twijfelen aan de impact van de bevindingen.

Anonymous Coward op Woensdag 13 Augustus 2008 14:37

image

Je bent nog vergeten te zeggen "IE7 op de 32 bits versie van vista" en "te omzeilen zijn mits je beschikt over een bufferoverflow die remote exploitable is via IE7".

Maar inderdaad was dit voor jou doen al een heel genuanceerde uitspraak vergelijken met eerdere teksten.
Zie je maar dat veel van mijn argumenten stiekum toch zijn blijven hangen
Had je met bovenstaande tekst de argumentaties begonnen was er nauwelijks discussie geweest.


Anonymous Coward op Woensdag 13 Augustus 2008 14:44

image

Als jij dan de volgende keer op dezelfde manier je 'evidentjes' en 'Vista is juist veel geschikter' ook op dezelfde manier nuanceert, dan hoef ik me ook niet meer te ergeren. Kunnen we misschien alsnog door één deur. Deal?

Anonymous Coward op Woensdag 13 Augustus 2008 14:47

image

Zie je maar dat veel van mijn argumenten stiekum toch zijn blijven hangen
Burp... teiltje!

Diogenes_Isher op Donderdag 14 Augustus 2008 01:57

image

dat ik cynisch ben en jij een kwispelende labrador.
"Cynisch" (dit woord komt uit het Grieks) betekent "hond-achtig" of "honds" en labrador retrievers zijn hele vriendelijke, trouwe, zeer intelligente dieren. Ooit lang geleden had ik zelf een schat van een grote, zwarte labrador...
Daarom vind ik de vergelijking van hAl met een labrador tamelijk onjuist en zelfs ongepast, voor de labrabors dan...

toiletpaper op Donderdag 14 Augustus 2008 10:06

image

Het kan zijn dat er een woord overeenkomst is tussen "cynisch" en het Griekse woord "kynos".

Echter heeft in het hedendaagse taalgebruik het woord een hele andere betekenis.
Er zijn twee mogelijkheden
- refererend aan een filosofische stroming
- een negatief en bitter wereldbeeld, en daarbij behorende spottende humor

In het algemeen wordt de tweede betekenis aangehouden.

Anonymous Coward op Dinsdag 12 Augustus 2008 09:55

image

@hal

Normaal zou ik nog daadwerkelijk in gaan op alle onzin die je loopt te verkondigen, maar deze thread slaat echt alles. Er is teveel onzin om een beginpunt uit te kiezen

Ik heb hier een paar dagen niet gekeken en loop nu even deze thread langs. Van boven naar onder schrijf je bijna geen enkele zin op die correct is. Je snap niet hoe overflows werken, je snapt niet wat Windows er tegen doet, je snapt niet wat Linux er tegen doet en bovenal snap je niet wat er in het paper staat. Bovendien sla je nog een toontje aan alsof JIJ mensen moet gaan uitleggen waar het hier precies over gaat.

Als ik jou was zou ik gewoon stoppen en thuis minesweeper gaan spelen.

ArjenB op Dinsdag 12 Augustus 2008 09:04

image

Speciaal voor Theodoor en ArjanB die het idee hebben dat de onderzoekers bevindingen niet specifiek zijn voor de browseromgevingIk geloof niet dat ik dat ergens beweerd heb. Adobe-, .NET-, Java-plugins, volgens mij zijn die native.

ArjenB. Met een e. Nauwkeuriger lezen?

Anonymous Coward op Dinsdag 12 Augustus 2008 09:08

image

Sorry Arjen, hAl heeft geen tijd om het fatsoen op te brengen om zijn reacties te controleren op spelfouten. Hij heeft het te druk met de verdediging van Windows tegen de rest van de (Web)wereld.

toiletpaper op Dinsdag 12 Augustus 2008 09:17

image

Binnen Windows zijn het ActiveX-objecten, en ze kunnen binnen IE7, maar ook iedere andere executable worden aangeroepen, en zelfs binnen een venster-context worden weergegeven. Een krachtige, doch ook gevaarlijke eigenschap van ActiveX.

toiletpaper op Dinsdag 12 Augustus 2008 09:21

image

In feite is een IE7 gewoon een executable met een bepaalde functionaliteit, die er deels uit bestaat om html-gestuurd activeX-objecten te laden.

Anonymous Coward op Dinsdag 12 Augustus 2008 09:30

image

Volgens mij hebben wij dan een verschil van mening over wat native is als jij een java plugin native noemt op windows.

De essentie blijft dat de onderzoeker bevestigd dat zijn onderzoek specifiek het niet effectief zijn van bepaalde Vista beveilingsfuncties in bepaalde situaties binnen het geheugen van een browser heeft aangetoond en dus niet het ineffectief zijn van deze Vista beveiligingsfuncties in het algemeen.

Anonymous Coward op Dinsdag 12 Augustus 2008 09:56

image

Wat denk je zelf? Zou het object npjpi160_05.dll (Java Plug-in 1.6.0_05) native code bevatten of niet? En Flash9d.ocx? Native of niet?

toiletpaper op Dinsdag 12 Augustus 2008 10:10

image

De essentie blijft dat de onderzoeker bevestigd dat zijn onderzoek specifiek het niet effectief zijn van bepaalde Vista beveilingsfuncties in bepaalde situaties binnen het geheugen van een browser heeft aangetoond en dus niet het ineffectief zijn van deze Vista beveiligingsfuncties in het algemeen.
Welke onderzoeker, Sotirov of Dowd?

Wat is het verschil tussen IE7 en een andere executable die scriptgestuurd ActiveX objecten kan laden en venster-context kan geven? (die programmeer ik met behulp van een app-code-wizard binnen een uur)

toiletpaper op Dinsdag 12 Augustus 2008 10:11

image

Vervolgens. nog geniepiger
Wat is het verschil tussen IE7 en een andere executable die scriptgestuurd ActiveX objecten kan laden zonder deze venster-context kan geven (onzichtbaar dus)?

Anonymous Coward op Donderdag 14 Augustus 2008 10:13

image

Omdat er nog veel nieuws later is binnen gekomen op de bovenstaande discussie hier wat nagekomen links:

Webwereld: Vista's beveiliging niet onherstelbaar stuk
ZDnet: Vista security not rended useless
Ars technica: The sky isn't falling
Black Hat researcher Sotirov: News Vista security broken completly inaccurate

toiletpaper op Donderdag 14 Augustus 2008 10:24

image

De links die jij noemt bevatten redundante informatie die al bestond tijdens deze discussie en ze is ook al uitgebreid tijdens deze discussie besproken.
Dat van Arstechnica staat onder dit kopje (hierboven) besproken: Peter Koopman 12-08-2008 17:02

Om te kunnen reageren, dient u ingelogd te zijn.

Loading Poll

Peiling

Loading Poll

Video: HP ziet grote toekomst in oprolbare s...

Verleden nieuws