[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] <note> in IMDN


Eric Burger wrote:
> 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.

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

> 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?
>>
>>> 2. IMDN is only for page-mode IM, not MSRP
>>
>> Oops, sorry. I forgot IMDN had been thrown out of MSRP.
>>
>>     Paul
>>
>>> On May 23, 2008, at 5:08 PM, Paul Kyzivat wrote:
>>>> 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:
>>>>>
>>>>>> 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
>>>>>>
>>>>>> Dean Willis wrote:
>>>>>>> On May 13, 2008, at 11:38 PM, Hisham Khartabil wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>> _______________________________________________
>>>>>>> Simple mailing list
>>>>>>> Simple at ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Simple mailing list
>>>>>> Simple at ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Simple mailing list
>>>> Simple at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/simple
> 
> 
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple