17 oktober 2006

De eerste analyses van de voor standaardisate bij ECMA ingediende specificaties van Office Open XML (OOXML), het door Microsoft gecreëerde XML-bestandsformat, leiden tot reacties, die het ergste doen vrezen voor het moment dat het formaat in gebruik komt. De reacties richten zich op verschillende aspecten van de specificaties. In essentie komt alles echter neer op het feit dat het door Microsoft bedachte XML-formaat niet aansluit bij de bestaande XML-industriestandaard en evenmin bij de daaruit voortvloeiende conventies. Zo ontstaan problemen die beveiligingsrisico's veroorzaken, zoals Righard Zwienenberg van anti-virusspecialist Norman stelt. Rob Weir richt zich meer op opgenomen afwijkingen van XML zelf, die, in zijn optiek, te maken hebben met het feit dat Microsoft niet bereid was om inconsistenties in de eigen bestandsformaten op te lossen voordat het een XML-bestandsformaat schreef. In de reacties op de opmerkingen van Rob Weir blijkt wel dat de consistentie met XML in het ODF-bestandsormaat wel aanwezig is. Het niet aansluiten bij geaccepteerde internationale standaarden is Microsoft eigen: zo wordt ook RFC 1521 voor het verzenden van mail niet gevolgd om zoveel mogelijk mail te kunnen laten zien.

Zwienenberg stelt dat doordat het bestandsformaat van de standaard afwijkt er aanzienlijke beveiligingsrisico's ontstaan. Het wordt dan namelijk mogelijk om systemen te confronteren met XML-documenten waarin exploits verwerkt kunnen zitten. 'Net als in Outlook en Outlook Express kan de hacker zich hierdoor uitleven om via allerlei verschillende constructies schadelijke code te verwerken in documenten', zo stelt hij. Zijn analyse is gebaseerd op de bevindingen van een groep internationale experts uit een onderzoek van de nieuwe Office-software. De introductie van XML-documenten in Microsoft Office brengt dezelfde mogelijkheden als de macro-virussen van weleer. 'Het opstarten van macro's in Office-documenten is een tijdje een gangbare methode geweest om computervirussen te verspreiden. Die rijke omgeving is straks terug als zij XML in het nieuwe Office hebben ontdekt'. Macro-virussen zelf zullen nauwelijks kans van slagen hebben, aangezien ze strakt in een afzonderlijk bestand worden opgeslagen dat heel goed op malware te scannen is. Dat is echter veel moeilijker bij XML-documenten. 'Door XML worden documenten tamelijk groot. Daarnaast moeten scanners eerst XML-documenten interpreteren om het leesbaar te maken. De scansoftware moet vervolgens het hele document uitkammen om te controleren of er geen kwaadaardige objecten in verwerkt zijn', stelt Zwienenberg. 'De kans is groot dat controle vooraf bij grote documenten misschien teveel tijd en geheugen zal vergen'. Als de officiële release van de software er is, is verder onderzoek dringend noodzakelijk. Weir wijst in zijn blog onder andere op de aanwezigheid van 'bitmasks', of 'a technique used by C programmers to encode multiple values into a single char (or int or long) variable by ascribing meaning to individual bits of the variables. For example, an 8-bit char can actually store the answer to 8 different yes/no questions, if we think of it in binary. So 10110001 is Yes/No/Yes/Yes/No/No/No/Yes. Expressed as an integer, it can be stored in a single variable, with the value of 177 (the decimal equivalent of 10110001). The C language does not provide a direct way to set or query the values of an individual bit, but it does provide some 'bitwise' operators that can be used to indirectly set and query bits in a bitmask. So if you want to test to see if the fifth (counting from the right) bit is true, then you do a bitwise AND with the number 16 and see if it is anything other than zero. Why 16? Because 16 in binary is 00010000, so doing a bitwise AND will extract just that single bit. Similarly you get set a single bit by doing a bitwise OR with the right value. This is one of the reasons why facility with binary and hexadecimal representations are important for C programmers'. Vervolgens gaat Weir in op de vraag wat dit met OOXML te maken heeft. Volgens Weir is OOXML 'pretty much a bit-for-bit dump of the Windows SDK memory structure. … It merely is a memory dump of a Windows data structure'. Er blijken heel wat bitmasks voor te komen in Microsoft's XML, zoals 'paragraph conditional formatting, table cell conditional formatting, table row conditional formatting, table style conditional formatting settings exception' enz. Weir is heel expliciet: 'Manipulating bits, my friends, is obscure in the realm of XML'. Hij heeft daar diverse redenen voor, die alle even valide zijn. 'One reason is addressing bits within an integer runs into platform-specific byte ordering difference. Different machine processors (physical and virtual) make different assumptions. A second reason to avoid bitmasks in XML is that avoids being part of the XML data model. You've created a private data model inside an integer and it cannot be described or validated by XML Schema, RELAX NG, Schematron, etc. Even XSLT, the most-used method of XML transformation today, lacks functions for bit-level manipulations. The use of bitmasks is not the thing to do if you want support in a wide set of tools and platforms. It can't be validated and it can't be transformed. Thirdly, the reasons for using bitmasks in the first place are not relevant in XML document processing. … But in XML, when the representation of the data is already in an expansive text representation to facilitate cross-platform use, trying to save a byte of storage here or there, at the expense of the additional code and complexity required to deal with bitmasks, that the wrong trade-off. Fourthy, bitmasks are not self-describing. If I told you the 'table style conditional formatting exception' had the value of 32, would that mean anything to you? Or would it send you hunting through a 6,000+ page specification in search for a meaning? But what if I told you that the value was "APPLY_FIRST_ROW", then what would you say? A primary virtue of XML is that it is humanly readable. Why throw that advantage away? Finally, there are well supported alternatives to bitmasks in standard XML, such as enumeration types on XML Schema. Why avoid a data representation that allows both validation and manipulation by common XML tools?' Volgens Weir is de enige reden waarom er bitmasks gebruikt worden, omdat Excel daarvan al gebruik maakte. Dus het is voor Microsoft makkelijker om de specificatie te laten aansluiten bij de broncode dan om gebruik te maken van een platform en applicatieonafhankelijk XML. Voor een ander voorbeeld van Weir dat op een afwijking in OOXML slaat klik hier.