[dcc2] Multi file sends

Mon Apr 26 21:46:20 EDT 2004

Jeremy Iverson <jeremy at algenta.com> said:

> Regarding security, we always need to be careful when implementing
> something, no matter what it is. Sure there can be vulnerabilities in
> XML parsers, but I seem to remember some implementations of strtok()
> itself having a rather serious hole in it awhile back. And people will
> also try to send malformed requests whether the format is XML or a
> token-based system. So it's a given that security is an issue, no
> matter what the format is. 
Well I've never heard of a strtok() exploit, I can't say that it doesn't 
exist, but I can't in my mind imagine how it would. Yes, people will try and 
find exploits in a token system as well. But, the parser will be far less 
complex and therefore should have less problems. I can think of tons of 
different things I'd try on a home built XML parser, and I'm sure some of 
them would indeed cause problems. On a token based system, it is far less 
complex and therefore there are less things to try. Just for example, a 
couple of things I'd try:
< name >< name></name >

<
n
a
m
e
>test<
/nA
Me>

<name><name><name><name><name><name><name>

</name><name>

Those are just some. An XML library would of course deal with all of those. 
But if someone is writing their own XML parser (as was suggested), then they 
have to deal with all those things. With a token based system, you just need 
to deal with missing/extra parameters, missing/extra quotes, and multiple 
spaces (maybe a couple others I forgot, but that's the majority of them). 
And, many of them can already be dealt with using the existing strtok() 
function. The only one that would need to be hand coded would be quote 
handling. With XML, there could be hundreds of potential illegal inputs that 
people try. And, as for using a library, libxml is a rather large library. If 
I remember, the rule of thumb is 1 bug per 1000 lines of code. Well the XML 
parsing libraries have several thousand lines of code. A token based parser 
might have 1-2 hundred. Just from the sheer size of the XML parsing 
libraries, you are bound to have more bugs. 

-- codemastr

> -----Original Message-----
> From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf
> Of codemstr at ptdprolog.net
> Sent: Monday, April 26, 2004 8:17 PM
> To: DCC2 Working Group List
> Subject: Re: [dcc2] Multi file sends
> 
> Tom McAlee <tom at klient.com> said:
> 
> > I'm not a fan of XMLifying everything, although this does seem to be
> 
> > an appropriate use of it.  Like others have said, even without XML 
> > libraries it wouldn't be much more effort than parsing a tokenized 
> > string.  For those who have and/or already use XML libraries, it
> will fit right in.
> 
> Would parsing XML be trivial? Sure. Well, at least parsing valid XML.
> But lets face it, not everyone is nice and plays by the rules. You are
> going to have people who will develop specifically crafted XML headers
> to try and cause crashes and exploits. Anytime you build a parser, you
> run the risk of these kinds of things. What happens if someone
> specifies an invalid tag? What happens if they leave out an ending
> tag? For get a quote? Specify multiple angle brackets? There could be
> hundreds of potential areas of issue with XML because it is rather
> complex. However, with a simple text format, you don't need much more
> than a modified strtok() [to support quoted strings] in order to do
> your parsing. We've all seen the havoc that DCC bugs can cause (mIRC),
> and those bugs occurred while parsing the incredibly simplistic format
> DCC uses today. Using XML makes the format more complex and therefore
> more bugprone. For example, one thing I'm thinking of right off the
> top of my head. HTML-style encoding. What if I want my meta data to
> include <test>hey</test>? Or even in the file description. To do that,
> I'm going to need to &lt; and &gt; That means the parser is going to
> need to decode HTML- style character codes. That is already making it
> a great deal more complex. 
> With a simple text format, the only kind of escaping you need is one
> for " 
> (\"). That's much easier than adding support for HTML character codes.
> 
> 
> If you use libxml/expat, you likely will not have problems (they are
> fairly well tested), but for those suggesting you can simply write
> your own basic parser, you're opening up a can of worms. If you do
> some Googling for "libxml exploit," you'll see that XML is no stranger
> to exploits and parsing bugs. 
> Why introduce these problems into IRC? 
> 
> Also another security and general issue associated with multi-sends. I
> don't see anywhere the draft mentioning how paths should be handled.
> In the samples, they all use "/path" notation. Well that's fine for
> the *nix world, but on Windows that's no good. But lets look at the
> opposite. If I do <name>C:\dir\file.txt</name> How should a linux
> client deal with that? But, lets consider the dangers of allowing
> paths. <name>C:\windows\system32 \my.dll</name>. Something like that
> would apparently be allowed using the multi file send system. That
> seems horribly dangerous to me. Personally, I again don't see the need
> to specify path information. As someone else said, if that's what you
> want, there are tons of compression programs out there that can
> maintain path information.
> 
> > Somebody else brought up the possibility of writing binary data at
> the 
> > beginning of the file.  I'm not so sure about that idea.  Given the 
> > skepticism thats already out there concerning DCC2's security, an
> open 
> > XML format that is easily readable by anyone is probably preferable.
> 
> > People are more comfortable with something when it is not obscured.
> 
> I still say a basic text format is best. Someone said my suggestion
> was no good because it doesn't allow meta data, so? Expand it so it
> can!
> FILE <ID> "<FILE.EXT>" "<DESC>" <SIZE> <CRC> "<META DATA>"
> FILE 1 "file.txt" "My fun file" 123 12341234 "Permissions=700
> Createtime=1234567890 Owner=joe"
> 
> That to me is much easier to parse than an XML file.
> 
> -- codemastr
> 
> > ----- Original Message -----
> > From: "Phoenix Fyrestar" <miyako_houou at comcast.net>
> > To: "DCC2 Working Group List" <dcc2 at dcc2.org>
> > Sent: Monday, April 26, 2004 7:23 PM
> > Subject: Re: [dcc2] Multi file sends
> > 
> > 
> > > Yeah, that was the point I was trying to make, though I think you 
> > > made it better than I did.
> > > At the end of the day, XML is not signifigantly more difficult to 
> > > parse
> > than
> > > any other effective scheme, and we get the benefit of having an
> open 
> > > and human-readable standard that is well understdood by many 
> > > applications with much library support.
> > > While it is always a good idea to consider alternate possiblities,
> I 
> > > think that spending too much time on comming up with another way
> may 
> > > lead to re-inventing the wheel so to speak.
> > >
> > > On Monday 26 April 2004 05:55 pm, Riley White wrote:
> > > > On Apr 26, 2004, at 3:44 PM, Phoenix Fyrestar wrote:
> > > > > I personally think that using XML is one of the better
> possible 
> > > > > solutions.
> > > > > While I understand the reluctance to do this because it would 
> > > > > require an XML parser, I think that any good solution would
> end 
> > > > > up comming back to something XML-like anyway.
> > > >
> > > > I honestly don't understand why XML could be considered a bad 
> > > > thing here. Some sort of format is going to have to be defined, 
> > > > and why not XML? For those of us that don't want to link to XML 
> > > > libraries, we're really only dealing with one specific format of
> 
> > > > data so it can be manually parsed just like any other solution 
> > > > will have to be. For those of us that don't mind using XML 
> > > > libraries, we have that choice. Manual parsing of XML conforming
> 
> > > > to a known schema may be a little more difficult than whitespace
> 
> > > > delimited strings, but, speaking as somebody whose had to do it
> on a couple of occasions, it's not too bad.
> > > >
> > > > --Riley
> > > >
> > > > _______________________________________________
> > > > dcc2 mailing list
> > > > dcc2 at dcc2.org
> > > > http://six.pairlist.net/mailman/listinfo/dcc2
> > >
> > > _______________________________________________
> > > dcc2 mailing list
> > > dcc2 at dcc2.org
> > > http://six.pairlist.net/mailman/listinfo/dcc2
> > >
> > 
> > _______________________________________________
> > dcc2 mailing list
> > dcc2 at dcc2.org
> > http://six.pairlist.net/mailman/listinfo/dcc2
> > 
> 
> 
> 
> -- 
> 
> 
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
> 

-- 