lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3a166c090603251912g572f7306mccd30eeb71eedd7e@mail.gmail.com>
Date: Sun Mar 26 04:13:20 2006
From: n3td3v at gmail.com (n3td3v)
Subject: Industry calls on Microsoft to scrap
	PatchTuesday for Critical flaws

The n3td3v group is part of world wide rogue employees already. While you
may not think its cool to rush a patch incase its faulty, lets look at the
alternatives. We can have a world where hackers are expoiting your
vulnerabilities by hacking systems, or you can have hackers which and
devloping patches before MS, and causing more havoc. If you release a third
party patch it causes the consumer to become confused. Sould the consumer
trust X third party and all its phishing, or should MS release its patch
before the third parties? As soon as MS allow enough time for third parties
to develop a patch, is as soon as the scope for malicious phishing
activities begin. So no matter how many times you go on about "disclosure to
patch cycle", the main point here is "disclosure until rogue patches and
malicious activites take over. Its easy to post something about MS need to
test a patch before its disturbuted, but thats crap. If third party
programmers are able to release patches which do the job, and Microsoft are
still left standing, then surely that means MShas lost the fight?


On 3/26/06, William Lefkovics <william@...kovics.net> wrote:

> Indeed.  You don't want to release a bad patch (who does?) and you also
> want
> to work on critical issues in an ASAP manner, not tied to any schedule
> like
> 7 to 14 days.
>
> "The worst scenario for us is that we release an update which has quality
> problems. We believe the downstream problems of releasing patches too
> quickly are even more serious than not putting in the quality that they
> deserve." - Ben English, Security Leader, Microsoft Australia
>
> Furthermore, Microsoft has an exception policy in place for addressing
> vulnerabilities with greater customer risk.
>
> "Microsoft will make an exception to the above release schedule if we
> determine that customers are at immediate risk from viruses, worms,
> attacks
> or other malicious activities. In such a situation Microsoft may release
> security patches as soon as possible to help protect customers."
> http://www.microsoft.com/technet/security/bulletin/revsbwp.mspx
>
>
>
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of
> Valdis.Kletnieks@...edu
> Sent: Saturday, March 25, 2006 6:23 PM
> To: n3td3v
> Cc: full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] Industry calls on Microsoft to scrap
> PatchTuesday for Critical flaws
>
> On Sat, 25 Mar 2006 22:12:23 GMT, n3td3v said:
>
> > You Microsoft must officially agree that all flaws marked as
> > "Critical" must have a patch within 7 to 14 days of public disclosure.
>
> OK... Nice try.
>
> Too bad you didn't add a requirement that the patch actually be *correct*.
>
> Also, you're totally overlooking the fact that *sometimes*, fixing a
> problem
> requires some major re-architecting - for instance, if an API has to be
> changed, then *every* caller has to be updated, and quite possibly
> re-designed, and the changes have an annoying tendency to ripple outward
> (if
> subroutine A has a 7th parameter added, then everybody who calls A has to
> be
> updated.  And it's likely that you'll find routines B, C, and D that have
> no
> *idea* what the correct value of the parameter should be, because they
> don't
> have access to the data - so now callers of B, C, and D have to pass
> another
> parameter that gets passed to A).
>
> Any company that will commit to a "must" on this one is nuts.  It's a good
> target, but making it mandatory is just asking companies to ship a
> half-baked patch that seems to fix the PoC rather than the underlying
> design
> flaw.
>
> And going back and reviewing the patch history on IE is instructive - more
> than once, Microsoft has released a patch for a known Javascript flaw,
> only
> to find out within a week that a very slight change would make the exploit
> work again.
>
> Is that *really* what you want?  It's certainly not what *I*
> want.  Waiting
> another 3-4 days past your arbitrary 14-day limit for a *good* patch is
> certainly preferable for those of us who actually have to deal with this
> stuff for a living, rather than hide out on a Yahoo group.
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060326/a126ecb9/attachment-0001.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