Hahaha, this actually made my day.

What part of:

"Due to the failure of not encoding the session id when
sending it trough a cookie it is possible to inject ';'"

or

"However, even if the cookie is not sent at all... It is a bad idea to
put in session id and session name into the cookie without URL encoding."

are so hard to understand? Both parts were written in the email conversation. I think this made it pretty clear that I do not consider it fixed until it is encoded.

Before I quit the security team there was an arrogant statement by some of the members that there are plenty of security aware people on the security team. If that is true then it would be their job to fix it. It is not my job as external to do your work and the vulnerability is not even mentioned in the release notes.

Additionally several guys of the Security Team believe they are competent enough to give PHP security talks. In these talks you claim that you should not trust user input and escape it before outputting it. You even cover header() Injection. So why in hell do I have to tell you that the session id is user input and needs to be encoded.

Ilia,

nothing is unpredictable. The whole purpose of the session_id() function is to set a user supplied session id. This function is meant to take user input. You even have session_id() examples on your own security slides.

You on the other hand were not reading my report, you were trying to outsmart me, because my inital example did not work, and get around the "encode it" suggestion and stop the cookie from being sent. Maybe one of the security team members was saying: Uhh no we cannot encode it. It will hit the performance.

Yes I took the time and wrote the stuff to protect those using PHP.
Those using PHP are also not the ones that write blog entries or mailinglist mails where they attack me for not helping, etc...

But hey... Don't fear... When I finished my paper I have another round of vulnerabilities for PHP.net.

PS: of course the session_id() issue is still remotely triggerable in applications using it to specify a session id. Because that is the purpose of the session_id() function.

Stanislav someone should really take your keyboard away.

Your statements gets more ridiculous by every day. You have obviously no fucking clue what you are talking about. And your involvement in the PHP security team throws a very bad reputation on the PHP project.

session_id() is a function of PHP that is used by applications to supply their OWN session id to PHP. Where do you believe this session ID is coming from you dumbhead. It is coming from user input.

Stanislav,

you do understand that something like this

index.php?PHPSESSID=xyz

is putting user input in a session id?

If you fail to understand that the session id is ALWAYS user input there is not much to discuss...

Oh btw... A google code search for "lang:php session_id\(\$" will show you that it looks like the latest phpMyAdmin version does exactly this...

Great now you admit that software exists that does use the session_id() function in exactly the way I described. In case of phpMyAdmin it might not be exploitable but phpMyAdmin is not the only software in the world.

Case closed.

Ilia,

do you want to make me laugh?

The next argument is that the htmlentities() function was originally not designed for user input and therefore the bufferoverflow in htmlentities() does not count. People should filter the user input before giving it to htmlentities().

Guys you should better just shut up and never ever give any comment about security issues anymore. The session_id() function was designed to allow scripts to supply their own session ID in case ext/session cannot extract it from GPC vars. For example when the session id is supplied through a XML POST or by some other means.

Your redefinition of the purpose of the session_id() function is just ridicolous. But that is typical for PHP developers. Blame the programmer, because PHP is bugfree.

It is up to the session module f.e. a userspace handler and the script to decide what characters are legal for session ids. A PHP developer cannot know that by putting a ; into the session id PHP ext/session will completely break.

Only ext/session is at fault here. If I have code like session_id($_GET['id']); then this is the same situation as if I only have session_name('id');
So how can it be MY FAULT that case 1 breaks PHP and case 2 is properly handled?


Beside the fact that ext/session should be avoided anyway because it makes PHP applications vulnerable to DOS.

Look at it from this angle....

The PHP programmer knows that ext/session handles any chars in the GPC variable PHPSESSID correctly. (Or atleast they think that is the case)

Now session_id() is a function to help ext/session to find the session id in case it cannot find it automatically. How should a PHP programmer magically know that suddenly it his responsibility to filter characters.

And well there are systems were ; is a perfectly legal character in a session id. I see it nowhere documented that this is not the case for PHP.

I don't understand all this discussion: ext/session puts user input into something like the header() call. Therefore it is ext/session's job to encode it.

First of all if I would commit all necessary security fixes without discussion I would loose my commit rights very soon because the PHP developers don't understand that security is always more important than performance.

The majority of PHP servers are not highspeed sites. They give a shit if a single syscall per request is removed. However Rasmus and Co have forgotten that the majority of PHP users are not enterprise companies with millions of PI per day that might need such performance tweaks.

And secondly I already told you several time that if I commit every fix then there will be NEVER EVER a change in the PHP development team/process. There is no learn effect if I do all the work (and the PHP developers have to learn alot about professional release management, vulnerability management).

It is very naive to believe that just commiting fixes is good for PHP. It is actually the opposite. It is never a healthy situation when the responsibility for the whole security etc... of such a big project rests on a single shoulder. And I am demonstrating exactly this.

And last but not least the behaviour of the PHP development team towards my person is indiscutable and therefore I don't see a reason why I should do their work for them.

I call stupid dumbasses "stupid dumbasses"...

So what. I am just honest. I have technical reason to call them dumb. They on the other hand just lie (spread FUD) because they dislike that I show how many vulnerabilities PHP has.

And for the rest of your comments. Well you are not a PHP developer, you were never a PHP developer. So please don't assume that you know what the PHP developers do and not do. I was forbidden often enough by rasmus, andi, zeev and the rest of the "group" to fix stuff correctly. I am no longer arguing about such things. They can commit the broken, half assed patches themself. I don't support half assed fixes.

And last but not least learn to read: The session vulnerability was disclosed 14 days before the release of PHP 5.2.3. I did not disclose it 1 day after the release but 2 weeks before. It is not my problem that the PHP developers do not commit the only fix that makes sense and that was recommended by me. All this mud throwing is as usual initated by the PHP developers, not by me. I just state facts and they attack me.

Blog postings like the one by Antony are just based on lies with the single goal to discredit me.