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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]