"Paco Hope" writes: > >Date: Mon, 20 Dec 2004 13:35:23 -0500 >From: "Paco Hope" <[EMAIL PROTECTED]> >Subject: Re: [SC-L] Re: DJB's students release 44 poorly-worded, overblowna= >dvisories > >On 12/20/04 1:03 PM, "Crispin Cowan" <[EMAIL PROTECTED]> wrote: >>> If they exploited notepad.exe when they activated would we announce a "r= >emote >>> exploit" on notepad.exe? They exploit a buffer overflow in local softwar= >e, >>> but they require action by the user before they can activate. >>> >> The difference between a local and a remote exploit, in this context, is = >that >> a local exploit requires overt action on the part of the user, e.g. take = >these >> 7 steps to perform the local exploit. A remote exploit can include malici= >ous >> content that you can e-mail to a naive user and reasonably expect them to= > do >> what is required to perform the exploit, such as "click on the attachment= >". > >Then reconsider whether rtf2latex or abc2midi are really "remote exploits." >I think it is safe to say that no one will have their email program or web >browser set up to run 'abc2midi' as the default option when they click an >ABC file (even though they could). Is this really remotely exploitable? It >requires the user to save the file to a disk and run a special command on >it. > >I feel like your explanation backs out to a debate about what lengths we ca= >n >"reasonably expect" someone to go to infect themselves. If clicking on an >attachment and typing a password qualifies (which I think most of us will >accept as reasonable), does "save this file to disk and run this command on >it" also qualify? > >Maybe it's just me, but I don't think filter programs like these x2y >programs (he cited "abc2midi" and "rtf2latex2e" among others) qualify. >There's no way someone will have their web or mail software set up to run >these converters as the default action. Most systems won't even have the >vulnerable programs installed by default. The user has to save the hostile >payload to a file and has to type the command. They also have to type the >command with a modicum of correct syntax (perhaps not 100% correct, but at >least enough to get past the basic usage() check). Thus, they have to follo= >w >some instructions from their attacker on how to get the software to run. > >Even if we're debating reasonableness, I still disagree that these are so >easy you can just take it for granted that someone will have the software, >will save the file, and will execute the command with the vulnerable syntax= >. >If the user receives a file from an untrusted source, and follows a script >of commands (even though it may only be 2 or 3), I call this a social >engineering attack, not a remote exploit. > >The "ease" of exploit here doesn't come anywhere near the ease of >exploiting, say, xmms or some other software that is highly likely to be th= >e >default application for a given content-type. > >Paco >- -- >Paco Hope, CISSP >Senior Software Security Consultant >Cigital, Inc. http://www.cigital.com/ >[EMAIL PROTECTED] -- +1.703.585.7868
I think we are getting overly concerned about terminology and the distinction between a remote exploit and social engineering. Dating all the way back to the 1987 Christma Exec worm ( http://www.computer.org/security/v1n5/j5cap.htm ), users have been remarkably easy to convince to do what a security expert would immediately see as stupid and dangerous. The human being is a part of the system and designers have to recognize that. If the typical clueless human user can be easily convinced to run a simple command or two that opens up the world, then that is just as serious a security problem as the fully automatic remote exploit. The distinction is that the clueful user would only be vulnerable to the fully automatic remote exploit, but until the ratio of clueful to clueless gets significantly better than it is today, the level of danger of the two classes of attacks remains roughly the same. Now if the attack requires the user to type 10 commands, compute a cube root, and stand on her/his head, that's different. But saving a file and clicking on it is still too likely to occur. - Paul
