there are certain types of handlers, but nost are thigns like ctrl-c
handlers and stuff. i'm not familaiar with a direct correlation to unix
style signals in a win32 environment. ipc happens, but almost all
objects(kernel or userland) have the option of having a security desciptor
associated with them, so you probably can protect against any odd situations
if implemented (STOP PASSING NULL AS A SECURITY DESCRIPTOR ON SECURITY
CONSCIOUS OBJECTS:).
i've been looking at this attack and there are in fact ways of doing what
you are talking about using termination handlers in Structured exception
handling. basically, when a proc is closing, threads are terminated, and
stack handlers unroll. all termination handlers should be called(i'm
talking about __finally{} blocks).
postmessage isn't really the same thing, directly, but perhaps
TermiateProcess could be considered similar to sending a SIGTERM to a
process, depending on how you use it.
Signed,
Ryan Permeh
eEye Digital Security Team
http://www.eEye.com/Retina -Network Security Scanner
http://www.eEye.com/Iris -Network Traffic Analyzer
----- Original Message -----
From: "Joakim Sandstrom" <jodeat_private>
To: <dullienat_private>
Cc: "Michal Zalewski" <lcamtufat_private>;
<SECPROGat_private>; <SECPAPERSat_private>
Sent: Wednesday, May 30, 2001 12:33 PM
Subject: Re: Re[2]: insecure signal handler design
> 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 : Thu May 31 2001 - 15:11:17 PDT