Author maker
Recipients eli.bendersky, maker, r.david.murray, scoder, serhiy.storchaka
Date 2013-08-27.15:04:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377615862.36.0.598330758678.issue18850@psf.upfronthosting.co.za>
In-reply-to
Content
> Michele, could you elaborate how you would exploit this issue as a security risk?
Sure. What I meant in my message is: assume you have a script that simply stores each message it receives (from stdin, from a tcp stream, whatever) inside an xml tree like 
'<text>{message1}</text><text>{message2}<text>',
and prints the tree on SIGINT.

What I would expect is the xml document not to allow control chars, as "restricted and discouraged", and consistent with lxml. 
What instead happens is that the control chars are not handled, and thus anybody can send control chars in my terminal. Changing the terminal title is a trivial example of those. 

For sure an echo server may have the same issue, but the premises are different, because I expect to print just a byte stream.
Mentioning this fact in the documentation may be a possible solution, but I believe more that keeping consistency with lxml is the right way.

> I mean, I can easily create a (non-)XML-document with control characters manually, and the parser would reject it.
False? The parser is *not* rejecting control chars.
 
> What part of the create-to-serialise process exactly is a problem here?
ElementTree.tostring().
History
Date User Action Args
2013-08-27 15:04:22makersetrecipients: + maker, scoder, r.david.murray, eli.bendersky, serhiy.storchaka
2013-08-27 15:04:22makersetmessageid: <1377615862.36.0.598330758678.issue18850@psf.upfronthosting.co.za>
2013-08-27 15:04:22makerlinkissue18850 messages
2013-08-27 15:04:21makercreate