Prepare for the worst

Tuesday, October 18. 2005

At the 19th July phpBB 2.0.17 had been released, which was just another security release. At the same time their development team proudly announced that they have started a audit of the complete source base together with a number of so called top-notch security people. They never wanted to elaborate the names of these people and therefore many people just believed that the audit did not exist at all and was only announced to stop hosters banning phpBB. Quite similiar to the sudden appearance of a certain inactive consortium after the Santy worm had been unleashed.

In the middle of August I had a look into the phpBB source code and found several weaknesses in phpBB that allowed to exploit a bunch of unitialised variables when register_globals is turned on (which is still the most often used setting). The problems I reported to them were several XSS, an SQL and even one remote code execution hole. While the whole impact of what I had found was not yet clear on the 14th of August it was the date of my initial report to the phpBB developers. This was obviously about 66 days ago.

From my point of view knowing about security holes, that can even allow remote code execution and that can be fixed by simply initialising a single variable for so many weeks, without releasing patches, is completely irresponsible. I surely can understand, that fixes need to be tested to ensure that nothing gets broken. But on 23th September I was told, that all security related patches are now given to the audit group to review and test them.

Because they obviously need more than 3 weeks to test all their security patches and because you can test the patches I sent them in a few hours, I am already prepared for the worst. They obviously have a very large amount of security patches that needs testing.

Who knows... Maybe the next reincarnation of Santy is not so far away...

Posted by Stefan Esser in Security, PHP at 19:20

Comments (11)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 Mike Willbanks wrote (Link) ()

phpBB I do not think will ever make it up to snuff. With so many security woes you have to wonder who do they have programming it? Many people program with flexibility with out taking mind to security. The more flexibility added into an application creates more thought and processes to weedout security problems.

I wonder if they thought about that

posted on Tuesday, October 18. 2005

#2 enygma wrote (Link) ()

Ironic about the title there - could be taken two different ways...

"the worst" referring to the bead things to come
"the worst" referring to phpBB

posted on Wednesday, October 19. 2005

#3 Acyd Burn wrote (Link) ()

Hi,

i am one of the developers (responsible for olympus and now leading development). We definatly have people auditing the source and with the release of 2.0.18 they will be shown at our about list. We do not want to announce them before to prevent people PM'ing them (it is ok if people get on our nerves sometimes but "they" should not waster their precious time with replying to peoples questions).

There are several fixes (more than ever) going into 2.0.18, some to prevent "things", a backport of one of olympus' security features, fixing some reported issues and a lot of bugfixes. Nearly all of these issues are not exploitable but "could" be exploited if a way is found. We think fixing these weak points now too is better than fixing them with 2.0.19. The issue you reported has been reported by a team member before too btw, and has been fixed in our branch. But since we have so much fixes and changes made we want to be really really sure. At the moment the packages for the debian package maintainer, the phpBB Teams and the international support teams are prepared, for much wider testing. We already have the changes in place at phpbb.com for 2 weeks now (the backported feature changes the way sessions are handled, therefore this long testing period).

Normally we fix issues very fast, if severe in a few days. But 2.0.18 seems to be another case here, obviously.

