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

From: Michael Wojcik (Michael.Wojcikat_private)
Date: Wed Jun 19 2002 - 12:15:01 PDT

  • Next message: Christopher Meiklejohn: "RE: procmail heap overflow"

    Well, a signal handler *is* a way of changing the instruction pointer, so it
    could in theory be used to vector into malicious code.  Consider something
    like this:
    
    - You can inject arbitrary code onto the heap, perhaps in the guise of valid
    data; for example, your code pretends to be a large POSTed content-body.
    You know approximately where this code is likely to end up in the process'
    virtual address space.
    
    - You have a vulnerability which lets you execute an arbitrary sigaction
    call.  (We haven't established that this is possible with this Apache
    vulnerability, of course - this is purely speculative.)
    
    - You have another vulnerability which lets you cause a signal to be raised.
    Obviously this is a common class of vulnerability for eg SIGSEGV.
    
    - So, you send your code, use vulnerability #1 to set the handler to point
    into it, use vulnerability #2 to raise the signal, then wait while your code
    is invoked as the handler.
    
    That seems pretty convoluted and unlikely to me, but I don't write exploits,
    and some of the ones we've seen in the past required some pretty impressive
    gymnastics to vector to the malicious code.  I'm not sure this is much
    harder.
    
    Simpler scenarios include changing a signal handler to vector into existing
    code that does something undesirable (eg causes the server to reconfigure
    using an attacker-supplied file, deposited through some other means) or
    simply messing with the signal handlers for fatal signals so it can't clean
    up gracefully while exiting.
    
    Note that with sigaction (the preferred interface), the signal handler
    location isn't itself a parameter to the system call - it's in a structure
    pointed to by the second parameter.  That makes it somewhat more difficult
    to usefully alter the sigaction call.
    
    Michael Wojcik
    Principal Software Systems Developer, Micro Focus
    Department of English, Miami University
    
    
    > -----Original Message-----
    > From: Anibal Ambertin [mailto:aambertinat_private]
    > Sent: Wednesday, June 19, 2002 8:56 AM
    > To: KF
    > Cc: vuln-devat_private
    > Subject: Re: ISS Advisory: Remote Compromise Vulnerability in Apache
    > HTTP Server
    > 
    > 
    > 
    > ----- Original Message -----
    > From: "KF" <dotslashat_private>
    > To: <vuln-devat_private>
    > Sent: Tuesday, June 18, 2002 4:18 AM
    > 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?
    > 
    >     I don't think this could be usefull for an attacker, 
    > since the only
    > thing
    > you can do is to change  the sigaction parameters, which doesn't imply
    > any risk at all (unless you can write the members of the 
    > sigaction structure
    > and make it go to another internal function -which should be 
    > part of the
    > vulnerable program, in this case, apache-).
    > 
    > > 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.
    > 
    >     Yes. And that's all. So, as I see it, it won't add any 
    > risk to this bug.
    > If I'm wrong I'm sure someone will give you (what? give us!) the light
    > you're looking for :). After all, I'm not a "signaling ninja" ;).
    > 
    > Cheers.
    > Anibal Ambertin
    > (Angel Dezkarriado/StrCpy)
    > 
    > 
    



    This archive was generated by hypermail 2b30 : Wed Jun 19 2002 - 14:06:51 PDT