In a new post to his site Mattias Geniar looks at an old security issue in PHP, opcache information leakage and how to mitigating the issue.

A very old security vulnerability has been fixed in PHP regarding the way it handles its OPCaches in environments where a single master process shares multiple PHP-FPM pools. This is the most common way to run PHP nowadays and might affect you, too.

He starts by talking about the vulnerability itself, that the PHP process doesn't validate the userid when fetching cached bytecode. This could result in information from other operations/scripts being exposed to other processes in a PHP-FPM pool. His solution? Upgrade PHP (the bug is fixed back in PHP 5.6.5) and set a few additional opcache ini settings to enforce the validation. Besides 5.6.29, it was also corrected in the PHP 7 releases (7.0.14 and 7.1.0). The post then talks about the potential exploit - an indirect local privilege escalation to root where the shared memory is read and access to outside information is possible.

Imagemagick, a well-used alternative by PHP developers for graphics manipulation (an alternative to GD) has had several new vulnerabilities announced. These vulnerabilities allow for everything from remote code execution to initiating network requests. The Imagetragick site has more information:

There are multiple vulnerabilities in ImageMagick, a package commonly used by web services to process images. One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.

A number of image processing plugins depend on the ImageMagick library, including, but not limited to, PHP’s imagick, Ruby’s rmagick and paperclip, and nodejs’s imagemagick. If you use ImageMagick or an affected library, we recommend you mitigate the known vulnerabilities.

There's two mitigations listed to help with a more immediate fix: using a policy.xml file and verifying that image data starts with the right "magic bytes". The site also shares more information about the different vulnerabilities and what kind of attacks they could allow. It is highly recommended that you add the mitigations they show and update your installation to use the latest release (7.0.1-1) with fixes for these issues.

In this new post Snipe looks at something that we, as web developers, don't seem to think about too much when designing our applications and architectures - risk (and how to manage it).

When I talk about risk as it relates to web applications, people usually assume I'm talking about hardening applications from hackers, spammers and other ne'er-do-wells. While malicious attacks are absolutely a non-trivial part of risk management, there's a lot more to it that's just as important.

She introduces some of the basic concepts behind risk management, specifically as it relates to web applications. She points out that it's not always an external threat you'll need to worry about either. Sometimes its your own development group that introduces bugs or something that makes the system come to a crashing halt. She recommends starting all projects "risk first" and include it into your planning process. She shows how to create a "risk matrix" to get insight into the problem and the data that should be on it.

Finally, she reminds you of a few good rules (including "keep your systems simple") and that analyzing risk doesn't have to be a boring process. Figuring out where things will break, how to break them and what happens when they do can be an interesting process.