to be absolutely honest, if were not for vb.org and the various hacks then vbulletin would be simply another set of forums

@marco

adding fuel to fire should be left to trolls ;)


thanks jammiegirl for a level headed approach

:D

as mentioned hopefully this can be avoided in the future

I'm sorry...I used the term "defaced" in my post, not realizing you did not know. Defacing is a very bad thing...
Oh, you're absolutely right! Even though I'm through modifying my own board (I think), I still love coming here to see the new mods. But seeing good mods end up in The Graveyard makes me sad.:(

You're welcome...I try!:D Hehe...you called me "jammiegirl"...how cute!:D

Been here, had this argument, lost it, and that's why my hacks are no longer available here either. Glad to see I'm not alone in feeling this way, though :)

What Jelsoft do is not relevant - they own and write vbulletin, so they simply fix any exploits and advise you to upgrade.

vbulletin.org do not own/control/write the modifications so they advise you to uninstall - whether you take that advice is entirely up to you.

Wouldn't it be much better for the people involved to do this:

1) Modification is reported with an exploit and it is verified.

2) Staff member puts a "Exploit found" flag on the modification. Within a notes field, the staff member can document the exploit and add any other necessary comments. When they save it, an email is fired off to the Author(s) of the addon.

3) The flag above also puts a notice on the addon and prohibits new users from downloading it until a new version is uploaded by the author. People who have already marked it as installed can still download it but a warning is shown on the first post in nice bright, eye-catching letters. This could also send the email out to users who have installed it. The text of which could be modified to something like:


4) Staff looks at new version, if okay then flag is removed and everyone goes about their merry business.

This would prevent moving addons to the "graveyard", give authors time to fix the problem and not make the exploit available to new users. Current customers can continue to get support. Addon authors keep their work and such and less work overall for the staff here. Seems likes it would be win-win-win all-around.

It seems most of this system is in place. Just a little different way of handling it

For what it's worth, I would fully support this. Thanks Wayne.

That would be much better but as the author I still want to have the opportunity to FIX the issue and send the security issue message at the SAME TIME. Rather than leaving users waiting for a fix! If I don't update it yeh sure send the message but the opportunity needs to be there.

i think wayne should be running things here because his ideas make alot more sense than whats happening right now

Please leave the install .txt file on graveyarded modifications and a list of files that would have been added to the server and their location.

If it's a file that causes the problem, then by removing the plugin only will not stop the risk, IMO.

This is true. Not all products 'disable' the way they should - especially if they contain file edits or template edits. Good point.

i have just ran into a problem uninstalling one in the graveyard, i uninstalled but it left a graphic behind that now i cannot find how to remove, searching for it in templates does not find it and the thread is locked so i cant ask questions and its a hack so vB.com wont support my problem

come on vB.org, this was not thought through :confused:

Not my job. The people in charge here are more than capable. The system just seems to need some refinement and I am sure they can do that. I am just putting in a suggestion as a user of the site.

In the meantime while they are waiting for you to fix the problem, upload the update, and verify that it corrects the security issue, everyone who has the mod on their site is sitting vulnerable. By sending the emails out immediately the end user now is aware that there is a security issue and can decide for themselves whether or not to remove the mod until it is fixed.

@quiklink;

ok, so WILL you uninstall vbulletin if it had a security issue? yes or no? will you uninstall a hack or no? please don't answer! Why don't Jeloft inform me about security issues when discovered but only when they have published the fix?

Do you feel the same way about vbulletin as a standalone product?

You have to understand the issue was reported privately hence no one knows about it (or very few) so the author has the opportunity to fix it and tell users at the same time. Now if someone made the security issue public, fair enough you would inform as many users as possible, since someone will now try to exploit the issue no doubt.

Now if you ask users to uninstall mods, e.g. if you had articles mod, six months later there is a security issue, by now the site might have plenty of articles etc and on uninstall everything will be lost, would you want that? you have to understand not everyone is technically minded or even simple things like uninstalling or disabling would mean the same thing to them...

