The previous journal entry (one of my auto-announcements) heralds a release
of my RPC::XML package that is going out to pre-emptively address a
potential security vulnerability. If you use the package, you really should
install this newer version.
As it was explained to me, XML-enabled applications that use parsers (such
as XML::Parser) which attempt to resolve external entities can be
subverted by sending a document with a carefully-constructed DTD that can
cause the service or application to attempt to access files or make Internet
connections that the developer of the service had not planned on. The person
who brought it to my attention will be sending a formal description to
relevant security watchdog groups.
Old news
Matts on 2002-11-02T16:17:08
This is old old news. I first thought about this when I was developing my first XML applications back in 1998. I think we probably talked about it on the perl-xml list back then, but I don't recall - it's a long time!
Anyway, I guess the issue is still a relatively minor security issue for most systems. I can see it being mainly a "discovery" mechanism, rather than an exploitation mechanism. You might conceivably be able to get some system to send back an error in the case of invalid content, which contains the original request, which potentially could include some included data. The bad thing of course is this data could potentially be something like
/etc/passwd.
One thing I thought about at the time was that it might be nice for XML to have forced external parsed entities to have a single top-level tag. This would alleviate some of the problem (i.e. a plain text document wouldn't work), but not all of it, obviously.
The other thing to watch out for would be any pure perl entity resolvers that might naively call open() on the filename, potentially allowing remote execution. I don't know of any such systems, but there's a remote possibility of something doing this.
Re:Old news
rjray on 2002-11-04T21:06:07
I had been under the (misguided) impression that entity resolution and validation were somehow linked, and that not providing the one (validation) meant you weren't doing the other.
It was a simple-enough fix, but since my server classes proudly identify themselves in headers, I didn't want anyone being left vulnerable.
