MSN helper module

MSN helper module

[Carlos Fernandez Sanz]

Hi,

Is there a helper module for MSN? If not, is it being developed and can I
join the effort?

If nothing is being done I'll just write the module myself before not having
full MSN support becomes a serious issue and starts going up...

Re: MSN helper module

[Patrick Schaaf]

On Tue, Dec 17, 2002 at 12:57:35AM +0100, Carlos Fernandez Sanz wrote:
> 
> Is there a helper module for MSN? If not, is it being developed and can I
> join the effort?
> 
> If nothing is being done I'll just write the module myself before not having
> full MSN support becomes a serious issue and starts going up...

Ahem - what would such a helper module have to do? As far as I know,
MSN is an Internet Service Provider, and there is no network protocol
called MSN. Did that change? Do they do the AOL, 10 years later?

I sure hope so, it would be their final death.

Sorry for off-topic; my first question, above, is what should be discussed.

best regards
  Patrick

Re: MSN helper module

[Carlos Fernandez Sanz]

Patrick,

MSN is (other than a ISP), an instant messaging service like ICQ.
Unfortunately, one of the most used these days (because it's the Microsoft
supported one). The helper module would have to do the same thing the other
modules do - keep track of children connection, rewrite some packets to
change IPs, etc.

Carlos.

----- Original Message -----
From: "Patrick Schaaf" <bof@bof.de>
To: "Carlos Fernandez Sanz" <cfs-netfilter@nisupu.com>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Tuesday, December 17, 2002 08:54
Subject: Re: MSN helper module


> On Tue, Dec 17, 2002 at 12:57:35AM +0100, Carlos Fernandez Sanz wrote:
> >
> > Is there a helper module for MSN? If not, is it being developed and can
I
> > join the effort?
> >
> > If nothing is being done I'll just write the module myself before not
having
> > full MSN support becomes a serious issue and starts going up...
>
> Ahem - what would such a helper module have to do? As far as I know,
> MSN is an Internet Service Provider, and there is no network protocol
> called MSN. Did that change? Do they do the AOL, 10 years later?
>
> I sure hope so, it would be their final death.
>
> Sorry for off-topic; my first question, above, is what should be
discussed.
>
> best regards
>   Patrick
>

Re: MSN helper module

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Patrick" == Patrick Schaaf <bof@bof.de> writes:
    Patrick> On Tue, Dec 17, 2002 at 12:57:35AM +0100, Carlos Fernandez Sanz wrote:
    >> 
    >> Is there a helper module for MSN? If not, is it being developed and can I
    >> join the effort?
    >> 
    >> If nothing is being done I'll just write the module myself before not having
    >> full MSN support becomes a serious issue and starts going up...

    Patrick> Ahem - what would such a helper module have to do? As far as I know,
    Patrick> MSN is an Internet Service Provider, and there is no network protocol
    Patrick> called MSN. Did that change? Do they do the AOL, 10 years later?

  I don't know, cause I've never been there, but I think that he means the
MSN instant message protocol. There is even a possibility that this is just
IETF IMPP. (Embrace and extend...)
  I didn't think it needed NAT support.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPf9U/YqHRg3pndX9AQE8oAQA6QLDohf/d+Fi86FPQ2ONrk8LiSqgKmwI
aiG+cL6pmH+R5lihxYBWMEJ/T+2MpMfeopP4Hc/mquzrkOpo6J64J8EmeqlcAm9c
7Rn/K/MvLK2VXFSkqzahZ7S2t5QmfeCQPtgp3QePKqy79AszWW+bxracQ9+ES7A6
BAzsdtHuPhs=
=v3E+
-----END PGP SIGNATURE-----

Re: MSN helper module

[Carlos Fernandez Sanz]

Yes, it needs some support for file tranmission, voice, etc. The protocol
works a lot like FTP when using PORT (active) connections. The initiator
client sends its IP address and a port number for the other end to connect
to. For basic messaging it doesn't need any special NAT support, though -
the reason being that all connections are outgoing and there are no related
children connections.

