[thelist] Outlook & Security was: Opera browser- now with a (free) new version

[Daniel J. Cody]

jeff wrote:

> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : From: Jacob Stetser
> :
> : Scripts _within_ an email client should not be
> : able to affect anything outside of the email
> : client - that means no writing files, no changing
> : system config. Hell, I don't really even want it
> : changing my email settings. The only real use
> : of scripting in an email is if you're using HTML
> : email and want mouseovers.
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> furthermore, the specific complaints of writing files, changing system
> configurations and things like that aren't really related to outlook
> specifically.  those specific virii are taking advantage of a very powerful
> tool within windows that allows you to write scripts to automate common
> tasks.  take away things like file writing and system config and there
> wouldn't be much purpose for this tool whatsoever.

I think Jacob's point is does the email client application really *need* 
access to a tool that can change system configurations and/or write 
files? Sure it can be disabled, but by disabling that tool you're 
shutting off the advantages that tool gives you in the frist place(inter 
application communication, etc.). There is no 'in-between'. Either you 
leave the tool enabled and stay at risk, or shut if off and lose 
features. Also, I wouldn't say they're related to Outlook specifically, 
but 99% of virii now target applications like Outlook(and all MS Office) 
precisley because of their tight integration with the OS. If these kids 
can write a little script to do some damange in an enviornment that is 
easier and takes half the time of writing a full fledged virus, thats 
what they're going to do.

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : I've said this before, but I think that the email script
> : sandbox needs to be much tighter on the default config.
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> granted, it should be tighter be default.  however, as users we have a
> responsibility to understand the capabilities of the software we're using.
> using your argument i could complain to a gun manufacturer that i'm upset
> that i was able to use a weapon they made to shoot holes in my car.  it's my
> responsibility to know that if it's loaded and i pull the trigger that it
> will shoot a projectile.  if i don't want to cause damage to my car i
> shouldn't point it at my car and pull the trigger when it's loaded

Poor analogy. The damage from the email virus comes not from the 
user(therefore, *you* shooting *your* gun), but from an external 
source(hacker/cracker). Also, email software wasn't made to do 
damage(shooting holes in your car) to the users sytem(car) just like a 
gun isn't meant to shoot holes in cars(well, ya know ;). Everyone has a 
responsibility to use things correctly, but this analogy makes it seem 
like, "If I'm just out shooting shit with my gun like I should be(or 
emailing like one should be), and all the sudden it starts shooting cars 
through no fault of my own, WTF is up with that?"

> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : And in Eudora you have to _open_ the attachment to
> : get the virus :)
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> no links handy atm but i'm confident that i've read of virii that infected
> eudora when you viewed the infected message if your security settings
> weren't high enough.  remember, eudora uses ie as it's internal html
> rendering engine - just like outlook.

Ya, it uses the rendering engine of IE, but most virii come in through 
windows scripting host, which Eudora does *not* have tight integration 
with like Outlook does. You mention the powerful tool up at the top 
there(WSH), but switch to a rendering engine here. AFAIK, one does have 
to manually open an attachment in Eudora(most any email client other 
than outlook actually) so the program associated with the file extension 
can be started, and the attachment executed.(.exe, .vbs, .bat, etc) If 
one chooses not to open the attachment, it won't be executed. By 
default, this isn't the case in Outlook.

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : You can't blame the user for _all_ the security flaws
> : of Outlook.  Just some (when your IT guy says "Don't
> : open any attachment that ends with .vbs, you listen
> : to him!). But if the preview pane auto-activates it for
> : you, and the preview pane is a default setup, how is
> : the new user supposed to know they should have
> : been doing something different?
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> how is the new unix server admin to know they should do something different
> when they set up a unix box for the first time and left access to telnet?

Not sure where Unix server admins came into the mix here ;) but it is a 
whole boatload different(if not completely irrelavant). A unix server 
admin(or any server admin FTM) isn't an end user. An admin is one who is 
excpeted to have a certain knowledge about the enviornment that they 
work in. An outlook user OTOH, is more than likely *not* an experienced 
computer user, they just want to send their grandkids pictures of their 
vacation to Florida and remind them to scrub behind their ears. They 
could give a (proverbial) flyingfuck about virii and 'security preferences'.

Also, leaving access to telnet is not even close to the lack of security 
that Outlook has. If one does leave open telnet services, an attacker 
has to somehow get a password and username to get access to the machine. 
This often requires advanced social engineering skills or an ethernet 
sniffer on a non-switched LAN(either of which are Not Easy). Even if 
said attacker were to somehow get access to the machine through telnet, 
they're connecting as a regular user, and to be able to do anything even 
halfway productive(in the attackers eyes), as they still have to get the 
root(admin) password.

My point is, in this example, its much much more difficult to be able to 
damage(or write files/alter sys configs) in that enviornment. With a 
default Win98 setup and Outlook, its very easy. Granted, that on a 
locked down, properly configured, patched box, this is more difficult, 
just answering the point here.

Sorry Jeff, guess I'm in a bad mood from unpacking so many boxes :)

ttyl..

.djc.