[dcc2] Multi file sends

Mon Apr 26 21:43:32 EDT 2004

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. 

I would agree that if it's not explicit already, it should be made
explicit that the file name and path in multi is relative, and must be
handled that way (with ../ disallowed). I assumed that it was, but
maybe that is not clear.  We could also standardize on a directory
separator (/ or \, doesn't really matter).

Welcome, by the way. I think it's your first post, we are glad to have
your input!

Jeremy

-----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