If the signature is good, but the signing key is invalid, it's because you
haven't signed the key yourself to make it valid on your keyring.

-----Original Message-----
From: Mobeen Azhar
To: win2ksecadviceLISTSERV.NTSECURITY.NET
Sent: 9/20/01 10:04 PM
Subject: Re: FW: New vulnerability in IIS4.0/5.0

Does anyone else get warnings about invalid signing keys on this
advisories from the ever-vigilant Microsoft Security Response Center or
is it just me?

--Moby

-----Original Message-----
From: Microsoft Security Response Center [mailto:secureMICROSOFT.COM]
Sent: Thursday, September 20, 2001 11:38 AM
To: win2ksecadviceLISTSERV.NTSECURITY.NET
Subject: Re: FW: New vulnerability in IIS4.0/5.0

*** PGP Signature Status: bad
*** Signer: Microsoft Security Response Center <securemicrosoft.com>
(Invalid)
*** Signed: 9/20/2001 11:38:24 AM
*** Verified: 9/20/2001 8:59:12 PM
*** BEGIN PGP VERIFIED MESSAGE ***

Hi All -

We've investigated this report, but it appears to be a false alarm.
We have been unable to reproduce any of the claims on IIS 4.0 or 5.0
with the latest cumulative patch applied
(http://www.microsoft.com/technet/security/bulletin/MS01-044.asp), or
on the latest beta version of IIS 5.1. The results from other
security organizations are the same -- none report any ability to
reproduce the claims in the report.

This is a good example of the wrong way to handle a security
vulnerability report. We didn't receive this report until mid-day on
19 September, well after it had been published on BugTraq and we'd
already begun an investigation. There is simply no rationale for
sending a vulnerability report to the world first, and to the vendor
-- the only party that could build a patch -- last.

If this had been a bona fide vulnerability, the irresponsible way it
was reported would have put a weapon into malicious users' hands,
thereby putting users needlessly at risk. Even though the report
turned out to be false, there still was a cost to the user community.
 Because the authors chose to create an emergency, Microsoft and
other organizations investigating the Nimda worm had to divert
resources into checking the new report. This cost all of us valuable
time, and hindered our efforts to help users defend their systems
against Nimda.

We established the Microsoft Security Response Center to make it easy
for people to report potential security vulnerabilities to us. We
monitor the securemicrosoft.com email address seven days a week, 365
days a year, and we investigate every report we receive. Sending a
report to the vendor first makes sense, both from the perspective of
protecting users and ensuring that the researcher's name is only
associated with valid, reproducible reports.

Regards,

Scott Culp
Microsoft Security Response Center
Microsoft Corporation

-----Original Message-----
From: ALife // BERG [mailto:buginfoinbox.ru]
Sent: Wednesday, September 19, 2001 3:38 AM
To: Bugtraqsecurityfocus.com
Subject: New vulnerability in IIS4.0/5.0

-----[ Bright Eyes Research Group | Advisory # be00001e
]-----------------

             Remote users can execute any command on several
               IIS 4.0 and 5.0 systems by using UTF codes

-------------------------------------[ security.instock.ru
]--------------

Topic: Remote users can execute any command on several
                    IIS 4.0 and 5.0 systems by using UTF codes

Announced: 2001-09-19
Credits: ALife
Affects: Microsoft IIS 4.0/5.0

----------------------------------------------------------------------

----
---[ Description
     For  example, target has a virtual executable directory (e.g.
"scripts") that is located on the same driver of Windows system.
Submit request like this:
http://target/scripts/..%u005c..%u005cwinnt/system32/cmd.exe?/c+dir+c:
\
Directory list of C:\ will be revealed.
Of course, same effect can be achieved by this kind of  processing to
 '/'  and  '.'. For  example:  "..%u002f", ".%u002e/", "..%u00255c",
"..%u0025%u005c" ...
Note: Attacker can run commands of IUSR_machinename account privilege
      only.
     This is where things go wrong in IIS 4.0 and 5.0, IIS  first
scans the given url for ../  and  ..\ and  for  the normal unicode
of  these strings, if those  are  found, the  string  is  rejected,
if these  are not found, the string will be decoded and interpreted.
Since the filter does NOT check  for the huge amount of overlong
unicode representations of ../ and ..\ the filter is bypassed and the
 directory  traversalling routine is invoked.
---[ Workarounds
     1. Delete the  executable virtual directory like /scripts etc.
     2. If executable  virtual directory is  needed, we suggest  you
to
        assign a separate local driver for it.
     3. Move all command-line utilities to another directory that
could
        be used  by an  attacker, and  forbid GUEST  group access
those
        utilities.
---[ Vendor Status
     2001.09.19  We informed Microsoft of this vulnerability.
---[ Additional Information
 [1] RFC 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode.
     RFC 2152
 [2] RFC 2044 UTF-8, a transformation format of Unicode and ISO
10646.
     RFC 2279
 [3] RFC 2253 Lightweight Directory Access Protocol (v3): UTF-8
String
              Representation of Distinguished Names.
---[ DISCLAIMS
THE INFORMATION PROVIDED IS RELEASED BY BRIGHT EYES RESEARCH GROUP
(BERG) "AS IS" WITHOUT  WARRANTY  OF ANY KIND. BERG  DISCLAIMS  ALL
WARRANTIES, EITHER EXPRESS OR IMPLIED, EXCEPT FOR  THE WARRANTIES OF
MERCHANTABILITY. IN NO EVENTSHALL BERG BE LIABLE  FOR  ANY  DAMAGES
WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL,
LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF BERG HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. DISTRIBUTION  OR
REPRODUTION OF THE INFORMATION IS PROVIDED THAT THE ADVISORY IS NOT
MODIFIED IN ANY WAY.
-------------------------------------[ security.instock.ru
]-------------- -----[ Bright Eyes Research Group | Advisory #
be00001e ]-----------------
 << File: be00001e.txt >>
*** END PGP VERIFIED MESSAGE ***
_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net
_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]