Re: cquirke, what's your opinion?

From: JW (JustPostYourReply_at_ToThisNewsGroup.pls)
Date: 03/07/05


Date: Mon, 07 Mar 2005 20:10:47 GMT

if you're still listening, cquirke, i would appreciate your opinion of
the effectiveness of SurfinGuard Pro by Finjan, or any other products
that intercept PC infections by running them in a caged sandbox.

cquirke (MVP Windows shell/user) wrote:
> On Sun, 6 Mar 2005 14:28:07 -0500, "Lanwench [MVP - Exchange]"
>
>>JW wrote:
>
>
>>>there once was a time when the only way to get an infection from an
>>>Email message was to click on something. this is no longer true.
>
>
> It hasn't been true for a long time.
>
> Limiting discussion to malware arriving via email (as opposed to
> diskettes, CDRs, peer-to-peer file sharing, LAN, IM, chat, direct
> network attacks via the Internet, hostile web sites, etc.)...
>
> 1) By design
>
> A few years ago, some thought it would be nice to add eye candy such
> as bold text, fancy fonts, inline graphics etc. (and indeed it is).
>
> Outlook first did this in a proprietary way, which was Bad, because
> email is supposed to be a standard, not a special format bound to one
> particular email application. Do you want to send email or Outlook
> mail? I don't deal with Outlook mail, so goodbye.
>
> The next logical step was to find an open standard for "rich" text,
> and HTML came to mind. But HTML does more than allow bold, fonts,
> inline graphics etc.; it also allows program (scripts, Java etc.) to
> be embedded, files to be automatically linked to via the Internet, and
> arbitrary text to be laid over URL links.
>
> The most obvious of these risks was scripts and other active content.
> Some email applications were smart enough to suppress these (e.g.
> Eudora, Pegasus), others were aware enough to offer suppression of
> these (Netscape Mail) and others hadn't a clue (OE, Outlook 2000).
>
> The result: By design, the more clueless email apps will autorun
> programmatic material in email "message text" when you "read" it.
> This is a clear escalation of risk, and when coupled with automatic
> preview as is the case in OE, the result is it becomes impossible to
> highlight a message to delete it without it running as code.
>
> BubbleBoy demonstrated the concept, Kak used it to spread widely
> through OE, and others (BleBla.B, San, Valentine) followed this up to
> the extent of adding data-destructive payloads.
>
> 2) By design cluelessness
>
> If autorunning scripts by design was dumb intent (or an obliviousness
> of implication), then the next layer of badness was design laxity.
>
> Files can be encoded within email messages in various ways. When the
> message is plain text, these files are to be linked to as attachments,
> but HTML allows certain types of files to be "opened" (intention:
> displayed) as part of the message. This is how inline graphics and
> autoplaying MIDI tunes work.
>
> There are four layers of content description at work here:
> a) The enclosure (encoding) of the file itself
> b) The MIME type of the file
> c) The file name extension of the file
> d) the internal type header data and structure of the file
>
> Where a standard defines an encoding process, as it does for (a), then
> all defining criteria should be met before you decode the file. This
> MS failed to do, so some improperly-coded files that might be ignored
> by some software (e.g. virus checker) may be decoded as files by MS.
>
> Where there is risk, design should be shrink-wrapped around intent.
> This applies to (a), (b) and (c), but once again MS has consistently
> failed to apply risk awareness to mismatches between these layers. So
> we see raw code in .PIF "shortcuts" being run ("opened") as code, Word
> macros in .RTF being run even though they should not be there, and in
> this case, raw code files mis-represented at the MIME level being
> "opened" (run) as raw code when the "message text" is "read".
>
> This is an extreme escalation of risk; you think you are "reading
> message text" (or maybe you're just trying to highlight a message to
> delete it, and the preview "reads" it for you) but what you are really
> doing is running raw code. BadTrans.B was the first to exploit this
> clickless email attack, and it's been routine for malware ever since.
>
> 3) Via defective code
>
> MS responded to the above as code defects and patched them, somewhat
> tardily (WinME's OE still autoran scripts by default, even after Kak
> was In The Wild). But if there was a barnacle of defective code, it
> was on the back of a volcano of bad design (scripts in "message text")
> or absence of code design (failure to sanity-check MIME type against
> file .ext against contents of file).
>
> Unlike silly design, true code defects are truly insane, running
> roughshod over any sort of safety or risk awareness. That means you
> typically can't defend against these via tighter settings; the only
> fix is to patch the code defect, or use a non-defective alternate app.
>
> There have been true code defects that facilitate clickless attack via
> email, and I expect there will be more in the future. So even if,
> right now as at March 2005, you are fully patched and risk managed
> against clickless email attacks - tomorrw's another day.
>
>
>>>the following came out a year ago on April 15:
>
>
>>>"The latest Netsky is squirming across the Internet as an email
>>>without an attachment.
>
>
> Now that can mean one or more of several things:
> - an insane message structure that exploits a raw code defect
> - an improperly-enclosed/encoded file
> - a MIME-spoofed file the email app will open inline
> - an explicit attachment
> - a masked link that pulls down malware when clicked
> - a remote graphic link that pulls down malware (no click)
> - scripts or active content embedded within the "message"
> - a valid but insane file that exploits when opened inline
>
> On the last, think of the GDIPlus defect that allows a real (but
> malformed) JPEG file to run itself as raw code. Once again, that's
> insane, and not something you can manage via safety settings.
>
>
>>>Yep, you heard me right, by using a combination of Windows security
>>>flaws, the creators of Netsky.v figured out how to infect a vulnerable
>>>computer without requiring the computer's owner to double-click on an
>>>attached file.
>
>
> Old news, but still serious news that is worth hearing.
>
>
>>What's so eye-opening about getting an infection because one isn't using up
>>to date AV software or practicing safe hex? That's a given - even if you
>>update daily, it's possible that your AV mfr hasn't released a pattern file
>>that can detect it yet, as you mentioned.
>
>
> Plus, you can't practice Safe Hex if the system is insane (code flaws)
> or stupid (inexcusably bad design) to take risks with unsolicited
> material on the user's behalf.
>
> You can't Just Say No if you werer never asked.
>
>
>>On networks running their own mail servers (which is what I mainly deal
>>with), I block a boatload of file extensions & also scan the entirety of the
>>message itself. Attachment types to block include exe, com, cmd, bat, pif,
>>scr, etc etc etc - and I also scan within zip files.
>
>
> That's risk filtering, which modern OE and Outlook can apply in a
> rather crude manner. ISPs can't do that for consumers, though what
> they can and often do do is scan for known malware. But a new (Day
> Zero) malware will cut through the ISP's scanner for the same reason
> it cut through the sender's av, and your av.
>
>
>>I'd say that spyware is usually a much larger problem than viruses
>>are these days, honestly.
>
>
> Larger in bulk, yes - though traditional malware may bite a lot harder
> (cause more damage) than commercial malware ("spyware")
>
>
>>Well, outside the fact that Netsky is indeed delivered via an attachment in
>>the first place, this is all pretty common sense stuff if you ask me. Keep
>>everything patched and updated. Use current-generation versions of Windows
>
>
> Er... no. Yes to upgrading or avoiding vulnerable edge-facing
> subsystems such as IE, WMP and MSware email, but I'd take a patched-up
> Win98SE over an out-the-box XP Gold any day of the year.
>
>
>>Keep your firewall ON all the time. Use very good AV software (have it
>>also scan mail if possible) that you update very frequently
>
>
> A free av updated daily's better than a commercial av updated once a
> week, IMO. regular updates can be difficult for dial-up users, but
> they have to just do what is required.
>
>
>
>>-- Risk Management is the clue that asks:
>
> "Why do I keep open buckets of petrol next to all the
> ashtrays in the lounge, when I don't even have a car?"
>
>>----------------------- ------ ---- --- -- - - - -



