OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Managing Innovation

[ Lists Home | Date Index | Thread Index ]

Bullard, Claude L (Len) writes:

 > Any system can be hacked and security bugs show up in all of them.
 > The issue of the monoculture is real enough, but not a catastrophe.
 > One could make the claim that securing one system is all that is
 > needed, but the facts say otherwise.

As John mentioned, you need to be careful about using the word
"hacked", because it has different meanings for different people.
For many developers, "easily hacked" means "easily extended and
maintained".  If you use the term "cracked" in your postings, there's
no ambiguity.

Microsoft is going through a painful, decade-long transition from
standalone and single-user to networked and multi-user -- the
transition means abandoning many principles that were originally dear
to them (and brought them great success in the standalone days), like
*always* favouring convenience over security.  Some of the
optimizations they made, like putting so much in the kernel (including
a lot of GUI code), will also keep coming back and biting them for a
while, since every bit of code inside the kernel is a potential

Posix operating systems also have vulnerabilities, of course, but
because they were designed to be multiuser and networked from the
start, their fundamental design is more sound: as I mentioned earlier,
Posix systems tend to have relatively thin kernels and do most of
their work in user space, so they can be hardened to a large extent
simply by making sure that the user-space programs do not have root
permissions.  Not everyone does that, but at least it *can* be done.

So, what about XML and its related specifications?  I'm afraid that
we're more like Microsoft than like the Posix systems: we're starting
with glaring security holes like external DTD subsets and external
entity references for the sake of convenience, and we will have to fix
those holes later if XML ever becomes popular on the Web.  With no
fixed limit on element names, number of attributes, nesting depth,
etc., XML applications can also easily fall prey to buffer-overflow
attacks or denial-of-service attacks if they are not very carefully
written.  I believe that the old SGML declarations were very annoying,
but it might not hurt to set some arbitrary, very high limits for the
next version of XML, such as

  Maximum name length: 4096 characters
  Maximum attributes:  1024
  Maximum element nesting depth: 65536

etc.  Every robust XML application has to do that anyway to avoid
either buffer-overlow or DOS attacks (by memory exhaustion), so it
would be a good idea to start spreading a good, standard practice now.

All the best,



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS