Atomicorp

Theres a new vulnerability in bash, you can read more about it here:

http://threatpost.com/major-bash-vulner ... s-x/108521

And here:

https://securityblog.redhat.com/2014/09 ... ash-flaws/

We released modsecurity rules to block attacks using this vulnerability. We've also released firewall IPS updates for ASL systems to protect other protocols. For rules only customers this should protect you from any web based attacks, for ASL systems this will also protect any other protocols from this attack (DHCP, etc.). We still recommend customers upgrade bash on their systems.

So if you are an ASL user, you were protected before this vulnerability became public. If you are a rules only user, you were protected from the web attacks.

These new rules are in the Virtual Patching ruleset, which is enabled by default in both ASL and aum. Custom rules users should ensure they have that ruleset loaded on their systems.

Mike:

Assuming this is the case but asking just in case, are the rules such that they are protecting against CVE-2014-6271 as well as the incomplete fix associated with CVE-2014-7169?

Thanks.

Yes, they protect against both CVE-2014-6271 as well as CVE-2014-7169. They enforce both valid inputs (which is part of our proactive security model), as well as the specific injection methods the vector would use.

Great, thanks for the clarification.

In short, if you are using ASL or our real time rules, as described above, you were protected from web attacks using this vulnerability before it was public knowledge. We posted a twitter update once the vulnerability was no longer embargoed (it actually wasnt supposed to become public as soon as it did). There are active exploits out there now, so we've move these rules from the strict ruleset to the virtual patches ruleset so its active on everyones systems by default.

On the off-chance anyone is still unavoidably running a RHEL4/Centos4 system, Oracle seems to have published some compatible patched Bash packages:

http://public-yum.oracle.com/repo/Enter ... test/i386/
http://public-yum.oracle.com/repo/Enter ... st/x86_64/

Also there are patched OpenSSL and bind packages.

I have tested on one system and the Bash package seems to work. Not tried any of the others.

I'm sorry, but I've not looked into why Oracle continues to offer support for their EL4 flavour while everybody else stopped years ago, nor do I know if there are any "gotchas" with mixing flavours in a small way like this, or using Oracle packages in general for that matter.

See http://en.wikipedia.org/wiki/Oracle_Linux for more

Mike:

Are the protective rules still contained in the virtual patches ruleset? Asking in relation to rules only situations to make sure the right rulesets are active (versus the prior strict set that may not always be active by default).

I assume so but just for clarification, are the rules protective for the potential new bash issues that have been noted since the release of the original two CVEs?

Thanks!

Thank you for the questions.

Are the protective rules still contained in the virtual patches ruleset? Asking in relation to rules only situations to make sure the right rulesets are active (versus the prior strict set that may not always be active by default).

Correct. We wanted to make sure they were on for everyone.

I assume so but just for clarification, are the rules protective for the potential new bash issues that have been noted since the release of the original two CVEs?

Also correct. The rules protect systems from all current CVEs (via the web vector). ASL will protect thos systems from other vectors too, like DHCP, SMTP, etc.

I'm having difficulty understanding what's actually happening with regards to the third Bash issue that's being worried about.

I got the impression that the second RH Bash (Friday) actually fixed the third issue that's being worried about, and that the methodology RH used was then published as a candidate patch to the generic Bash source code. IF this is correct, then if you compile your bash from source or use a non-RH-derived distro, you need to be looking at a third update, while those who use the Centos/RH rpms should be OK.

But I'm not sure if this is the case or not. It seems clear as mud to me As a precaution, I keep checking for updates just in case.

Mike:

Great, thanks for confirming.

Also, make sure you protect all your web services with ASL, including control panels. Many control panels include their own versions of bash, which are also vulnerable, and will not be patched by just upgrading your systems version of bash. Instructions for putting ASL in front of a control panel are available at the URL below:

https://www.atomicorp.com/wiki/index.php/ASL_WAF#local

Please note for our rules only users that because many control panels use their own web servers, which do not support modsecurity, you must use ASL to protect these services.

Still when i enable T-WAF on plesk panel file manager will give.
I know plesk was using @ and that why this happen
Then there was tolled it should be fixed in plesk 12

This is plesk 12 and still got that problem.