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: <Pine.GSO.4.43.0307021650470.1694-100000@tundra.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: Microsoft Cries Wolf ( again )

I owe you an appology in making my last posting on this topic and in
response to your posting here, seem to be a point of taking potshots at
you, and that was really not my intent.  For your narrow focus upon this
issue is no more tunneled and short of sight, or myopic then those that
merely  decalre information should be free and vulns are no different and
so they  should be shared as fully and freely as possible.  This topic
dates many  of us, and has perspectives that some have hit upon and others
have not.  It's been tugged to and fro for a few decades now, and I doubt
a few more decades of further discussion will resolve it.  If the likes
of Eugene Spafford, Brent Chapman and others could not come to a firm
conclusion on this issue, I'm doubting we'll resolve it here in any time
soon.  As I mentioned there are a number of perspectives on this issue
other then the one you and others have proposed in this area.  Mine lay
with those that feel that the basis of responsibility lies with the
vendors, and the larger the vendor, the more impact they have in forcing
change by setting a precedent not only in mouthing a commitment to
releasing software and OS's with secure code and default settings, but, in
how they deal with the whole issue of resarchers and their bug findings in
the vendors products.  Alot of the comments to this thread and those in
the past show many are frustrated with the stances many vendors have
taken, not only recently, but, historically, in this regard.  Especially
when it;s been shown that the vendors gain quite a bit from the free Q&A
these researchers are actually providing them.


Additionally my posting was certainly not trying to be narrow and also
focus upon one major vendor, no matter the fact that their history is
shorter with the industry then many other vendors that produce OS's, and
surely more deeply rooted with problems and issues in that shorter
history. But, being the giant they are, and with the voice they have to
the computing public, one would like to see them step forward and take the
issues of problems with their products and code beyond their competitors
and turn the whole area of vendors/researcher/disclosure into something
other then a battle and maze of confusion frustration, and repeated
problem scenarios that it presently is.  My impression is that until the
vendors stepup up to the plate with a better commitment to responsible
reselase of products, they will find that the research community continues
to eye them with focused suspicion and outrght cynical spite.  Some share
that perspective, some have a different focus of it, some reject it as
invalid, but, the circle jerk of argument we are rehashing here will
continue as long as the status quo remains what it presently is.

Thanks,

Ron DuFresne