as always there are pro/cons to every procedure.

While owned by Jelsoft, this site has nothing to do with security on vBulletin. I keep seeing many make this comparison and it doesn't wash, not to mention the liability issue to Jelsoft should they know of a vulnerability in a mod and not make it known. It's one thing to have a liability on your own product, it's quite another to assume potential liability on a 3rd party product. And regardless of what Jelsoft does with it's own products, what YOU are doing is advocating allowing the end users to remain vulnerable for a security issue you created.

Jelsoft's practices have no bearing on this discussion because these are not Jelsoft mods.

Obviously at least one person knows of the vulnerability, there quite possibly could be many others who are choosing to exploit the vulnerability rather than announce it. Again, you advocate allowing this to happen.

It's up the the end user to make that decision. You have no right to make it for them and you have a responsibility to inform them of the vulnerability immediately so that they may protect themselves from harm through code you produced.


There is no pro to your argument. Only cons, and the con is to the end user you want to keep at risk to protect your own reputation.

Have I said Jelsoft should be held reposible for anything made by 3rd party, where SHOW ME! Jelsoft choose not to inform users when they discover a security issue but only and as quickly as the release the fix.

So its fine for Jelsoft not to inform its users but not me? you don't seem to make sense, you are asking me to inform all my hack users, then why not Jelsoft?

who said it does? so you like Jelsoft practices but not mine, its a shame that the practices are exactly the same! yet you see a difference? I wan't to try and make sure when I inform users of a security issue I issue the fix at the same time, if I am unable to fix its fair to say I should inform them with 24 hours IF i can't fix it!

the same again applies with every script out there not matter who creates it, if no one reports a security issue, it won't be fixed. Remember the user reporting has done so in good faith so the issue can be fixed, no doubt there are users who won't report it and rather take advantage. Ones a issue becomes public it becomes a race to get the fix out before even more users are able to take advantage. Now the minority has become the majority. And now there's more pressure on the mod creator.

Wait so Jelsoft have the right to make the decision for you and I don't? why not me? Wheres my right? So you trust Jelsoft more than the coders here.

wait don't Jelsoft do that?

I'm sorry for using Jelsoft as a example I'm sure theres more out there.

Jelsoft has made it abundantly clear they have no liability for any mods on this site, period.

@Sniper: I'd focus your arguments on staff and not get sidetracked by posts from members, for what my opinion is worth :)

thanks will do :)

its a shame there are narrow minded people out there...doh.

damn Wayne, it's time to drop that user title then.. lol..

So because Jelsoft follows such a practice that makes it ok for you to do so?

We aren't talking about Jelsoft, though you keep trying to use them as your defense. So again you advocate leaving the end user and their customers vulnerable to cover your own reputation. Nice.

You have no idea if the exploit has already been know by others and is only now being reported by a responsible person. But apparently the risk to the people who are using your mods means nothing to you save what it means to your reputation should it be found out that your mod has a security flaw.

Again, quit trying to use Jelsoft's practices as an excuse for your own. If you or I have an issue with how Jelsoft handles security for vBulletin it belongs over at the vb.com site, not here. We are talking about security risks in the mods available here.

That means absolutely nothing and would not prevent Jelsoft from being drug into court should someone decide to sue them over a vulnerability in a mod obtained from here. It also does not necessarily mean they will win either, particularly if they were aware of a security vulnerability in a given mod and allowed it to continue to be available and did not warn those who had it installed.

So the opinions of the users of these mods doesn't matter? Guess I should have already realized that from those coders who are condoning leaving the users vulnerable because announcing a flaw in their code might hurt their reputations.

I've been programming for better than 20 years and I'm quite aware that stuff happens and vulnerabilities occur. It's a fact of life when programming. What I have an issue with are those coders who are willing to leave their users hanging and at risk rather than notify them immediately of the risk and then working to get a fix out as fast as possible. That's just plain irresponsible. I have a lot more respect for the coder who thinks of their users first and their reputations second.