I hope 2.0.x will get a good security boost (it's years old code, from a time no one knew about security related stuff which is common to know nowadays) with the release of 2.0.18. The positive here is that so many people are trying to break into phpbb installations, to find ways in, to exploit it... that it will get stronger and stronger.

posted on Wednesday, October 19. 2005

#4 Richard ()

[ Comment by Richard deleted ]

I am not tolerating rants from people that hide behind the anonymity of the web. If you are to shy to tell your name while ranting against my person (without actually knowing how often I have rescued the asses of the PHP Project and the members of the PHP community), then you will get your comments deleted.

posted on Thursday, October 20. 2005

#5 NeoThermic wrote (Link) ()

I write this three months and a day to the release of .17 (as per the date you quote).

I ask you; how long do you think a secuirty audit should take?

phpBB isn't small. There's approximaly 17,246 places in the phpBB code where variables are in usage, be that initialisation, loops, being given user input to being the result of one of the 479 possible SQL queries that is a phpBB install. With 51,790 total lines to a default .18 install, do you think that approximaly 3 months is a reasonable time for an audit?

You, having knowledge in secuirty, must remember what goes into a successfull audit. There's the actual finding of possibly insecure code. Then there's the exploit crafting, or setting forth the conditions in which said code can be exploited. After that, there's the process of working out how to fix the hole via patches, and then you'll run some regression testing (as in does this break any other patches or bring back any other secuirty holes?). Not to mention that since the session code is chaning in .18 that itself needs a lot of testing, as apart from usage in 3.0; still in development, there hasn't been any audit of the code, nore has there been any wide scale testing of it on diffrent phpBB installs.

As for the fleeting comment about santy in the first paragraph; the fix for santy was released about two months before the worm appeared. Lack of people upgrading caused it to be as big as it was, not lack of effort from the phpBB group.

Finally, as Acyd Burn said, phpBB 2.0.x's codebase is very old; 3 years, 6 months two weeks and two days to be exact to today. I ask you, how many projects of that age and size can you pick up and expect not to have secuirty problems?

Sometimes it's like people are bashing phpBB because they can, without knowing all the facts...

NeoThermic

P.S Why oh why are there no scroll bars on this textbox? Typing half of this was a case of type until it dissapeared, then use the down arrow to bring it all back again...

posted on Thursday, October 20. 2005

#6 Stefan Esser ()

Noone says, that 3 month is enough to audit the complete phpBB source code line by line.

But this has nothing todo with you knowing about 66 days (more than 2 months) of a specific vulnerability. That is maybe only exploitable under some conditions (PHP5, register_globals...). But infact it is exploitable under some conditions and allows remote code execution.

And you always have the chance to Release 2.0.17 with a security release for that particular vulnerability. But you choose to wait. While you maybe think this is the right way to handle this situation other may think different.

Ohh btw... and it is really funny that you guys now claim that your auditing team found the stuff I reported 66days ago before I did...

Very funny indeed, because I had to write several times to the security bug tracker until your "security pros" understood what the problem is. Very funny that they claim to realise after 66 days, that they already knew about this...

With claims like that, you cannot take the phpBB developers seriously...

posted on Thursday, October 20. 2005

#7 Techie-Micheal ()

I'm going to try to be nice here, but your attitude remains much the same as it was in the Security Tracker. If my memory serves me correctly, the issue you reported was reported a whopping 12 hours after the first person reported it. Take a deep breath, relax, and enjoy life.

posted on Thursday, October 20. 2005

#7.1 Stefan Esser ()

Yes exactly. This is really realisitc. After all this time that these bugs existed, the same 3 bugs were suddenly reported 12 hours before I reported them. LOL.

That's why you personally asked me to clarify my report. If you knew about it before you would have known the problem and would not need a more detailed explanation.

posted on Thursday, October 20. 2005

#8 Richard ()

[ Comment by Richard again deleted ]

Well it gets boring to delete anonymous rants...

I am not insulting anyone in my blog.

If you consider it an insult, that I search for security holes and disclose them to the vendor, then you have certainly a strange point of view.

If you consider it an insult when I tell people about the fact that the vendor is ignoring security holes, then you have certainly a strange point of view.

If you consider it an insult when I tell people my opinion about a certain consortium that is doing nothing (proof me wrong) and is only used by their members to advertise their own services, then you have certainly a strange point of view.

If you consider it an insult that I am not going to let a few marketing monkeys grab credits for improving the security within the PHP community, while most of the security in PHP is done by me alone, than I really don't care about your opinion...

posted on Thursday, October 20. 2005

#9 Acyd Burn wrote (Link) ()

Regarding the other person, it was Pit (a former team member who helped creating the global unsetting code and not being a member of the audit group).

Your report came in on Sun Aug 14, 2005 11:38 pm and has been last changed at Sat Oct 08, 2005 2:09 pm (setting to patching in progress). Pits report came in on Tue Aug 30, 2005 12:44 am and has been last Changed at Sat Oct 08, 2005 2:10 pm. The reports only differ in that you reported the possible XSS for the variables and Pit just stated that his code is no longer working with PHP5 and provided a possible fix.
Therefore within the changelog both of you are mentioned.

So, to be fair, you were the one who reported the issue first (giving full details on 6th September).

of course it is questionable if it is the correct way, but i rather release 2.0.18 with a bunch of fixes (if the reporters agree to hold off their disclosure postings for some time) rather than having to package 2.0.18 with a tiny fix. This often goes hand-in-hand with those reporting problems.

posted on Thursday, October 20. 2005

#9.1 Stefan Esser ()

Hello Acyd Burn,

I just posted this blog entry because I believe that vulnerabilities like this (remote code execution) have to be fixed fast. And it is quite annoying to wait and wait... If you have a look at EEYE.com you will realise, that EEYE follows a similiar policy. They announce the presence of a vulnerability in "a product of vendor xyz" when they disclose it to the vendor and after 60 days have passed they consider the vulnerability overdue and give out more information.

I waited 66 days, before I announced anything so I was kinda fair if you have a look at "industry standards".

Well yeah and in the end I was tricked by myself and thought for quite a long time, that one of the "tricks" also works against PHP4. My fault. Would have made the whole thing more dangerous. (Doesn't mean that I don't come up soon with a working PHP4 trick

In the end... Thank you for your clarification, that I was indeed first. And keep up the work. Like I said with this blogpost, you obviously needed a long time to test the patches. This means a lot of changes (=fixes?) and I guess the PHP community will only benefit from a security bug-free phpBB.

posted on Thursday, October 20. 2005

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:

Standard emoticons like :-) and ;-) are converted to images.

Remember Information?
Subscribe to this entry

Calendar