Message-ID: <023001c3f4c1$27edb0a0$8e16a8c0@Constant>
From: jeremiah at nur.net (Jeremiah Cornelius)
Subject: Misinformation in Security Advisories (ASN.1)

Who is "John Compton"?  He speaks pretty authoritatively for someone with no list history on Bugtraq or  full-disclosure.  There is a "john compton" who posted from a different webmail address in 2002 - with questions about an ssh2 exploit in RedHat.  Other than that, no questions or commentary searchable on SecurityFocus, Neohapsis, Netsys or even Google.

> It seems that misinformation is included in security advisories far too often, 
> and for many different reasons. I'd like to point out a
> couple examples, and promote discussion as to how this misinformation affects the 
> security community and the non-experts who rely on this
> information to be valid.

There is possibly misinformation in security advisories.  Does Microsoft break its patch schedule based on misinformation?  Do they waste six months NOT verifying these findings, before releasing a patch?  Do they label such a patch CRITICAL, based on unverified assertions?  The theme of unverified assertion is important - as it seems to be the thread of continuity binding your argument together.

> First of all, there is good news for those of you out there who are worried about the
> new ASN.1 vulnerability in Microsoft operating systems. It is NOT exploitable to run 
> arbitrary code in anything approaching a real-world scenario. 
> You are likely not going to see any more than the DoS exploit that has already come 
> out. 
  
On what evidence do you base this assertion?   Have you reproduced the conditions eEye established, and verified this with the eEye POC code?  In the absence of scientific validation/repudiation methodology, the larger security community relies on reputation.  Mr. Maifrett has established his.  "John Compton", and his unnamed security start-up have not.

