Email Clients and digital signatures
Sun Jul 6 18:59:02 2003
Content-Description: signed data
On Sunday 06 Jul 2003 2:00 pm, CL Gilbert wrote:
> Well yes, activeX has full control. But activeX is just another name
> for COM/DCOM which still can not simply run automatically. I turned off
> HTML because I got tired of being *asked* to run code that I knew I
> would not let run. Always, "so and so script wants to run, this can be
> dangerours", "Authorize?" This is what I always get from outlook
> express. A request, not an automatic run of a program. So much so that
> when Norton would catch virused emails, sometimes I would just view them
> anyway to see what they were going to try and do. Never failed that
> outlook express *asked* me if I wanted the script to run.
That would be reassuring if it was always true. That alert box isn't 100%=20
reliable. Do you think all vulnerabilities in IE have been patched? The=20
problem lies deeper - IE shouldn't be passing ALL requests to WSE. Don't re=
on VBS detection to be the be all and end all protection. Behind the dialog=
box is a mechanism that encourages trojans. Nimda was one those what bypass=
the dialog and - on a DEFAULT system - would execute the payload.=20
> My IE settings (which is the renderer outlook express is using say this
> for security.
> 1. Download Signed ActiveX control ->Prompt
> 2. Download unsigned ActiveX controls ->Prompt
> 3. Initialize and script ActiveX controls not marked as safe ->Prompt
> 4. Run ActiveX controls marked as safe for scripting ->Prompt
Only by changing these settings to DISABLE can you be protected from the ne=
generation of Nimda. Take an analogy to a firewall - you don't reject bad=20
packets, that involves CPU cycles, you DROP bad packets. In the time it tak=
to execute the CPU cycles to reject the bad packet and create a return pack=
to say what has happened, the packet is still active. You shouldn't leave t=
virus hanging in memory whilst waiting for a prompt box - it should be=20
disabled and a specific user action required before it can be activated.=20
Windows default is to leave it pending but still in memory. Dump it out of=
memory and get confirmation later. Windows sits there and waits for the=20
dialog box to be answered, all the while the code is in memory. (Take a loo=
with a debugging memory pointer inspection tool.)
That is an example of a default Windows action that simply doesn't close th=
door. It just says: "Wait there, be a nice little thug and don't do anythin=
while my back is turned." Doh!
> These are default settings. They mean for any ActiveX control I will be
> asked first. Its not automatic.
You wish. Just because it's worked so far, or it works in 99.9% of cases, a=
you so confident that all vulnerabilities are patched?=20
The default is to keep the trojan in memory - active and able to launch an =
or similar. Close the preview, close the file handle, release the memory an=
de-allocate the pointers. NOW ask the user. Even better, display a warning =
PLACE of the message instead of annoying the user by throwing up a pesky=20
dialog box. In Scotland, there are road signs that say, "Frustation causes=
accidents - let others pass". In Windows, it's "Continuous generation of=20
dialog boxes will inevitably lead to one being clicked OK when it should ha=
been Cancel!" It only takes one.
> Only time its automatic is when A bug is found that someone exploits to
> make it automatic.
And that's hard?
That's your defence strategy??
One slip and the default action takes over. That is what is so dangerous - =
hole and EVERYTHING becomes automated, available and erasable. Security is=
not a dialog box, it is a process, a strategy under constant review.=20
Security should acknowledge that there will ALWAYS be vulnerabilities and=20
that protection needs therefore to catch problems in the next layer. OE/IE=
use a single layer security that isn't even worth the name.
> Yes, VBSCript runs automatically, but it can not access the stuff you
> are worried about without invoking some other code like activeX that it
> downloads first. and as shown above you are asked about the download.
It can open the door.=20
=46rom the I Love You records:
2. The virus disables your Windows Scripting Host's ability to pause befor=
executing script code, effectively thwarting the efforts of any other progr=
that might be able to discern whether the code is malicious before Windows=
executes it. For Outlook to have time to notice an email attachment's type=
and send up a warning, or for an anti-virus program to have the time to see=
which application has been loaded, there needs to be a pause in the Scripti=
Host's activity. Here, the virus takes away that pause. This makes it=20
impossible for Outlook to stop itself and renders it more difficult (though=
not impossible) for an anti-virus program to step in and stop damage from=20
Next, the ILOVEYOU virus makes it possible for another virus or some other=
script -- for instance, one embedded in a Web page -- to come into your=20
system and potentially inflict significantly more damage. The virus asks yo=
computer for the name of the directory where Internet Explorer downloads it=
files. Next, it checks for the presence of a file that theoretically could =
created by a second virus or by a "Trojan horse" script.
> > Not true. A site does not need a certificate to execute ActiveX
> > elements. Nor does it need to be on a website - as the quote showed, it=
> > easier to execute from an HTML email where certificates have no impact.
> As I have shown above, my default IE settings disagree with you. And as
> I have said above, HTML emails are rendered using IE.
I said that too. Only I meant that as a PROBLEM not a solution! The default=
settings are not reliable. The settings themselves are stored in universall=
readable form and can be changed by any single attack that DOES get through=
You would never know. One Nimda, one registry change, a flood begins. The=20
dialog box could still be generated, this time by the trojan!!
> Never had a virus. =20
How do you know? Anti-virus scans never claim to catch 100%.
86% thought they were safe.
91% of the computers had what AOL categorized as spyware installed.
> I read the below email and Still just plain
> disagree. This is not the default behavior. This is the behavior
Default: Action that is taken unless settings are changed. I'm not saying=20
Windows will do this in all installations - the risks can be reduced. A=20
default system is not patched, it is not secure and it will execute malicio=
code whilst sometimes giving the illusion of protection from a ridiculous=20
dialog box. What is more dangerous - a false positive or a false negative?=
The dialog box is a false negative. "Nothing is wrong" when it can easily m=
> always indicated when a new bug is found. "so and so bug...may allow
> user to run arbitrary code on users machine..." These announcements
> make no sense because you are saying anyone can at anytime run arbitrary
> code on your machine anyway.
I never said that. I maintain that the default action within Windows is to=
execute code without even seeking permission. A few paper-thin single layer=
devices (like that dialog box) don't change what lies beneath. The fact tha=
this dialog box has already been evaded should illuminate the risk!
What I did say was that 'running arbitrary code' does not mean a quick game=
> *Show me* some example code and I will believe you.
Why? Are you going to wait for someone else with different intentions to=20
finish the job before you do anything about it?
(example code NOT sent to a publicly archived list!!)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----