Help! LsaSrv dies w/Event ID: 5000

Greetings!
I've searched the newsgroups & forums and found many flavors of similar
problems, but not this particular flavor.

Win2K Server, SP4, running Exchange 5.5 SP4

The unique part of this crash is the 7855f218 address. I found articles with
other crashes, but none of the addresses matched this one.

This system has been stable for years; just started getting these errors
earlier this week, and it is getting more frequent (1 Saturday, 2 yesterday,
1 today). Always the same address, unknown what is stimulating the problem.
Once this crashes, we end up having to reboot the server.

After digging, the only item I found that might relate to this issue is
MS04-11 (835732) (both LSASS.EXE and LSASRV.DLL were updated), but there is
nothing specific about the crash's address that says this is the problem and
it gets fixed.

Outside world can touch IIS, FTP, and PPTP on this server which is NATted by
the firewall. Internally, clients are all Win2K or WinXP. There is a new
Server2003 box on their network but it isn't interfacing with anything yet.

If anyone has seen this and knows what could be happening, I'd appreciate
whatever you might know.

Sample snip from the error log is below:

Event Type: Error
Event Source: LsaSrv
Event Category: Devices
Event ID: 5000
Date: 6/3/2005
Time: 7:38:06 AM
User: N/A
Computer: SERVER-E
Description:
The security package Negotiate generated an exception. The package is now

disabled. The exception information is the data.
Data:
0000: 05 00 00 c0 00 00 00 00 .......
0008: 00 00 00 00 18 f2 55 78 .....Ux
0010: 02 00 00 00 00 00 00 00 ........
0018: 0c 00 00 00 3f 00 01 00 ....?...
0020: 00 00 00 00 00 00 00 00 ........
0028: 00 00 00 00 00 00 00 00 ........
0030: 00 00 00 00 00 00 00 00 ........
0038: 7f 02 ff ff 00 00 ff ff ...
0040: ff ff ff ff 00 00 00 00 ....
0048: 00 00 00 00 00 00 00 00 ........

Version info currently running:

LSASRV.DLL: 6/19/03 1:05 pm 518,928 bytes ver: 5.0.2195.6695
LSASS.EXE: Same (33,552 bytes) ver: 5.0.2195.6695

Thanks!!

Hello

We have had 4 servers die over the last few days with the same error
message.

All servers were Windows 2000 SP4, Exchange 2000 SP3, Mcafee
Groupshield 5 + Netshield - all running latest DATS.

In all cases once it hung mad.exe was using nearly all cpu time, but
restart and everything seemed fine.

We have tried updating mcafee engine and dats manually with superdat on
2 of the servers, along with checking all windows critical updates were
installed - and both seen to have been stable for the past 2 days.

One of the other servers died within 1 hour of being rebooted
yesterday.

All machines are behind firewalls.

thanks

Jonathan

Hi there,

we have exactly the same problem here. It startet from the 1st of June.
We got 3 Windows 2000 Servers (all SP4) and one W2003 Domain
Controller. Only one (for the time) Windows 2000 Server is affected. We
is serving as a Exchange 2k and SQL2k for our network. The Exchange
System is separated from the outside world throug a mailrelay. Only the
IIS (which is needed for OWA) is directly connected via the firewall to
the internet.

After receiving the LSAsrv Error you can only hard reset your system.
We did not install any software updates to our system, so it´s a very
strange issue. I scanned for viruses with two different scanners,
nothing found. I reapplied SP4, no change.
Now I installed every security fix I can get via MS Update. But I
don´t think I will help. Furthermore I shut down the OWA Access, to
ensure the system did not have any direct access from the internet.

If anybody got an idea how to troubleshoot please post ist.

Maybe it´s an issue for Microsoft, cause it´s strange the a lot of
people have the same behaviour at nearly the same time

regards,

thorsten

I was experiencing the same thing on a windows 2000 SBS server with
service pack 4 installed. I noticed that when the server became
unresponsive I was getting "The security package Negotiate generated an

