Nederlanders vinden onafhankelijk van elkaar zelfde lek in OpenOffice

Nederlandse beveiligingsonderzoekers hebben een lek ontdekt in Apache OpenOffice dat ertoe kan leiden dat een aanvaller een heel systeem kan overnemen. Een update die het lek verhelpt is onderweg en is nu een releasecandidate.

Fedora 10 -- Gnome -- OpenOffice.org 3

Alle versies van Apache OpenOffice tot en met 4.1.16 zijn kwetsbaar, blijkt uit de melding van Apache. Het gaat om CVE-2026-63277 en zit in de integratie van de Java-runtime van OpenOffice. Gebruikers die nog niet kunnen of willen updaten naar 4.1.17 kunnen die runtime uitzetten in de instellingen. Het is onbekend of het lek actief misbruikt wordt.

Twee van de drie ontdekkers van het lek zijn Nederlanders. Het gaat om Thomas Rinsma van Codean Labs, die samen met collega Edoardo Geraci het lek ontdekte, en om Rick de Jager van V12 Security. Volgens Apache ontdekten Rinsma en Geraci het lek onafhankelijk van De Jager.

Reacties (33)

[closefuture]

De melding van LibreOffice is wat duidelijker:

When linking spreadsheet cell ranges to external data sources in Calc, a document can specify an external Java database driver. By convincing a user to open a specially crafted document, a remote attacker can force the application to download and execute untrusted Java code from a remote location, resulting in arbitrary code execution.

Tja, als je een externe JDBC driver kunt opgeven die dan gedownload word en geinstalleerd word is het wel game-over ja. Klinkt als een feature die in de 00's een goed idee leek om er in te stoppen.

[Little Penguin]

Het is nooit een goed idee geweest om code van derden zomaar uit te kunnen voeren, hoewel daar in rond de eeuwwisseling wel anders over gedacht werd.

Wat me vooral verbaast is dat er nog steeds software is die code van een arbitraire bron op kan halen en uitvoeren (met dezelfde rechten als de gebruiker), dat was al een slecht idee toen (denk aan de embedded code in Word/Excel e.d. en de ActiveX-controls in IE) en nu (denk aan de aanvallen op npm).

Maar als ik deze reactie goed begrijp zit de bug ook in LibreOffice, als dat zo is zou dit ook wel bij de titel van dit bericht mogen staan...

[bzzzt]

Het is nooit een goed idee geweest om code van derden zomaar uit te kunnen voeren, hoewel daar in rond de eeuwwisseling wel anders over gedacht werd.

Je tikt nu je reactie in een browser die niets anders doet dan remote code uitvoeren. Hopelijk met voldoende veiligheidsvoorzieningen.

Wat me vooral verbaast is dat er nog steeds software is die code van een arbitraire bron op kan halen en uitvoeren (met dezelfde rechten als de gebruiker), dat was al een slecht idee toen (denk aan de embedded code in Word/Excel e.d. en de ActiveX-controls in IE) en nu (denk aan de aanvallen op npm).

Word macros worden in een beperkte sandbox uitgevoerd (soms net niet beperkt genoeg), ActiveX controls moesten worden gesigneerd zodat code traceerbaar was naar een persoon (beetje vergelijkbaar met app stores nu).

Maar als ik deze reactie goed begrijp zit de bug ook in LibreOffice, als dat zo is zou dit ook wel bij de titel van dit bericht mogen staan...

LibreOffice heeft bepaalde Java functionaliteit herschreven, maar de interface zodat Java database drivers gebruikt kunnen worden zal mogelijk nog wel bestaan.

[Little Penguin]

Je tikt nu je reactie in een browser die niets anders doet dan remote code uitvoeren. Hopelijk met voldoende veiligheidsvoorzieningen.

Daar heb je gelijk in en ik heb even overwogen om dat te benoemen, maar vond het niet relevant voor deze discussie.

