Hi, does anyone come across this Vulnerability (CVE-2016-10073)? I tried to search but could not find specific info. Our security team reached out to me to check on F5. but not sure whether even it relates to F5 or not. Following info they have provided to me.
Improper input handling is one of the most common weaknesses identified across applications today. Poorly handled input is a leading cause behind critical vulnerabilities that exist in systems and applications. Generally, the term input handing is used to describe functions like validation, sanitization, filtering, and encoding and/or decoding of input data. Applications receive input from various sources including human users, software agents (browsers), and network/peripheral devices. In the case of web applications, input can be transferred in various formats (name value pairs, JSON, SOAP, etc...) and obtained via URL query strings, POST data, HTTP headers, Cookies, etc... Non-web application input can be obtained via application variables, environment variables, the registry, configuration files, etc... Regardless of the data format or source/location of the input, all input should be considered untrusted and potentially malicious. Applications which process untrusted input may become vulnerable to attacks such as Buffer Overflows, SQL Injection, OS Commanding, or Denial of Service.
In Apache (http://httpd.apache.org/docs/trunk/vhosts/examples.htmldefaultallports) and Nginx (https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/) you can make SERVER_NAME trustworthy which can be done by creating a dummy vhost that catches all requests with invalid Host headers. Another method under Nginx is to specify a non-wildcard SERVER_NAME (http://nginx.org/en/docs/http/server_names.html) and under Apache you can use a non-wildcard serverName (http://httpd.apache.org/docs/2.2/mod/core.htmlservername) and turning the UseCanonicalName directive on.
In IIS one method is to have proper bindings setup with a specified host header (https://www.iis.net/configreference/system.applicationhost/sites/site/bindings/binding) so that if someone changes the host header it will not reach the web site on IIS.
Alternatively, at the application level, you can attempt to validate any values coming from the Host or X-Forwarded-Host request headers using a whitelist of acceptable values. You can also choose not to use host header values that come from the client in your application logic and use variables set through server configurations if necessary.