Feel free to have all the opinions you want. Have an opinion party. How much they count really depends on the opinion, and how well you express it.

You were defending Jelsoft policy. Since you don't work for them, doing much more than noting your opinion on the subject and moving on, isn't very productive to the discussion.

Yep I am defending not leaving the mod users at risk. Sorry if that seems to be a strange or unpopular choice. Where I learned programming we try to watch out for our customers rather than leave them vulnerable to attack.

I have yet to see a reasonable justification for leaving the mod users vulnerable to attack.

I've given several.

1) Calling attention to a vulnerability before a fix is available actually increases the risk to the end-user.
2) Not giving clear instructions, but simply saying 'disable' or 'uninstall' will likely not remove the vulnerability is many cases, since file edits and template edits may have been made.
3) Sending these notices out over and over again, as is starting to happen now, creates an atmosphere in which the users will simply begin to ignore them, once again increasing their risk.

Now, if a fix is not provided by the author within a reasonable time frame, then pulling the hack and notifying the users is the only logical choice. But, it is not the best choice as a first line of defense.

There are reasons why Jelsoft and other companies don't operate that way. It is logical to assume they don't want to harm their customers because that's bad for business. So to believe that the policy being used here is the correct policy, you have to believe that everyone else in the industry got it wrong.

That's not a good reason. They are still vulnerable to the attack. You don't know exactly how widespread the problem is before being finally notified about it. And are these notices detailing exactly how the exploit is occurring?

Template edits aren't usually going to be a security issue. File edits yes I agree would. While detailed removal instructions would be good, it would be difficult for vborg to give such instructions for every mod. I agree that in the graveyard the info for proper removal/uninstall should be left so that the user can get that info if they don't already have it.

That's the end user's problem. You can't fix stupid.

What exactly is a reasonable time frame for leaving a user vulnerable? Answer: No time, they should be informed immediately. Are you willing to accept the responsibility and liability for any damage or theft of information because you didn't announce the vulnerability when you first learned about it? No I thought not...But believe it or not, an end-user could quite easily decide to haul you into court for doing just that. You can post all the disclaimers in the world and it doesn't protect you.

Everyone in the industry certainly does not do this. In fact, with most major applications the vulnerabilities are posted immediately on known sites to get the information out as fast as possible. This is often how the developers learn about the vulnerabilities in their own code in the first place.

Sorry but all I am seeing from this is an attempt by the mod developers to cover their reputations at the risk and expense of the user.

Well, you're wrong on pretty much all accounts, but hey, free speech man.

That's right, some hacks also have a seperate install funtion as well as the plugin which means that if you remove it via the plugin without doing the product uninstall via the product itself, the template and DB edits, etc. are still there and you can't re-download the files.

If a hack is marked as a security risk, the files should still be left so people can deal with the above issues. If they install it to use normally, that's their own bloody fault as they don't read or listen to the risks.

Can someone from vB.org please let me know if this will be possible?

If news of an exploit has been made public (by whatever route) and the modification moved to the GY, then the files will no longer be downloadable. This means all files in the thread, we cannot seperate out individual files because they happen to be instructions - in most cases there is only one zip file anyway (containing everything).

then you are just informing people of a risk but not letting them have all the tools they may need to eliminate it? infact making their vB installation more vurnerable!

Well, they are advised to disable/uninstall it. If they don't do that, it's their problem really.
IMHO it's better to inform users imediately rather than having them run vulnerable code without knowing.
If they know, they can take appropriate actions - if they don't they cant.

As a user of a lot of modifications on this site, I say that we should be warned of the problem with a modification as soon as the problem is highlighted. If we then opt to still use the affected modification and something happens to our site then this is our problem but if we disable or remove it then we know that we are safe.

Imagine for a minute that you buy a tin of beans from a shop. Now the next day the manufactorer finds that a bit has broke off the machine. They check the batch numbers of the beans produced since the last known time that the piece was there and then issue a recall notice with the product, description, and batch details and tell you not to eat them.