Want, de code die uitgevoerd wordt gaat namelijk primair over het manipuleren van de DOM en in JavaScript, zoals browsers dat uitvoeren, zit geen functionaliteit om het lokale bestandssysteem te benaderen. Dat neemt niet weg dat er nog steeds bugs in de implementatie kunnen zitten, maar het ontwerp is wel anders dan bij Java (ik vergeet gemaksderhalve even de Applet Sandbox van vroeger), waar tegenwoordig helemaal geen sandbox meer aanwezig is. Waarbij ik overigens vermoed dat dit stukje uit OpenOffice.org toch al niet van de Java Security Manager gebruik maakte...

Ik ben de uitdaging overigens aangegaan en heb voor deze ene reactie JavaScript in de browser uitgezet, ook gewoon om te kijken of Tweakers nog steeds aan graceful degradation doet.

Word macros worden in een beperkte sandbox uitgevoerd (soms net niet beperkt genoeg), ActiveX controls moesten worden gesigneerd zodat code traceerbaar was naar een persoon (beetje vergelijkbaar met app stores nu).

Alleen al de opmerking dat de sandbox soms net niet beperkt genoeg is dat moet al alarmbellen af laten gaan. Qua ActiveX in IE zal er mogelijk later signing toegevoegd zijn (of was het controleprocess nogal belabberd), ik heb namelijk wel kennissen moeten helpen (ergens begin deze eeuw) toen hun MS-Windows 98 besmet geraakt was door ActiveX-malware.

Ik blijf erbij dat een office-document en code gescheiden moet zijn...

* Little Penguin geeft overigens gelijkt toe dat JavaScript uitzetten de gebruikerservaring wel een stuk anders en wat bewerkelijker maakt. Nadenken over hoe teksten aangehaald moeten worden bijvoorbeeld, als dat goed overkomt is mijn geheugen op dat punt nog perfect... :-)

[bzzzt]

Want, de code die uitgevoerd wordt gaat namelijk primair over het manipuleren van de DOM en in JavaScript, zoals browsers dat uitvoeren, zit geen functionaliteit om het lokale bestandssysteem te benaderen.

Think again: https://developer.mozilla.org/en-US/docs/Web/API/File_System_API

Waarbij ik overigens vermoed dat dit stukje uit OpenOffice.org toch al niet van de Java Security Manager gebruik maakte...

Dat lijkt mij ook niet. An sich is het prima mogelijk Java code te sandboxen, maar de echte fout die ze gemaakt hebben is automatisch een stuk code downloaden en uitvoeren van een niet door de applicatie of gebruiker gekozen URL.

ik heb namelijk wel kennissen moeten helpen (ergens begin deze eeuw) toen hun MS-Windows 98 besmet geraakt was door ActiveX-malware.

Als je Windows 98 had waren ActiveX controls het minste van je zorgen. Feitelijk voerde dat OS alle code als 'root' uit dus malware kon je via vrijwel iedere invoer oplopen.

Ik blijf erbij dat een office-document en code gescheiden moet zijn...

Een heel mooie gedachte ware het niet dat vrijwel alle populaire document formaten (Word, PDF, HTML) voorzien zijn van macro- of script uitbreidingen. De pragmatische aanpak van het toevoegen van scripts om meer toepassingen mogelijk te maken zorgt er voor dat dit soort formaten op meer plekken gebruikt kunnen en dus zullen worden.

[necessaryevil]

Het is nooit een goed idee geweest om code van derden zomaar uit te kunnen voeren

Soms kan een lek juist daar voor zorgen. Bijvoorbeeld een buffer overflow of iets met de geheugenadrestoewijzing van arrays/strings die blijkbaar niet automatisch afgeschermd wordt door de compiler. Goed, eerlijk gezegd ligt dit op het randje van wat ik snap en weet, misschien heeft iemand een betere uitleg.

Ik weet ook niet of de bug die in het artikel genoemd word veroorzaakt door zo'n geheugen overflow.

[beerse]

