From bmurray at snf.stanford.edu  Sun Nov  3 17:56:47 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Sun, 3 Nov 2002 17:56:47 -0800 (PST)
Subject: rosen.stanford.edu blackholed on SMTP servers (fwd)
Message-ID: <Pine.LNX.4.04.10211031755170.31937-110000@snf.stanford.edu>

Mr. computer at snf,

Unfortunately, I don't have time to deal with this at the moment.  Maybe
being "blackholed" at Stanford is a good thing.

Bill

---------- Forwarded message ----------
Date: Sun, 3 Nov 2002 14:20:55 -0800 (PST)
From: Jason Conroy <jconroy at cisnet.stanford.edu>
To: John Shott <shott at snf.stanford.edu>, Bill Murray <bmurray at snf.stanford.edu>,
     Mike Bell <mbell at snf.stanford.edu>
Subject: rosen.stanford.edu blackholed on SMTP servers (fwd)

---------- Forwarded message ----------
Date: Sun, 03 Nov 2002 10:22:04 -0800
From: Russ Allbery <eagle at windlord.stanford.edu>
To: "jconroy at teargarden.Stanford.EDU" <jconroy at teargarden.Stanford.EDU>,
     "security-nr at stanford.edu" <security-nr at stanford.edu>
Cc: "action-mail at stanford.edu" <action-mail at stanford.edu>
Subject: rosen.stanford.edu blackholed on SMTP servers

I've blackholed rosen.stanford.edu on the SMTP servers because it appears
to be an open relay.  Example double-bounce message attached.

         name: rosen
            alias: labadmin, rosencrantz
         type: Node (Host)
          cpu: Sun Ultra 2                                                     
       op-sys: Solaris (1)
   department: Electrical Engineering                                          
     location: Ctr for Integrated Systems (CIS) (04-050)                       
   interfaces: 
     1) ip-addr: 171.64.101.12      
         user: William McGaffee Murray (ds493h284)
administrator: Jason F Conroy (ds569b046)
        group: Electrical Engr
   updated-by: Jason F Conroy (ds569b046)
 date-updated: Nov 08 13:40 PST 2000

-- 
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITSS Infrastructure Services, Stanford University


-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 12901
URL: <http://snf.stanford.edu/pipermail/computer/attachments/20021103/16e34054/attachment.mht>

From mtang at snf.stanford.edu  Mon Nov  4 10:18:03 2002
From: mtang at snf.stanford.edu (Mary Tang)
Date: Mon, 04 Nov 2002 10:18:03 -0800
Subject: Help!!!!!
Message-ID: <3DC6B9DB.AE22C358@snf.stanford.edu>

Hi guys --

We've got an emergency situation here!  Paul's desktop won't boot -- and
as he's got everyone's mask files and programs for conversion, we're
down for maskmaking (darn!  Just when the maskwriter's come up!)  I'm
going to try to get a boot disk (he says he was running Win98??) and see
if we can find out what's wrong -- but I have to admit to being pretty
reckless when it comes to troubleshooting, and hope one of you can find
it in your hearts to lend a hand, or at least some sage advice...

Thanks,

Mary

--
Mary X. Tang, Ph.D.
National Nanofabrication Users' Network
Stanford Nanofabrication Facility
CIS Room 136, Mail Code 4070
Stanford, CA  94305
(650)723-9980
mtang at snf.stanford.edu




From bmurray at snf.stanford.edu  Wed Nov  6 09:22:46 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Wed, 6 Nov 2002 09:22:46 -0800 (PST)
Subject: Your Outlook/Email Problem
Message-ID: <Pine.LNX.4.04.10211060921130.25159-100000@snf.stanford.edu>

Cesar,

I got your voice mail concerning your Outlook and email problems. 
Unfortunately, both Mike and I are working on urgent, time-critical
problems that John insists we complete before looking at anything else.

Dick has mentioned that Ray has an aptitude for and interest in computer
system administration.  Perhaps, Dick would allow him time to help you
troubleshoot your problem.  If that doesn't work, you better speak
with Dick or John about getting some of our time.

Sorry I can't be more helpful,
Bill 



From mtang at snf.stanford.edu  Wed Nov  6 18:08:27 2002
From: mtang at snf.stanford.edu (Mary Tang)
Date: Wed, 06 Nov 2002 18:08:27 -0800
Subject: CAD PC's
Message-ID: <3DC9CB1B.A039A50A@snf.stanford.edu>

Hello gentlemen --

The two PC's in the CAD room have a lot of stuff on them...  It seems
that it might be good to give people the option of saving their files on
CD.  I'd like to install a CDRW on each of them.  I think they need to
be IDE and NT compatible -- are there any other specific criteria you
think we should consider?  Well, other than cost...  Personally, I'd
rather like it if it used Nero software -- it seems to be supported well
and used by most CDRW.  The "Lite-on" system has good reviews and I
think meets these criteria (it's about $60):

http://osnews.pricegrabber.com/search_getprod.php/masterid=550413/ut=ab4064a204bf8db9

What do you think?  May I go ahead and order these?  (Or am I missing
something important?!)

Mary

--
Mary X. Tang, Ph.D.
National Nanofabrication Users' Network
Stanford Nanofabrication Facility
CIS Room 136, Mail Code 4070
Stanford, CA  94305
(650)723-9980
mtang at snf.stanford.edu




From bmurray at snf.stanford.edu  Fri Nov  8 07:34:22 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Fri, 8 Nov 2002 07:34:22 -0800 (PST)
Subject: crystal down? (fwd)
Message-ID: <Pine.LNX.4.04.10211080734170.29854-100000@snf.stanford.edu>



---------- Forwarded message ----------
Date: Thu, 7 Nov 2002 23:58:45 -0800 (PST)
From: Amol Joshi <amol at Stanford.EDU>
To: William McGaffee Murray <bmurray at Stanford.EDU>
Subject: crystal down?


Hi Bill,

It seems that crystal.stanford.edu is not responding to ping or ssh. It is
required for tylansige since certain programs can only be loaded using
crystal. I am planning to use tylansige at 9am Friday. Is it possible to
have crystal working by that time?

Thanks a lot,

- Amol




From michael.bell at stanford.edu  Fri Nov  8 07:37:26 2002
From: michael.bell at stanford.edu (Michael Bell)
Date: Fri, 08 Nov 2002 07:37:26 -0800
Subject: crystal down? (fwd)
References: <Pine.LNX.4.04.10211080734170.29854-100000@snf.stanford.edu>
Message-ID: <3DCBDA36.75E6614E@stanford.edu>

Replugged the cable and it's responding to a ping now.

mike

Bill Murray wrote:

> ---------- Forwarded message ----------
> Date: Thu, 7 Nov 2002 23:58:45 -0800 (PST)
> From: Amol Joshi <amol at Stanford.EDU>
> To: William McGaffee Murray <bmurray at Stanford.EDU>
> Subject: crystal down?
>
> Hi Bill,
>
> It seems that crystal.stanford.edu is not responding to ping or ssh. It is
> required for tylansige since certain programs can only be loaded using
> crystal. I am planning to use tylansige at 9am Friday. Is it possible to
> have crystal working by that time?
>
> Thanks a lot,
>
> - Amol



From bmurray at snf.stanford.edu  Mon Nov 11 14:10:03 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 11 Nov 2002 14:10:03 -0800 (PST)
Subject: defective computer mice (fwd)
Message-ID: <Pine.LNX.4.04.10211111409570.4716-100000@snf.stanford.edu>



---------- Forwarded message ----------
Date: Mon, 11 Nov 2002 14:03:31 -0800 (PST)
From: Amol Joshi <amol at stanford.edu>
To: bmurray at snf.Stanford.EDU
Cc: mbell at snf.stanford.edu
Subject: defective computer mice


Hi Bill,

Three coral terminals opposite wbdiff have defective mice. Please
replace/repair them. It is extremely irritating to use them.

Thanks,

- Amol



From bmurray at snf.stanford.edu  Mon Nov 11 14:11:08 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Mon, 11 Nov 2002 14:11:08 -0800 (PST)
Subject: defective computer mice
In-Reply-To: <Pine.GSO.4.44.0211111357380.8078-100000@elaine20.Stanford.EDU>
Message-ID: <Pine.LNX.4.04.10211111410100.4716-100000@snf.stanford.edu>

Amol,

The maintenance staff has replacement mice and takes care of this.

Thanks,
Bill

On Mon, 11 Nov 2002, Amol Joshi wrote:

> 
> Hi Bill,
> 
> Three coral terminals opposite wbdiff have defective mice. Please
> replace/repair them. It is extremely irritating to use them.
> 
> Thanks,
> 
> - Amol
> 



From tberg at snf.stanford.edu  Mon Nov 11 14:21:25 2002
From: tberg at snf.stanford.edu (Ted Berg)
Date: Mon, 11 Nov 2002 14:21:25 -0800
Subject: Crystal not working
Message-ID: <3DD02D65.699AB0B9@snf.stanford.edu>

Hello guys, i just did theplug thing again and still cannot connect to
crystal. and tylan both network cards were blinking when i left . Any
thoughts??



From amol at stanford.edu  Mon Nov 11 14:26:13 2002
From: amol at stanford.edu (Amol Joshi)
Date: Mon, 11 Nov 2002 14:26:13 -0800 (PST)
Subject: defective computer mice
In-Reply-To: <Pine.LNX.4.04.10211111410100.4716-100000@snf.stanford.edu>
Message-ID: <Pine.GSO.4.44.0211111415090.8078-100000@elaine20.Stanford.EDU>


Hi Bill,

I was not aware of computer at snf. It is not listed on snf page.

Thanks,

- Amol


On Mon, 11 Nov 2002, Bill Murray wrote:

>Amol,
>
>The maintenance staff has replacement mice and takes care of this.
>
>Thanks,
>Bill



From tberg at snf.stanford.edu  Tue Nov 12 06:54:30 2002
From: tberg at snf.stanford.edu (Ted Berg)
Date: Tue, 12 Nov 2002 06:54:30 -0800
Subject: Crystal connection is not working
Message-ID: <3DD11626.FDC99D06@snf.stanford.edu>

Hello guys,
    I did the plug trick yesterday and i still cannot connect to
crystal, any ideas??ted



From bmurray at snf.stanford.edu  Tue Nov 12 07:33:43 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Tue, 12 Nov 2002 07:33:43 -0800 (PST)
Subject: Crystal connection is not working
In-Reply-To: <3DD11626.FDC99D06@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10211120729530.27562-100000@snf.stanford.edu>

Ted,

It's actually a miracle that we have been able to keep this computer 
running this long.  I had advised everyone over 5 years ago that we would
not be able to keep crystal running after January 1, 2000.  It's time
to power down crystal for good and put your plan B into effect.

Bill 


On Tue, 12 Nov 2002, Ted Berg wrote:

> Hello guys,
>     I did the plug trick yesterday and i still cannot connect to
> crystal, any ideas??ted
> 



From tberg at snf.stanford.edu  Tue Nov 12 07:47:42 2002
From: tberg at snf.stanford.edu (Ted Berg)
Date: Tue, 12 Nov 2002 07:47:42 -0800
Subject: Crystal connection is not working
References: <Pine.LNX.4.04.10211120729530.27562-100000@snf.stanford.edu>
Message-ID: <3DD1229E.26F7EA54@snf.stanford.edu>

Bill, I wish there was a plan B if we want any kind of status from the system
either we get it directly from the tycom in the lab or get none. It doesn't
look like any budget for anything else.ted

Bill Murray wrote:

> Ted,
>
> It's actually a miracle that we have been able to keep this computer
> running this long.  I had advised everyone over 5 years ago that we would
> not be able to keep crystal running after January 1, 2000.  It's time
> to power down crystal for good and put your plan B into effect.
>
> Bill
>
> On Tue, 12 Nov 2002, Ted Berg wrote:
>
> > Hello guys,
> >     I did the plug trick yesterday and i still cannot connect to
> > crystal, any ideas??ted
> >



From booth at snf.stanford.edu  Tue Nov 12 08:52:51 2002
From: booth at snf.stanford.edu (Len Booth)
Date: Tue, 12 Nov 2002 08:52:51 -0800
Subject: CORAL strangeness?    Nov 12, 2002
Message-ID: <3DD131E3.A033E3B0@snf.stanford.edu>

All -
	Several of us in maint have noticed
CORAL operation that seems odd.
We can successfully enable/disable equipment
& the CORAL application does show the user name
when enabled, and the green/yellow/red indicator
lights change appropriately, BUT no automatic
e-mail messages are being generated & sent to
us in maint.  I see that this condition has been
like this since at least about 10pm last night.
Ted check with his CORAL account, and sees the
same symptoms.  Could you please investigate
& let us know?		thanks,
			Len


From bmurray at snf.stanford.edu  Tue Nov 12 08:58:19 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Tue, 12 Nov 2002 08:58:19 -0800 (PST)
Subject: CORAL strangeness?    Nov 12, 2002
In-Reply-To: <3DD131E3.A033E3B0@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10211120857590.30847-100000@snf.stanford.edu>

Len,

Thanks for the warning.  I'll take a look at the logs now.

Bill

On Tue, 12 Nov 2002, Len Booth wrote:

> All -
> 	Several of us in maint have noticed
> CORAL operation that seems odd.
> We can successfully enable/disable equipment
> & the CORAL application does show the user name
> when enabled, and the green/yellow/red indicator
> lights change appropriately, BUT no automatic
> e-mail messages are being generated & sent to
> us in maint.  I see that this condition has been
> like this since at least about 10pm last night.
> Ted check with his CORAL account, and sees the
> same symptoms.  Could you please investigate
> & let us know?		thanks,
> 			Len
> 



From bmurray at snf.stanford.edu  Tue Nov 12 09:04:10 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Tue, 12 Nov 2002 09:04:10 -0800 (PST)
Subject: CORAL strangeness?    Nov 12, 2002
In-Reply-To: <Pine.LNX.4.04.10211120857590.30847-100000@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10211120902390.30847-100000@snf.stanford.edu>

Len,

This bug has been fixed, but we have not yet had the time to install
the fix in production.  Sorry!  I've restarted the servers.  You may
see things a little out of synch for a short time.

Thanks,
Bill

On Tue, 12 Nov 2002, Bill Murray wrote:

> Len,
> 
> Thanks for the warning.  I'll take a look at the logs now.
> 
> Bill
> 
> On Tue, 12 Nov 2002, Len Booth wrote:
> 
> > All -
> > 	Several of us in maint have noticed
> > CORAL operation that seems odd.
> > We can successfully enable/disable equipment
> > & the CORAL application does show the user name
> > when enabled, and the green/yellow/red indicator
> > lights change appropriately, BUT no automatic
> > e-mail messages are being generated & sent to
> > us in maint.  I see that this condition has been
> > like this since at least about 10pm last night.
> > Ted check with his CORAL account, and sees the
> > same symptoms.  Could you please investigate
> > & let us know?		thanks,
> > 			Len
> > 
> 



From tberg at snf.stanford.edu  Tue Nov 12 15:15:21 2002
From: tberg at snf.stanford.edu (Ted Berg)
Date: Tue, 12 Nov 2002 15:15:21 -0800
Subject: Thanks
Message-ID: <3DD18B89.F8D7309A@snf.stanford.edu>

Thanks for bringing crystal back to life at least for now.ted



From shott at snf.stanford.edu  Tue Nov 12 15:20:33 2002
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 12 Nov 2002 15:20:33 -0800
Subject: Thanks
References: <3DD18B89.F8D7309A@snf.stanford.edu>
Message-ID: <3DD18CC1.B98028D@snf.stanford.edu>

Ted:

We'll, I was able to clean up a few things ...

However, as Bill indicated, we are running on borrowed time on this system ...
we are nearly 3 years past it's "drop dead" date.  Also, the operating system
that we are using (Ultrix) was not the main operating system of DEC (their
primary operating system was VMS in that era ...) and DEC no longer exists
(they were bought out by Compaq who has since merged with HP ...).

There are parts of this system that died of a Y2K problem and there simply is
no means of upgrading them.

So, the best that we can do is limp along with what we have ....

Thanks,

John


From michael.bell at stanford.edu  Wed Nov 13 07:08:52 2002
From: michael.bell at stanford.edu (Michael Bell)
Date: Wed, 13 Nov 2002 07:08:52 -0800
Subject: monitor out
Message-ID: <3DD26B04.5BC9675B@stanford.edu>

Per a phone message left by Mario there is a computer monitor down in
the litho area of the lab.

Bill was that monitor that I put in the lab last week the last one we
had?

Mike





From michael.bell at stanford.edu  Wed Nov 13 07:29:56 2002
From: michael.bell at stanford.edu (Michael Bell)
Date: Wed, 13 Nov 2002 07:29:56 -0800
Subject: [Fwd: monitor out]
Message-ID: <3DD26FF4.3F0374DA@stanford.edu>

Mario,

I've forwarded this to the computer request list. Is this a Sunray (that
uses smart cards), a regular PC, or something else? If you can please
reply to the computer at snf.stanford.edu.

Thanks.

Mike
-------------- next part --------------
An embedded message was scrubbed...
From: Mario Vilanova <vilanova at snf.stanford.edu>
Subject: Re: monitor out
Date: Wed, 13 Nov 2002 07:15:25 -0800 (PST)
Size: 1694
URL: <http://snf.stanford.edu/pipermail/computer/attachments/20021113/142c35da/attachment.mht>

From michael.bell at stanford.edu  Wed Nov 13 08:19:12 2002
From: michael.bell at stanford.edu (Michael Bell)
Date: Wed, 13 Nov 2002 08:19:12 -0800
Subject: mice
Message-ID: <3DD27B80.62693E06@stanford.edu>

Len,

Thanks for swaping out the dead mice for us. Per our conversation I've
ordered another 10 mice.

Mike



From bmurray at snf.stanford.edu  Wed Nov 13 10:35:03 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Wed, 13 Nov 2002 10:35:03 -0800 (PST)
Subject: monitor out
In-Reply-To: <3DD26B04.5BC9675B@stanford.edu>
Message-ID: <Pine.LNX.4.04.10211131034300.17485-100000@snf.stanford.edu>

Mike,

No, this must be a different monitor.

Bill

On Wed, 13 Nov 2002, Michael Bell wrote:

> Per a phone message left by Mario there is a computer monitor down in
> the litho area of the lab.
> 
> Bill was that monitor that I put in the lab last week the last one we
> had?
> 
> Mike
> 
> 
> 



From curlwang at stanford.edu  Wed Nov 20 08:42:19 2002
From: curlwang at stanford.edu (Ke Wang)
Date: Wed, 20 Nov 2002 08:42:19 -0800 (PST)
Subject: STS mail list
Message-ID: <Pine.GSO.4.44.0211200837410.25843-100000@elaine38.Stanford.EDU>

Hello,

I think I'm probably not included in the mail list of STS PECVD, since I
haven't received any email about it. Could you please have a check? My coral
is kwang.

Many thanks!

Ke

_____________________________________________
Ke Wang
PHD Candidate
Department of Applied Physics, Stanford University

CISX B113-14
Stanford, CA 94305-4070

Phone: (650)723-8040



From bmurray at snf.stanford.edu  Thu Nov 21 11:01:17 2002
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Thu, 21 Nov 2002 11:01:17 -0800 (PST)
Subject: [GECOS] Fwd: Microsoft Security Bulletin MS02-065: Buffer Overrun
 in Microsoft Data Access Components Could Lead to Code Execution (Q329414)
 (fwd)
Message-ID: <Pine.LNX.4.04.10211211056190.32217-100000@snf.stanford.edu>

John and Mike,

Since my Windows machine at home was hacked recently, I've been careful
to keep it patched.  I periodically patch the OS, run virus scan, and
defrag the disks.  Although some of these items can be automated, I prefer
to run them manually for a number of reasons.  This last patch is critical.
I suspect that most of our staff desktops are at risk.  Just to let you
know, this took about an hour of my time to do on my machine.

Bill

---------- Forwarded message ----------
Date: Wed, 20 Nov 2002 12:44:33 -0800
From: Joe Little <jlittle at open-it.org>
To: gecos at island.stanford.edu
Subject: [GECOS] Fwd: Microsoft Security Bulletin MS02-065: Buffer Overrun in
    Microsoft Data Access Components Could Lead to Code Execution (Q329414)

Something to patch on W2K/XP/WinME.. pretty important as it is marked  
critical.


Begin forwarded message:

> Resent-From: mssec at kigi.mailshell.com
> From: "Microsoft"  
> <0_41279_1F68B851-2F7D-EB41-A6C3- 
> CAB5E6906B6F_US.at.Newsletters.Microsoft.com at mssec.at.kigi.mailshell.co 
> m>
> Date: Wed Nov 20, 2002  10:46:18 AM US/Pacific
> Resent-To: jlittle at open-it.org
> To: "mssec at kigi.mailshell.com" <mssec at kigi.mailshell.com>
> Subject: Microsoft Security Bulletin MS02-065: Buffer Overrun in  
> Microsoft Data Access Components Could Lead to Code Execution > (Q329414)
> Reply-To:  
> "3_41279_1F68B851-2F7D-EB41-A6C3- 
> CAB5E6906B6F_US at Newsletters.Microsoft.com"  
> <3_41279_1F68B851-2F7D-EB41-A6C3- 
> CAB5E6906B6F_US.at.Newsletters.Microsoft.com at mssec.at.kigi.mailshell.co 
> m>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> -  
> ----------------------------------------------------------------------
> Title:      Buffer Overrun in Microsoft Data Access Components Could
>             Lead to Code Execution (Q329414)
> Date:       20 November, 2002
> Software:
>             Microsoft Data Access Components (MDAC) 2.1
>             Microsoft Data Access Components (MDAC) 2.5
>             Microsoft Data Access Components (MDAC) 2.6
>             Microsoft Internet Explorer 5.01
>             Microsoft Internet Explorer 5.5
>             Microsoft Internet Explorer 6.0
> Impact:     Run code of attacker?s choice
> Max Risk:   Critical
> Bulletin:   MS02-065
>
> Microsoft encourages customers to review the Security Bulletins at:
> http://rd.mailshell.com/www.microsoft.com/security/security_bulletins/ 
> ms02-065.asp
> http://rd.mailshell.com/www.microsoft.com/technet/security/bulletin/ 
> MS02-065.asp.
> -  
> ----------------------------------------------------------------------
>
> Issue:
> ======
> Microsoft Data Access Components (MDAC) is a collection of components
> used to provide database connectivity on Windows platforms. MDAC is
> a ubiquitous technology, and it is likely to be present on most
> Windows systems:
>
>
> - - It is included by default as part of Windows XP, Windows 2000, and
>   Windows Millennium.
> - - It is available for download as a stand-alone technology in its
>   own right.
> - - It is either included in or installed by a number of other products
>   and technologies. For instance, MDAC is included in the Windows NT
>   4.0 Option Pack, and some MDAC components are present as part of
>   Internet Explorer even if MDAC itself is not installed.
>
> MDAC provides the underlying functionality for a number of database
> operations, such as connecting to remote databases and returning data
> to a client. One of the MDAC components, known as Remote Data
> Services(RDS), provides functionality that support three-tiered
> Architectures ? that is, architectures in which a client?s requests
> for service from a back-end database are intermediated through a web
> site that applies business logic to them. A security vulnerability
> is present in the RDS implementation, specifically, in a function
> called the RDS Data Stub, whose purpose it is to parse incoming
> HTTP requests and generate RDS commands.
>
> The vulnerability results because of an unchecked buffer in the Data
> Stub. By sending a specially malformed HTTP request to the Data Stub,
> an attacker could cause data of his or her choice to overrun onto the
> heap. Although heap overruns are typically more difficult to exploit
> than the more-common stack overrun, Microsoft has confirmed that in
> this case it would be possible to exploit the vulnerability to run
> code of the attacker?s choice on the user?s system.
>
> Both web servers and web clients are at risk from the vulnerability:
> -  
> ----------------------------------------------------------------------
> - - Web servers are at risk if a vulnerable version of MDAC is
> installed
>   and running on the server. To exploit the vulnerability against
> such
>   a web server, an attacker would need to establish a connection with
>   the server and then send a specially malformed HTTP request to it,
>   that would have the effect of overrunning the buffer with the
>   attacker?s chosen data. The code would run in the security context
>   of the IIS service (which, by default, runs in the LocalSystem
>   context)
> - - Web clients are at risk in almost every case, as the RDS Data Stub
>   is included with all current versions of Internet Explorer and
>   there is no option to disable it. To exploit the vulnerability
>   against a client, an attacker would need to host a web page that,
>   when opened, would send an HTTP reply to the user's system and
>   overrun the buffer with the attacker's chosen data. The web page
>   could be hosted on a web site or sent directly to users as an HTML
>   Mail. The code would run in the security context of the user.
>
> Clearly, this vulnerability is very serious, and Microsoft recommends
> that all customers whose systems could be affected by them take app-
> ropriate action immediately. Web server administrators should either
> install the patch, disable MDAC and/or RDS, or upgrade to MDAC 2.7,
> which is not affected by the vulnerability. Web client users should
> install the patch immediately on any system that is used for web
> browsing. It is important to stress that the latter guidance applies
> to any system used for web browsing, regardless of any other
> protective measures that have already been taken. For instance, a
> web server on which RDS had been disabled would still need the patch
> if it was occasionally used as a web client.
>
> Mitigating Factors:
> ====================
> Web Servers
> - - Web servers that are using MDAC version 2.7 (the version that
>   shipped with Windows XP) or later are not affected by the vulner-
>   ability.
> - - Even if a vulnerable version of MDAC were installed, a web server
>   would only be at risk if RDS were enabled. RDS is disabled by
> default
>   on clean installations of Windows XP and Windows 2000, and can be
>   disabled on other systems by following the guidance in the IIS
>   Security Checklist. In addition, the IIS Lockdown Tool will
>   automatically disable RDS when used in its default configuration.
> - - If the URLScan tool were deployed with its default ruleset (which
>   allows only ASCII data to be present in an HTTP request), it is
>   likely that the vulnerability could only be used for denial of
>   service attacks.
> - - IIS can be configured to run with fewer than administrative priv-
>   ileges. If this has been done, it would likewise limit the
> privileges
>   that an attacker could gain through the vulnerability.
> - - IP address restrictions, if applied to the RDS virtual directory,
>   could enable the administrator to restrict access to only trusted
>   users. This is, however, not practical for most web server
> scenarios.
>
> Web clients
> - - The HTML mail-based attack vector could not be exploited auto-
>   matically on systems where Outlook 98 or Outlook 2000 were used
>   in conjunction with the Outlook Email Security Update, or Outlook
>   Express 6 or Outlook 2002 were used in their default
> configurations.
> - - Exploiting the vulnerability would convey to the attacker only the
>   user?s privileges on the system. Users whose accounts are
> configured
>   to have few privileges on the system would be at less risk than
>   ones who operate with administrative privileges.
>
> Risk Rating:
> ============
>  - Internet systems: Critical
>  - Intranet systems: Critical
>  - Client systems: Critical
>
> Patch Availability:
> ===================
>  - A patch is available to fix this vulnerability. Please read the
>    Security Bulletin at
>     
> http://rd.mailshell.com/www.microsoft.com/technet/security/bulletin/ 
> ms02-065.asp
>    for information on obtaining this patch.
>
> Acknowledgment:
> ===============
>  - Microsoft thanks  Foundstone Research Labs
>    (http://rd.mailshell.com/www.foundstone.com/) for reporting this  
> issue to us
>    and  working with us to protect customers.
>
> - ---------------------------------------------------------------------
>
> THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
> PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS
> ALL
> WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE
> WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
> IN NO EVENT
> SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY
> DAMAGES
> WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL,
> LOSS OF
> BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR
> ITS
> SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME
> STATES DO
> NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL
> OR
> INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.1
>
> iQEVAwUBPdvJ8I0ZSRQxA/UrAQER+wgAj6UQfMzv8Ydv4ZuZVuQS0CHiVQ+r8Ykm
> kDZ/EQhmDo7/j+SXVqGjvycrZCGFET5guGbrGzc7z4bQFAQMs2YxbOxhDYirCxQ6
> 9zsRDuUkmztjY7VB+oeWBIgaENcFPfv0v9XOMN8pArr1PziHaKOeZ+pYkoFvM83t
> IegB6sRw6dc8UfvC0j5eyCnW+YXrRgWjAq3KCn+TW7dVgGSCONUXtwXPxzEivk21
> zcNu8pOWY7z49zOLJKJlad78XiraUvhUNj1IGM0J5/XhRHsVe1MI3+V8Btsx0EGo
> XwwHx8Zua0l4n/XMufIr5Zr0jhNH9KO2jABDvDCEw3ofGeYo/mJgZw==
> =CYOd
> -----END PGP SIGNATURE-----
>
>
> *******************************************************************
>
> You have received this e-mail bulletin because of your subscription to  
> the Microsoft Product Security Notification Service.  For more  
> information on this service, please visit  
> http://rd.mailshell.com/www.microsoft.com/technet/security/notify.asp.
>
> To verify the digital signature on this bulletin, please download our  
> PGP key at  
> http://rd.mailshell.com/www.microsoft.com/technet/security/notify.asp.
>
> To unsubscribe from the Microsoft Security Notification Service,  
> please visit the Microsoft Profile Center at  
> http://rd.mailshell.com/register.microsoft.com/regsys/pic.asp
>
> If you do not wish to use Microsoft Passport, you can unsubscribe from  
> the Microsoft Security Notification Service via email as described  
> below:
> Reply to this message with the word UNSUBSCRIBE in the Subject line.
>
> For security-related information about Microsoft products, please  
> visit the Microsoft Security Advisor web site at  
> http://rd.mailshell.com/www.microsoft.com/security.
>
>
> ---------- Your email is protected by Mailshell ----------
> To block spam or change delivery options:  
> http://www.mailshell.com/> control.html?a=bmfxunag1_qf4mjs5ggakkoqtkhqt2e
>
> ReturnPath.net http://rd.mailshell.com/ad481
> Earn up to $3 for each of your friends who signs up with Mailshell!  
> http://rd.mailshell.com/sp5

_______________________________________________
GECOS mailing list
GECOS at island.stanford.edu
http://island.stanford.edu/mailman/listinfo/gecos



From utkan at stanford.edu  Tue Nov 26 17:35:28 2002
From: utkan at stanford.edu (Utkan Demirci)
Date: Tue, 26 Nov 2002 17:35:28 -0800 (PST)
Subject: Capture software (fwd)
Message-ID: <Pine.LNX.4.44.0211261734020.6521-100000@cardinal2.Stanford.EDU>

> Hi,
> The capture software for taking pictures is down since last
> saturday. This is the software setup in the room next to the gowning
room.
 It seems to need reloading. Could I request it to be fixed?
> I am waiting for it to get fixed before I can take my device out of the
> clean room.
>
> Thanks,
> Utkan