First uses of the PHP 5.4 security backports

I recently checked the Debian PHP 5.4 changelog and found out this message (5.4.45-0+deb7u3 and 5.4.45-0+deb7u4):

* most patches taken from https://github.com/kaplanlior/php-src
Thanks a lot to Lior Kaplan for providing them.

I was very pleased to see my work being used, and I hope this would save other time while providing PHP long term support.

Also, while others do similar work (e.g. Remi from RedHat), it seems I’m the only when that make this over GIT and with full references (e.g. commit info, CVE info and bug number).

Comments and suggestions are always welcome… either mail or even better – a pull request.

Leave a comment

Filed under Debian GNU/Linux, PHP

Anonymous CVE requests

A year ago I’ve blogged about people requesting CVE without letting upstream know. On the other hand, per requests from Debian, I’m working on improving PHP upstream CVE request process. For the last few release this means I ask the security list members which issues they think should have CVE and ask for them in parallel to the release being made (usually in the space between the release being tagged publicly and is actually announced).

In the last week, I’ve encountered a case where a few CVE were assigned to old PHP issues without any public notice. The fixes for these issues have been published a year ago (August 2015). And I find out about these assignment through warning published by the distributions (mostly Debian, which I’m close to).

Sometimes things fall between the chairs, and it’s perfectly OK to ask for CVE to make sure security issues do get attention even if time has passed. But after the issues (and fixes) are public, I don’t see a reason to do so without making the request itself public as well. And even if the request wasn’t public, at least notify upstream so this info can be added to the right places. Most of these bug were found out when I started to add sequential number into the CVE search after getting an a notice from Debian for two of the issues.

  • CVE-2015-8873 for PHP #69793
  • CVE-2015-8874 for PHP #66387
  • CVE-2015-8876 for PHP #70121
  • CVE-2015-8877 for PHP #70064
  • CVE-2015-8878 for PHP #70002
  • CVE-2015-8879 for PHP #69975
  • CVE-2015-8880 for PHP aa8cac57 (Dec 2015)

And while working on processing these issues for PHP, I also notice they weren’t updated for libGD where appropriate (including recent issues).

Beyond keeping the eco-system up to date, another aspect of publicity is getting opinions from other parties. For example, in the case of CVE-2015-8879, RedHat doesn’t agree with the classification of the bug as security. To give an example of a way things should happen is the request of CVE for PHP 5.5.34 in April, in which the Gentoo security team asked for assignment without upstream knowledge, Debian representative CCs upstream (Thanks!) and also asks CVE for issues covered by Ubuntu, to which the Ubuntu guy then adds some details.

I hope this blog post will reach the anonymous people behind these CVE requests, and also the people assigning them. Without transparency and keeping things in synchronization, the idea of having a centralized location for security warning is not going to accomplish its goals.

Leave a comment

Filed under Debian GNU/Linux, PHP

Implementing NATO’s standards (STANAG)

I recently joined Linnovate, and while working on one of the open source projects the company produces, we needed to process video content according to NATO’s standard agreement (STANAG) 4609: NATO Digital Motion Imagery Standard.

Obviously we started with trying to find code already done, but we only found some implementation in Java, while our project is written in JavaScript. We decided to just implement the standard in the way most convenient to us, and later refactoring the project when more standards (STANAGs) will get implemented.

So I’m happy to introduce our new project: STANAG at https://github.com/linnovate/stanag , also available with NPM (see https://www.npmjs.com/package/stanag).

1 Comment

Filed under Linnovate

Backporting of PHP security fixes

4 months ago I wrote my thoughts about PHP support during the “PHP 5 support timeline” vote:

I think we should limit what we guarantee (meaning keeping only one year of security support till end of 2017), and encourage project members and the eco-system (e.g. Linux distributions) to maintain further security based on best effort.

This is already the case for out of official support releases like the 5.3 and 5.4 branches (examples for backports done by Debian: 5.3 and 5.4). And of course, we also have companies that make their money out of long term support (e.g. RedHat).

On the other hand, we should help the eco system in doing such extended support, and hosting backported fixes in the project’s git repo instead of having each Linux disto do the same patch work on its own.

