that comes because Jelsoft forgot to alert the admins of the "Uninstall" process... a simple "remember that when you uninstall this product, all related information, settings and DATA will be lost." would give a great hint of the process.. .lol

We will not be sending out emails to users with the advice to 'uninstall' anymore. We will advice non-destructive methods. If we can already give a really more tailored advice at this time i am not so sure about yet.

DIE!!!!

I added an option to save or delete data when uninstalling to the latest version I released and set it to keep data by default, it's well worth doing when you're adding valuable data to the database.

Wow, just wow. So the damage to my business through the loss or compromise to data on my system through a security vulnerability you created means nothing. It's more important that your reputation be protected. Nice attitude.

And again trying to defend this position by basically saying, 'well others do it so I should be able to as well'...

That's the end user's problem not yours. As I said before you can't fix stupid. If they haven't been backing up their data, that's their fault. That aside, there is also the matter of compromised data, such as personal information being stolen, the possibility of root server accces through the vulnerability, etc.

Sorry, there is NO excuse or reasonable reasoning for not informing the end user immediately upon the discovery of a security issue.

Good to hear. Keep up the good work guys!

Please stop accusing me of ridiculous things I never said. I made an entire post (several posts) defending my position. How about you defend your position of being a jerk, now?

tss tss... calm down guys... you're going off-topic...

Yes and throughout you gave nothing resembling a sound reason for allowing the end user to remain at risk.

Please also note that while responding, by 'you' I am referring to coders that have mods available on this site. I am well aware that you (Hambil) have removed yours from this site. This isn't a direct attack on you, but on those who advocate putting users at risk when they themselves have nothing more than their reputations as coders on the line.

yes thats right!

should everbody get a mail, when in hack xx is a error? i don't think so...
why should i get extramails just because hack xyz have some unescaped variables, and i haven't heard or read something of this hack...

Feel free to discuss this topic and post your view on things, but refrain from namecalling and such, or this thread will be closed.

Please keep the discussion clean.

I believe this highlights that we need to standardize the actual message that is sent, and I agree that it should now suggest disabling rather than uninstalling - this is really something left over from the past, as before we had products, the advice of uninstalling was not really a problem as few modifications actually had an uninstall function that removed data. Now that the vb product system automates this, different advice is needed.

Thank you for supporting my suggestion Paul. I believe that this will reduce the problem by 50%. Further more I believe that all new mods must be check by Moderators before going to public. That's adds an extra security and protect end users from rubish (don't like to say "defaces"(?).

Maria

Although it would be a solution its never going to happen unless vBulletin.org hire someone, the moderators here get paid nothing and are voluntary, most:p of them have lives too and don't have enough time to check every modification.

Anyway if the person who created the script cannot spot one how do you expect someone who has never seen the script to have a better chance at finding it!

Also you have to think that if a moderator does check it and gives it the all clear and later an exploit is found and forums get comprimised, it puts alot of pressure on vBulletin.org and on the moderator, possibly legally too.


Distance

Even if it's something that many users thought, I believe that the real reason is something else than Marco wrote before ("Lots of reports lately").

In my opinion the problem came from the new moderators who came in the field like bulls in crystall shop, trying to get their first congratulations.

To be honest, I was very upset with this situation (for many reasons) but when I seen the moderator's profile, I understood many things just by seeing his photo. By the way (this is for Cordinators and Administrator), don't you think that Moderators (in other words staff) must be more carefull on choosing their photo? "Caesar's wife dosen't need just to be good. She must look good too". At least he has the 2 fingers up and not just one :D

Maria,

I do not like to be called a liar. Also my previous post on the reason of the amount of vulnerabilities found the last few days was simply the truth, please stop trying to suggest that there is anything else to it.

The vulnerabilities have been reported by regular members/coders and staff investigated each report and took action if confirmed.

I NEVER called you liar, or at least my meaning wasn't this one. I've never called anybody liar. My meaning is (with much more simple words): "There are lots of reasons. Some of them 1st priority, some other 2nd. I do believe that there were lots of reports and the staff hasn't the time to check all of them, so everyday the queue becaming bigger and bigger. So, when the new staff started on duty, they started from there. And because (here is my point) they don't have the experiance, they did mistakes.".

I apologize if you got my meaning on the bad side.

Actually, the reports started coming in AFTER the new staff were introduced.

The timing was just for refference. The main goal is that reports checked by the new unexperiant moderators. And to avoid any future misunderstanding: Unexperiant as Moderators. Maybe he is guru on vB.

We are not running behind in handling vulnerability reports. Until now we have been able to address each report within a day (more often within hours).

You can make a lot of assumptions, but unless you can provide some facts, they are nothing more then unfounded assumptions. Obfuscating a discussion with such assumptions does not lead to any constructive discussions.

PS The only time that Staff checked for unreported vulnerabilities in a modification has been when a larger number of modifications of the same author have already been reported. In that case staff might be looking into other modifications by the same author to see if there are similar vulnerabilities.

Again you are assuming that new moderators are uncapable of verifying and handling a vulnerabity report or that they have to handle such a report without the assistence of more experienced staff.

I kindly ask you to stop feeding the discussion with such unfounded acquisations.

Unfounded? If you check the vulnerability that he found in vbDigiShop is on the file finishpayment.php which is the procedure that controls 2Checkout return value. Except if you believe that 2Checkout can return an SQL query instead of a "True" or "False".

An experiant Moderator is able to understand that this file is not important. If it was on the main vbdigishop.php as it was for vbarticles.php I can understand it. But in a routine file which has nothing to do with user inputs, I dont believe that is a vulnerability.

The unfounded relates to your remarks/suggestions that newer staff members are unable to correctly judge a vulnerability report.

I will not go into a public discussion on the details of a specific report, but you are free to contact me in private to discuss if a report is founded or not. Nobody say that we never make a mistake, and if we do i will be glad to help to sort it out.

PS All i will say in public on this, is that i just personally checked on the report and other then what you claim the file contains a serious vulnerability.

One of the most important things that we should focus upon with this thread is that progress has been made and that the end product is that both the user and author will benefit by the changes

This is good

Well done to all

:up:

Although it is unlikely to happen willingly, it might happen accidently.

Do you think an attacker really cares which file he must acess to break into the system?
I doubt that. The important point is: Would it be potentially possible that the input contains anything other than the expected values?
If so, this must be handeled correctly, even if it would normally only be accessed by automatic processes.

Never ever trust user input!

There is some files not accessible by the users. In any case, I'm going off the discussion, I'm not coder any more, so this thread is not for me.

@Marco
Thank you for spending your time to check the file. I'll appreciate if you PM your remarks and I'll correct them asap as I did yesterday.

Maria

PM sent.

I think I can safely say this will not happen in the forseeable future.

Sorry but this is just totally irrelevant. A moderators picture has nothing to do with their coding knowledge, or their function on vbulletin.org.

Actually Paul, i would suggest that you never use that kind of sentence again... with the late events regarding "not happening changes" that came to be happening, i would suggest that all suggestions are taken into consideration, but not refused publically like that...

Not sure if that is such a good advice nexialys.

We can only respond with the knowledge and plans we have at the time of the reply. The best thing is to be honest, and reply that it is very unlikely or even that it will not happen in the forseeable future.

We received many complaints that we do not respond to suggestions, and now you are asking not to respond at all in public if the answer is No? That seems to be a contradiction.

it is not contradiction... Paul told us at least 4 or 5 times this week that the suggestion would never come executed... and you just posted a new thread for suggestion about our point of view - in the coders thread.... THAT is in contradiction with what Paul said to all last week...

and my suggestion is about refusing directly without anyother advice... not refusing generally.. you can refuse some suggestions, but that kind of answer is not very politically correct...

As I said in another thread - it may just be a matter of perception (god knows I have that problem, too) but those kind of responses, given how and where they were, feel like attempts to shut down discussion. Sometimes they are even accompanied by the closing of the thread.

Not trying to get this thread turned into a word game now, but:

In the above post Paul replied to the suggestion to let staff check all modifications before making them available to the public. He responded that this is unlikely to happen in the foreseeable future. (Some reasons for this reply are simple: Not enough staff to do so - we tried to setup such a thing with volunteer members performing this in the past but that did not get enough volunteers for a longer period of time - and the fact that if we "aprove" a modification we might be implicit liable for anything vulnerability that we miss)

The thread you are reffering to is on a totally different topic (advice to users in case of a found vulnerability) and we have never said (on the contrary even) that we would not reconsider the current message sent to users.

I beg your pardon? My profile or whatever you think you know about me by looking at my profile picture has absolutely nothing to do with your modifications containing a vulnerability. And if by some extremely inaccurate measure you think that I'm unqualified for this position simply because I'm younger, you're sadly mistaken.

You might also be interested to know that I am not the one who found the vulnerabilities in your modifications, I'm merely the one that confirmed their existence.

In any event, I suggest you focus more on coding according to vBulletin's standards instead of attempting to analyze someone based solely on the contents of their profile. :)

hum, interesting, now we're on personal attacks... flaming is not permitted here, so please, everybody, behave correctly, or just quit discutting...

Thank you, I'm afraid I don't think I'll be taking up that suggestion.

I'm not sure what I've said 4 or 5 times (nothing I can think of). If you are refering to site policy then you are mistaken. Asking for suggestions on how to word something is not setting site policy.

I suggst you concentrate on posting useful suggestions instead of some of the not so useful posts you seem to be making recently - and try not to engage in pointless arguments over the wording of posts (mine or anyone elses).

Couldn't agree more with this - I've certainly had my eyes opened a little to the motivations of at least one coder in this thread. I hasten to add that the majority of coders do an excellent job and do indeed think of their users first, but a minority seem to be thinking first of their wallets (or indeed purses).

Keep up the good work, vbulletin.org - it's good to know you'll let mod users know of vulnerabilities.