Toegegeven, ik ben beslist niet op de hoogte van technische details. Maar gezien OpenOffice origineel gebaseerd was op java-code en praktisch niet zonder kan, ga ik er voor het gemak van uit dat de java-koppelingen voor OpenOffice interne code is.

Bij LibreOffice hebben ze hun best gedaan om java uit de interne code te halen, dat java code dus altijd externe code is en een drempel over moet.

Daarmee zijn uitdagingen met java code bij OpenOffice eerder een probleem dan bij LibreOffice.

[elmuerte]

Maar gezien OpenOffice origineel gebaseerd was op java-code en praktisch niet zonder kan, ga ik er voor het gemak van uit dat de java-koppelingen voor OpenOffice interne code is.

Dat is niet zo. StarWriter was at 10 jaar oud voordat Java 1 uit was. Ik denk dat pas toen Sun het kocht de Java integratie geïntroduceerd werd. Dit was voornamelijk om vanuit StarOffice gebruik te kunnen maken van, niet alleen JDBC, maar ook om StarOffice uitbreidbaar te maken met Java code. Beetje zoals Java applets browsers konden uitbreiden.

[amsterdamned]

Ik kan het zo gauw niet vinden, maar geldt dit ook voor Linux?

[tszcheetah]

Er staat in de CVE nergens dat het alleen voor Windows of MacOS is, dus ga er maar vanuit dat het probleem op alle platformen speelt.

Het scheelt wel dat OpenOffice niet zo populair meer is; LibreOffice wordt actiever onderhouden en meer standaard geleverd met Linux distributies. De vraag is alleen nog of LibreOffice niet ook hetzelfde lek bevat, aangezien ze een gedeelde geschiedenis hebben (en de bug mogelijk aanwezig was voor de LibreOffice fork).

[wamu]

De vraag is alleen nog of LibreOffice niet ook hetzelfde lek bevat, aangezien ze een gedeelde geschiedenis hebben (en de bug mogelijk aanwezig was voor de LibreOffice fork).

Het bevat hetzelfde lek, maar is ondertussen ook reeds gepatcht.

[Reactie gewijzigd door wamu op 6 oktober 2026 15:19]

[fastedje]

OpenOffice is op sterven na dood. Er zijn ondertussen genoeg forks zoals LibreOffice die beter onderhouden worden. Dit betekent niet automatisch dat er minder lekken in zitten, maar wel dat ze sneller gedicht worden.

[mk1992]

So what? Ik zoek een wit vel waar ik woordjes in kan typen en kan printen/mailen. Zo wereldschokkend is de ontwikkeling in een tekstverwerker/spreadsheet niet.

[beerse]

Het is de koppeling tussen OpenOffice (of LibreOffice) en de java-virutal-machine. Die zit in veel meer software die java-code kan uitvoeren voor add-ons en dergelijke.

Voor zover ik weet is dat onafhankelijk van het besturingssysteem. Maar wel kan LibreOffice zonder java, waar OpenOffice nog best wel afhankelijk is van java code waarmee de jvm daar niet zomaar uit kan.

[dmantione]

Zo te lezen heeft het ook betrekking op LibreOffice en daarmee op de meeste Linux-desktops. Je hebt er evenwel alleen last van als je Java in LibreOffice hebt ingeschakeld. Ik denk dat de meerderheid LibreOffice zonder Java gebruikt.

[El_Bartholomew]

Gewoon een stomme vraag. Ik draai almalinux als desktop en alle apps zoveel mogelijk via flatpak omdat dit een sandbox heeft.

Kan dit lek dan ook een gevaar zijn als Libreoffice via flatpak draait?

[dmantione]

Die sandbox moet je je niet teveel van voorstellen: Ja, Flatpak draait het in een container, maar je wilt juist bij je bestanden kunnen in LibreOffice, dus dat is allemaal beschikbaar. En als onbekende code kan draaien, kan deze dus bij je bestanden. Dus ja, het kan een gevaar zijn, maar ik zou verwachten dat Java ook in deze situatie uit staat.

[teek2]

