Re[2]: insecure signal handler design

From: dullienat_private
Date: Wed May 30 2001 - 12:13:09 PDT

  • Next message: Joakim Sandstrom: "Re: Re[2]: insecure signal handler design"

    Hey there,
    
    JS> could be a way to do it?  My goal is to find out who is subscribing to what
    JS> SIG. So it would be easier finding possible problems on win32 (yes lucky you
    JS> who are playing on opensource) :). Night night..
    
    Correct me if I am wrong, but signal races should not be an issue
    under Win32. I am assuming now that UNIX signals have their direct
    equivalent in Win32 window messages. Please bear in mind that what I
    state here is what I --think-- not what I've tried.
    Since NT comes from Mach the signal/message sending is a bit more
    thought out than in the 'average' Unix.
    The distinction between SendMessage()/PostMessage() is that
    SendMessage() will directly call the signal handler -- which can only
    be done within one process address space. PostMessage() will put a
    message into the message queue and wait for the target process to
    _fetch_ it; to send messages to a foreign process you need to use
    PostMessage(). As it is only one thread that processes those signals,
    a signal race will not really be an issue if I am correct.
    
    What is a problem are services that do their IPC via Messages and
    which, for that reason, create invisible windows. If they trust the
    input they're getting (e.g. accept pointers or whatnot) there is a
    danger of privilege escalation.
    
    The direct race condition described in lcamtuf's (great) paper don't
    apply AFAIK.
    
    Cheers,
    dullienat_private
    



    This archive was generated by hypermail 2b30 : Wed May 30 2001 - 17:55:02 PDT