Relevant Pages

  • Re: cquirke, whats your opinion?
    ... >> The most obvious of these risks was scripts and other active content. ... >> 2) By design cluelessness ... >> failed to apply risk awareness to mismatches between these layers. ... >> MS responded to the above as code defects and patched them, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: no longer true
    ... By design, the more clueless email apps will autorun ... Where there is risk, design should be shrink-wrapped around intent. ... and it's been routine for malware ever since. ... MS responded to the above as code defects and patched them, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: vague talk of safe hex is deadly !
    ... has "inherent design flaws", or has more "security vulnerabilities" than ... > Where there is risk, design should be shrink-wrapped around intent. ... and it's been routine for malware ever since. ... > MS responded to the above as code defects and patched them, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Task Mgr & Registry locked! AV wont load!
    ... > every new malware has the potential for Day Zero spread (if it's ... > ISP's av, your frontier server's av (unless trapped by risk screening, ... > Risk management = curbing software design defects ... > just the code-defect barnacle on the tip of a volcano of bad design, ...
    (microsoft.public.security)
  • Re: Task Mgr & Registry locked! AV wont load!
    ... > every new malware has the potential for Day Zero spread (if it's ... > ISP's av, your frontier server's av (unless trapped by risk screening, ... > Risk management = curbing software design defects ... > just the code-defect barnacle on the tip of a volcano of bad design, ...
    (microsoft.public.security.virus)