Consider for a second that most uninstalls remove data from the database. Now consider that you have to deal with numerous angry and confused users and explain to them that the data they spent months, perhaps years, building and collecting has just been wiped out because they acted on advice to uninstall for a problem you could have fixed in 5 minutes had you been given some advanced warning. It costs real time, and yes, if you don't work for free then real money, to deal with that mess. It's also very upsetting to the users. Beyond that, there are numerous already stated reasons to tweak the process from how it is done now, and even the staff agrees, which is why changes are being discussed.

Still, if you want to see the worst in something, or someone, then I can't stop you. As the famous quote goes: You can't use logic to argue someone out of a position they didn't use logic to get into.

None of which has anything to do with or justifies leaving the end user vulnerable.

You say it their data can get wiped out, yes it can if they haven't backed up. That's the end user's problem not yours. Then again if they get hit due to the vulnerability while waiting for a fix they can run into a lot worse problems. I have no problem with changing how the user is notified and what they are told, it's a good idea. But it's never a good idea to leave them vulnerable. I mean how long is an adequate time to wait? What happens if the coder doesn't get the message about the vulnerability immediately because they are away from their computer, out of town, asleep, can't be bothered to update the code, etc? The end user is forced to remain at risk which is unacceptable.

This sounds like the most logical solution for both sides.

After reading this thread, I don't know who on this site to trust as an actual programmer. I know that anything that Kirby or Paul or Princeston (and a select few others) programs/writes/codes, I would trust, but beyond that, I don't know whether they are some noob/novice that learned how to hack a php script and accidently got it working without any real knowledge of how it works, but released it as a hack/product or whether the individual actually knows php, does it for a living (not a hobby) and cares about the script itself and not the acolades that may or may not come with it....

As a professional programmer and database admin, it disgusts me to see people that call themselves programmers want to keep a known vulnerability from an end user/client. There is NOTHING, not a darn thing positive about this at all and is totally unprofessional. Its your responsibility when you release code to an end user/client to also protect that client from any harm by insuring that your code is to standard and does not have any potentially harmful vulnerabilities. If you don't know what you are doing and don't care, then don't pretend you do by releasing code to the public. Another part of being a programmer is to notify them ASAP of any known or posible vulnerabilities, ensure them that you are currently working on the issue(s), give them recommendations, ie, remove the hack until its fixed, continue to use the hack/code/product but inform them of what may or may not happen,(leave the option to the end user to make the decision to remove it or disable it) and get them the fix ASAP.

Most programmers and end users/clients understand that you don't want to publish what the vulnerability actually is, cause hackers search for that stuff and then can easily do more damage.... But to sit here and argu that withholding information from an end user/client about a vulnerability is good practice is beyond me. Im certainly adding this topic to my hiring check list that I use to interview potential programmers. I have and probably will in the future fire someone over this unprofessional practice. I can not believe what I've read in this thread.

Its too bad that there are not more members that REALLY care (not pretend they do) about their product. Seems like this place is getting over run by novice hackers (I can't and won't call them programmers).

I keep reading comments about the loss of data due to uninstalls, well, that goes back to the programmer getting off his back side and giving the recommendation to the client on how to prevent that from happening while a fix/solution is being worked on. This should be included in the first post when releasing a hack/script/module/product. Anyone that has been a professional programmer knows that IT departments (good ones) have what are called disaster and recovery plans. When you release a product, you also have steps on how to deal with vulnerabilities, data loss prevention, down time, recovery, disabling, removing, etc etc etc ... I can't believe I even have to bring that up.

Recommendations:

I recommend that the wording that is sent out to members that have installed a hack that is found to contain a vunerability be changed slightly (which I think Paul has already mentioned that it would be)....

1) I would not use the word "Uninstall" as the first course of action.

2) I would inform the end user of several courses of action that they can take, not just to uninstall.

3) I would recommend that the end user contact the author of the thread for further guidance by first reading the thread to see if the author has posted how to deal with vulnerabilties or if the author has posted about the reported vulnerability.

4) I would assign one of the staff members to monitor the situation of the vulnerability. This would entale the staff member working with the author to ensure that a solution is being worked on or if the author has no desire come up with a solution. This way the staff member could then tag the thread as being abandon and vBorg could inform members that no solution to the vulnerability is being worked on by the author. They could then choose to fix it themselves giving the members a solution or they could inform the members that nothing will be done and the thread locked. On the other side, they could assist the author if the author requests it.

5) I would recommend that authors include procedures on how to deal with potential vulnerabilities within the release of the product.

6) I would recommend that an article be written by one of your better writers on how to deal with vulnerabilties (to prevent the loss of important data particularly). A link to this article would be included in the email sent to the end users.

5) PLEASE DO NOT stop informing members of vulnerabilties!

Anyway, I hope that the vBorg staff continues to notify members of vulnerabilities of hacks published on this site, cause god knows, some of the authors of these hacks certainly don't care and won't.