Now in the same way, vB.org has told us about the product and the version that is affected by security issues. This is something that needs to be done right away. Proper testing of modifications before they are released to the trusting non-coders should be done by the coders to make sure that this doesn't happen, although there will always be some that get through anyway.

Coders then can fix the problem, or not, as they decide while the people using the modification can see it, or not, at their own risk as they are aware that there is an issue.

Really it's like everything - if you know something is dangerous would you still do it? If going down a mountain do you take the path, the cable car or jump from the top? If you opt for the cablecar then find out that the cable is frayed, would you still use it while waiting for it to be fixed?

But those examples aren't like 'everything'. They are life and death. Anytime something is a matter of life and death companies always immediately inform everyone (let's not get into automobile recalls that are not done or delayed - yes companies make evil decision, too but as a rule in life and death people are immediately informed).

Nothing on this site will kill you.

But it might kill the data that took you years to get on your site.....

but it will cause hardship .. many members devote hours to their sites - in some cases this is their livelihood that we our dealing with.

Our priority is to protect our members.

Can we find a balance between protecting members and making our coders happy?
We are discussing the matter.

I would like to hear more SOLUTIONS - instead of what's better and for whom it should favor. Who knows .. it may be something we haven't thought about.

well have you considered the FACT instructing users to uninstall a mod would do the same thing, not everyone backups their data or knows that on on uninstalling the mod it would remove the related database tables. Now the mod could be a gallery or a article system etc

One of the improvements we are currently discussing (and i think this has already been mentioned in this thread) is if we can give a more tailored advice based on the type of vulnerability and the modification in question to the users. This might however not be possible as we can not be aware of all the ins and outs of a modification and how to block only access to vulnerable locations in the modification.

<i>This is just my opinion, but I think the current solution is acceptable.</i>

asking users to disable is fair enough but no doubt the same doesn't apply to hacks which require file uploads as mentioned before.

I would rather, considering the mods are are aware of the issue, when sending out the email suggest a temp fix.

e.g. The vulnerability has been discovered for hack xx, in order to fix the the vulnerability please follow these steps (write steps) or disable the product and wait for the author to upload the fixed version.

I can understand it would not be possible if there are many locations within the code but if its only two or three, it isnt much work.

Suggestion:

1. If it's a plugin only modification and the vulnerbilitie lies in the code or added templates, advise users to disable it
2. If it's a vulnerbilitie in a template modification that would still exist if all plugins are disable, advise users to revert the template(s)
3. If the vulnerbilitie lies in added files, advise users to disable the modification and delete all files added by the modification
4. If the vulnerbilitie lies in code added/modified in vBulletin files, advise users to overwrite files with the original ones

This way, it should be possible to protect users whil keeping them from loosing data.
Though, this provides more information about the type of vulnerbilitie - information that could be abused for searching the vulnerbilitie and exploiting it.

MY SOLUTION: a PR technician...

one of the guys upthere is reserved for community/coders contacts... that person is the one to contact coders when something goes wrong with any code, that person also is the one moderating these releases when things go wrong...

if the author can't be reached, the hack is stored and members alerted.

if the author is reached, the PR guy is the one to contact the coder, in the minute a exploit/problem is found, and if a solution come, they all update the release... i would suggest 24 hours, but as said earlier, usually when an exploit is found the solution came with it... we all know how to code here!...

there is 2 switches actually:

1- problem fixed: we alert everybody who have downloaded the hack to update
2- problem not fixed / author unreached: we alert everybody who download to disable the tool

it's just a question of what to say to everybody... not only the ones who clicked the INSTALL button... i never click these, and i downloaded most of the hacks released here... maybe i would miss the alert.

when Ford have to recall the entire line of a car, they do not contact only the persons who signed a newsletter, they contact all the buyers, and even make an announcement in the News...

A first step is to inform members to Disable a product and not to uninstall it. Most members don't know that by uninstalling it they're loosing their data. I realized it from a huge amount of emails that I got from members asking me (but after uninstallation) if they lost their data.