Subject: Re: [Simple] <note> in IMDN

From: [email-masked]
Date: Wed, 14 May 2008 00:45:44 +0000

Nice to have, but useless (language issue) as well as an attack vector. If that information is really important, we should have codes or tokens an automoton can interpret.
------Original Message------
From: Hisham Khartabil
To: Eric Burger
Cc: [email-masked]
Subject: Re: [Simple] <note> in IMDN
Sent: May 14, 2008 7:17 AM

It for the IMDN to carry extra information about the IM. For example, information on why it was not delivered. 
  
   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xlmns="urn:ietf:params:xml:ns:imdn">
      <message-id>34jk324j</message-id>
      <datetime>2006-04-04T12:16:49-05:00</datetime>
       <recipient-uri>im:[email-masked] <mailto:[email-masked]> </recipient-uri>
      <original-recipient-uri>
          im:[email-masked] <mailto:[email-masked]> 
       </original-recipient-uri>
      <disposition>
         <delivery/>
      </disposition>
      <status>
         <failed/>
      </status>
      <note lang="en">The IM could not be delivered due to network failure</note>
    </imdn>

On 13/05/2008, Eric Burger <[email-masked] <mailto:[email-masked]> > wrote: Why do we have a <note> field in an IMDN?

It cannot be for correlation, as the sender MUST have a Message-ID.
 
It cannot be for letting the user what the message is, because we are
talking about IMs here, not e-mails.

It cannot be for displaying status to the IM sender, because the IM
Recipient UA has no idea what the locale of the sender is and will
 undoubtably use the wrong language and character set.

It could be used as a spam attack vector, but that would be silly of
us to build in to a protocol.

Does ANYONE object to simply taking out the field?
 Does ANYONE want the field to be present?

Please respond to the list ASAP, as this document is WAY overdue.
_______________________________________________
Simple mailing list
[email-masked] <mailto:[email-masked]> 
 https://www.ietf.org/mailman/listinfo/simple <https://www.ietf.org/mailman/listinfo/simple> 

Sent from my Verizon Wireless BlackBerry
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 14 May 2008 12:39:43 +1000

well, its in there already and we are passes WGLC and into IESG Discusses. I
think its too late to be asking the question of requirements.

Regards,
Hisham

On 14/05/2008, [email-masked] <[email-masked]>
wrote:
>
> Nice to have, but useless (language issue) as well as an attack vector. If
> that information is really important, we should have codes or tokens an
> automoton can interpret.
>        <recipient-uri>im:[email-masked] <[email-masked]> <mailto:
> [email-masked] <[email-masked]>> </recipient-uri>
>       <original-recipient-uri>
>           im:[email-masked] <[email-masked]> <mailto:
> [email-masked] <[email-masked]>>
> On 13/05/2008, Eric Burger <[email-masked] <mailto:
> [email-masked]> > wrote: Why do we have a <note> field in an
> IMDN?
>
> https://www.ietf.org/mailman/listinfo/simple <
> https://www.ietf.org/mailman/listinfo/simple>
>
>
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 14 May 2008 11:51:37 +0800

Do you have text for the Security Considerations section short of  
"here is a nice big attack vector that, by the way, has no protocol  
use"?

On May 14, 2008, at 10:39 AM, Hisham Khartabil wrote:

> well, its in there already and we are passes WGLC and into IESG  
> Discusses. I think its too late to be asking the question of  
> requirements.
>
> Regards,
> Hisham
>
>
> On 14/05/2008, [email-masked]  
> <[email-masked]> wrote: Nice to have, but useless  
> (language issue) as well as an attack vector. If that information is  
> really important, we should have codes or tokens an automoton can  
> interpret.
> It for the IMDN to carry extra information about the IM. For  
> example, information on why it was not delivered.
>
> On 13/05/2008, Eric Burger <[email-masked] <mailto:[email-masked] 
> > > wrote: Why do we have a <note> field in an IMDN?
>
> https://www.ietf.org/mailman/listinfo/simple <https://www.ietf.org/mailman/listinfo/simple 
> >
>
>
>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 14 May 2008 14:38:37 +1000

Can you explain how it is an attack vector?

On 14/05/2008, Eric Burger <[email-masked]> wrote:
>
> Do you have text for the Security Considerations section short of "here is
> a nice big attack vector that, by the way, has no protocol use"?
>
> well, its in there already and we are passes WGLC and into IESG Discusses.
> > I think its too late to be asking the question of requirements.
> >
> > Regards,
> > Hisham
> >
> >
> > wrote: Nice to have, but useless (language issue) as well as an attack
> > vector. If that information is really important, we should have codes or
> > tokens an automoton can interpret.
> > [email-masked]> </recipient-uri>
> >      <original-recipient-uri>

---

