"Okay" on all topics save the one below. Thanks!
Ben. On Apr 7, 2014, at 4:34 PM, Paul Hoffman <[email protected]> wrote: [...] >>>>>> >>>>>> -- 5, security considerations >>>>>> >>>>>> I wonder if the possibility of executable content existing in an RFC or >>>>>> draft is worth mention here? For an extreme example, see RFC6716, >>>>>> Appendix A. But more realistically, 2.5.5 mentions the possibility of >>>>>> in-lined binary content, and 2.5.6 allows the identification of code in >>>>>> a way that a naive processor implementation might take as an invitation >>>>>> to interpret said code. >>>>> >>>>> Yup, and (as above) I added a paragraph about this. >>>>> >>>>>> Also, does the need for a processor to potentially render binary content >>>>>> in general (in-lined or otherwise) expand the attack surface over that >>>>>> for previous versions of XML2RFC? >>>>> >>>>> Not in any way I can think of. >>>> >>>> For example (just thinking "out loud"), if a processor could insert JPEG >>>> artwork, does it need to worry about buffer overflow attacks on the JPEG >>>> format, as well as attacks on the xml itself? If so, does it matter if the >>>> artwork was in-lined vs referenced? >>> >>> Um, maybe. I'm not at all sure how to word a security consideration about >>> that that would be more useful than "a processor should not be stupid when >>> doing includes". >> >> Just as a strawman example: >> >> Unlike previous versions, XML2RFC V3 allows the inclusion of potentially >> binary content via the "src" attribute of the <artwork> element. Processor >> implementors should bear in mind that such content may have vulnerabilities >> of its own. For example, certain JPEG renderers have been vulnerable to >> buffer-overflow attacks. An xml2rfc processor that allows the inclusion of >> artwork in JPEG format might be subject to buffer overrun attacks on both >> its XML parser and in its JPEG rendering code. > > It really depends on what you mean by "binary". The v2 format supports > inclusion of files in a few places already; a malicious submitter could make > those files "binary". Were those files likely to be binary in normal usage? (I also note that the v2 security considerations are almost identical to the V3 ones, except for a disclaimer that they are probably incomplete :-) ) > Further, a processor doesn't render anything: it puts out files. That's an interesting point that I hadn't considered. I think it's probably true most of the time, but not all the time. On minimal thinking, I can imagine a processor that converts artwork to some preferred format. Or maybe some sort of just in time render that combines xml processing with direct display or printing. > So, at best, the advice is "don't have a buffer overrun when including a file > that you might output", which seems dumb. I'm still open to adding a security > consideration, but I guess I feel it has to at least be marginally useful. I still think it might be useful to say something to the effect of "While most of these security considerations apply to the interpreting of XML and rendering into various output formats, implementors may find that they are interpreting things other than XML, and should remember that those things may have additional security considerations". The situation that seems most worthy of mention is that, if someone writes a processor that pulls in other (perhaps downloadable) libraries, plug-ins, OS functions, etc to process input beyond the XML itself, they may inherit any security issues of those things. I realize that's a true statement about computing in general--but it seems more relevant for V3 processors than for previous versions. The fact that people keep finding vulnerabilities in such architectures suggests that the horse is not quite dead. Obviously, this is all personal opinion, and carries no more weight than those of any other commenter (and probably less than those who have actually been working on updating xml2rfc). _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
