Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 92 reacties
Bron: C|Net

Onderzoekers hebben een veiligheidsgat in het kantoorpakket OpenOffice.org ontdekt. Hierdoor zou het mogelijk zijn om op afstand kwaadaardige programma's te laten uitvoeren op Windows, Linux en Mac OS X.

OpenOffice.org klein logoHet veiligheidsprobleem werd ontdekt in de code voor het inladen van tiff-bestanden. Wanneer een dergelijk bestand wordt geopend, wordt op basis van enkele gegevens in het bestand nagegaan hoeveel geheugen er gealloceerd moet worden. Doordat voor het berekenen van de geheugenruimte voor tags in de tiff-afbeelding ongecontroleerde waarden worden gebruikt, kan een integer overflow optreden. Dit heeft weer tot gevolg dat voor het reserveren van geheugenruimte op de heap een onjuist getal wordt gebruikt, waardoor het mogelijk is een heap overflow te creëeren.

Hierdoor is het mogelijk om kwaadaardige programmacode te laten uitvoeren op een computer, vertelt Andreas Baumhof, een van de onderzoekers. Aangezien het om een fout in OpenOffice.org zelf gaat en niet in het onderliggende besturingssysteem, is de bug aanwezig in alle platformversies van het officepakket. Dit betekent volgens Baumhof dat onder andere Windows-, Linux- en Mac OS X-gebruikers er last van hebben, hoewel hij erbij vertelt dat het lek tot nu toe alleen in de Linux-versie is geverifieerd.

Alle versies van het officepakket zijn kwetsbaar voor het lek dat aangepaste tiff-afbeeldingen met zich mee kunnen brengen. Er is één uitzondering en dat is versie 2.3. Die versie van de kantoorsoftware zag op 17 september het levenslicht en bevat een fix voor het lek.

Moderatie-faq Wijzig weergave

Reacties (92)

Ik vraag me alleen af of het op Windows Vista wel een bruikbaar lek is aangezien daar geheugen adressen Random zijn waardoor het volgens mij lastig tot bijna onmogelijk is om iets bruikbaars te doen met deze exploid.
Op een x86 processor kun je relatieve code schrijven, die draait ongeacht het adres waar hij staat.. En bepaalde dll's bij naam aanroepen, dan krijg van het OS het adres terug van die DLL.

Niet dat de technologie waardeloos is, maar hij is ook niet zalig makend.
De ruimte die gecreerd wordt door de buffer overflow staat nog steeds in user-space, dus zonder root rechten -(inux ?en mac?) kan de code nog steeds niet zijn vrije gang gaan. En een ieder die OO met root rechten draait vraagt erom. Wel kan de code al de bestanden in je home directory wissen of ze opsturen naar een concuerent, maar ach ;);)
Een stukje malware kan dat slechts wat jij ook zou kunnen ?
* Al je persoonlijke bestanden weggooien ?
* Mail versturen (spam of verder verspreiding van de malware)
* Sites benaderen op het internet (DoS aanval)
* IRC chatten (contant leggen met een botnet eigenaar)
* Je keys loggen en resultaten ergens op het internet afleveren (bijvoorbeeld persoongegevens, wachtwoorden, creditcard gegevens? )

Tja dat is natuurlijk allemaal niet zo schadelijk....
Het kan je systeem niet vernielen
Dat zal Righard bedoelen
Ik ben zelf geen liefhebber van OO, maar om nu hiermee te komen gaat wat ver. Het probleem is immers al opgelost in de nieuwste versie. Altijd zorgen dat je software up-to-date is.
Jouw reactie is wel erg simpel. Als je in een bedrijf OO hebt uitgerold, ga je niet snel een complete versie updaten. Het is teveel werk om een complete installatie te moeten doen. Het zou OO.org sieren als ze met een patch zouden komen voor de oudere versies.

Verder moet je dit bericht lezen als een waarschuwing voor mensen die een oudere versie hebben draaien, dat ze of een nieuwe versie moeten installeren, of dat ze een patch moeten draaien.
Jouw reacties is ook erg simpel
Software producenten moeten de fouten fixen En de oplossing delen.
Securety patches zijn taken van de OS. atans de Meeste besturings systemen/Distro's hebben dit.
@daft_dutch

Dus als ik een programma schrijf met een lek erin dan moet volgens jou Microsoft het OS zo gaan aanpassen dat mijn foute programmaatje geen schade kan aanrichten. Hoezo kort door de bocht?

Daarmee zeg je in feite dat Microsoft verantwoordelijk is als iemand een virus schrijft die het OS infecteerd, dus niet via OO maar gewoon rechtstreeks.

[Reactie gewijzigd door Fairy op 26 september 2007 09:47]

