It seems that the predictions made by tech journalists after a serious of attacks in 2014, are coming for real. According to them, the situation in 2015 would be worse viewing to the more advanced techniques been used to penetrate … Continue reading
A vulnerability in the Bourne Again Shell (bash), dubbed “Shellshock,” has become a major security concern and drawn comparisons to the Heartbleed bug.
The post Could the Shellshock Vulnerability be the Next Heartbleed? appeared first on Web Hosting Talk.
Security experts and researchers have found a risky vulnerability in GnuTLS, a secure communications library for SSL, TLS and DTLS protocols and associated technologies, which has experts frantically urging users to update GnuTLS. According to a bug description, posted by Bugzilla Red Hat, “a flaw was found in the way GnuTLS parsed session IDs from ServerHello messages of the TLS/SSL handshake. A malicious server could use this flaw to send an excessively long session ID value, which would trigger a buffer overflow in a connecting TLS/SSL client application using GnuTLS, causing the client application to crash or, possibly, execute arbitrary code.”
The flaw in question, according to thewhir.com, ”was found in the way GnuTLS parsed session IDs from ServerHello messages of the TLS/SSL handshake. A malicious server could use this flaw to send an excessively long session ID value, which would trigger a buffer overflow in a connecting TLS/SSL client application using GnuTLS, causing the client application to crash or, possibly, execute arbitrary code.”
In a blog post from radare, a company that creates reverse engineering frameworks, it showed that its r2 software could be used to exploit the GnuTLS vulnerability. radare’s recommendtion is to update GnuTLS to version 3.1.25, 3.2.15 or 3.3.4.
“In order to test that vulnerability I choose to run a 32bit VoidLinux Virtualbox VM, fetched the r2 source from git, and executed the GnuTLS binaries against the system libs. This way, switching between the fixed and vulnerable executions can be done by changing the
“It’s recommended to use r2 from git: read this post to install r2 in your system.”
“A quick check on all the packages that depend on GnuTLS shows some hints of which client software is vulnerable to this issue.”
“GnuTLS credits Joonas Kuorilehto of Codenomicon as the individual who originally discovered the vulnerability. Codenomicon employees were among those that found the Heartbleed bug, a recent and devastating vulnerability in OpenSSL that presented risks for many high-profile sites, causing millions to change their web account passwords.”
“GnuTLS is an open-source transport-layer security library similar to OpenSSL, but less popular. Yet it is still widely used. It is shipped by default in Red Hat, Ubuntu and Debian, and more than 200 Linux software packages depend on it for SSL/TLS.”
“With the OpenSSL vulnerability in recent memory, administrators will want to take a similar level of diligence to ensure that GnuTLS doesn’t provide a way for hackers to interfere with their servers and applications.”
ZDNet writer, Liam Tung, speaking on this bug, relays that “while it’s thought the library is used by around 200 operating systems and applications, arguably many of them were not likely targets for a man-in-the-middle attack.”
This is not the first time ZDNet has mentioned the bugs in GnuTLS. In a March 6th article from earlier this year, Steven J. Vaughan-Nichols wrote:
“According to some reports you’d think the security sky was falling. Yes, GnuTLS, an open-source “secure” communications library that implements \Secure-Socket Layer (SSL) and Transport Layer Security (TLS), has serious flaws. The good news? Almost no one uses it. OpenSSL has long been everyone’s favorite open-source security library of choice.”
“Latest? Yes, latest.”
“You see, GnuTLS has long been regarded as being a poor SSL/TLS security library. A 2008 message on the OpenLDAP mailing list had “GnuTLS considered harmful” as its subject — which summed it up nicely.”
At the end of his article, he looks to kill the issues:
“No one should be using GnuTLS. There are far better security programs out there starting with the far more popular OpenSSL. If for some reason you must use GnuTLS for now, either upgrade to the latest GnuTLS version (3.2.12) or apply the GnuTLS 2.12.x patch. Oh, and developers? Start weaning your programs from GnuTLS, you, and your users, will be glad you did.”
Vaughan-Nichols’ news from two months ago begs the question, was the bug worse than first thought? Was the problem ignored? Is it really as bad as people have said or did the Heartbleed bug scare the hell out of security experts and programmers, getting faster action on GnuTLS? Is it another case of the sky is falling but no one really wants to be the one to look up and see? Whatever the answer, is there really any bug that can be ignored?
Top image ©GL Stock Images
cPanel & WHM servers using the default cPanel PHP CGI configuration are not vulnerable to the command line switch vulnerability.
A recently disclosed flaw in PHP’s CGI implementation allows malicious users to remotely view and execute source code. The exploit was documented by the Eindbazen team and documented as CVE-2012-1823.
cPanel & WHM servers are not affected by this, thanks in part to a wrapper script used by cPanel & WHM when Apache is configured to use CGI for the PHP handler. This wrapper script does not pass through any command line options.
Server administrators are encouraged to verify their PHP configuration.
When configured to use CGI or FCGI, cPanel & WHM instructs Apache to use the following wrapper script /usr/local/cpanel/cgi-sys/php5 or /usr/local/cpanel/cgi-sys/php4 (The number after “php” is based upon the current major version of PHP.) The unmodified version of the wrapper script looks like the following:
# If you customize the contents of this wrapper script, place
# a copy at /var/cpanel/conf/apache/wrappers/php$ php_version
# so that it will be reinstalled when Apache is updated or the
# PHP handler configuration is changed
exec $ binary
The $ binary placeholder will contain /usr/bin/php or /usr/php4/bin/php By default, no command line parameters are included.
A memory corruption vulnerability exists in Exim versions 4.69 and older (CVE-2010-4344). Exim is the mail transfer agent used by cPanel & WHM.
This update has been rated as Important by the cPanel Security team.
A memory corruption vulnerability has been discovered in Exim. This vulnerability may lead to arbitrary code execution with the privileges of the user executing the Exim daemon. cPanel previously released RPMs that mitigated the severity of the vulnerability on December 9, 2010 (CVE-2010-4345). This notification is for the release of new RPMs which remove the remote memory corruption vulnerability in its entirety. The vulnerability relies upon "rejected_header" being enabled (default setting) in the log_selector configuration.
To resolve and work around the issue on Linux systems, cPanel has issued new Exim RPMs. Server Owners are strongly urged to upgrade to the following Exim RPM versions:
Systems configured to use Maildir: Exim 4.69-26
Systems configured to use mbox (deprecated): Exim 4.63-5
Exim RPMs will be distributed through cPanel’s package management system. All cPanel & WHM servers receiving updates automatically will receive the updated Exim RPM during normal update and maintenance operations (upcp). To begin an Exim update on cPanel systems immediately, run the following command as root:
FreeBSD systems should be running Exim 4.72 by default, which is not affected by this issue.
This notification covers CVE-2010-4344.
The notification release earlier on December 10, 2010 with the summary "A privilege escalation vulnerability exists in Exim, the mail transfer agent used by cPanel & WHM." covers CVE-2010-4345. At the time of the earlier announcement, the CVE had not been assigned.
CVE-2008-5519: Apache Tomcat mod_jk information disclosure vulnerability
Vendor: The Apache Software Foundation
mod_jk 1.2.0 to 1.2.26
Situations where faulty clients set Content-Length without providing
data, or where a user submits repeated requests very quickly may permit
one user to view the response associated with a different user’s request.
Upgrade to mod_jk 1.2.27 or later
This issue was discovered by the Red Hat Security Response Team
The Apache Tomcat Security Team
[ Category : Apache Tomcat ]