I'd be very surprised if XML MARID documents exercised every single
line of code in your XML library, so the absolute size of the
library isn't necessarily significant, is it?
Bad guys can publish any complex and hostile MARID documents they
want. Typical MARID documents are indeed likely to be pretty simple,
but if word gets around that there's a bug in an XML library, how long
will it take until there's MARID data to exploit it? Minutes, I'd
guess.
This is uninformed scaremongering.
If there is a bug in the XML parser libraries in use today it will be
quickly uncovered by other applications where the consequences are likely
to be more than a DDoS attack.
The advantage of using standards is that you test out your software
components in multiple environments. The XML parser in windows is
used by IE, web services, etc. etc. The XML parser in apache has been
extensively tested in other programs.
This is one of the major benefits of standards and software architecture.
Look, we know that the messaging world is currently adopting a major
XML based standard - RSS/ATOM. It has already adopted HTML and may
well adopt Jabber as a standard, if not Jabber whatever does succeed
in that space will be a Web Service.
So scaremongering about XML parsers is besides the point. I can write
an XML parser in a couple of pages of code. All it takes is an FSM with
a small amount of support code. It takes a lot more to write a validating
parser, but not as much as you might think.
And in any case, if you are still using a language that is vulnerable to
buffer overflow issues you are a decade out of date. There are plenty of
languages that implement bounds checking, Java, C#, FORTRAN, ALGOL60.
If people want to write in C I can give them a couple of range checking
macros which prevent overrun conditions - starting with:
#define strncpy() exit(-1)
Phill