Subject: RE: filtering active content

From: "David Lemson" <[email-masked]>
Date: Sat, 28 Jul 2001 19:33:43 -0700

> The correct solution is to find out who at Microsoft refuses to put
> security safeguards on the address book(s) and allows scripts to 
> fully send messages instead of queueing for approval.  I find it 
> amazing that they haven't implemented such easy fixes in the past 
> couple of years, after things started getting really bad. 

Good news. This exact safeguard has been available as an add-on "patch"
for Outlook 98 and Outlook 2000 since June 2000, and it is built-in to
Outlook XP (aka Outlook 2002, released several months ago).  People
using Outlook 98 or 2000 with the patch, or anyone using Outlook XP will
not propagate viruses that run as script within Outlook.  
You can read more at:

http://www.microsoft.com/Office/previous/outlook/downloads/security.htm
(related to the patch for Outlook 98 and 2000)

http://www.microsoft.com/Office/it/solutions/security.htm (related to
features in Office XP - information on this feature begins on page 15)

David

---

From: "James P. Salsman" <[email-masked]>
Date: Sun, 29 Jul 2001 15:55:46 -0700 (PDT)

David,

Thanks for your message.  I followed the designated site well past June
2000, but I am in no mood to quibble with your version of history.

How do you feel about filtering winsock connections to TCP port 25 in 
a way such as would allow the user to confirm that a particular program 
could always do so, but would be asked to approve the connection when 
programs without prior approval do so?  That would take care of the 
SirCam strain.

A general winsock version of the tcpwrappers utility might go a long 
way, too, but might be subject to other forms of abuse.

Cheers,
James

> Date: Sat, 28 Jul 2001 19:33:43 -0700
> From: "David Lemson" <[email-masked]>
>

---

From: [email-masked]
Date: Sun, 29 Jul 2001 20:31:34 -0400

> programs without prior approval do so?  That would take care of the 

A patch has been available that would fix SirCam *and* most other
address-book viruses for a *year*, and we're still getting hosed by it.

Certainly doesn't bode well for when CodeRed wakes up in about 47 hours
and 30 minutes - I'll bet most of the 300K machines that got hacked are
still unpatched and still infected.

It's gonna be a LONG week guys.

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "James P. Salsman" <[email-masked]>
Date: Sun, 29 Jul 2001 18:25:28 -0700 (PDT)

> address-book viruses for a *year*, and we're still getting hosed by it.

I'm told SirCam doesn't look directly in the address book; instead it 
searches for email addresses in stored messages and web cache files.

That is why the IETF discussion list is getting hit harder by it than 
Melissa or ILOVEYOU or their ilk caused.

Also, SirCam finds your SMTP server and opens a direct connection to 
port 25 of that host, bypassing Outlook spool guards.  

> CodeRed wakes up in about 47 hours ... I'll bet most of the 300K 
> machines that got hacked are still unpatched and still infected.

I agree.  At least it doesn't cause spew on the IETF list.  Speaking 
of prevention measures, is there anything in i386 architecture which 
can prevetn execution of code on the stack, or is that exclusive to 
SPARCitecture?

Cheers,
James

---

From: Ari Ollikainen <[email-masked]>
Date: Sun, 29 Jul 2001 19:47:13 -0700

>It's gonna be a LONG week guys.

	A patch is available for Micro$oft IIS against CodeRed as well.

	Perhaps the Internet would be better off if all systems running
	Micro$oft Internet Information Services were just turned OFF
	until the patch is applied...

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Jul 2001 10:21:59 +0200

In your previous mail you wrote:

   Speaking of prevention measures, is there anything in i386
   architecture which can prevent execution of code on the stack, or
   is that exclusive to SPARC architecture?
   
=> you need a read-write-not_executable protection scheme in page
table entries. This is not common as you can see in NetBSD kernel sources
(/usr/src/sys/arch/*/include/pte.h). Of course i386 has not that.
BTW to make the stack not executable has side effects and is not as
effective as one can think.

Regards

[email-masked]

PS: if careful coding is not possible, we should promote safer languages
than C/C++, i.e. bound checking, strong typing, etc.