exception. The package is now disabled. The exception information is
the data" Logged in the event viewer. I also noticed at the exact
same time that event was logged, I was getting an HTTP request or SMTP
request in my IIS logs. It seems to be related to "Microsoft Security
Bulletin MS04-007" which can be found at
http://www.microsoft.com/techn*et/s.../MS04-007.*mspx .
I
downloaded the patch from that site and the problem has gone away. It
started to occur on June 1st. and was coming from multiple IP
addresses around the country, so it appears to be a new worm of some
sort, or it could be someone on IRC running a botnet to gain access to
windows boxes. If someone finds out exactly what it is, could you
please post it here?

New information...

I've contact Microsoft's security via email yesterday ~9 PM EDT and this
morning via the web form, but as yet haven't heard back.

Someone is testing a new exploit. I don't know if it is for a new security
hole or if it is for one that has already been plugged.

What I know at this time:

Windows Server 2000 / SP4 / not fully security patched is affected.
Windows Server 2000 / SP4 / fully security patched - not yet known (waiting
for the nasty expoit to again be tested on the server)
Windows Server 2003 / IIS 6.0 is not affected.

The attack vector is via an IIS packet which calls for authentication, hands
it a whole lot of data, and crashes LsaSrv that instant. Requires a server
reboot to bring the 2K Server back online.

I've correlated 4 occurrences of LsaSrv crashing with 4 incomming IIS
requests, all the same size, all at the exact same timestamp, all giving the
same error code out of IIS. The incomming request to IIS is 5699 bytes long,
and I see an error code in the IIS logfile of 2148074244, both of which are
highly suspicious.

Windows Server 2003 shows an error code of 404.

Based on the very low frequency of occurrence, I believe the exploit is
being tested and is not yet widely used. Prior to this discovery, I thought
this was a normal LsaSrv crash (thus the "Has anyone seen this?" original
post).

If someone with a fully security patched server can report in a "I've seen a
packet this size and my server didn't crash" or "My server crashed too and it
was fully patched" statement, that could tell us (and Microsoft) if this is a
new exploit for an old hole that is fixed or a new exploit for a new hole
that isn't yet fixed.

The input vector is via a public facing IIS port 80. The packet gets IIS to
try and do an SNMPv2-SMI::security.5.2 authentication (AKA: "SPNEGO - Simple
Protected Negotiation") When the oversized packet (it is filled with
"AAAAAAA...AAAA" to pad the buffer out) is handed around to various windows
processes, apparently that overflows a buffer and does some other damage. I'm
not sure what that other damage is yet.

More will be posted here as I learn it, though I was looking forward to not
working this weekend!

Forgot to mention...

The first packet that caused this crash was Thursday, 6/2/05 @ 4:00 AM EDT,
not last Saturday as originally reported. The next packet came in at 7:30 AM.
The last packet I've seen came in Friday at 7:50 PM EDT.

I have the offending packets captured via Ethereal.

The log line looks like this:

66.54.153.162, -, 6/3/2005, 7:38:06, W3SVC1, SERVER-E, 192.168.1.2, 110,
5699, 1 82, 500, 2148074244, GET, /, -,

Search for the 5699 packet size. The IP address in that log was one of the
attacking servers. The return code is also interesting; it should be 404 (and
is 404 on a Windows Server 2003 box).

Word from Microsoft folks:

"Based on the data below, this is most likely a variant of the Sasser worm
that exploits the LSASS vulnerability in MS04-011 that you reference below.
This a bug in the SPNEGO code so the negotiate errors you are seeing are
right in line with that."
....
"If you want to send us the network trace we would be happy to further
investigate and confirm this for you, but most likely this is a well known
and patched issue.
Best Regards
Scott"
-----------
The offending packets are in Microsoft's hands, awaiting their analysis.

The biggest concern is MS04-11 patches for Sasser variants, however until
now that vulnerability was not exploitable via IIS.

That is no longer the case. So your servers with port 80 accessible to the
outside world now need at least this update.