> For those of you interested in the technical explanation of why, it is included below 
> (it's honestly beyond my complete understanding). Most of the security researchers 
> I've spoken to agree with this assessment and the information below.

Who have you spoken to?  Are they under NDA?  Are you? Was this written inside MS, to cover a dev teams ass?  It SOUNDS authoritative.  It is also - in the context of your message - unverified assertion, unaccompanied by well-known reputation.

>  However, this impact of this misinformation is that many corporations out there spent 
> tens of thousands of dollars (or more) in resources and manpower last week to get this 
> issue fixed enterprise-wide.

Why? Because they were not enabled with an enterprise patch-management strategy?  Because they were unable to assess the different degree of risk in different systems regarding exposure and sensitivity of content?  If they don't have these acts together - God help 'em!  They are stuck with an unmanageable situation, that is itself a critical operations vulnerability.  Good operations and management could result in patching high risk/exposure hosts reactively, and a timely, scheduled remediation for the remainder of the organization. 

>  I work for a start-up security-intelligence vendor, 

Me too. I'm not posting on their behalf, so I'm not naming names in this post.  You are using your vendor status to give the appearance of concern and establish a sense of credibility.  Without disclosing this, you try and impeach the credibility of eEye?

> and we warned our customers that this bug was only exploitable as a denial of service, 
> yet many of them were not willing to take the risk that the next Blaster might appear 
> over the weekend, despite our in-depth explanation of why this bug is not exploitable. 

Let me see if I get this straight...  You are a security vendor - who has not scientifically repudiated the claims of an established researcher - and you are DISCOURAGING your clients from action that could limit their risk in the face of an issue that Microsoft labeled "CRITICAL" after six months of familiarity?  

> Why wouldn't they believe us?

"Once bitten, twice shy".  

>  http://archives.neohapsis.com/archives/bugtraq/2004-02/0293.html
>
> In that post to Bugtraq, dated February 10th, Mr. Maiffret claims that Eeye has
> developed a functional exploit that they used to compromise an IPSec-protected 
> network. Setting aside his claims of "Client side, server side, world wide", he goes 
> on to claim that users are all affected and that they shouldn't even think twice but 
> simply install the patch.
>
> For some of our clients, installing the patch means deploying it enterprise-wide 
> across tens of thousands of machines. It means deploying it in test environments 
> before rolling it out on production servers. It doesn't mean just clicking on 
> "Windowsupdate.microsoft.com" or that icon in the system tray. 

We know what this means.  See the above response about management and operations frameworks for risk management.

> I think that Mr. Maiffret's inaccurate statements are costly to others. If large 
> enterprises knew that this bug could only be exploited as a denial of service 
> condition, their approach would be considerably different, and their associated costs
> significantly lower.

Again, you think that the operational costs in establishing good risk-management exceed the risk of loss in a compromise?  This goes beyond the issues of a single incident/vulnerability.  Ultimately - even if 20% of alerts are "duds" - the ability to respond is crucial.  If you are not assisting your enterprise customers in achieving response-ability (responsibility), at least do not hinder them with poor advice.

> Sometimes misinformation in security advisories is unintentional, however in this case 
> it appears to be intentionally misleading 

Let's call a spade a spade.  I think YOUR misinformation appears to be unintentional, however it may very well be "intentionally misleading".

> and I think it's time that someone spoke 
> openly about it. 

Another give-away statement that may betray disingenuity on your part.  "Someone" speaks openly about this issue all the time.  It is an obsessive fodder for rumination and debate on full-disclosure, and a lesser extent on BugTraq.  It is the "meta-topic" of the decade.  

"What the heck is full-disclosure?  Responsible disclosure?  What is FUD? What is appropriate response to risk?  How is risk assessed, defined and validated?  What is the role of investigative research? Is the inclusion of vendor-interest benign or coercive?

You may simply uninformed, and not setting up a "straw-man".  If so I apologize - but your posting is frankly, non-creditable.

> I'm trying to promote discussion about misinformation in our 
> industry, and it's not my intention to directly attack Eeye, however they have done 
> this in the past.
 
"When DID you stop beating your wife?"
  
> A less blatant example of misinformation in a security advisory, yet one reminiscent 
> of ASN.1, would be:
>
>  http://archives.neohapsis.com/archives/bugtraq/2003-03/0282.html
>
> This bug, as some of you may remember, affected the SunRPC xdr data translation, and 
> could be considered a serious risk to some networks if it allowed remote code 
> execution. Eeye certainly seemed to think that it was:
>
>  "Severity: 
>  High (Remote Code Execution/Denial of Service) "
>
> When Sinan Eren questioned the exploitability of this issue, there was no response 
> from Eeye:
>
>  http://archives.neohapsis.com/archives/bugtraq/2003-03/0288.html
>
> However, there was still a Cert advisory, and multiple vendor-released advisories,
> which all stated that this issue might be used to execute arbitrary code. Again, we 
> told our customers about the limited exposure they faced from this issue back in March 
> of last year, yet many of them chose to ignore our advice and agree with the industry > consensus of exploitability.

Ahh.  At last, a name we know.  Sinan disagreed with a number of vendors, based on his knowledge.  That knowledge is extensive - he engineers the Entercept HIPS.  So he DOES disagree, and IS creditable.  But he didn't run the code.  A pity the thread dies with his message.  Such a disagreement is hardly "deliberate misinformation".  CERT doesn't issue warnings based on my friggin' mail threads.  I hope they don't retract 'em on yours!

> For a company that does so much quality vulnerability research and employs many 
> talented people, it's very disappointing to see what honestly can't be characterized 
> as anything but deliberate misinformation. 

You build what you describe as an honest characterization?  This is an /ad-hominem/ attack, badly dressed up as researched investigation.

I HOPE you are not professionally employed to undermine eEye or vulnerability disclosure process.  Your motives are either immature emotional reactions, or deliberately coercive.  In either case - they are sloppy and poorly conceived. 

> I'd like to ask someone from Eeye to respond to these claims, but honestly they're not 
> the only security researchers guilty of this.

Again, with the "honestly" business.  It seems like some magical incantation, periodically invoked to produce an effect not otherwise in evidence.

> I'd be interested to hear opinions from other perspectives, as I do not do security 
> research nor roll out protection for security bugs for a living.

Ferchrissakes! NOW you tell us!  You're a columnist!

>  Regards,
>  John

Likewise,
Jeremiah


<SNIP of 'could be true, who knows the source?' assertion>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3796 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040216/1b38edc0/smime.bin

Powered by blists - more mailing lists