Results 1 to 9 of 9

Thread: interesting bug ...

  1. #1
    Banned
    Join Date
    Aug 2004
    Posts
    534

    interesting bug ...

    from one of my favorite security mailing lists

    this if for newbs ... click on the link so you can see bug in action



    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    The below email (not from me) is an interesting and weird bug and I
    felt it merited some notice.

    - -dave


    _____________________________________________________________________________

    From: Michael Zalewski - lcamtuf@dione.ids.pl

    Good morning,

    This might not come as a surprise, but there appears to be a *very*
    interesting and apparently very much exploitable overflow in Microsoft
    Internet Explorer (mshtml.dll).

    This vulnerability can be triggered by specifying more than a couple
    thousand script action handlers (such as onLoad, onMouseMove, etc) for
    any
    single HTML tag. Due to a programming error, MSIE will then attempt to
    write memory array out of bounds, at an offset corresponding to the ID
    of
    the script action handler multiplied by 4 (due to 32-bit address
    clipping,
    the result is a small positive integer).

    The list of IDs can be found on the Web, and is as follows (values in
    parentheses = resulting offsets):

    onhelp = 0x8001177d (+0x45df4)
    onclick = 0x80011778 (+0x45de0)
    ondblclick = 0x80011779 (+0x45de4)
    onkeyup = 0x80011776 (+0x45dd8)
    onkeydown = 0x80011775 (+0x45dd4)
    onkeypress = 0x80011777 (+0x45ddc)
    onmouseup = 0x80011773 (+0x45dcc)
    onmousedown = 0x80011772 (+0x45dc8)
    onmousemove = 0x80011774 (+0x45dd0)
    onmouseout = 0x80011771 (+0x45dc4)
    onmouseover = 0x80011770 (+0x45dc0)
    onreadystatechange = 0x80011789 (+0x45e24)
    onafterupdate = 0x80011786 (+0x45e18)
    onrowexit = 0x80011782 (+0x45e08)
    onrowenter = 0x80011783 (+0x45e0c)
    ondragstart = 0x80011793 (+0x45e4c)
    onselectstart = 0x80011795 (+0x45e54)

    What happens next depends on the structure of the page in which the
    malicious tag is embedded, as well as previously visited page and
    previously initialized extensions (all these factors can be controlled
    by
    the attacker).

    When the offending page contains no additional elements, and the user
    is
    not redirected from elsewhere, the browser will typically crash
    immediately, because there is no allocated memory at the resulting
    offset.
    In all other cases, crashes will typically occur later, due to
    attempted
    use of unrelated but corrupted in-memory buffers -for example, when the
    user attempts to leave or reload the page. Another good example is
    coming
    from a page that contains Macromedia Flash - this usually causes the
    Flash
    plugin itself to choke on corrupted memory on cleanup.

    For non-believers, there's a short but fiery demonstration page
    available
    at http://lcamtuf.coredump.cx/iedie.html (yes, it will probably crash
    your
    browser).

    Tested on MSIE 6.0.2900.2180.xpsp2.040806-1825 on Windows XP SP2. As
    far
    as I can tell, other browser makes (Firefox, Opera) are not susceptible
    to
    this attack.

    I eagerly await due reprimend from Microsoft for not disclosing this
    vulnerability in a manner that benefits them most, not passing start,
    not
    collecting $200 (from iDefense?).

    Regards,
    /mz
    http://lcamtuf.coredump.cx/silence/
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

    iD8DBQFEGes4B8JNm+PA+iURAsZsAJ0XGy+wgQVYxD1THdhkuTpw7pLnQgCaA03g
    gBd30LhoXNtpVYFXWZNYzko=
    =f+Yl
    -----END PGP SIGNATURE-----

  2. #2
    Howdy.

    Well i tried the link with the demonstration on it, and either the page isn't done correctly or i survived this overflow..

    cheers
    f2b

  3. #3
    Also here's the source for the page..
    Very interesting message at the bottom of the source code..
    Maybew they should test it properly before launching.

    Sorry for the double post but i couldn't attach 2 images.

  4. #4
    Senior Member
    Join Date
    Jan 2003
    Posts
    3,915
    Hey Hey,

    I just tested it and it definatey was effective.. .

    The post from unhappy was Dave Aitel's repost on DailyDave.

    The original comment came in to a few lists... it also had this follow up shortly after

    ---SNIP---

    > BTW, tested the POC on MSIE (File Version = 6.00.2900.2180
    > (xpsp_sp2_rtm.040803-2158)) with mshtml.dll (6.00.2900.2802
    > (xpsp_sp2_gdr.051123-1230)) and it didn't worked.

    Daniel followed up with me in private and confirmed that the PoC *did* work for him when he followed certain additional instructions: because the attack depends on memory layout and usage, to get consistent results, be sure to close *all* MSIE windows, then go to Start -> Run... and type:

    iexplore http://lcamtuf.coredump.cx/iedie.html

    That should crash the browser immediately, because there are no other buffers nearby to "absorb" the initial fencepost. Still, if no dice, try hitting 'Reload' a couple of times.

    /mz
    ---SNIP---

    Peace,
    HT

  5. #5
    Banned
    Join Date
    Aug 2004
    Posts
    534
    thanx for info... HTRegz

  6. #6
    Senior Member
    Join Date
    Mar 2003
    Posts
    372
    yeah, more than one window opens definately affects this bug. If you have two open it will most likely crash the window that opened the POC but the other window will be unaffected. If you have three or more open there is the possibility that the POC will not work at all.

    I did notice with two windows open that there was a long delay between opening the POC and crashing of the window.

    Give a man a match and he will be warm for a while, light him on fire and he will be warm for the rest of his life.

  7. #7
    Howdy..
    Daniel followed up with me in private and confirmed that the PoC *did* work for him when he followed certain additional instructions: because the attack depends on memory layout and usage, to get consistent results, be sure to close *all* MSIE windows, then go to Start -> Run... and type:

    iexplore http://lcamtuf.coredump.cx/iedie.html
    Ht i just tried that, and i still got the same results of it doing completly nothing..
    I then tried on a clients Pc with no update's etc and it did crash it..

    Allwell next time hey.

  8. #8
    Senior Member
    Join Date
    Jan 2003
    Posts
    3,915
    Originally posted here by .:front2back:.
    Howdy..


    Ht i just tried that, and i still got the same results of it doing completly nothing..
    I then tried on a clients Pc with no update's etc and it did crash it..

    Allwell next time hey.
    It has nothing to do with updates, so that has no bearing as there hasn't been a patch for this yet.. and I'm not sure if it's patchable or just a flaw in implementation of options.. (Haven't looked into it enough)..

    If it's not working for you... then let's go over a few things

    Amount of RAM in the system.
    Amount Available.
    Amount used by IE
    Version of IE
    Version of mshtml.dll...

    There could be a hundred minor things that factor into you not experiencing the crash, but there have been many, many reponses on the various mailing lists of different versions of IE with different system specs crashing.. including IE7 Beta.

    Peace,
    HT

  9. #9
    Howdy..

    Amount of RAM in the system.=2gb
    Amount Available.=1.3gb give or take
    Amount used by IE=about 100 not sure..
    Version of IE=latest
    Version of mshtml.dll.= ComponentVersion=6.0

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •