FYI, another PHP security related update to 5.3.12 and 5.4.2:

http://www.php.net/archive/2012.php#id2012-05-03-1

in regards to updates for the atomic repo php packages.

Thanks.

Thanks for the warning.

I couldn't get that to trigger using "normal" or FastCGI in Plesk. I don't have any running in CGI mode. I kind of assumed FastCGI mode might be vulnerable too, but apparently not. Good!

No, FastCGI is not vulnerable. Only plain CGI.

Parallels also published the following two knowledge base articles:

PHP-CGI remote code execution vulnerability (CVE-2012-1823)
http://kb.parallels.com/en/113814
http://kb.parallels.com/en/113818

Also see this thread: http://www.atomicorp.com/forum/viewtopic.php?f=2&t=5895

Sorry, forgot to mention that ASL and real time rules users are already immune to this. So if you are running ASL, or our real time rules, you do not need to upgrade PHP.

Of course, there may be other fixes in PHP that you may want to enjoy that are unrelated to this vulnerability, or you just want some added defense in depth (nothing wrong with that) so if you want to upgrade please do. Just know that if you are running ASL or our real time rules that you dont need to worry about this vulnerability effecting you.

According to http://www.securityweek.com/official-fi ... rchers-say the fix in PHP 5.3.12 and 5.4.2 is easily bypassed.

ASL and real time rules users are still immune to this. The newer bypasses are also stopped by ASL and the real time rules. If you are a user of either, you are immune.

how does the ASL protection manifest itself (without giving anything away)? I tried ?-s and although nothing bad happened, I wasn't blocked.

In this case ASL detects if an attempt is successful and blocks it, if its not successful it just quitely ignores it. The principle is that in some cases it might be legitimate to allow this, maybe some app needs - in the first part of the query string but isnt setup in this vulnerable way. FPs are dicey stuff, I'm no longer surprised by the bizarre stuff some web applications do that we thought "no one would ever do something like that". like the web app I recently saw that used raw SQL from the request as part of the cookie, er... OK... terrifying bad idea, apparently the app just used it as "randomization". Terrible randomization, but I guess good enough for the app to work, but an awful idea all around just imagine third party tools parsing that data, or log analyzers. We always block SQL in a cookie for that reason, but apparently this app used it "benignly". We recommended the developer change that as it would require a hole thats not really necessary. Anyway, I digress, but FPs are a concern with any rule, so we added in intelligence to try to prevent this from occuring (plus there were existing rules to detect things like inoformation leaks that would catch some of the cases independently). It might be overkill, and if we dont see an issue that requires it we may remove this intelligence in the future.

If ASL determines it is malicious, then the rule blocks, if it is sure its NOT malicious then it blocks. It will only let it through if it knows its not malicious (i.e. didnt do anything on execution).

Anyway, point is ASL stops the attack in a more nuanced way than just the rules. We generally do this for new protections, we dont like FPs or FNs. We experiment on an ongoing basis, and if the FP issue looks like its overblow we back out some of this intelligence. We've had a project going for a few days to see if this is necessary for this protection, and if its not then we'll default to the less nuanced method and just block the query, even if the system isnt vulnerable to this. It wouldnt be the first time some app did something no one thought was possible (which is why those mod_rewrite work arounds are going to be interesting to watch to see how much they break), so we just want to be careful and secure where possible.

Interesting. Thanks.