GHOST Vulnerability (CVE-2015-0235)
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.
Using ASM to Mitigate WordPress GHOST exploit
uricontent:"xmlrpc.php"; objonly; nocase; content:"methodcall"; nocase; re2:"/https?://(?:.*?)?[\d\.]{500}/i";
uricontent:"xmlrpc.php"; objonly; nocase; content:"methodcall"; nocase; pcre:"/https?://(?:.*?)?[\d\.]{500}/i";
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_ChernyakovHistoric F5 AccountFast and efficient response!
- hooleylistCirrostratus
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_MaherNimbostratusIf 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_MaherNimbostratusor via File Type length checking?
- SimonS_84965NimbostratusIs there any reason that this has not been released as part of an Attack Signature Update?
- Maxim_ZavodchikHistoric F5 AccountMike, 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_ZavodchikHistoric F5 AccountThis 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.