RE: Six Step IE Remote Compromise Cache Attack

From: Drew Copley (dcopley_at_eeye.com)
Date: 11/06/03

  • Next message: Mandrake Linux Security Team: "MDKSA-2003:104 - Updated CUPS packages fix denial of service vulnerability"
    Date: Wed, 5 Nov 2003 16:32:54 -0800
    To: "Benjamin Franz" <snowhare@nihongo.org>, "Thor Larholm" <thor@pivx.com>
    
    

    > -----Original Message-----
    > From: Benjamin Franz [mailto:snowhare@nihongo.org]
    > Sent: Wednesday, November 05, 2003 2:50 PM
    > To: Thor Larholm
    > Cc: Liu Die Yu; bugtraq@securityfocus.com
    > Subject: RE: Six Step IE Remote Compromise Cache Attack
    >
    >
    > On Wed, 5 Nov 2003, Thor Larholm wrote:
    >
    > > This post raises an interesting question. Is our goal to find new
    > > vulnerabilities and attack vectors to help secure users and
    > critical
    > > infrastructures, or is our goal to ease exploitation of existing
    > > vulnerabilities?
    > >
    > > There are no new vulnerabilities or techniques highlighted in this
    > > attack (which is what it is), just a combination of several already
    > > known vulnerabilities. This is not a proof-of-concept designed to
    > > highlight how a particular vulnerability works, but an exploit
    > > designed specifically to compromise your machine. All a malicious
    > > viruswriter has to do is exchange the EXE file.
    > >
    > > Believe me, I am all in for full disclosure and detailing
    > every aspect
    > > of a vulnerability to prevent future occurances of similar threats,
    > > but I don't particularly think that we should actively be trying to
    > > help malicious persons.
    >
    > I have mixed emotions about this. On one side - why put
    > millions of systems at risk to script kiddies? On the other
    > side, as noted by the poster, one of these vulnerabilities
    > has been known for more than _TWO YEARS_. Surely far more
    > than enough time for MS to have actually _fixed_ the problem
    > if they intended to. MS seems (at least in some cases) to
    > ignore security problems until someone publically 'holds
    > their feet to the fire' over them. I suspect this happens
    > when the problem 'runs deep' in their code and will require
    > more than fixing a boundary limit check and recompiling.

    Very well said.

    I would note that I believe their strategy for securing code wants to be
    inline with their strategy for pushing their products. The company is
    full of strategies, and this is good. But, the primary stategy needs to
    be to "put security first". Especially, post 9/11.

    A few others things...

    As with all security issues, the researcher is not bound to tell anyone
    about them. Liu Die Yu could have just shared this with his friends, and
    we all could have kept these to do as we will. Kind of like keeping your
    own personal nuclear weapon. Who knows? Maybe there will be a rainy day.

    My question then, to everybody, is "would you have preferred that he
    keep this to himself and his friends, or would you have preferred for
    him to have disclosed this, with a workaround?"

    Because Liu Die Yu has worked with Microsoft (China) in the past, and he
    has, unfortunately, found that he can not trust them. Maybe he talked to
    the wrong person. Who knows? But, we can all see plainly that Microsoft
    was without excuse to ignore these problems all of these years. What was
    the thinking behind that?

    Was somebody's job saved so this could happen? Was somebody able to make
    a more successful career move because of this? Are researhers like Liu
    Die Yu too intimidating to deal with, too challenging, too successful?

    What would have happened if someone else put these flaws together and
    discovered they could make them work? What would have been the case in
    that situation? Why did Microsoft ignore the advice of all these
    researchers and not do something about these issues? Why did they think
    they could go it alone in this way? The advice was free for them.

    They had almost two years to fix this, should Liu Die Yu even
    conceivably be forced to wait another three to six months from a company
    that has shown him bad dealings in the past?

    This is using the system at its' best. It is an example of the best kind
    of system. There is no bureaucracy, there is no limitation, no glass
    ceilings, no prejudice... Anyone who is capable, come, find bugs.

    Microsoft is putting out millions of dollars in bounties for worm
    writers while people like Liu Die Yu are just trying to get into the
    security field, so they can do what they are best at. What they love to
    do. It isn't like he is incapable of doing this. He has found swarms of
    bugs since starting to look for them.

    Bounties work. We know they do. But, let's close the gap. Let's make
    sure that tomorrow's bugs are not found outside of the Full Disclosure
    community. Why would anybody be making these kinds of shortcuts? What
    good is AV or Firewalls or anything if your OS let's the attacker
    through?

    We worry about script kiddies trying to figure out what Liu Die Yu did
    here to make their own version? We should be worrying about rogue
    nations and criminal organizations creating teams of bug finders so they
    can penetrate any system they want to.

    The computers themselves are worthless, compared to human lives, but the
    information within them are invaluable. Blueprints. Military strategies.
    Political strategies. Security strategies. Governmental secrets.
    Corporate secrets. Identities. Weaknesses.

    I have to wonder when people when begin to figure out that security bugs
    mean... security holes mean: keys to the application, and generally,
    keys to the system. We can ponder all we want about the NSA having a
    backdoor, or merely Microsoft having a backdoor... But anytime someone
    finds a security hole like this, they have a backdoor.
     
    If you want, ask the researcher to please alert the vendor. Be rude
    about it, whatever. But, understand that if they were bad or interested
    in doing evil... They would not report it to the world. They would use
    it.

    Lastly, just to be fair. Most researchers that find bugs in Microsoft's
    products do so at least partly because everyone uses their software.
    Microsoft actually has a code auditing team, they actually have made
    moves towards securing their software. Most companies have not done
    this. Their code is not even looked at. If the case were anything
    different, Liu Die Yu would just put his resume on monster or dice, and
    he wouldn't be speaking to us right now. He would be working in the
    field he loves.

    Drew Copley

    Research Engineer, eEye Digital Security

    Fun quote for the day:
    "Who knows what evil lurks in the hearts of men? The Shadown knows!"

    >
    > --
    > Benjamin Franz
    >
    > Gauss's law is always true, but it is not always useful.
    > -- David J. Griffiths, "Introduction to Electrodynamics"
    >
    >
    >


  • Next message: Mandrake Linux Security Team: "MDKSA-2003:104 - Updated CUPS packages fix denial of service vulnerability"

    Relevant Pages

    • Re: Six Step IE Remote Compromise Cache Attack
      ... bounties for bugs and repairing of product I have been duped into ... Microsoft Internet Explorer v6.Sp1; up-to-date on 2003/10/30 ... Liu Die Yu's file-protocol proxy bug to reach MYCOMPUTER zone ... I would like to work professionally as a security researcher/bug ...
      (NT-Bugtraq)
    • Re: Vulnerability Auditing Checklist
      ... CAN-yyyy-nnnn) for specific vulnerabilities that demonstrate the given ... suite-based testing, and fault injection. ... symlink following bugs are the combination of multiple ... e.g. checking a security option does nothing, ...
      (SecProg)
    • Re: RFC: Starting a stable kernel series off the 2.6 kernel
      ... >> You mentioned security issues in your initial post. ... > I've fixed bugs which turned out to be security vulnerabilities. ... > pose is normally /much/ harder than to fix the bugs. ...
      (Linux-Kernel)
    • Re: DEFCON 16 and Hacking OpenVMS
      ... credible because you spoke "chinese" with terms that are foreign to VMS.. ... it is a common used description in SECURITY ... vulnerabilities and write PoC code to proof that the vulnerabilities ... we can't fix bugs that are found ...
      (comp.os.vms)
    • Re: Thou shalt have no other gods before the ANSI C standard
      ... The key point being that most security ... >> vulnerabilities are just another kind of bug, and bugs can be prevented. ... in both removing them and mitigating their effects. ...
      (sci.crypt)