From: Dean Willis <[email-masked]>
Date: Tue, 20 May 2008 09:36:37 -0500

> Can you explain how it is an attack vector?

Unconstrained rich content is one of the most easily exploited attack  
vectors.

Buffer overrun attacks as well as all of the typical MIME compound- 
component attacks are likely. For example, the common JPEG  
vulnerabilities might be exploitable:

http://www.news.com/Image-virus-spreads-via-chat/2100-7349_3-5390463.html

Or the content-execution weakness that caused the Macintosh Safari  
browse to be most easily exploited in recent hacking contests:

http://www.engadget.com/2007/07/23/safari-exploit-gives-hackers-full-control-of-your-iphone/

There have also been exploits against QuickTime, Flash, and most other  
plugin components from time to time.

--
Dean

---

From: Eric Burger <[email-masked]>
Date: Tue, 20 May 2008 20:01:59 -0400

Because it is unconstrained and by definition free-form.

On May 20, 2008, at 7:22 PM, Hisham Khartabil wrote:

> On 21/05/2008, Dean Willis <[email-masked]> wrote:
>>
> How is this different from every other header or part of an XML body
> in SIP, MSRP, IMPP or any other protocol that allows text to be
> entered in a field? Why is this particular <note> giving people grief?
>
>>
>> component
>> attacks are likely. For example, the common JPEG vulnerabilities  
>> might be
>> exploitable:
>>
>> browse to
>> be most easily exploited in recent hacking contests:
>>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 21 May 2008 11:03:18 +1000

Eric,

I don't understand. I am slow I know. Please explain in detail how are
other fields like Subject in SIP, <note> in presence, or any other
field that allows strings or token to be entered not unconstrained and
not free-form while this one is?

Please don't reply with a one liner.

Thanks,
Hisham

On 21/05/2008, Eric Burger <[email-masked]> wrote:
> > > Buffer overrun attacks as well as all of the typical MIME
> compound-component
> > > attacks are likely. For example, the common JPEG vulnerabilities might
> be
> > > exploitable:
> > >
> > >

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 21 May 2008 09:22:04 +1000

>
> Buffer overrun attacks as well as all of the typical MIME compound-component
> attacks are likely. For example, the common JPEG vulnerabilities might be
> exploitable:
>
> Or the content-execution weakness that caused the Macintosh Safari browse to

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 May 2008 20:45:31 -0400

Its kind of late to be thinking about this now. THe problem is pervasive 
in MSRP.

In SIP there are lots of unconstrained fields. But they are all 
constrained by the overall size of the message, and people commonly put 
limits on that.

In MSRP, because of chunking, a single MSRP message can be gigabytes 
long. So using that to bound the unconstrained parts of the headers 
doesn't work very well.

A robust implementation might take a similar approach - define its own 
limit on the total message size, excluding the body. Then it could 
constrain all the unconstrained fields to fit within it.

But picking on one header isn't a solution to the problem. Either assume 
the developers will be able to deal with it, or else do and MSRPv2 that 
eliminates all unconstrained fields.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 May 2008 18:08:24 -0400

Eric,

I guess I'm missing what kink of problem you are trying to prevent by 
constraining the content, and what kinds of constraints are needed for 
this to be helpful.

Are you concerned with unconstrained *length* or unconstrained 
*content*? You can already put fields of unconstrained length and nearly 
unconstrained content into MSRP headers, in those places where 
quoted-string are allowed.

	Paul

Eric Burger wrote:
> Actually, IMDNs, even the SIMPLE free-form fields, are fairly 
> constrained.  Any mis-match is an opportunity to filter out bad IMDNs.  
> The <note> field has three problems:
> 
> 1. It cannot be filtered, as any content could be real (which introduces 
> the attack vector)
> 
> 2. It cannot know what language it should use, and thus is not likely to 
> be useful to the recipient
> 
> 3. It has no protocol value, and is of no value to the UA
> 
> 
> So, if something has no useful protocol value and introduces a spam 
> opportunity, why would we want to include it?
> 
> 
> 
> On May 21, 2008, at 7:45 PM, Paul Kyzivat wrote:
>

---

From: Eric Burger <[email-masked]>
Date: Fri, 23 May 2008 17:09:49 -0500

1. The content

2. IMDN is only for page-mode IM, not MSRP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 May 2008 18:23:50 -0400

> 1. The content

Then aren't you concerned with all the nearly unconstrained content that 
is possible in sip itself? (quoted-strings can be used in many places, 
and comments are allowed in a few.)

In the context you are talking about, the content is constrained by the 
syntax of xml. Are you concerned with the xml parser screwing up? Or 
with an application screwing up processing the content after it has been 
parsed from the xml - perhaps by doing a bad job of trying to display it?

> 2. IMDN is only for page-mode IM, not MSRP

