[Critical] New vBulletin 5 SQL Injection

Did you read Kevin Sours' reply? He is lead dev for vB5, but he talks like someone else is or had been making the design decisions. What is up with that?

OMG! He is finding this revelation at this late point in the game? Flags and logic, like showing errors, belong in the controller part of MVC in the first place, not in the view, which he seems to be inferring is an issue with vB5 now.*head shaking in disbelief*

Is it just me, but when I read the word "refactor" in terms of vBulletin, the hair on the back of my neck go up and I get an ugly chill down my spine.

Scott

 

It's probably me being thick but I don't understand how the op in the vBulletin thread was able to resolve the problem if he's locked out of his forum in such a fashion.

 

In vBulletin 5, the template is also a defacto page controller.

The contententry template is one of the biggest offenders, with the following entry around line 249:

Code:

<vb:comment><!-- ------------- BEGIN TEMPLATE ------------- --></vb:comment>

 

Bob had the same problem on the version he runs here
Lets hope Bob can answer his own fix on the problem

 

So vB5 is an MV system? LOL!

Scott

 

More like MC system... (model crud)

 

No, there's a controller layer in there, too. Where else would the output be printed from?

 

eval ?

 

I see what you did there.

Tihihihi.....Dats a gud wun!

Scott

 

And another security patch has been released today

Potential Security Issue Found in vBulletin Connect 5.1.2.
http://www.vbulletin.com/forum/foru...curity-issue-found-in-vbulletin-connect-5-1-2

 

Great... a privilege escalation issue.

 

This is a clear sign of an issue with dev competency, either with the system design or with programming in general. It is not a good sign and something vB doesn't need at all. But, it all seems just par for the course. A shame really.

Scott

 

excuse me but I cannot believe what I read..... excuse my strong words, warn/ban me if you like but just cannot express it other way.....

If I understand correctly there is a hole in vb5 code which allows SQL Injection attack to be performed..... how stupid one must be to produce code that allows that kind of activity? Where is testing team of IB?

Two golden rules:

1. Test your code in lab enviroment before introducing it on live-servers. The more tests performed, the better,
2. Never ever add new code to an existing code on live-server. It will always lead to disaster. Make neccessary changes on server in lab enviroment and than (if ok) upload it to live-server.

I cannot even think of uploading untested code to live-server. Its sometrhing professional programmer/coder should kniow just like people know not to touch hot things (instinct)..... Not to mention I'd be quickly out of job for uploading untested code to live-server.......but its not really that, its just that it cannot get to my mind even in the wildest dreams......

Its just the thing that professional IT staff dont do......

 

nice patch than......hihi

 

It wasn't just a SQL injection. They also had a cross site request forgery (potential privilege escalation to an admin account) and another privilege escalation here (attachment.php where you can download any attachment, bypassing the permissions model)

 

You'd be surprised, but IB does test the vB code. It's just that they obviously don't have the testing aimed at finding possible insecure code and they obviously have programmers with a lack of understanding or knowledge for secure PHP code. Now add a group of Romanians with some time on their hands and mix the three together and you have the issues you see arising now with vB5.

Scott

 

Could you explain their testing methodology Scott ?

 

My statement is based on something Allen Lin said to me some time ago that they only do black box testing and no white box testing. That might have changed, but the security issues tell a different story and thus, I stand by my statement.

Scott