FW: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server

[Peter Werner <Peter.Werner () WGSN com>]

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:dotslash () snosoft com]
> 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:dotslash () snosoft com]
> > Sent: Tuesday, June 18, 2002 8:18 AM
> > To: vuln-dev () securityfocus com
> > 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