Microsoft hasn't yet confirmed this fixes the problem, though it seems very
likely right now.

I've patched the system that was experiencing the test runs of this exploit,
but as of yet the person controlling the release of this exploit hasn't tried
to hit that server again. If he does, that will confirm the fully-patched
server will not experience the issue.

I've also put out requests to a few folks that have seen this on their
servers to see if they have MS04-11 already installed. If they do and their
system was affected, that could escallate this in Microsoft's eyes.

I'll keep this thread posted with new developments as I find them.

We have the same problem... finding quite a few posts of this around th
Internet all starting around the same time... mid/late last week.
Haven't found a solution yet, but is sounding a bit suspicious.


David Soussan wrote:
> *Greetings!
> I've searched the newsgroups & forums and found many flavors o
> similar
> problems, but not this particular flavor.
>
> Win2K Server, SP4, running Exchange 5.5 SP4
>
> The unique part of this crash is the 7855f218 address. I foun
> articles with
> other crashes, but none of the addresses matched this one.
>
> This system has been stable for years; just started getting thes
> errors
> earlier this week, and it is getting more frequent (1 Saturday,
> yesterday,
> 1 today). Always the same address, unknown what is stimulating th
> problem.
> Once this crashes, we end up having to reboot the server.
>
> After digging, the only item I found that might relate to this issu
> is
> MS04-11 (835732) (both LSASS.EXE and LSASRV.DLL were updated), bu
> there is
> nothing specific about the crash's address that says this is th
> problem and
> it gets fixed.
>
> Outside world can touch IIS, FTP, and PPTP on this server which i
> NATted by
> the firewall. Internally, clients are all Win2K or WinXP. There is
> new
> Server2003 box on their network but it isn't interfacing wit
> anything yet.
>
> If anyone has seen this and knows what could be happening, I'
> appreciate
> whatever you might know.
>
> Sample snip from the error log is below:
>
> Event Type: Error
> Event Source: LsaSrv
> Event Category: Devices
> Event ID: 5000
> Date: 6/3/2005
> Time: 7:38:06 AM
> User: N/A
> Computer: SERVER-E
> Description:
> The security package Negotiate generated an exception. The packag
> is now
>
> disabled. The exception information is the data.
> Data:
> 0000: 05 00 00 c0 00 00 00 00 .......
> 0008: 00 00 00 00 18 f2 55 78 .....Ux
> 0010: 02 00 00 00 00 00 00 00 ........
> 0018: 0c 00 00 00 3f 00 01 00 ....?...
> 0020: 00 00 00 00 00 00 00 00 ........
> 0028: 00 00 00 00 00 00 00 00 ........
> 0030: 00 00 00 00 00 00 00 00 ........
> 0038: 7f 02 ff ff 00 00 ff ff ...
> 0040: ff ff ff ff 00 00 00 00 ....
> 0048: 00 00 00 00 00 00 00 00 ........
>
> Version info currently running:
>
> LSASRV.DLL: 6/19/03 1:05 pm 518,928 bytes ver: 5.0.2195.6695
> LSASS.EXE: Same (33,552 bytes) ver: 5.0.2195.6695
>
> Thanks!!


-
quiTec
-----------------------------------------------------------------------
Posted via http://www.webservertalk.co
-----------------------------------------------------------------------
View this thread: http://www.webservertalk.com/message1086590.htm

Here is the official word from Microsoft:

"Your trace matches other traces we have on this issue. Our data at this
point matches the June 5 entry here:
http://www.phreedom.org/solar/explo...asn1-bitstring/.

Let me know if I can be of any other help. We can confirm that the MS04-007
and MS04-011 security updates protect systems from all known ASN and LSASS
based issues, including your report."

I'm waiting for one of these nasty packets to hit the server again now that
it is patched. Hopefully the packet will bounce off harmlessly.

We also got hit by this problem yesterday. We have SP4 installed on the
affected server but not the mentioned hotfix.

At the moment we have closed the port 80 access to prevent this from
happening again until a valid solution is released. Any more word from
MS on this issue?