So it is not a lot of work but it needs to be done. I haven't found anything
about it so I'm assuming no one has started any work, so I'll do it myself.
Anyway it's pretty much a one man job.

----- Original Message -----
From: "Michael Richardson" <mcr@sandelman.ottawa.on.ca>
To: <netfilter-devel@lists.netfilter.org>
Sent: Tuesday, December 17, 2002 17:46
Subject: Re: MSN helper module


> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Patrick" == Patrick Schaaf <bof@bof.de> writes:
>     Patrick> On Tue, Dec 17, 2002 at 12:57:35AM +0100, Carlos Fernandez
Sanz wrote:
>     >>
>     >> Is there a helper module for MSN? If not, is it being developed and
can I
>     >> join the effort?
>     >>
>     >> If nothing is being done I'll just write the module myself before
not having
>     >> full MSN support becomes a serious issue and starts going up...
>
>     Patrick> Ahem - what would such a helper module have to do? As far as
I know,
>     Patrick> MSN is an Internet Service Provider, and there is no network
protocol
>     Patrick> called MSN. Did that change? Do they do the AOL, 10 years
later?
>
>   I don't know, cause I've never been there, but I think that he means the
> MSN instant message protocol. There is even a possibility that this is
just
> IETF IMPP. (Embrace and extend...)
>   I didn't think it needed NAT support.
>
> ]       ON HUMILITY: to err is human. To moo, bovine.           |
firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
>
> iQCVAwUBPf9U/YqHRg3pndX9AQE8oAQA6QLDohf/d+Fi86FPQ2ONrk8LiSqgKmwI
> aiG+cL6pmH+R5lihxYBWMEJ/T+2MpMfeopP4Hc/mquzrkOpo6J64J8EmeqlcAm9c
> 7Rn/K/MvLK2VXFSkqzahZ7S2t5QmfeCQPtgp3QePKqy79AszWW+bxracQ9+ES7A6
> BAzsdtHuPhs=
> =v3E+
> -----END PGP SIGNATURE-----
>

Re: MSN helper module

[Carlos Fernandez Sanz]

Filip,

Thanks for the links. I have done some research already. I don't think it's
going to be a weekend project but possibly not a lot more :-) Anyway I don't
really have an option. It's starting to escalate...

BTW, when you started to work on this, did you take a look at the FTP
module? I think it solves most of the problems (including security), since
the connection method is identical to an active (PORT initiated) FTP data
connection.

Carlos.

----- Original Message -----
From: "Filip Sneppe (Cronos)" <filip.sneppe@cronos.be>
To: "Carlos Fernandez Sanz" <cfs-netfilter@nisupu.com>
Cc: <netfilter-devel@lists.netfilter.org>; "Michael Richardson"
<mcr@sandelman.ottawa.on.ca>
Sent: Tuesday, December 17, 2002 22:52
Subject: Re: MSN helper module