en daar heeft hij gelijk in. Een OS moet niet zomaar taken kunnen uitvoeren die niet door de beugel kunnen. Om een programma te installeren, of iets uit te voeren wat de kern van het OS aan dreigt te tasten moet het nodig zijn voor de gebruiker om op JA/NEE te drukken, of een wachtwoord in te typen. Iets in elk geval dat het niet zomaar kan gebeuren.

Je moet als consument een compleet OS eisen, dus ook compleet qua veiligheid. Tegenwoordig eist de consument (of haar vertegenwoordiging) echter dat er geen Media Player in het OS zit, maar de beveiliging maakt niet uit.

Het is trouwens helemaal niet moeilijk. Op de Mac is het onmogelijk een kwaadwillend bestand uit te voeren zonder een bevestiging van de gebruiker. Dan moeten ze bij MS dát toch ook kunnen maken (ze kopiëren immers alles)
<quote>en daar heeft hij gelijk in. Een OS moet niet zomaar taken kunnen uitvoeren die niet door de beugel kunnen. </quote>

Over kort door de bocht gesproken.
Ik kan prima applicaties schrijven op eender welk operating systeem die dingen doet die jij niet wil dat er uitgevoerd worden.
Daar kun je echter de maker van het operating systeem niet verantwoordelijk voor stellen.
Ik maak geweoon gebruik van standaard bibliotheken waarmee ik gewoon legitieme uitvoerbare code schrijf. Voor bijvoorbeeld IBM cluster unix, of Silicon Graphics IRIS, HP UX, BSD Linux, Ubuntu. Allemaal geen enkel probleem om die te vernaggelen met een applicatie die op een normale manier wordt geinstalleerd zoals dat met Open Office gebeurt.

Geen enkel operating systeem of beveiligings optie kan zoiets tegenhouden.
@Hartok: er staat niet dat het onmogelijk moet zijn, er staat dat het niet _zomaar_ moet kunnen. Dat is wat anders.

@matiov: Vista is inderdaad wat dat betreft iets netter dan XP (het meestgebruikte Windows OS), maar of dat mechanisme echt goed werkt moet nog bewezen worden.

[Reactie gewijzigd door mae-t.net op 26 september 2007 12:50]

@t-h

Beetje stomme reactie. ten eerste is er bij windows vista al uac, ten tweede bespeur ik een turtleneck hipster uitlating en ten derde, wat is het verschil tussen een vnc server geinstalleerd door een hacker om remote desktop te kunnen krijgen en vnc server geinstalleerd door de eigenaar van de pc?
@ matiov:
UAC wordt als uiterst hinderlijk gezien en meteen uitgezet door veruit de meeste mensen waardoor het dus geen enkel nut meer heeft. Overigens is UAC een slecht systeem aangezien de eerst aangemaakte user nog altijd administrator rechten heeft welke alleen worden ingeperkt en met iets als UAC weer open wordt gezet. Bij zo'n account hoef je dan alleen maar op de Allow knop te drukken van het UAC venster en klaar. Bij een gewone user daarentegen werkt het zoals het zou moeten werken: je krijgt een UAC scherm met een username erin en je moet er een username plus bijbehorende wachtwoord invoeren van een account dat admin rechten heeft. Precies zoals dat met sudo onder Linux en MacOS X gebeurd. UAC is dus een security through obscurity ding is netzo nuttig als pen en papier voor een duiker.

Het verschil tussen VNC server die een hacker installeert en die een user installeert lijkt me toch wel overduidelijk. De laatstgenoemde is geïnstalleerd door de user van de computer zelf waardoor deze er ook zelf controle over heeft. Je kunt dus zelf je security kiezen door je firewall in te stellen, wachtwoord toewijzen, beperken tot een ip-adres, etc. Als een hacker het installeert dan heeft die persoon er de controle over en niet de user van de computer. Buiten het feit dat het uiteindelijke doel ook anders is (kwade en niet-kwade bedoelingen).

Verder is security een aangelegenheid dat niet beperkt is tot 1 onderdeel zoals een programma of het OS. Security is een samenspel van diverse onderdelen waaronder programma's, operating system en mogelijk zelfs hardware. Ook de mens zelf speelt een belangrijke rol en dat is tegenwoordig veelal de grootste rol en ook de zwakste schakel in het geheel. Het is niet ongewoon dat wanneer je mensen naar hun loginnaam vraagt ze meteen het wachtwoord vrijgeven wat dus echt nergens voor nodig is. Overigens is iets als geheugenmanagement wel een onderdeel wat het OS hoofdzakelijk moet doen. Het moet niet zo zijn dat je met gemak met het gereserveerde geheugen voor applicatie x kunt gaan lopen rommelen dmv applicatie y. Datzelfde zorgt er ook min of meer voor dat als een applicatie crasht de rest er geen hinder van ondervindt of iig een stuk minder hinder.

