GHOST Vulnerability (CVE-2015-0235)

[Maxim_Zavodchik]

On 27 of January Qualys published a critical vulnerability dubbed “GHOST” as it can be triggered by the GetHOST functions ( gethostbyname*() ) of the glibc library shipping with the Linux kernel. Glibc is the main library of C language functionality and is present on most linux distributions.

Those functions are used to get a corresponding structure out of a supplied hostname, while it also performs a DNS lookup if the hostname is a domain name and not an IP address.

The vulnerable functions are obsolete however are still in use by many popular applications such as Apache, MySQL, Nginx and Node.js. Presently this vulnerability was proven to be remotely exploited for the Exim mail service only, while arbitrary code execution on any other system using those vulnerable functions is very context-dependent. Qualys mentioned through a security email list, the applications that were investigated but found to not contain the buffer overflow. Read more on the email list archive link below:

 http://seclists.org/oss-sec/2015/q1/283

Currently, F5 is not aware of any vulnerable web application, although PHP applications might be potentially vulnerable due to its “gethostbyname()” equivalent.

UPDATE:

WordPress content management system using xml-rpc ping back functionality was found to be vulnerable to the GHOST vulnerability. WordPress automatically notifies popular Update Services that you've updated your blog by sending a XML-RPC ping each time you create or update a post.

By sending a specially crafted hostname as paramter of xml-rpc ping back method the vulnerable Wordpress will return "500" HTTP response or no response at all after resulting in memory corruption. However, no exploitability was proven yet.

Using ASM to Mitigate WordPress GHOST exploit

As the crafted hostname should be around 1000 characters to trigger the vulnerability, limiting request size will mitigate the threat. Add the following user defined attack signature to detect and prevent potential exploitation of this specific vulnerability for WordPress systems.

For version greater than 11.2.x:

uricontent:"xmlrpc.php"; objonly; nocase; content:"methodcall"; nocase; re2:"/https?://(?:.*?)?[\d\.]{500}/i";

For versions below 11.2.x:

uricontent:"xmlrpc.php"; objonly; nocase; content:"methodcall"; nocase; pcre:"/https?://(?:.*?)?[\d\.]{500}/i";

This signature will catch any request to the "xmlrpc.php" URL which contains IPv4 format hostname greater than 500 characters.

iRule Mitigation for Exim GHOST exploit

At this time, only Exim mail servers are known to be exploitable remotely if configured to verify hosts after EHLO/HELO command in an SMTP session. 

If you run the Exim mail server behind a BigIP, the following iRule will detect and mitigate exploitation attempts:

 
when CLIENT_ACCEPTED {
 
        
   TCP::collect
 
}
 
when CLIENT_DATA {
 
  
      if { ( [string toupper [TCP::payload]] starts_with "HELO " or [string toupper [TCP::payload]] starts_with "EHLO " ) and ( [TCP::payload length] > 1000 ) } {
 
                log local0. "Detected GHOST exploitation attempt"
 
                TCP::close
 
        }
 
        TCP::release
 
       TCP::collect
}

This iRule will catch any HELO/EHLO command greater than 1000 bytes.

Create a new iRule and attach it to your virtual server.

[Ilya_Chernyakov]

Fast and efficient response!

[hooleylist]

Here's an optimization to the iRule: 

when CLIENT_ACCEPTED { 
    TCP::collect 
} 
when CLIENT_DATA { 
    switch -- [string toupper [TCP::payload 5]] {
        "HELO " - 
        "EHLO " { 
            if {[TCP::payload length] > 1000 ) } { 
                log local0. "Detected GHOST exploitation attempt" 
                TCP::close return 
            } 
        }
    }
    TCP::release 
    TCP::collect 
}

[Mike_Maher]

If you are running ASM, and this attack is via a parameter wouldn't it be viable to protect this via the length checking on parameter values as well?

[Mike_Maher]

or via File Type length checking?

[SimonS_84965]

Is there any reason that this has not been released as part of an Attack Signature Update?

[Maxim_Zavodchik]

Mike, limiting the length of parameter values will mitigate it as well, but can cause false positives on legitimate long parameter values (like free text).

[Maxim_Zavodchik]

This signature is a first response, so ASM users can already start detecting exploitation attempts until we release it in the upcoming Attack Signature Update after more research.