Ok, Hmms. Not exactly what I was thinking about. I'm not talking about PostMessage or SendMessage (Window messaging). But on signals as in unix. I'm sure allot of services f.ex. want to handle a crash or termination nicely by handling and emptying all log data for example.. this could be done using the same techniques as in unix environments.. refering to signal(SIGTERM, sh) function and the handler.. I don't think it's possible to get SIGTERM messages or SIGABRT messages as window messages.. abnormal termination messages etc.. My "guess" is that many services (w3svc, sql server etc..) are using exactly the same way of handling (un-expected program terminations etc..) as unix is? Am I right? Or is there another way of doing this in win32? /JODE ----- Original Message ----- From: <dullienat_private> To: "Joakim Sandstrom" <jodeat_private> Cc: "Michal Zalewski" <lcamtufat_private>; <SECPROGat_private>; <SECPAPERSat_private> Sent: Wednesday, May 30, 2001 9:13 PM Subject: 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 - 21:09:19 PDT