@hAl: op dit moment is het uitschakelen van UAC de meest gestelde vraag mbt Vista op diverse fora in Nederland en de rest van de wereld. Buiten dat zijn er diverse onderzoeken geweest waarbij allemaal de uitkomst was dat UAC irritant was en meteen werd uitgeschakeld door de gebruikers. Ik kan het ook zelf merken met klanten die Vista draaien en met andere mensen die een Vista machine hebben waarmee ik in aanraking kom.Het probleem is trouwens niet alleen maar in het begin. Er zijn heel veel mensen die continu dingen aanpassen al zijn het maar kleine dingen zoals de tijd of het installeren van een programma. Hiervoor wordt altijd door UAC om toestemming aan de gebruiker gevraagd.

Wat jij roept is dus volstrekte nonsens, temeer omdat er geen enkele onderbouwing aan vast zit en al helemaal niet als je er nieuwsberichten e.d. erbij naast gaat leggen. Heb jij enige ervaring op gebied van helpdesk/systeembeheer voor wat Windows betreft?

[Reactie gewijzigd door ppl op 26 september 2007 20:52]

Volstrekt nonsense.
De meeste mensen laten UAC gewoon aanstaan.
Je krijgt er ook al snel minder last van.
Alleen in het beging wanneer je veel instellingen wilt wijzingen en software wilt installeren is het wat hinderlijk
Lees het artikel eens beter. Dit zeg jij:
Het is trouwens helemaal niet moeilijk. Op de Mac is het onmogelijk een kwaadwillend bestand uit te voeren zonder een bevestiging van de gebruiker. Dan moeten ze bij MS dát toch ook kunnen maken (ze kopiëren immers alles)
Dit staat in het artikel:
Dit betekent volgens Baumhof dat onder andere Windows-, Linux- en Mac OS X-gebruikers er last van hebben,
Blijkbaar toch wat moeilijker dan jij denkt dus, want een Mac is dus net zo kwetsbaar.

[Reactie gewijzigd door mjtdevries op 26 september 2007 13:37]

pff.. dat zit al lang in Vista en noemt zich UAC (je weet wel.. dat deel dat de meesten hier uitschakelen omdat het irritant zou werken... )
Huh? Sinds wanneer zo security alleen een OS taak zijn???

In dit geval zit het probleem toch echt in de applicatie, en moet die gepatched worden.
Huh? Sinds wanneer zo security alleen een OS taak zijn???
Hij bedoelt dat Windows geen fatsoenlijk package/update management heeft en dus elke applicatie zelf voor een auto-update mechanisme moet zorgen. :(
Wel eens van MSI gehoord? Windows heeft, zeker in een kantooromgeving prima package management in de vorm van Group Policys en software publishing / assignment.
@Bor: MSI is een installer, niet echt dat je zegt een ideale patcher/updater, lijkt me zo.
Na het uitrollen van een msi kan men altijd ook nog een patch uitrollen over het pakket. Weet niet precies hoe dit werkt, maar MS heeft hier wel degelijk over nagedacht. Ben er zelf niet echt voorstander van. Vooral wanneer je te maken hebt met vaak nieuwe gebruikers, dan liever bij de huidige gebruikers het pakket terugtrekken en goed pakket uitrollen.

Daarnaast, alle installers hebben hun voor en nadelen.

Ook het uitrollen van een nieuwere versie hoeft niet een heel groot probleem te zijn als je je business goed in hebt gericht. Zoals Bor de Wollef al zei, kun je via AD dan wel SMS (tenminste als we het over MS hebben, zijn nog veel meer tools. Bv NetInStall van Enteo) snel pakketten uitrollen naar groepen gebruikers als je ze maar (goed) laat Packagen/Scripten.
Het nadeel van MSI (voor zover ik weet), is dat het geen mechanisme heeft om zelf nieuwe updates te zoeken. Dat moet ieder programma zelf regelen.

In de Linux wereld is het min of meer de standaard dat je 1 package manager op je systeem hebt, die van ieder programma op je systeem weet waar de updates te halen zijn.

Als systeembeheerder hoef je dan niet zelf al je software pakketen in de gaten te houden, maar de package manager verteld je van welke pakketen er nieuwe versies zijn, en helpt je die te downloaden.

Je kunt het redelijk vergelijken met hoe Windows Updates werken, maar dan voor alle software op je systeem.
Onzin, met Microsoft System Manager Server kun je geautomatiseerd voor heel het domein je updates downloaden en distribueren wanneer het JOU uit komt.

Hoezo je vakgebied niet kennen en Windows maar wat afzeiken.
ook onzin. Fabrikanten van software kunnen op verzoek hun software gewoon herkenbaar maken in microsoft update (das het voordeel boven het gebruik van windows update, microsoft update is wat uitgebreider).

Dat geen enkele fabrikant (behalve enkele driver fabrikanten) er op dit moment gebruik van maken, kan MS ook weinig aan doen.


En daarnaast bestaan er MSI's met een patch functie (MSP). Die patches kun je sinds de nieuwe msi versies (als die gebruikt worden) via add/remove programs zelfs onafhankelijk van elkaar deinstalleren.
Hij vermeldt 'distro's', wat me doet denken dat hij vooral over Linux praat. En in Linux wordt je hele systeem geüpdatet door de package manager, terwijl op Windows de update-functie alleen Microsoft-componenten updatet.
Jouw reacties is ook erg simpel
Software producenten moeten de fouten fixen En de oplossing delen.
Securety patches zijn taken van de OS. atans de Meeste besturings systemen/Distro's hebben dit.
Ik snap jouw redenering niet helemaal. Ja je hebt gelijk in het feit dat security moet worden opgelost in het OS. Maar dit geldt alleen voor het OS gedeelte. We spreken hier echter niet over een OS probleem maar over een Applicatie probleem. Dit is een totaal andere tier binnen het begrip desktop.

Een systeem is opgebouwd uit een aantal componenten te weten:
  • Operating systeem.
  • Applicaties.
Hiernaast heb je soms een backoffice tier welke behoord tot je infrastructuur. Simpele voorbeelden zijn:
  • Groupware.
  • File sharing.
  • Database.
  • Applicatie servers.
Ook deze systemen bestaan uit meerdere lagen zoals een desktop waarbij Unix (achtigen) een wat mooiere scheiding hebben dan Windows systemen. Maar ook hier geldt:
  • Operating systeem.
  • Applicaties/Services.
Binnen deze entiteiten (server, werkplek) zit nog een stukje security en controles. Je zou in theorie de hele boel uit kunnen kleden volgens het ISO model met haar 7 lagen en hiernaast de OS en Applicatie tiers kunnen leggen.

Zo heeft het OS inderdaad de verantwoording dat deze controle's moet uitvoeren op data die haar wordt aangeboden. Bijvoorbeeld een malformed datachunk die naar de IP stack wordt gezonden of naar de hardware abstractie laag. Maar in dit geval zit het totaal anders.

De reden dat dit totaal anders zit en geen verantwoordelijkheid rust bij het OS is als volgt: Op disk staat ergens een blok data, te identificeren als een Binary/TIFF bestand. Dit is gewoon een stream aan bytes. De interpretatie van deze bytes zit op applicatieniveau, voor het OS is het gewoon een stream binaire data, zonder enige structuur. De structuur wordt bepaald door de applicatie. Onder Windows zie je in explorer dat het een TIFF bestand is, maar dat komt omdat de Explorer ook een applicatie is die toevallig de link kan leggen tussen extensie en het soort data wat met deze extensie wordt beschreven. Een TIFF bestand hoeft tenslotte geen TIFF te heten maar mag ook JPG heten of TXT. Het afhandelen geschied echter in de applicatie en daar heeft het OS geen weet van. De applicatie leest dus het bestand in, het OS geeft de bytes terug als een rauwe chunk data. Het OS mag dan ook totaal niet ingrijpen in de vraag van de applicatie, manipulatie van de data en checks liggen volledig bij de applicatie die de data moet verwerken. Dat deze applicatie er niet goed mee omgaat en er een eventuele security breach is is het probleem van deze applicatie. Het enige wat mag gebeuren is een virusscanner die tussen applicatie en OS in zit, deze zou mogen ingrijpen, maar geen data mogen manipuleren.

Dit soort problemen zijn dus altijd Applicatie problemen en de verantwoording ligt dus altijd bij de schrijver van de applicatie. Hierbij is echter één uitzondering te maken en dat is wanneer het fout gaat bij een API die integraal onderdeel uitmaakt van het OS, bijvoorbeeld een hypotetische OS API call ConvertTag(*Compressed data, *Uncompressed data). Wanneer deze call de mist in zou gaan dan is het een OS probleem, helaas is dit bij deze bug niet het geval en praten we gewoon over beroerd programmeren met verkeerde checks. Neem bijvoorbeeld de simpele pseudocode:
B= Buffersize
Buffer= GetMem(Buffersize)
P= 0
Herhaal
X=Lees volgende byte
U=Unpack byte (variabele lengte)
Buffer[P]= U
P=P+Lengte(U)
Tot Laatste byte is gelezen
Bovenstaande code is vragen om probleem. Onderstaande code echter:
Buffer= GetMem(Buffersize)
P= 0
Herhaal
X=Lees volgende byte
U=Unpack byte (variabele lengte)
Als P+Lengte(U)>(BufferSize) dan Exceptie "Bufferoverflow"
Buffer[P]= U
P=P+Lengte(U)
Tot Laatste byte is gelezen
Zeker als je weet dat er geen update naar 2.3 wordt gedaan onder Ubuntu 7.04 en men gaat wachten tot de nieuwste release van Ubuntu voor de 2.3
security patches worden dan (eventueel enigzins aangepast) tegen de oudere versies uitgevoerd en opnieuw gecompileerd...
waardoor de bug ook in oudere versies verholpen is

wat belet je om het zelf te fixen?
In Ubuntu 7.04 (nieuwste versie dus) zit nog steeds OpenOffice 2.2. En ik krijg geen melding van software updates dus voor zover ik weet ben ik helemaal up-to-date.

Nu kan ik wel zelf versie 2.3 installeren, maar eigenlijk heb ik er weinig zin in om buiten mijn package manager om te gaan rommelen om een update te installeren, dat zou de package maintainer moeten doen.
Hmm, heeft Ubuntu nog geen security update?
Debian wel: http://www.debian.org/security/2007/dsa-1375

Een dikke week geleden opgelost voor alle actuele versies die ze ondersteunen (zowel 1.1.3, 2.0.4, 2.2.1 als 2.3.0 in oldstable, stable, unstable en experimental)
Niet alle software updates worden door je package manager geinstalleerd, alleen updates die getest en 'veilig bevonden' zijn voor de Ubuntu distributie waar je nu mee werkt. Meestal zijn dat alleen minor version updates.

Grotere software updates zoals OO 2.3 worden pas geinstalleerd in een upgrade naar een nieuwe distributie en worden eerst getest in samenhang met alle andere applicaties voordat ze worden uitgeleverd.
Veel distro maintainers voeren back-ports uit van kritieke bugs. SUSE doet dit in ieder geval en gezien de post van _JGC_ doet Debian dat ook.
Het komt bij mij haast over alsof iemand zich de moeite heeft genomen om de checklist vd updates te bekijken en dan vervolgens daar een al bekende bug blijkbaar bij de OO team publiceerd. Beetje erg slappe manier imo om publiciteit te trekken.
Ik vraag me eigenlijk zo wel af hoeveel meer bugfixes er gedaan worden die niet bekend zijn gemaakt.
Vaak houden security researchers bugs geheim voor het grote publiek totdat er een patch is, dat was altijd de standaard manier om met security om te gaan en de meest fatsoenlijke, tegenwoordig is dat blijkbaar bij de n00bs & fanbois een teken van te kwader trouw handelen.

Mischien prefereer jij het als men een ernstige remote exploit onmiddelijk bekend maakt in de toekomst voordat er een patch voor is?

[Reactie gewijzigd door Tijger op 26 september 2007 09:24]

Correct. Alleen als software leveranciers er voor kiezen om het laag op een prio lijstje te ztten komen ze er vaak wel mee naar buiten om zo de leverancier te "dwingen" sneller met een oplossing te komen.
http://qa.openoffice.org/issues/query.cgi alle bekende bugs van OpenOffice staan hier. Indien ze niet hier staan weten de mensen achter OpenOffice er niets van.

OpenOffice zelf houdt niets geheim tot er een patch is.
@Tijger moeilijk te geloven dat een 40 jarige man zich zo uitlaat.. maar ik prefereer inderdaad dat fouten bekend worden gemaakt zodoende weten eindgebruikers namelijk waar ze aan toe zijn. Hoe zou jij het vinden om te weten dat je voordeur een klein halfjaartje eigenlijk niet sluit. Ik zou dat zelf minder charmant vinden en zou dan ook door Lips of in dit geval door OO op de hoogte willen gesteld worden van dit probleem. Zodoende zou ik bv ervoor kunnen kiezen om OO te chroten of bv onder een aparte user te draaien ipv nietswetend misschien mijn systeem te laten misbruiken. Want mocht iemand dit vinden betekend dat andere dit misschien ook gevonden hebben en die hebben ipv dit te publiceren er misbruik van gemaakt.
Hoe zou jij het vinden om te weten dat je voordeur een klein halfjaartje eigenlijk niet sluit. Ik zou dat zelf minder charmant vinden en zou dan ook door Lips of in dit geval door OO op de hoogte willen gesteld worden van dit probleem.
Het moet natuurlijk ook niet om een halfjaar gaan; maar een week of 2 is best acceptabel.

Om op jouw voordeur-verhaal terug te komen: stel jouw voordeur staat open, heb je dan liever dat ik aan jou meldt: je voordeur staat open of dat ik gelijk een groot neon-bord in je tuin plaats met een pijl naar je deur: "Open!!!".

Ik ben absoluut voor openheid rondom bugs en met name security bugs, maar als je een "nieuwe" bug vindt, lijkt het mij toch handiger om de leverancier even de tijd te geven om het probleem op te lossen voordat het publiek bekend gemaakt wordt; dat publiek bekend maken kan altijd nog als stok achter de deur gebruikt worden als de leverancier vertikt het probleem op te lossen.
@Tijger

Het idee is, zoals n4m3l355 al zegt, duidelijkheid verschaffen. Dat je zegt dat n00bs & fanbois ter kwader trouw handelen is niet helemaal waar. Vaak wordt een bedrijf op de hoogte gesteld van een dergelijke bug, als er binnen (een redelijke) korte tijd geen fix is dan wordt de bug gepubliceerd om druk te zetten.

Bij Windows is het wat anders, daar wordt geprobeerd om Microsoft in een zo kwaad mogelijk daglicht te stellen. Voor een beetje marktwerking misschien niet verkeerd, maar totaal onetisch en onverantwoord. Dat laatste omdat Windows op zoveel desktops draait, zowel thuis als op vele werkplekken.
Ik ben zelf geen liefhebber van OO, maar om nu hiermee te komen gaat wat ver. Het probleem is immers al opgelost in de nieuwste versie. Altijd zorgen dat je software up-to-date is.
Maar goed dat OO nog niet zo populair is in het bedrijfsleven want je beseft niet wat het kost om een nieuwe applicatie uit te rollen. Zo simpel als jij het stelt is het namelijk niet.
  • Inventariasatie verschillen van versies.
  • Impact analyse van de nieuwe versie voor werknemers.
  • Bouwen van installatie package.
  • Testen van nieuwe applicatie.
  • Impact bepalen voor andere applicaties en macro's en huisstijlen.
  • Budget en uren vrijmaken voor de uitrol.
  • Uitrolplan samenstellen.
  • Eventuele procedures aanpassen.
  • Testgroep samenstellen.
  • Testen met beperkte groep gebruikers.
  • Eventuele test uitkomsten vewerken.
  • Eventueel gebruikers opleiden.
  • Uitrollen.
  • Nazorg.
Afhankelijk van het aantal werkplekken en werknemers kan het implementeren van een nieuwe versie tussen de ¤ 1.500 en ¤ 50.000 euro kosten. En dan spreken we alleen over de uren en nemen we niet mee dat er ook productieuren verloren gaan op de werkvloer waardoor de "verborgen" kosten ook nog meewegen.

Een update van een aantal binaries heeft veel minder impact en kost met een goede software distributie architectuur veel minder, bijvoorbeeld met Altiris:
  • Altiris job bouwen.
  • Proef uitrol.
  • Testen en Impact analyse.
  • Uitrol.
Afhankelijk van het uurtarief van de beheerder/bouwer/scripter kost dit ongeveer tussen de ¤ 500,00 tot ¤ 1.000.

Persoonlijk denk ik dat er te simpel wordt geroepen dat het installeren van een nieuwe versie de oplossing is. Binnen een managed omgeving, waarbij de principes van ITIL worden aangehouden (ITIL<>regels) en volgens Prince2 wordt gewerkt heeft een dergelijk iets een zodanige impact dat je niet ff 1.000 desktops in één keer van een nieuwe versie voorziet. Serieuze ICT afdelingen zijn namelijk het "doen we even tussendoor" amateur pricipe al lang voorbij.
Wat een onzin "oude bug"

Als dit windows was zou iedereen aan het klagen zijn...

Weet je hoeveel mensen dit niet lezen en vurnable zijn voor attacks, en geloof me er zijn genoeg mensen die hier misbruik van maken.

Bovendien is dit zon lek waarbij het mogelijk wordt op kwaadaardige programmacode te laten uitvoeren waardoor het probleem toch aanzienlijk groter is dan bijvoorbeeld een simpele dos vurnability

[Reactie gewijzigd door blizz107 op 26 september 2007 09:26]

Het is een standaard buffer overflow exploit. Een standaard bug die veel voor komt en bijna nooit net nieuws bereikt tenzij het remote exploitable is. Verder zijn dit soort bugs niet exploitable op systemen die shared libraries op random memory locaties plaatst. Verder bij goed gebruik van de NX bit is dit ook te verhelpen. Address space layout randomization staat standaard aan in Linux 2.6.20 en Open BSD kernels. Vista doet het alleen voor applicaties die er special voor compiled zijn.

anyway...
Ik zie niet in waarom er een nieuws item geplaats moet worden voor een simpele niet remote exploitable buffer overflow bug.
Een klein overzichtje van debian packages die een buffer overflow fix hadden:

[09 Sep 2007] DSA-1372 xorg-server: buffer overflow
[04 Sep 2007] DSA-1368 librpcsecgss: buffer overflow
[04 Sep 2007] DSA-1367 krb5: buffer overflow
[29 Aug 2007] DSA-1361 postfix-policyd: buffer overflow
[28 Aug 2007] DSA-1360 rsync: buffer overflow
[26 Aug 2007] DSA-1358 asterisk: several vulnerabilities
[07 Aug 2007] DSA-1351 bochs: buffer overflow
[22 Jul 2007] DSA-1336 mozilla-firefox: several vulnerabilities
[07 Jul 2007] DSA-1331 php4: several vulnerabilities
[07 Jul 2007] DSA-1330 php5: several vulnerabilities
[01 Jul 2007] DSA-1328 unicon-imc2: buffer overflow
[28 Jun 2007] DSA-1323 krb5: several vulnerabilities
[23 Jun 2007] DSA-1320 clamav: several vulnerabilities
[23 Jun 2007] DSA-1317 tinymux: buffer overflow
[19 Jun 2007] DSA-1313 mplayer: buffer overflow
[09 Jun 2007] DSA-1301 gimp: buffer overflow
etc.
Dit lijkt me een nogal klassieke bug. Als deze al door het vangnet heen is gekomen, wil dat dan niet zeggen dat er nog veel meer van deze kritieke fouten in OpenOffice zitten?
Inderdaad... zo'n buffer overflow zit aan de basis van een heleboel bugs. Kunnen ze daar nou niets aan doen? Eens een beetje meer range-checking doen.

Of moet misschien C++ eens een beetje aangepast worden? Het heeft me altijd verbaasd hoe makkelijk men daar met pointers smijt. Met bijvoorbeeld Pascal had je die dingen veel minder hard nodig, en werkte je met normale taal-constructs. Die hadden hun eigen range-checking, en daardoor kun je volgens mij de meeste van dit soort buffer overflow's vermijden...


Verder.... hadden de moderne CPU's niet opties om dit soort misbruik te voorkomen? Worden die nog steeds niet gebruikt, of zijn die toch niet zo effectief als men het deed voorkomen?
Automatische range checking is in dit geval vrij lastig omdat bij het inlezen van binaire bestanden erg lowlevel gewerkt moet worden. Ook als je het in pascal schrijft.

In C++ zal men niet gauw automatische range checking toevoegen aangezien C++ is gericht op volle snelheid. Als je echter goed C++ programmeert zijn de kansen op dit soort fouten gering. Echter een hoop C++ programmeurs zijn eigenlijk C programmeurs die nooit de moeite hebben genomen om de volledige kracht van C++ te ontdekken en dus vaak onveilige C oplossingen gebruiken in plaats van de veiliger C++ oplossing. Maar TIFF bestanden lezen blijft lastig.

Overigens is het wel een bekend probleem dat bij inlezen van bestanden de code er te vaak vanuit gaat dat het bestand klopt.
Waarom zou range checking ineens moeiliker zijn bij het inlezen van binaire bestanden?

Gewoon een nette range checking heeft ook vrijwel tot geen invloed op de snelheid van een stuk software. Dat valt namelijk zelden tot nooit in die 10% van het programma dat daadwerkelijk de snelheid van het programma bepaald.

En wat is er nou lastig aan het lezen van een TIFF bestand?
Ze hadden even moeten checken of de data die ze aan het inlezen waren niet buiten maxint zou vallen. Dat is helemaal niet lastig.
Het betekent alleen dat je op een andere manier moet gaan denken.

Zodra je ongecontroleerde input moet afhandelen zou een programmeur meteen in "paranoïde modus" moeten springen en alle waarden die ie inleest checken en doublechecken.
Helaas doet bijna niemand dat en wordt het ook mensen ook zelden aangeleerd bij cursussen.

95% van alle exploits waren gewoon te voorkomen geweest als er van tevoren beter naar dit soort zaken gekeken was geweest.

En wat betreft die performance: Heb je ooit een fix voor een exploit meegemaakt die een stevige performance impact op de applicatie had?
Ik niet!
In elk programma zitten bugs en aangezien elk programma door mensen is geschreven zal elk programma ook domme bugs bevatten. Veel belangrijker is: hoe snel worden bugs opgelost. Ik heb veel liever een programma met 5 bugs, waarvan er 4 nog niet ontdekt zijn en waarvan de 5e morgen gepatched is, dan een programma met 2 bugs die allebei na ontdekking nog 3 maanden ongepatched blijven...
Het is een open deur maar natuurlijk zitten er nog meer kritieke fouten in OpenOffice. Net zo als er kritieke fouten in vrijwel alle andere software zullen zitten.

Zolang software ontwikkelaars niet defensiever gaan ontwikkelen blijf je fouten van dit soort kaliber tegenkomen. Daarnaast heb je nog een scala van andere fouten die net zo kritiek kunnen zijn. Ik dacht dat we nu wel wisten dat er geen software van enige omvang bestaat zonder fouten.
in ben het ermee eens dat in alle pakketten een of ander programeerfoutje zit. Op zich niet erg als het maar gefixed wordt. Een ander aspect is dat in een bedrijfsomgeving niet zomaar gepatched kan worden zonder dat er eerst een testfase tussenkomt.
Door die waarden in de tiff-afbeelding aan te passen, kan een buffer overflow getriggerd worden. Die zorgt ervoor dat de geheugenberekening een onjuist getal oplevert, waardoor er een incorrecte hoeveelheid geheugen wordt vastgelegd, wat een heap overflow oplevert.

Hierdoor is het mogelijk om kwaadaardige programmacode te laten uitvoeren op een computer...
Dit is echt Chinees voor mij. Onderstaande info uit wikipedia maakt e.e.a. misschien iets duidelijker
Wikipedia:

A buffer overflow is an anomalous condition where a process attempts to store data beyond the boundaries of a fixed-length buffer. (...)

A heap overflow is another type of buffer overflow that occurs in the heap data area. Memory on the heap is dynamically allocated by the application at run-time and typically contains program data.

Heap overflows are sometimes used by crackers to exploit poorly written software. Exploitation goes as follows: if an application copies data without first checking to see if it fits into the target destination, the cracker could supply the application with a piece of data that is too large, overwriting heap management information (metadata) near the destination. This allows an attacker to overwrite an arbitrary memory location with a small amount of data. In most environments, this may allow the attacker control over the program execution.
Hmm, Tiff licentie is in handen van Adobe en die hebben ook de PDF-lienctie.

Zou hier een overeenkomst zitten?
Dat de Tiff code binnen PDF's tot dezelfde problemen leidt?
Waar ik me mateloos aan irriteer is dat OO 2.1 (of 2.2) zelfs niet eens de melding geeft dat er nieuwe patches zijn. Terwijl ik op zijn minst wil weten dat ik handmatig kan upgraden naar versie 2.3.
Heb je de optie "automatisch controleren op updates" wel aanstaan, dan?
Dat is natuurlijk niet zo heel erg belangrijk op het moment dat het ook niet gebeurt als ik handmatig controleer.
Lijkt mij meer een taak voor de installatie manager in je OS die dat mag bijhouden. Maar punt blijft dat het dan ook wel gedaan moet worden.
Er zijn meer applicaties (bv. Opera) die zelf checken of er een update beschikbaar is. Dus dat zou prima in de applicatie kunnen.
Het kan prima in de applicatie, maar dat geeft wel erg veel overhead (zowel in je systray als volledig op de achtergrond lopen handen vol updaters en andere onduidelijke applicaties). Misschien is het handiger als de package manager dat bijhoudt. Gemiste kans in Vista, misschien iets voor Windows 7.0. Of het komt natuurlijk in een belangrijke update van MSI uit.
En vervolgens kunnen bepaalde attention whores weer paniek gaan zaaien dat de privacy geschonden word door het naar huis bellen ;)

maar goed, dat is een optie die tijdens de installatie gepresenteerd moet worden.
Ik vind de Windows-update best een handig iets, maar ik heb er nooit bij stilgestaan dat Microsoft die ook open zou kunnen stellen voor klonen en concurrenten van hun producten.

Lijkt me ook niet dat dat ooit gaat gebeuren.
Wat ik me afvraag is hoe dit een gevaarlijke bug kan zijn??? Iedereen die probeert een corrupte tiff in zijn OOo-writer (Overigens de enige goede schrijfwijze, niet OO) te plaatsen crasht zelf. Dus lijkt het mij onmogelijk om op deze manier een corrupt bestand te maken welke je daarna met opzet rond gaat mailen...
Hooguit als het om een externe link (dus niet embedded) gaat kan je de tiff naderhand aanpassen of vervangen dor een corrupte.
Het komt in ieder geval niet over als iets heel gevaarlijks, of ben ik nu gek?

[Reactie gewijzigd door Savantas op 26 september 2007 10:00]

Wat ik me afvraag is hoe dit een gevaarlijke bug kan zijn??? Iedereen die probeert een corrupte tiff in zijn OOo-writer (Overigens de enige goede schrijfwijze, niet OO) te plaatsen crasht zelf. Dus lijkt het mij onmogelijk om op deze manier een corrupt bestand te maken welke je daarna met opzet rond gaat mailen...
Hooguit als het om een externe link (dus niet embedded) gaat kan je de tiff naderhand aanpassen of vervangen dor een corrupte.
Een malware verspreider maakt een odt file met daarin een normaal tif. Even open met winzip en de tiff vervangen door een speciale geprepareerde tiff file die inspeelt op deze vunerability en malware kan verpreiden en klaar.
En dan even naar je botnetweerkje overzetten om massaal deze geprepareerde .odt filetjes te gaan verspreiden via email.
Dat vroeg ik me dus ook af. Je kunt een buffer overflow krijgen, wat heb je daaraan? hoe kun je dankzij een crash nou een pc overnemen :?

Thuis ook mijn OO maar snel updaten in elk geval :/ wel mooi dat er al een fix voor is.
Je hoeft het document niet in OOo aan te maken..

@Metro2002: Kan wel degelijk, zie de uitleg van Rekcor hieronder.

[Reactie gewijzigd door mae-t.net op 26 september 2007 13:01]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True