> >> However, a security vulnerability is not, in itself, harmful.  What *is*
> >> harmful about a security vulnerability are individuals who wish to
> >>exploit the flaw.  Therefore, the harm from a vulnerability increases
> >>dramatically if more people with the ability to exploit the vulnerability
> >>are aware of it.  This includes exploiting the flaw through pre-written
> >>exploit code of some kind.  This harm is especially great if
> >>administrators are exposed without a known-good workaround.  Therefore,
> >>vendor communication is the *preferred* method of dealing with security
> >>flaws, at least in the short term.  However, if it becomes obvious that
>  >>the vendor does not wish to resolve the vulnerability at hand, it should
> >>be disclosed.  However, workarounds should be available so that the added
>  >>information actually has the ability to help the administrator.
>
> >Nice tunnel vision, one sided interpretations often tend bolster humor at
> >least.
> [SNIP]
> >The spread of information not only supplies all the lamesters wishing to
> >exploit and ow3n what's not theirs, but, also feeds information to those
> >tasked to fend off those with less then bright lights and wanting what's
> >not theirs.  Now, feeding that info to a vendors might not get the info
> >out to the masses of their clients, cause, damn, why would they want to
> >risk losing customers over an issue?  They sure do not need to be
> >harrassed with tons of e-mails from various clients about when a fix might
> >come down the pipes, and certainly have no time to talk to any press on
> >the matter while doing some tongue and cheek about "secure computing
> >innitiatives".
>
> Obviously, you don't understand the secure computing initiative.  Secure
> computing has resulted in the discovery of some severe vulnerabilities,
> which the public was warned about.  I'm also guessing you haven't heard of
> the security bulletin notification service?  While it could be tweaked not
> to require a passport, it provides a simple process for notifying
> administrators of security issues.
>
> As for the criticism on Microsoft's blasting researchers who poorly handle
> security vulnerabilities, most of it is not valid.  People who disclose
> vulnerabilities to the public the same day they notify the vendor?  I'm not
> saying we should all become mindless slaves to vendors and let them take
> whatever time they please, but I will say that it is usually wrong to
> assume that a vendor will be unresponsive.
>
> >Certainly the founding issues that brought about the
> >'original' bugtraq and many of the newer lists like this very one, are
> >promoted by vendors that tend to hide and sit upon information about
> >weaknesses in their products.  They tend to cry "foul" alot, and then
> >often tend to follow through not with work to fix their products, but with
> >threats and lawsuits, right snosoft?  Folks forget too quickly the minor
> >fallout they had with HP...
>
> I don't know about HP, as I've never worked with HP.  But, in any case,
> you're accusing me of "tunnel vision" and "blindness", but you cite one
> vendor's poor security response as a reason why all vendor security
> responses therefore suck.  You've obviously not worked with MSRC, so let me
> provide some balance for *YOUR* tunnel vision, Mr. Dufresne.  Security at
> Microsoft is a priority, both in terms of dealing with vulnerabilities, and
> promoting generally secure programming practices.  However, fixing a
> security flaw is a lengthy process -- just as any other fix.  My previous
> e-mail clearly pointed that out, and instead of responding to it with
> logical statements, you simply accused me of having "tunnel vision".  Who
> is really the one going blind here?
>
> Secondly, Microsoft is more than right in the majority of cases to point
> out that immediate disclosure of security vulnerabilities without prior
> contact *ATTEMPTS* is ridiculous.
>
> >> While there is some argument about what makes a vendor un-responsive,
>  >>patch times in this case are, likely and understandably, quite lengthy.
> >
> >Now we add over generalising to tunnel vision.  It depends upon the issue
> >at hand, often the whole fix might be nothing more then removing the suid
> >bits, or something else as trivial...
>
> How ridiculous is that?  For one, Windows doesn't even have the concept of
> suid bits, and although I know your example was a general one, perhaps it
> would be appropriate to at least provide one with some context. ;-)
>
> Once again, you completely missed my point.  Even if a patch is simply to
> remove an ACL entry, or something as simple as this, the very bulletin
> advising people to change the entry needs to be translated into dozens of
> languages.  And, as much as they try, Babelfish is still not acceptable to
> translate business materials.  This takes time.
>
> >> These fixes are not trivial to begin with, thanks in no small part to the
> >> incredible number of customers Microsoft has.
> >
> >So, now we are at a pass in a trail, but, since we've gone about nearly
> >blind, why open our eyes at this point!?
> >
> >Had security been a prime motivator  in the early M$ days, they might not
> >be so hindered now by zillions of lines of insecure code!
>
> Perhaps you would consider that security is rarely a motivator in any
> company, except ones that produce so-called security solutions, where
> security breaches are usually emphatically denied for as long as possible.
> As the X-Force Internet Watch defacement, various security holes in ISS
> main site (very nicely pointed out by Sir Mordred on this very list a
> matter of weeks ago), and a buffer overflow vulnerability in Symantec's
> Online Scanner show -- all within a matter of weeks -- nobody is perfect.
>
> Security takes time -- when you learn a language, you are not immediately
> educated in its weaknesses.  Sure, a good tutor will tell you things like
> "avoid strcpy()", "watch %s formats", "always validate input", "allow
> known-good input only", etc., but it is ultimately up to the programmer to
> learn to code securely.  Also, even the best programmers make security
> mistakes.  You will not find one person here with the experience of an
> average Microsoft developer who can honestly say they've not made one
> security-relevant mistake.
>
> >> As if the literally millions of configurations Microsoft software must
> >>support weren't enough, think for a second about the multiple different
> >>character sets its code applies to.  Even the *DOCUMENTATION* for the
> >>patch must be translated into dozens of different languages -- no small
> >>task with exploitation looming on the horizon.  However, it is obvious
> >>that in this case, the reporter did not attempt any contact with
> >>Microsoft what-so-ever.  As a user of IE myself, I find it ridiculous
> >>that this course of action was even considered.
> >
> >And the users that refuse at any cost to have to work with IE in any way
> >shape or form, they chuckle each time those that "remain loyal" spew
> >private information to the  unintended eachtime the product is
> >re-exploited, which seems to be about once every 2-4 weeks.
>
> And, of course, none of IE's competitors have ever suffered
> vulnerabilities.  Or, at least, they won't publicly admit to it.  Nearly
> all of IE's major competitors have no established process to contact
> clients when vulnerabilities are found.  I personally receive notifications
> about IE patches in my own mailbox.
>
> However, as you rightly pointed out, most researchers who find IE flaws
> announce them before patch development is complete.  So, how is it that I
> manage to survive with nearly no patches since IE 6.0 SP1 was released?
> The reason I'm able to avoid exploitation is because I employ an incredible
> security tool known as common sense.  I thouroughly inspect the credentials
> of all objects I'm asked to download, and usually tend to avoid sites where
> I know that malicious content is likely.
>
> Further, the newest version of IE 6.0 for Windows Server locks down IE's
> security settings much tighter than previous versions in an attempt to
> prevent vulnerabilities from being exploited.
>
> >>And, last but not least, I don't drink. :-)
> >
> >You might want to take it up <smile>, viewing from another perspective
> >might add some clarity...
>
> What other perspective is there, Mr. Dufresne?  See, we live in an
> imperfect world -- people make mistakes...
>
> >> Might I suggest that someone who would share details with people
> >>interested in exploiting the flaw, before people that flaw might affect,
> >>truly *IS* irresponsible?  With that in mind, it doesn't seem like
> >>Microsoft would be wrong at all to call someone who would consider such a
> >>course of action irresponsible.  In fact, this is probably exactly what
> >>the reporter was hoping for -- not caring about the established
> >>disclosure process, seeking instead to increase his/her own standing by
> >>antagonizing a major company, at the expense of its millions of
> >>customers.  While I cannot speak for the philosophies of other
> >>researchers, it is my firm belief that a policy which exposes millions of
> >>systems to exploitation without providing feasible alternatives for any
> >>of them is not only irresponsible, it is negligent.
> >
> >The debate will rage on for many more years.  But allowing M$ and various
> >other vendors to cry foul when information about their lack of pride and
> >responsibility to produce something other then mere crap for big bucks to
> >their clients puts them on par with the spammers and lamers their code
> >tends to foster.
>
> And you're still standing by your statement that *I* have tunnel vision?
> I'm laughing.  Well, when you run a major company serving millions of
> different customers from all over the globe, and offering hundreds of
> products, and your security staff is paid to simply sit on their asses (as
> your code would, of course, be perfect), you can then criticize others.
>
> The truth is that while lengthy, Microsoft has the best security response
> of major commercial software developers.  And, for all of their
> vulnerabilities, Microsoft's products have outsold competitors on their
> quality.  Until recently, security was a relative non-issue for most of
> Microsoft's user base -- perhaps this is why so many IE users "reveal
> information to the unintended" so frequently.  How can you blame the
> company for putting security on the back burner when the vast majority of
> its client base did the same?  One only needs to see another SMTP mass
> mailer (in spite of the virus filter that now ships standard with
> Microsoft's mail clients), to prove that a system is only as secure as its
> administrator.
>
> For the number of products it offers, and the large feature sets typically
> seen in each, the relative vulnerability of Microsoft's code is only
> increased compared to others when Microsoft's products make it too easy to
> be stupid.  This has been a very valid criticism, but regardless of your
> willingness to admit this, this is slowly but surely being corrected.  When
> you have as large of a product base as Microsoft does, major changes to the
> design profile of that software take time.
>
> >Seems to take far less lines of code to create and foster an exploit upon
> >the computing public then the number of it takes lawyers/politicians to
> >screw lightbulbs.
>
> And you, I assume, are very familiar with the legal team at Microsoft, and
> of course, know the source tree of every product they've produced inside
> out.  It is unproven criticisms such as this that make my point so well --
> Microsoft is targeted for senseless criticisms such as these because of its
> position in the industry.
>
> And, while IE may have vulnerabilities, those can be effectively
> neutralized with good browsing habits.  The startup time on that slow,
> klunky piece of shit called Mozilla, or the nightmare of a CSS/JavaScript
> engine in Opera?  Well, that's another story, because in Mozilla's case,
> fixing that horrible startup time is a matter of re-writing the browser,
> and Opera, well, I can't even do that.
>
> With IE, it's a matter of either avoiding suspect sites, adding the ones I
> need to my "Trusted Sites" list (which, if you're lazy, does require an
> extra 5 clicks or so), or setting a few option buttons to "Disable".
> Really tough to avoid all those exploits in this "mere crap" that MS has
> produced -- mere crap that easily out-performs its competition, and is far
> easier to use than those competitors.  Sorry to say, but if IE is mere
> crap, I could read you the entire list about the other options... but that
> would be dropped by all the corporate profanity filters, so I won't.
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