Ja, mijn eerste reactie: Ach who cares, OpenOffice, die partij die hun naam niet kwijt wilde, maar ook geen onderhoud doen. Maar het is blijkbaar ook relevant voor LibreOffice en dat is WEL belangrijk.

[teek2]

Nou, deze auteur is toevallig een Tweakers OG met veel kennis dus ik zou dat niet zomaar zeggen, maar idd, veel lezers zullen in het bericht met zo'n titel direct naar LO speuren.

Misschien is de vraag ook wel: Waarom concentreren deze beveiligingsonderzoekers zich op OO en niet LO?

[Reactie gewijzigd door teek2 op 7 oktober 2026 08:25]

[Jerie]

Het lijkt er op dat de auteurs op Tweakers geen technische achtergrond hebben en meer IT nieuws naar het Nederlands vertalen zonder enig inhoudelijk begrip. Wellicht dat men erg jong is of met minder ervaring, maar hopelijk krijgt men wel de kans om op technisch vlak ook echt dingen te leren.

(Allemaal aannames. In dit geval incorrect.)

Ook goden zoals @arnoudwokke maken fouten. Het zijn net mensen.

Als je een fout ziet in een artikel: klik op Feedback (in dit geval kom je dan bij deze URL uit).

En ja, ik zou ook direct kijken of belangrijke forks (zoals LibreOffice, maar ook Collabora Online) er last van hebben. In mijn omgeving waar Collabora Online geïnstalleerd staat (Nextcloud), geen Java interpreter geïnstalleerd. Dus ik mag aannemen dat deze geen Java kan babbelen. Desktops is een ander verhaal.

[Z_God]

Het gaat niet om fouten, maar de auteur van dit stuk is vooral sterk met smartphones (volgens z'n bio) en lijkt nu weinig gelegenheid te krijgen zich in andere onderwerpen te verdiepen. Waarom er uiteindelijk zo'n artikel uitkomt waarin basale dingen lijken te missen, weet ik niet. Het gebeurt vaker dat Tweakers artikelen niet diep gaan. Dat heeft niets met fouten of schuld te maken, zeker bij journalistiek staat er vaak druk op de ketel, maar het zou wel fijn zijn als daar toch iets mee kan gebeuren.

[Jerie]

Juist als jij patronen ziet die je ook kunt onderbouwen is een discussie bij Geachte Redactie waardevol.

[Z_God]

Ik zal dat eens opzoeken, dank voor de tip!

[StefanJanssen]

Daar lijkt het wel op

[23m3]

Onafhankelijk van elkaar maar misschien wel dezelfde LLM gebruikt? Dat kan door de trainingset ook leiden tot gelijke conclusies.

[Bromano]

Precies wat ik dacht, tot zover het innoverend vermogen van LLM’s 🥴

[SnijtraM]

Open .. watte?! Bestaat dat nog?

[Raymond Deen]

Het is ook open Office en niet closed ms office. /s

Hoe oud is Java nu al niet? Toch gek dat dit soort lekken niet ondertussen al gevonden en gedicht zijn.

[StefanJanssen]

Het is zover ik begrijp ook geen lek in Java, maar in het uitvoeren van externe code die zomaar vertrouwd wordt.

[Little Penguin]

Het is de verantwoordelijkheid van de applicatie die gebruik maakt van een JVM (Apache OpenOffice in dit geval) om er voor te zorgen dat de juiste afscherming gebruikt wordt.

Tegenwoordig hebben diverse OS'en sandbox technology waarmee het mogelijk is om de rechten van de uitgevoerde code sterk in te perken. In dit geval zou alleen netwerktoegang naar een bepaalde host toegestaan moeten zijn (in hoeverre de sandbox op dit niveau beperkingen kan opleggen weet ik niet overigens; maar toegang tot het lokale systeem kan wel sterk beperkt worden...)

[Standeman]

Het heeft Bar weinig met Java an sich te maken. Anders kan je C/C++ wel van nog veel meer lekker berichten :+