> On Tue, 2002-12-17 at 19:35, Carlos Fernandez Sanz wrote:
> > Yes, it needs some support for file tranmission, voice, etc. The
protocol
> > works a lot like FTP when using PORT (active) connections. The initiator
> > client sends its IP address and a port number for the other end to
connect
> > to. For basic messaging it doesn't need any special NAT support,
though -
> > the reason being that all connections are outgoing and there are no
related
> > children connections.
> >
> > So it is not a lot of work but it needs to be done. I haven't found
anything
> > about it so I'm assuming no one has started any work, so I'll do it
myself.
> > Anyway it's pretty much a one man job.
> >
>
> Hi Carlos,
>
> If you're thinking about this, these links will be of great help:
>
> http://www.hypothetic.org/docs/msn/index.php
> http://www.hypothetic.org/docs/msn/ietf_draft.php
> http://www.venkydude.com/articles/msn.htm
>
> I started working on a connection tracking module for this, but
> really didn't go any further than adding the basic conntrack/nat
> helper framework.
>
> If you're really serious about this, I can send you a diff of
> the basic conntrack/nat module to get you started. Just let me
> know.
>
> One thing to watch out for when writing a conntracker for
> this, is that the MSN packet that should add an expectation for
> a file transfer should contain data that like this:
>
> ...
> Invitation-Command: ACCEPT
> Invitation-Cookie: 33267
> IP-Address: 10.44.102.65
> Port: 6891
> AuthCookie: 93301
> ...
>
> Now the problem is that MSN also allows some chat-like protocol
> over the same port.
>
> If you're writing a conntracker, you must make sure that you
> are not parsing the "Messaging" packets as file transfer
> requests. Otherwise the code has a security vulnerability
> where a specially crafted "Messaging" packet can add a firewall
> connection expectation. When I realized my module was going to
> have to detect this, I realized this wasn't going to be a
> "weekend project" kind of thing and sort of gave up on it
> for now. It would be great if you picked up the slack !
>
> Regards,
> Filip
>
>

Re: MSN helper module

[Filip Sneppe (Cronos)]

On Tue, 2002-12-17 at 19:35, Carlos Fernandez Sanz wrote:
> Yes, it needs some support for file tranmission, voice, etc. The protocol
> works a lot like FTP when using PORT (active) connections. The initiator
> client sends its IP address and a port number for the other end to connect
> to. For basic messaging it doesn't need any special NAT support, though -
> the reason being that all connections are outgoing and there are no related
> children connections.
> 
> So it is not a lot of work but it needs to be done. I haven't found anything
> about it so I'm assuming no one has started any work, so I'll do it myself.
> Anyway it's pretty much a one man job.
> 

Hi Carlos,

If you're thinking about this, these links will be of great help:

http://www.hypothetic.org/docs/msn/index.php
http://www.hypothetic.org/docs/msn/ietf_draft.php
http://www.venkydude.com/articles/msn.htm

I started working on a connection tracking module for this, but 
really didn't go any further than adding the basic conntrack/nat
helper framework. 

If you're really serious about this, I can send you a diff of
the basic conntrack/nat module to get you started. Just let me
know.

One thing to watch out for when writing a conntracker for
this, is that the MSN packet that should add an expectation for
a file transfer should contain data that like this:

...
Invitation-Command: ACCEPT
Invitation-Cookie: 33267
IP-Address: 10.44.102.65
Port: 6891
AuthCookie: 93301
...

Now the problem is that MSN also allows some chat-like protocol
over the same port.

If you're writing a conntracker, you must make sure that you
are not parsing the "Messaging" packets as file transfer
requests. Otherwise the code has a security vulnerability 
where a specially crafted "Messaging" packet can add a firewall
connection expectation. When I realized my module was going to
have to detect this, I realized this wasn't going to be a
"weekend project" kind of thing and sort of gave up on it
for now. It would be great if you picked up the slack !

Regards,
Filip

Re: MSN helper module

[Filip Sneppe (Cronos)]

hi Carlos,

On Tue, 2002-12-17 at 22:46, Carlos Fernandez Sanz wrote:
> Thanks for the links. I have done some research already. I don't think it's
> going to be a weekend project but possibly not a lot more :-) Anyway I don't
> really have an option. It's starting to escalate...

Good to hear that we may have an additional netfilter module soon !

> BTW, when you started to work on this, did you take a look at the FTP
> module? I think it solves most of the problems (including security), since
> the connection method is identical to an active (PORT initiated) FTP data
> connection.

I think I heard Rusty explain how he dealt with this during some netfilter
talk, I think. IIRC, with ftp there are "end-of-line" markers before
or after the PORT/PASV commands that allow the module to distinguish
them from weird filenames in the control channel. That's the only
protection mechanism I heard of for the ftp conntrackers.

With MSN, it's a little trickier:

A normal messaging command looks like this:

MSG 3 A 157
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-MMS-IM-Format: FN=Microsoft%20Sans%20Serif; EF=I; CO=000000; CS=0;
PF=22

Hello! How are you? 


where the "157" is a length indicator (including header). Now the 157
bytes minus header that follow this can be anything: end-of-line
characters, and stuff that looks like "MSG 4 A 140<cr>".

What the module shouldn't do, is get confused by this "user-supplied"
content and start interpreting it. Otherwise, if a user supplied:

MSG 4 N 238
MIME-Version: 1.0
Content-Type: text/x-msmsgsinvite; charset=UTF-8

Invitation-Command: ACCEPT
Invitation-Cookie: 33267
IP-Address: 10.44.102.65
Port: 6891
AuthCookie: 93301
Launch-Application: FALSE
Request-Data: IP-Address:

as the content of a MSG message, it would create a security problem.

So I guess you need to do something like this:

- Parse the first data packet, assuming that you're not parsing
  a packet from a "messaging" session, because that could already
  contain spoofed data.
- If you encounter a "MSG 4 N xxx" message in the MSN header, check
  the rest of the header for the "Content-Type: text/x-msmsgsinvite"
  string. If that's present, it's an MSN file transfer request.
  go from there to add the expectation.
- If you encounter a "MSG 4 N xxx" message without the
  "Content-Type: text/x-msmsgsinvite" stuff in the MSN header,
  you should ignore the xxx bytes of that MSN packet (and possibly
  the following packets if xxx >> MTU) and not parse it at all:
  it's just user supplied data.
- I think you'll need to keep track of that MSG length field
  inside some ip_ct_msn_master to keep track of it accross
  various packets. I don't know if your module has to deal with
  out of order packets, ...
- Possibly you could do even stricter checking by watching the
  Invitation cookies etc.

Does this sound correct ?

Regards,
Filip

Re: MSN helper module

[Carlos Fernandez Sanz]

Filip,

I need to check the protocol specs (and even more important, I need to see
some actual data flow) a bit more in detail before getting into any deep
discussion, but I believe it's better to focus on a working implementation
and then tight the security with all the checks that might be needed.

I'm reading some docs and they say that for a file transfer to take place,
you need to send an invitation message over a switchboard session. It
doesn't say whether such a session can be an existing one or not, the
example opens one so I can't really tell.

BTW...and I'm saying this without careful documentation reading...the
protocol seems 'secure enough' :-)

Anyway, if you are up for a challenge, I'll let you know as soon as I have
something working and you can have some fun trying to break it :-)

Carlo.s

----- Original Message -----
From: "Filip Sneppe (Cronos)" <filip.sneppe@cronos.be>
To: "Carlos Fernandez Sanz" <cfs-netfilter@nisupu.com>
Cc: <netfilter-devel@lists.netfilter.org>; "Michael Richardson"
<mcr@sandelman.ottawa.on.ca>
Sent: Tuesday, December 17, 2002 23:38
Subject: Re: MSN helper module


