[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] <note> in IMDN
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:
>
>
> 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
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple