THIS JUST IN: BLOGS A CRAPPY WAY TO HANDLE DISCLOSURE

Thomas Ptacek | April 26th, 2007 | Filed Under: Uncategorized

EXCLUSIVE: MUST CREDIT MATASANO

Numerous confirmed sources reporting to us, at this precise moment, that successive blog posts turn out to be a crappy way to convey the details of important vulnerabilities.

Seriously, folks: this started out fun, because we were dealing with a laboratory-isolated specimen of a problem that Apple was in a position to easily fix. But it turns out, that’s not the case. There are a lot of things we’ve learned in the past couple of days that lead us to believe that the QuickTime hole is going to cause real (read: Mom’s bank account) problems.

The gathering miasma of unpleasant details about this vulnerability includes:

  • … that it affects FireFox as well as Safari

  • … that it affects Windows as well as OSX

  • … that it may or may not be auto-updatable on non-Mac platforms

  • … that it affects IE7

  • … that it may, or may not, be difficult for bad actors to reverse the vulnerability from the details already cleared by 3Com

Thankfully, I think we can put to rest the notion that the exploit is bouncing around in the wild, but that drama alone is reason enough for us to think that posting information to our blog piecemeal isn’t a good idea.

3Com has paid $10,000 for this vulnerability, and controls what details about it can be published. There are things users can and should do today, before patches are released, to mitigate the vulnerability. The entire world knows it exists, and a large body of talented attackers has a head start on where to look for the details. 3Com is in a much better position to fact-check and publish information about this bug than we are. When they provide a URL or a 1-800 number or something to provide up-to-the-minute, fact-checked details about this finding, we’ll post it here.

Thanks for following along. We’ll have more to say about Mac security in upcoming posts, but much less to say about our friend Dino’s QuickTime finding.

11 Comments so far

  • Chris_B

    April 26th, 2007 8:05 pm

    Wonder if this is going to be the one which finally makes it crystal clear to everyone that bug bounties and our whole current disclosure infrastructure is morally corrupt?

    Nonetheless, thanks for the coverage.

  • Chris

    April 26th, 2007 9:21 pm

    Why are they morally corrupt exactly?

  • Robert C.

    April 28th, 2007 10:47 am

    Could Microsoft issue an auto-update that would fix this bug? Either one written by Apple that fixed Quicktime, or one written by M/S that prevented IE from executing the bug? In theory, could they use the normal M/S auto-update?

  • ivan

    April 28th, 2007 6:57 pm

    aha! now everybody knows quicktime has no clothes but only Tippingpoint can publish the nekkid pix!@ at least the pr0n industry has the decency of not pretending that they’re doing it because they are reponsibly helping you improve your sexual health.
    Interestingly enough this quicktime/java thingie is all over the security news and blogs but nobody seem to have picked up the fix for an AUTH_UNIX RPC integer overflow (yes, unauthenticated, remote on every RPC program) that came out on the latest batch of patches from the fruity OS.

  • Thomas Ptacek

    April 28th, 2007 7:47 pm

    On the other hand, how many RPC programs run on the standard install?

    (And how many Xserves are there in the whole world?)

  • mac

    April 30th, 2007 8:49 am

    is it affecting all the versions of the quicktime ?

  • Rolf

    April 30th, 2007 8:47 pm

    I’m surprised it’s taken this long for somebody to find the exploit. If it’s what I suspect it is, it’s probably been around since Mac OS 9 days, and affects all versions of QuickTime since QT 4.

  • Rosyna

    May 1st, 2007 4:25 pm

    It’s ok, Apple just fixed it.

    http://www.apple.com/support/downloads/quicktime716formac.html

    So it was QuickTime for Java

    Available for: Mac OS X v10.3.9, Mac OS X v10.4.9, Windows XP SP2,
    Windows 2000 SP4
    Impact: Visiting a malicious website may lead to arbitrary code
    execution
    Description: An implementation issue exists in QuickTime for Java,
    which may allow reading or writing out of the bounds of the allocated
    heap. By enticing a user to visit a web page containing a
    maliciously-crafted Java applet, an attacker can trigger the issue
    which may lead to arbitrary code execution. This update addresses the
    issue by performing additional bounds checking when creating
    QTPointerRef objects. Credit to Dino Dai Zovi working with
    TippingPoint and the Zero Day Initiative for reporting this issue.

  • Matasano Chargen » Quicktime Patch Available

    May 1st, 2007 5:17 pm

    […] Rosyna of Unsanity reports: It’s ok, Apple just fixed it. […]

  • Tempter of High Calories

    May 2nd, 2007 9:24 am

    So what would be a better way to handle disclosure? A newsgroup threat that announces it, and the 3000 consequent replies that follow it?

    Oh wait, I get it!! The best way to handle disclosure is to sell it to a high-end security company so they can PROPERLY distribute it - for a fee. Right?

  • Thomas Ptacek

    May 2nd, 2007 9:25 am

    http://www.matasano.com/log/mtso/ethics

    You are preaching to the choir.

    • Leave a reply