Re: Avoid unknown code sources (was: Re: RFC archival format)

On Jul 7, 2009, at 9:19 PM, Doug Ewell wrote:

> Douglas Otis <dotis at mail dash abuse dot org> wrote:
>
> > The concern is about the application accepting document  
> > instructions and text and then generating document output.  When  
> > this application is proprietary, it is prone to change where  
> > remedies might become expensive or impossible.
> The implication is that open-source software is inherently stable  
> and commercial software is inherently unstable.  That's hardly a  
> safe across-the-board assumption.
When an application is open and the OS APIs change, recompilation  
often provides a remedy.  When the application is proprietary, whether  
patches become available as a remedy to an OS change depends upon the  
vendor, who might also expect some precondition be met.  This concern  
becomes somewhat more pressing when the same vendor controls both the  
application and the OS. :^(
> > The evolution in hardware tends to force the use of different  
> > operating systems which may no longer support older applications.
> "Tends to," "may."  Sounds like FUD to me.  I haven't had any  
> trouble using Word 2003 under XP to read documents I created in Word  
> 95 thirteen years ago.
Often application APIs exhibit security vulnerabilities.  Unforetold  
changes to improve security inevitably will inhibit some  
applications.  It was your good fortune that the application was  
updated and made available at a reasonable price.  Backward  
compatibility modes to support older applications might lessen  
security, or simply not function.  After all, due to security  
concerns, libraries are continuously updated, sometimes in  
incompatible ways.
> > IIRC, I did work back in the early 90's that contained Russian  
> > written using Word 5.  Conversion proved difficult since  
> > proprietary fonts were needed.  Document recovery then required a  
> > fair amount of work to rediscover the structure and character  
> > mapping.  Trying to get any version of Word to generate plain text  
> > outputs consistently always seemed to be a PITA, that varied from  
> > version to version, and never seemed worth the effort.
> All work involving Cyrillic text was hit-and-miss fifteen years ago.  
> Every word processor or other application had its own custom format.  
> Many used KOI8-R, some used CP866 (or worse, CP855), a few used ISO  
> 8859-5.  PDF files depended entirely on the embedded font to convey  
> meaning; copy-and-paste from PDF was useless.  Compatibility  
> problems in the era before widespread Unicode adoption were hardly  
> limited to Word.
Not having source available significantly increased recovery efforts,  
nor could this effort be shared per the EULA. :^(
> > When people are required to input Word Document "instructions" into  
> > their Word application, they might become exposed to system  
> > security issues as well.
> "Might be."  More FUD over security.  Has anyone suggested  
> *requiring* users to employ mail-merge-type macros as part of I-D  
> preparation, or is this just a general flame against Word?
The concern about what might be embedded within documents was not in  
regard to simple macros, but that of a program language capable of  
compromising the operating system.   The concern was voiced in  
opposition to suggestions for using Word input files as a means to  
generate inputs for I-D or RFC generation utilities.  Of course,  
collaborators are likely to share these input documents as well.   
Sharing potentially hazardous input files among often virtual  
strangers represents a bad practice with respect to security.  This is  
not any different than warning users not to click on "greeting- 
card.exe" email attachments.
> > The variability of the Word data structures makes identifying  
> > security threats fairly difficult, where many "missing" features  
> > seem to be an intended imposition as a means to necessitate use of  
> > the vendor's macro language.
> Translation: I don't like Microsoft.
IMHO, unnecessary risks are being taken with respect to code having  
unknown origins.  In other words, this is an argument about ensuring  
people are able to recognize the gun before pulling its trigger.  As a  
result of their iFrame innovation and inevitable clickjacking,  
websites now need to inhibit iFrames with X-FRAME-OPTIONS (supported  
by IE 8 and NoScipts).  Users are also warned to disable this feature  
within their browsers.
WMA files with ".mp3" extensions will launch and prompt with a system  
pop-up for the installation of OS extensions obtained from unknown  
locations hidden within the mislabeled files.  Often users mistakenly  
trust messages that appear generated by the OS.  In view of mistaken  
trust, why are document related exploits low on a list of concerns  
when discussing the generation of archival formats?  Why call this  
FUD?  There is nothing uncertain about the concern.
> > Inherent security issues alone should disqualify use of proprietary  
> > applications.
> Hey, maybe if I say the word "security" enough times, people will  
> get scared and not use Word any more!
Detecting the malware contained within exchanged active content is  
becoming less effective, since malware from unknown sources evolve  
every few minutes into new forms.  Knowing what might be malware, and  
where it originated, remains a difficult problem made increasingly  
difficult by organizations that give security low priority.
> > It would be sending the wrong message to mandate the use of  
> > proprietary operating systems or applications in order to  
> > participate in IETF efforts.
> Who ever proposed to *mandate* the use of Windows or Word to write  
> an I-D or otherwise participate in IETF efforts?  The proposal was  
> to ALLOW users to prepare I-Ds using Word, and translate the output  
> of Word into a format the IETF tools and RFC Editor can deal with.   
> Nobody ever said anything about *mandating* any of these tools.
There are security related reasons for not venturing down this path.   
In addition, other options might be allowed to fail with a rationale:
"Since Word generates an input that eventually receives IETF nit  
checker approval, other options become nonessential, since 80+% of  
desktops run Windows."
> > After all, lax security often found within proprietary operating  
> > systems and applications threatens the Internet.
> Pure and complete FUD, despite the real macro threats of a few years  
> back.  The Internet will not fall apart if someone uses Word, feeds  
> the output into a Word2RFC tool, and submits that output to IETF.
What fundamental design element has changed the basic security  
concerns related to the input files?  Simpler structures in XML form?
> > Open source includes more than just Linux, and the exposure of  
> > requiring proprietary applications or operating systems would  
> > affect nearly all IETF participants that maintain existing  
> > documents or generating new ones.
> Nobody, but nobody, has proposed requiring Word or Windows for IETF  
> use.
Sorry, but it would be wise not to consider this application due to  
its lack of security whenever expecting to have shareable process  
inputs.
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf