EHS Blog
  Previous 10 Posts
  - Komodo 101
  - Adding Fresh Blood to the Bleeding Edge of Web Development with Komodo 4.1.1
  - ActiveState Hackathon: Get Your Boss to Do This!
  - Google hack to instantly search for files
  - 10 JSP tag libraries no programmer should be without
  - Learning the JavaFX way of doing things
  - Using JavaFX Script for UI Declarations
  - Unicode support in JavaFX Script
  - Could you cut your development time in half?
  - Cookie Handling


Web Hosting
Website Design


No Records !!!

5 6 7 8 9 10 11 12 13 14 15 16 

Watching the PHP CVS
at 2007-08-12 15:10:20

One of the worst things in PHP security is the fact that vulnerabilities in PHP are usually patched in the CVS and then wait for months until they are disclosed to the public. Time enough for everyone to grab the fixes from CVS and develop exploits for the vulnerabilities. Therefore PHP vulnerabilities are usually already known to the bad guys for weeks or months when a new PHP version comes out and the public is notified about the vulnerability.

However sometimes even after a release the general public does not know about some vulnerabilities, because it somehow happens that they are forgotten to be mentioned in the release announcement. This happened before and has happened once again with the release of PHP 5.2.2

A while ago a bug in the mcrypt_create_iv() function was reported and fixed that c

OWASP Risk Evaluation
at 2007-08-12 15:10:20

When you read the OWASP risk evaluation standard carefully you might get as confused as I got. They estimate the risk by first estimating the likelihood and then estimating the technical and business impact. The estimation is done by assigning the numbers 0..9 to a number of factors.

So far so good. Most of it makes perfect sense, but I was a little bit confused about the following factor:

What resources and opportunity are required for this group of
attackers to find and exploit this vulnerability? No access or special
resources (0), limited access and resources (4), special access or
resources (7), full access or expensive resources (9)

According to this factor the likelihood of an attack increases when more access to the application and more expensive resources are required on the attacker's side. I dare t

Suhosin 0.9.20 and crypt() Thread Safety Vulnerability
at 2007-08-12 15:10:20

I just released Suhosin 0.9.20 that adds a few new features and bugfixes. The most important addition is that a mutex is placed around the call to the system's crypt() function to ensure thread safety. This mutex is necessary to close a bunch of possible attacks on the libc crypt() function on multi threaded systems.

Because the libc crypt() function (and also the PHP port for windows) is not thread safe there exists a race condition that can be exploited on multi threaded systems. When for example two threads are trying to validate passwords through crypt() at the same time they are using the same internal memory area which can result in both crypt() actions returning invalid results or the result of the one operation can overwrite the result of the other. It is obvious that in this case a thread using a wrong password will return the correct crypted password i

PHP 4 - Reference Counter Overflow Fix
at 2007-08-12 15:10:20

Because the PHP developers do not want to fix the PHP 4 Reference Counter Overflow Vulnerability that was disclosed during the Month of PHP Bugs the Hardened-PHP Project as usual had to step in to protect the users of PHP.

I created a patch for the refcount overflow problem that took about 30 minutes to develop and that fixes the problem without breaking binary compatibility. Something that is according to claims of Zend Engine developer and Zend employee Stanislav Malyshev not possible at the moment. You can apply it directly or wait until it was ripped and merged into the default PHP CVS after it was relabled as the work of the PHP developers.

PHP 5.2.3 released...
at 2007-08-12 15:10:20

PHP 5.2.3 was released with several security fixes.

Again not all security fixes are mentioned in the release announcement.

Again security bugs known to the developers were not correctly fixed.

More info here.

PS: Why does always release security fixes just before the weekend?

UPDATE: Antony Dogval from Zend meanwhile wrote a blog entry where he comments on this blog entry. He claims that I did not tell the PHP developers how to fix the issue. I love it how members of the PHP development team that do not receive the mails to try to convince the world that I never sent those mails. I wrote atleast 2 times in the conversation about the described bug that the problem is because the session id is not encoded. I am not the p


5 6 7 8 9 10 11 12 13 14 15 16 

Check Out Amazon