[sc34wg3] <mergeMap/> and security

[Patrick Durusau]

Lars,

Lars Heuer wrote:

>Hi all,
>
>While several aspects of the advantages and disadvantages of the
>mergeMap element were discussed here I believe nobody has mentioned
>that the mergeMap feature may be insecure.
>
>I think XTM is considered as one of the essential technologies that
>will enable TM applications to talk to each other and to share their
>knowledge encoded in topic maps.
>
>Ad hoc I can imagine the following DoS attacks using the mergeMap
>element:
>
>- Blocking the application:
>  Topic map A contains a reference to topic map B.
>  The attacker serves topic map B very, very slow from his server.
>
>  
>
And that is different from slowness due to heavy load on the server with 
topic map B in what way?

Isn't slowness of service something that would have to be dealt with at 
the application level?

>- Creating an endless loop
>  Topic map C contains a reference to topic map D where D is a script
>  that generates itself a new
>         <topicMap><mergeMap href="[URI]"/></topicMap>
>  topic map, where [URI] points back to the script and [URI] is
>  changed at every iteration (i.e. using a simple counter).
>
>  
>
And loop detection is difficult for what reason?

>IMO these scenarios are not very appealing and offering
>possibilities for such an attack via an *interchange* syntax is a bad
>idea.
>
>  
>
Agree they are not very appealing but so far you haven't made the case 
that well designed applications cannot avoid them.

Noting that I would be reluctant to change an interchange syntax to 
protect poorly designed applications.

>The mentioned attacks are possible with XTM 1.0, we should take care
>that they are not possible with XTM 2.0. We should remove the
>"mergeMap" element from XTM 2.0.
>
>  
>
Attacks are always possible in a networked environment. There are 
attacks that are possible using links even without mergeMap.

Should we eliminate linking altogether so as to avoid those attacks?

What if a link points to what is ostensibly a useful resource but turns 
out to be a core dump that will eventually overwhelm the users system?

>The argument that the applications that read the XTM could be
>configured that they ignore the "mergeMap" element is not very good
>because once we've the "mergeMap" element in the syntax, authors will
>use it and expect that it will be proceed according to the XTM
>standard.
>  
>  
>
Perhaps "ignore" is the wrong term. Give the user the option to run 
mergeMap or no.

For example, if I have an XTM instance with several mergeMap directives 
and I am offline, it would certainly be bad behavior for an application 
to keep complaining that it can't carry out the directives.

It would certainly be possible to design a "safe" interchange syntax 
that puts no burden on implementers to make some sensible choices but it 
would not be terribly interesting or perhaps even useful. Poor 
applications will be weeded out from the better ones by market forces. 
Well, I say that knowing the number of people who rely on virus trap  
email clients. ;-)

Hope you are having a great day!

Patrick

>Best regards,
>Lars
>  
>

-- 
Patrick Durusau
Patrick at Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!