Oops, sorry. I forgot IMDN had been thrown out of MSRP.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Sun, 25 May 2008 07:57:44 -0500

Almost all of the fields in IMDN are verbatim copies of the IM, which  
means an automaton can filter spoofed IMDN's.  Just about all of the  
fields have some protocol semantic value.  However, the <note> field  
is a spam delivery vector that has no protocol value.  That is my  
issue with it: no value *and* a method to introduce spam.  That does  
not sound like a winning combination.

On May 23, 2008, at 5:23 PM, Paul Kyzivat wrote:

>
>
> Eric Burger wrote:
>> 1. The content
>
> Then aren't you concerned with all the nearly unconstrained content  
> that is possible in sip itself? (quoted-strings can be used in many  
> places, and comments are allowed in a few.)
>
> In the context you are talking about, the content is constrained by  
> the syntax of xml. Are you concerned with the xml parser screwing  
> up? Or with an application screwing up processing the content after  
> it has been parsed from the xml - perhaps by doing a bad job of  
> trying to display it?
>
>>>>>> compound-

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 May 2008 12:23:50 -0400

Eric Burger wrote:
> fields have some protocol semantic value.  However, the <note> field is 
> a spam delivery vector that has no protocol value.  That is my issue 
> with it: no value *and* a method to introduce spam.  That does not sound 
> like a winning combination.

OK. This I get.

But if we are going to start talking about attack vectors for breaking 
sip servers then I think it needs to be a different kind of discussion, 
and much broader. It may be a discussion we ought to have.

	Paul

>> the syntax of xml. Are you concerned with the xml parser screwing up? 
>> Or with an application screwing up processing the content after it has 
>> been parsed from the xml - perhaps by doing a bad job of trying to 
>> display it?
>>

---

From: Eric Burger <[email-masked]>
Date: Sun, 25 May 2008 17:02:32 -0500

It was Dean that was talking about attack vectors.  I'm the one who is  
fixated on a data element with no positive virtues and a negative side- 
effect.

On May 25, 2008, at 11:23 AM, Paul Kyzivat wrote:

>>> up?
>>>>>>> A robust implementation might take a similar approach - define  
>>>>>>> its
>>>>>>> own
>>>>>>> But picking on one header isn't a solution to the problem.  
>>>>>>> Either
>>>>>>> assume
>>>>>>> the developers will be able to deal with it, or else do and  
>>>>>>> MSRPv2
>>>>>>> that
>>>>>>>> There have also been exploits against QuickTime, Flash, and  
>>>>>>>> most
>>>>>>>> other

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 May 2008 11:41:51 -0500

> not sound like a winning combination.

A lot of the spam on the IETF servers comes from forged "bounce"  
messages. If a message looks like a bounce sent in response to a  
message that might have come from the IETF list, it is very difficult  
to weed out. For example, as sip-owner, I get a couple of hundred  
forged bounce spams a day. Does IMDN share this property? It feels to  
me like it might. Now personally, I wanted IMDN totally banned from  
the deliverables; it has proven to be a nightmare in the email world,  
and I bet it is going to cause us grief. But if we must do it, let's  
make it as safe as possible.

The unconstrained MIME body is a related problem. Since it is there in  
an IMDN, it could be populated with stuff of the sender's choosing.

Much more so than some arbitrary quoted-string in a SIP header, a MIME  
note body (just like a MIME message body) is likely to get parsed out  
and handed over to the OS-registered handler for the associated MIME  
type. Many of those handlers have security flaws.

So are we building an attack vector that can't readily be stopped by  
spam-defense techniques and that is likely to result in malicious code  
execution? Just how smart is that?

--
Dean

---

From: Eric Burger <[email-masked]>
Date: Thu, 29 May 2008 21:38:50 -0400

Don't forget the last little bit: not only does it open a vector for  
delivering a spam payload, but it has no value in the white hat case.

On May 29, 2008, at 12:41 PM, Dean Willis wrote:

> message that might have come from the IETF list, it is very  
> difficult to weed out. For example, as sip-owner, I get a couple of  
> hundred forged bounce spams a day. Does IMDN share this property? It  
> feels to me like it might. Now personally, I wanted IMDN totally  
> banned from the deliverables; it has proven to be a nightmare in the  
> email world, and I bet it is going to cause us grief. But if we must  
> do it, let's make it as safe as possible.
>
> The unconstrained MIME body is a related problem. Since it is there  
> in an IMDN, it could be populated with stuff of the sender's choosing.
>
> Much more so than some arbitrary quoted-string in a SIP header, a  
> MIME note body (just like a MIME message body) is likely to get  
> parsed out and handed over to the OS-registered handler for the  
> associated MIME type. Many of those handlers have security flaws.
>
> spam-defense techniques and that is likely to result in malicious  
> code execution? Just how smart is that?
>
> --
> Dean
>
>
>