From: llurch@Networking.Stanford.EDU (Richard Charles Graves)
Date: Mon, 13 Nov 1995 20:37:05 +0800
To: Cypherpunks Lite <cp-lite@comsec.com>
Subject: MS Corrects Press Release on "Samba" Security Problem
Message-ID: <199511130517.VAA21401@comsec.com>
MIME-Version: 1.0
Content-Type: text/plain


The Win95 product manager let me know yesterday that they'd corrected some
of the errors on their Web server. I'm sure Microsoft is planning to
publicize the changes in greater detail, so I'll just summarize them here. 

Load the original security bugfix news release at
gopher://quixote.stanford.edu/0R1271897-1279147-/win95netbugs side-by-side
with the corrected version now at
http://www.microsoft.com/windows/software/w95fpup.htm to see the changes. 
Notable corrections are:

1. Microsoft has retracted the puzzling allegation that SMBCLIENT sends
"illegal commands" across the network. 

2. Microsoft is now a bit more forthright in acknowledging that the 
problem applies to all language versions of Win95.

They didn't change the date, and they still say that Samba is shareware. 
And they still fail to give proper credit to the third parties that
actually found the problems for Microsoft. Oh well, can't have everything. 

Microsoft has also promised that localized (foreign-language) versions of
the "updated files that address the issue" will be made available within
two weeks. I still don't understand what the hold-up is, but a time frame 
is good.

In addition, Microsoft is reconsidering the position of the NE4100 and
certain NE2000- compatible PCMCIA cards like the EFA-207 on the hardware
compatibility list because, well, they aren't. 

Yusuf has given his imprimatur of Official Microsoft Response to the
discussion of the well-known IPX SAP routing and security issue saved at
gopher://quixote.stanford.edu/0R161799-178969-/win95netbugs. Previously
this had only been posted with the "speaking only for myself" disclaimer,.
Microsoft had acknowledged only the specific "server name conflict issue"
covered by PC Week, not the underlying general problem that has been
widely discussed on Usenet. Maybe we'll get a good article into the
Knowledge Base now. 

I'm still hoping they'll document the known and acknowledged ProviderPath 
problem with wsock32.dll.

Progress comes slowly.

-rich