But suggesting to others what they should do is easy, so I decided to finally find the time to also implement this myself. I’ve started with back porting PHP 5.5 fixes to PHP 5.4, resulting in a GitHub repository with all the fixes, including CVE info NEWS file entries and references to the original commits. See https://github.com/kaplanlior/php-src/commits/PHP-5.4-security-backports . I hope this would later on find it’s way into PHP LTS packages for Debian Wheezy.

Next step would be to start doing the same for PHP 5.3 (back porting from PHP 5.4, and later on also from PHP 5.5). This can be in use for RHEL 6.x (as LTS support for Debian Squeeze was recently finished).

The main idea of this repo, is to have a more central location for such work, hoping people would review and contribute fixes that should be taken into consideration.

During the process of digging into the CVE information and the commits, I’m also filling up a info such as CVE IDs to the NEWS file (e.g. https://github.com/php/php-src/pull/1892/files) and the web changelog (e.g. https://github.com/php/web-php/commits?author=kaplanlior), so users and researchers would find this info where it should be instead of digging themselves.

6 Comments

Filed under Debian GNU/Linux, PHP

PHP 5 Support Timeline

With the new year starting the PHP project is being asked to decide about the PHP 5 support timeline.

While Aligning PHP 5.6 support timeline with the release date of PHP 7.0 seems like common sense to keep the support schedule continuous, there’s a big question whether to extend it further to an additional one year of security support till the end of 2018. This would make PHP 5.6, the last of the PHP 5 branch, to have 2 years of security support and de facto getting the same life span as PHP 7.0 would (ending support of both in Dec 2018).

But beside of support issues, this also affects adoption rate of PHP 7.0, serving as a catalyst due to end of support for the PHP 5 branch. My concerns are that with the additional security support the project would need to deal with the many branches (5.6, 7.0, 7.1, 7.2 and then to be 7.3 branch).

I think we should limit what we guarantee (meaning keeping only one year of security support till end of 2017), and encourage project members and the eco-system (e.g. Linux distributions) to maintain further security based on best effort.

This is already the case for out of official support releases like the 5.3 and 5.4 branches (examples for backports done by Debian: 5.3 and 5.4). And of course, we also have companies that make their money out of long term support (e.g. RedHat).

On the other hand, we should help the eco system in doing such extended support, and hosting backported fixes in the project’s git repo instead of having each Linux disto do the same patch work on its own.

1 Comment

Filed under PHP

Overdue GPG signing

In the last few years I wasn’t really maintaining my GPG keys. I’ve created a new one (B4E14499) in 2011 during DebConf11, after the older primary one (99E81DA0) became too weak (1024D). I thought that I didn’t have enough signatures on the new key and almost lost my place on the debian keyring due to removal on the old one (without adding the new key).

Due to my confusion with the key signature, I didn’t really take the time to sign other people keys. But that doesn’t mean I ignored them completely, as I kept all the information from Debconf11 (yes, 4 years ago) and also the slips I was handed since.

Today, I finally took the time to finish the backlog and sign all the keys which are strong enough and still valid (haven’t expired / revoked). One less item on the todo list.

For those who got my signatures – I’m sorry for the delay, but better later than never, right ?

Leave a comment

Filed under Debian GNU/Linux

CVE assignment without upstream knowledge

In the past few months I’ve been dealing with aligning PHP CVE information to enable easier tracking of security fixes. The two main locations are the NEWS file which is part of each release and the changelog available on the website which is more popular (and easier to update).

Usually the CVE are assigned per PHP.net security team request or with cooperation with one of the Linux distribution’s teams (either PHP or security), as should be in a good ecosystem.

Recently I got a few notifications issued by Debian about its PHP package, which I wasn’t familiar with these CVE IDS. When checking this, I found out a few CVE assigned per 3rd party (Linux distribution, bug reporter, etc…) request without upstream knowledge. Digging deeper I found out that some CVE were assigned a month after the fixes were released, while others were only a week or two after. While this makes sure the security information is documented, it’s harder to add the information after tagging and releasing.

In another case, while discussing about a CVE for a specific bug, we found out one was already assigned per the reporter’s request but without the our or the upstream library knowledge. Even if the issue isn’t severe, upstream should get a fair chance to fix issue before making them public. Which also leads to a problem with requesting CVE IDs on a public mailing list which in some cases leads to security information leakage. We should balance transparency with some grace period for upstreams (as projects share code).

1 Comment

Filed under Debian GNU/Linux, PHP