Misinformation in Security Advisories (ASN.1)

From: John Compton (john_compton24_at_yahoo.com)
Date: 02/16/04

  • Next message: Buck Huppmann: "Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption" 
    Date: Mon, 16 Feb 2004 09:47:28 -0800 (PST)
To: bugtraq@securityfocus.com

    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.
     
    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. 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.
     
    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.
     
    I work for a start-up security-intelligence vendor,
    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. Why wouldn't they believe us?
     
    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.
     
    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.
     
    Sometimes misinformation in security advisories is
    unintentional, however in this case it appears to be
    intentionally misleading and I think it's time that
    someone spoke openly about it. 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.
    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.
     
    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.
     
    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.
     
    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.
     
    Regards,
    John
     
    Supporting technical information about ASN.1
    vulnerability:
     
    The ASN.1 vulnerabilities discovered by Eeye (there
    were several very similar ones) resulted in a memcpy
    of 4GB less a few bytes (0xFFFFFFFX) bytes to the
    process heap. This will quickly corrupt the entire
    heap and hit a guard page or unpaged address and cause
    an unhandled exception. When this unhandled exception
    occurs, application and then OS exception handlers
    will be called in order to attempt to deal with the
    protection fault.
     
    These exception handlers, in virtually every Microsoft
    application, do NOT use the heap since it is not
    guaranteed to be in a consistent state. This rules out
    the possibility of simply causing an exception and
    having the exception handlers traverse the heap and
    cause an arbitrary memory overwrite leading to code
    execution.
     
    Another possibility for remote code execution would be
    to trigger a context-switch mid-memcpy which would
    halt the memory copy operation before it hits an
    unpaged address. This, if possible, might leave the
    heap in a corrupted state but allow another thread to
    access/traverse the heap before the exception occurs.
    However, Microsoft compilers optimize the memcpy()
    function call to the REPNE MOVSD instruction. This
    makes it extremely unlikely, if not statistically
    impossible, to get a context switch at the right time
    before an unpaged address is accessed. Once again,
    this cannot be used to exploit this bug.
     
    Another possibility is vectored exception handling,
    which stores pointers to exception handlers on the
    process heap. If these exception handlers existed, it
    would be very viable to corrupt them and have them
    called when the exception occurred (ala SEH on the
    stack). However, vectored exception handling was only
    introduced in Windows XP, and no Microsoft
    applications use them by default.
     
    The final, and equally unlikely possibility, is that
    an exception occurs but before the exception handler
    is called another thread accesses the heap. However,
    the system exception handlers are given higher thread
    priorities in order to quickly handle a condition that
    requires immediate attention. As such, the application
    will always exit before another thread has a chance to
    access the corrupted heap.
     
    The result, quite honestly, is a non-exploitable
    condition. This issue is limited in scope to a denial
    of service vulnerability.

    (thanks to a friend for this info)

    __________________________________
    Do you Yahoo!?
    Yahoo! Finance: Get your refund fast by filing online.
    http://taxes.yahoo.com/filing.html

  • Next message: Buck Huppmann: "Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption"

    Relevant Pages

    • Re: friendly error messages for usernameForCertificateSecurity
      ... You are receiving that security error because WSE could not validate the ... The WSE core is who creates that exception, and it does not provide a way ... a.You can maybe use a WSE router between the client and the service, ...
      (microsoft.public.dotnet.framework.webservices.enhancements)
    • [NT] PNG (Portable Network Graphics) Deflate Heap Corruption Vulnerability (Windows)
      ... Beyond Security would like to welcome Tiscali World Online ... exception filter, overwriting the pointer to the handler with the address ... is set to the address of the unhandled exception filter hook. ...
      (Securiteam)
    • Re: Security.Exception
      ... Here is the stack info: ... asm, PermissionSet granted, PermissionSet refused, RuntimeMethodHandle rmh, ... (A far more obscure exception is ... >> allowed by the security policy. ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: [Full-Disclosure] Misinformation in Security Advisories (ASN.1)
      ... Most of the security researchers ... I think YOUR misinformation appears to be unintentional, however it may very well be "intentionally misleading". ... > industry, and it's not my intention to directly attack Eeye, however they have done ... yet many of them chose to ignore our advice and agree with the industry> consensus of exploitability. ...
      (Full-Disclosure)
    • Re: Odd StrongNameIdentityPermission failure during an NUnit run
      ... This exception should have nothing to do with NTFS security. ... you should probably contact the NUnit development team. ... > more security permission fails. ...
      (microsoft.public.dotnet.security)