I recently purchased a Samsung Galaxy Note II and have been thoroughly enjoying it. The number of diverse applications is pretty amazing.
Unfortunately, a few days ago, a colleague passed an article along detailing an exploit associated with my brand of phone. The exploit is connected to the Exynos processor and the capability to obtain access to all physical memory.
A serious PHP vulnerability has been released today. Only sites running PHP as a CGI script are affected. From php.net:
Some systems support a method for supplying a [sic] array of strings to the CGI script. This is only used in the case of an ‘indexed’ query. This is identified by a “GET” or “HEAD” HTTP request with a URL search string not containing any unencoded “=” characters.
By constructing a URL similar to the following on a PHP-CGI site, an attacker could dump the highlighted source of that script.
http://example.com/index.php?-sphp.net has issued a patch to fix this issue in PHP 5.3.12 or PHP 5.4.2. However, as pointed out by De Eindbazen, the patch is trivial to bypass.
A workaround has been provided by php.net using Apache’s mod_rewrite:
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC] RewriteRule ^(.*) $1? [L]Other mitigation options have been proposed by De Eindbazen, but you may find the mod_rewrite method to be the best approach until a PHP releases a better fix.
Both Threatpost and the SANS Storm Center report that Microsoft RDP services are vulnerable. The exploit is rumored to be capable of crashing or causing denial of service attacks on vulnerable Windows machines.
Companies using RDP should install the Microsoft patch and, in the meantime, block off RDP from all sources except those absolutely required for the business.
The Hacker’s Choice (THC) has recently released THC-SSL-DOS, a new tool for performing an SSL-exhaustion attack.
In this type of attack, the client (attacker) creates multiple SSL handshakes. This is done by issuing many SSL-renegotiation requests to a web server (target), or by using new TCP connections for multiple, initial SSL negotiations. Because it takes more processing power on the server-side to handle SSL handshakes, one or two clients (even with limited bandwidth) are able to utilize most or all of the server’s processing ability. This prevents other legitimate users from accessing the system, thus creating a Denial of Service (DoS).
This new tool has received a lot of press in the last few days (at least within the security community). This bothers me, but not because I don’t think the tool is worthy of press - THC-SSL-DOS is an excellent proof-of-concept tool that is up to par with the many other wonderful THC tools.
My concern lies in the fact that this vulnerability has been known for many years. The THC-SSL-DOS release notes include the following statement:
This problem affects all SSL implementations today. The vendors are aware of this problem since 2003 and the topic has been widely discussed.
It seems that this situation illustrates one of the all-too-common patterns in how vulnerability disclosures play out:
Doing security well is not easy; it takes time, effort, and resources. The release of THC-SSL-DOS should serve as yet another reminder of how important it is make every effort to try and do things the right way the first time.
If and when mistakes do happen, the aim should be to address them before they become a significant issue.