> hi Carlos,
>
> On Tue, 2002-12-17 at 22:46, Carlos Fernandez Sanz wrote:
> > Thanks for the links. I have done some research already. I don't think
it's
> > going to be a weekend project but possibly not a lot more :-) Anyway I
don't
> > really have an option. It's starting to escalate...
>
> Good to hear that we may have an additional netfilter module soon !
>
> > BTW, when you started to work on this, did you take a look at the FTP
> > module? I think it solves most of the problems (including security),
since
> > the connection method is identical to an active (PORT initiated) FTP
data
> > connection.
>
> I think I heard Rusty explain how he dealt with this during some netfilter
> talk, I think. IIRC, with ftp there are "end-of-line" markers before
> or after the PORT/PASV commands that allow the module to distinguish
> them from weird filenames in the control channel. That's the only
> protection mechanism I heard of for the ftp conntrackers.
>
> With MSN, it's a little trickier:
>
> A normal messaging command looks like this:
>
> MSG 3 A 157
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> X-MMS-IM-Format: FN=Microsoft%20Sans%20Serif; EF=I; CO=000000; CS=0;
> PF=22
>
> Hello! How are you?
>
>
> where the "157" is a length indicator (including header). Now the 157
> bytes minus header that follow this can be anything: end-of-line
> characters, and stuff that looks like "MSG 4 A 140<cr>".
>
> What the module shouldn't do, is get confused by this "user-supplied"
> content and start interpreting it. Otherwise, if a user supplied:
>
> MSG 4 N 238
> MIME-Version: 1.0
> Content-Type: text/x-msmsgsinvite; charset=UTF-8
>
> Invitation-Command: ACCEPT
> Invitation-Cookie: 33267
> IP-Address: 10.44.102.65
> Port: 6891
> AuthCookie: 93301
> Launch-Application: FALSE
> Request-Data: IP-Address:
>
> as the content of a MSG message, it would create a security problem.
>
> So I guess you need to do something like this:
>
> - Parse the first data packet, assuming that you're not parsing
>   a packet from a "messaging" session, because that could already
>   contain spoofed data.
> - If you encounter a "MSG 4 N xxx" message in the MSN header, check
>   the rest of the header for the "Content-Type: text/x-msmsgsinvite"
>   string. If that's present, it's an MSN file transfer request.
>   go from there to add the expectation.
> - If you encounter a "MSG 4 N xxx" message without the
>   "Content-Type: text/x-msmsgsinvite" stuff in the MSN header,
>   you should ignore the xxx bytes of that MSN packet (and possibly
>   the following packets if xxx >> MTU) and not parse it at all:
>   it's just user supplied data.
> - I think you'll need to keep track of that MSG length field
>   inside some ip_ct_msn_master to keep track of it accross
>   various packets. I don't know if your module has to deal with
>   out of order packets, ...
> - Possibly you could do even stricter checking by watching the
>   Invitation cookies etc.
>
> Does this sound correct ?
>
> Regards,
> Filip
>
>

Re: MSN helper module

[Octavio / Super]

Carlos:

Bauke Fahner and I started working on something, but couldn't get much actually done.

At 01:56 a.m. 18/12/2002 +0100, Carlos Fernandez Sanz wrote:
>Filip,
>
>I need to check the protocol specs (and even more important, I need to see
>some actual data flow) a bit more in detail before getting into any deep
>discussion, but I believe it's better to focus on a working implementation
>and then tight the security with all the checks that might be needed.

I completely agree with that.

>I'm reading some docs and they say that for a file transfer to take place,
>you need to send an invitation message over a switchboard session. It
>doesn't say whether such a session can be an existing one or not, the
>example opens one so I can't really tell.

I don't actually think it should be that difficult. The thing is that I haven't understood some part of the Netfilter documentation, but here is my opinion.

With the current implementation of MSNP and Netfilter, you only need to do conntrack and nat for outgoing file transfers.

Since in the current protocol implementation, switchboard sessions will always be opened on port 1863, my idea is to capture this port and start the connection tracking from here.

As for NAT, we should only need to do the same thing: Accepted packets should be analyzed and checked to see whether the packet is asking the client for information, and, on the reply packet change the port number and IP address accordingly (and update the rest of the packet accordingly, also).

>BTW...and I'm saying this without careful documentation reading...the
>protocol seems 'secure enough' :-)
>
>Anyway, if you are up for a challenge, I'll let you know as soon as I have
>something working and you can have some fun trying to break it :-)

I'm in. I have the rest of December and the whole January.

Octavio.
---
/**************************************************
Octavio Alvarez (aka: Super, Doogie)
ICQ# 42020731. MSN_ID: alvarezp2000@h0tmail.com
**************************************************/