Likes Likes:  0
Resultaten 1 tot 3 van de 3
Geen
  1. #1
    Nick FitzGerald
    Re: [Full-Disclosure] RE: Unchecked buffer in mstask.dll
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: [Full-Disclosure] RE: Unchecked buffer in mstask.dll

    "Jordan Cole (stilist)" <stilist@gmail.com> to Paul Szabo:

    > > Being curious, on Win2k, I copied cmd.exe (from winnt\system32) as xyz.pif;
    > > then (right-click) Properties, Program crashes explorer.


    I had to specifically click on the "Program" tab, which evoked a null-
    pointer read attempt (at a guess, something in the .PIF parser assumes
    a length or offset will always be >0 so doesn't do any sanity checking,
    and/or some higher level routines don't do any checking).

    > I'd say that's because you changed the filetype; pif files simply
    > contain information on how to handle a DOS executable; they aren't a
    > program themselves. All you did was make it get confused and kill
    > itself.


    Yeah, but how long is it now since we've been telling programmers
    "don't trust user-supplied data"?? (Hmmmm -- does it also fail on
    W2K3??)

    And don't you also find the inconsistencies this throws up at least
    somewhat interesting?

    Rename a PE executable to a .PIF extension, right click, ask to see the
    file's properties and splat -- whatever code is invoked to handle that
    task dies a stupid, if not ugly, death because internally the file is
    the wrong type. However, if you double-click that renamed file it is
    executed as if nothing is amiss.

    And to think that some folk will see this as further reason to enforce
    their belief that when it comes to security and code quality, Microsoft
    really just doesn't get it...

    Why did MS make ".EXE files renamed as .PIF" execute "properly"? Aside
    from "because we can", I'd not be at all surprised if it was on some
    internal "stupid user tricks we should eliminate support calls for"
    list. But, whatever the reason, did anyone at Microsoft give two
    milliseconds of thought to the security (or other) consequences of that
    design decision? I seriously doubt it and I'm sure I'm far from alone
    in that...


    --
    Nick FitzGerald
    Computer Virus Consulting Ltd.
    Ph/FAX: +64 3 3529854


  2. #2
    Jordan Cole
    Re: [Full-Disclosure] RE: Unchecked buffer in mstask.dll
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: [Full-Disclosure] RE: Unchecked buffer in mstask.dll

    > Being curious, on Win2k, I copied cmd.exe (from winnt\system32) as xyz.pif;
    > then (right-click) Properties, Program crashes explorer.


    I'd say that's because you changed the filetype; pif files simply
    contain information on how to handle a DOS executable; they aren't a
    program themselves. All you did was make it get confused and kill
    itself.

    --

    [stlst]

  3. #3
    Dmitry Yu. Bolkhovityanov
    Re: [Full-Disclosure] RE: Unchecked buffer in mstask.dll
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Unchecked buffer in mstask.dll

    On Thu, 15 Jul 2004, Paul Szabo wrote:

    > Being curious, on Win2k, I copied cmd.exe (from winnt\system32) as xyz.pif;
    > then (right-click) Properties, Program crashes explorer. Is this related to
    > IconHandler, and is it exploitable?


    Right -- in Win2K SP4 clicking on [Program] tab of Properties
    window causes "access violation" -- the memory at 0x00000000 could not be
    "read" by SHELL32.DLL. MSVC++, acting as a debugger, shows a mixture of
    KERNEL32, COMCTL32, USER32, SHELL32 and SHLWAPI in stack trace.

    Disassembly window shows that there was an attempt to read dword
    at [EAX] (EAX=0). So at first glance this doesn't seem to be trivially
    exploitable, but I'm not a win32 expert, and intuition suggests that there
    must be a way.

    _________________________________________
    Dmitry Yu. Bolkhovityanov
    The Budker Institute of Nuclear Physics
    Novosibirsk, Russia


Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics