[FIXED][3] Bug 2.2.9-prior [Moderate]: Email validation not applied to certain users

[Paul]

Hello,

Below you will find a report of a suspected issue with vBulletin. In order to clearly identify and troubleshoot issues which we believe to affect this product, bug/vulnerability reports from us will be delivered in this fashion.


Known affected versions: Tested on vB 2.2.9. May affect all versions prior.
Synopsis:

When a registered user modifies his or her e-mail address via the User Control Panel and the "Verify E-mail address in registration" option is set to "yes" in the Administrator Control Panel, vBulletin moves the user into the "Users Awaiting E-mail Confirmation" user group and requires that the registered user reactivate his/her account by clicking on a link that is e-mailed to the user. vBulletin will not require users outside of the "Registered" or "Users Awaiting E-mail Confirmation" user groups to revalidate their account and will therefore accept any e-mail address. This, for illustrative purposes only, could be used for various denial of service attacks, unsolicitied e-mail harassment, and accidental disclosure of sensitive information. Desired behavior would be at the very least that all users, regardless of usergroup, be forced to revalidate their account. We recommend that a separate user group value be added to make e-mail validation a per-user group option.


Severity: Moderate


Mitigating Factors: Administrator must have "Validate E-mail address in registration" set to "Yes." Forum installations that do not require e-mail validation are not affected by this issue. Only users in usergroups other than "Registered" and "Users Awaiting E-mail Confirmation" (specifically, usergroupids "2" and "3") can exploit this vulnerability.Steps to reproduce:

Save.
How this affects your end-users:
While, arguably, it may be a good idea to require Moderators, Super Moderators, and even Administrators to validate their e-mail address once changed, in most cases this is probably not a very large concern. Administrators who have not defined any custom usergroups fall into this category and will need to assess their own vulnerability to this issue. Administrators that have added additional user groups beyond those included in the default installation of vBulletin, may or may not, depending on the users and permissions set for the additional user groups, be at a higher level of risk for users exploiting this vulnerability. Since we do not know how common it is for administrators to specify custom usergroups for their users, we have given this issue a "Moderate" rating. It is our educated guess that most installations of vBulletin will have the majority of registered users set to usergroupids 2 and 3. Theoretically, from what we know about user group permissions in vBulletin 3.x, this should not be an issue for 3.x installations.
Recommendations: There is no recommended fix at the time of this posting. One may appear from us in the near future, but only if Jelsoft classifies this as a bug. Otherwise, a hack will be posted at vBulletin.org that produces the desired, and what we believe to be expected, result. Administrators are advised to apply any sanctioned fixes offered by Jelsoft if and when they become available. Always remember to backup your databases and files before making any code modifications. Administrators are advised to limited the amount of users that belong to usergroups other than "Registered" and "Users Awaiting Email Confirmation" and and that those with custom usergroups pay close attention to the e-mail addresses of users within any other groups, custom or otherwise. We believe that e-mail validation, as it appears in vBulletin 2.x should be applied as an administrator-definable per-user group setting--that when creating or modifying a user group, the administrator should have the ability to define whether or not users in the user group should be subjected to e-mail verification, if enabled on the forum. Hard-coding usergroupids should be avoided as often as possible.
What we're doing: We have released this notification to the vBulletin.com community shortly after the issue was known to us. As this issue is difficult to "exploit" and requires specific permissions, we do not consider it sensitive and have not provided Jelsoft with advanced notification via their support contact. We will work with Jelsoft to provide any additional information requested as it becomes available to us. We will work with users within the context of this thread to provide limited assistance with this issue.Regards,
Paul

[ccd1]

Thank you for making that fifteen times longer than it needed to be :

[Paul]

Originally posted by baragon0
Thank you for making that fifteen times longer than it needed to be : I suppose we could have increased the font size? ;)

We want to make sure that when take the time to research vulnerabilities, Jelsoft has a complete understanding of we've found.

It is our experience that all too often not enough information is supplied to make a timely determination if there is a problem with vBulletin's code.

Should you have any other comments on our posts that do not reflect the reported issue itself, please feel free to send a private message.

Best wishes,
Paul

[ccd1]

Originally posted by LoveShack
I suppose we could have increased the font size? ;)

We want to make sure that when take the time to research vulnerabilities, Jelsoft has a complete understanding of we've found.

It is our experience that all too often not enough information is supplied to make a timely determination if there is a problem with vBulletin's code.

Should you have any other comments on our posts that do not reflect the reported issue itself, please feel free to send a private message.

Best wishes,
Paul

The point is that you repeated the exact same thing over and over to the point where it became too hard to follow what the real bug was and for other uses to identify and apply a fix themselves until Jelsoft releases a fix :)

[Paul]

Originally posted by baragon0
The point is that you repeated the exact same thing over and over to the point where it became too hard to follow what the real bug was and for other uses to identify and apply a fix themselves until Jelsoft releases a fix :) The issue involves more than changing a few lines of code. The fix would require modifications to the database structure which we don't feel comfortable publishing before Jelsoft comments.

Note that once a user changes their e-mail address, they are put into usergroupid "3". Upon reactivating their account, they'd be put into usergroupid "2". There needs to be a way to store the previous usergroupid on a per-user basis when changing e-mail addresses and a way to flag whether or not the usergroup should be subjected to verification emails.

There's no quick workaround that will fix all the problems associated with this issue without modifying the structure of the database or losing functionality (you could simply force users to e-mail you directly to change their e-mail address). We do not feel comfortable suggesting that users modify their database structure without comment from the author of this software.

Best wishes,
Paul

P.S. -- It's bed time. I spent all day shoveling snow. Leave me alone. ;)

[Steve Machol]

Confirmed. Moved to Bugs.

[Ken 01-Cobra]

Originally posted by baragon0
The point is that you repeated the exact same thing over and over to the point where it became too hard to follow what the real bug was and for other uses to identify and apply a fix themselves until Jelsoft releases a fix :)
Nope...as a coder, I wish ALL bugs/wierdnesses/unexpected results would be reported just as they report them! As a matter of fact, I think it should be required!! ;) It is SO much easier than

"I did something and the software broke"
"What did you do?"
"I don't remember, but it wasn't wierd or anything."
"In what way did the software break?"
"It didn't do what I wanted it to do."
"What were you expecting it to do?"
"Something other than what it did! When can I expect a fix?"

Best Regards,

[Erwin]

LoveShack, you did a fine job with your report. :) Good work. Ignore the non-constructive criticisms.

[Freddie Bingham]

Originally posted by Erwin
LoveShack, you did a fine job with your report. :) Good work. Ignore the non-constructive criticisms. It is also not appropriate for outside entities to post bug fixes because (a) it is modifying the source code, which we don't support because it gives the appearance that we support the suggested code changes. If you have suggested changes they should be emailed to support and not posted on the forums.

[ccd1]

Originally posted by freddie
It is also not appropriate for outside entities to post bug fixes because (a) it is modifying the source code, which we don't support because it gives the appearance that we support the suggested code changes. If you have suggested changes they should be emailed to support and not posted on the forums.

Not what I meant. What I meant was why post:

There seems to be a problem with vBulletin. The problem is in line 242 of file.php. This can easily be fixed. Jelsoft is being notified.

Problem:

line 242 is wrong

Solution: Notify Jelsoft

The error on line 242 shouldn't be that bad, but notifying Jelsoft should make them release a fix.

Why not just say:

I found a potential bug on line 242 on file.php. Is this a bug?

I think this is more constructive criticism than just a "Good job".

[Scott MacVicar]

Originally posted by LoveShack
Hello,

Below you will find a report of a suspected issue with vBulletin. In order to clearly identify and troubleshoot issues which we believe to affect this product, bug/vulnerability reports from us will be delivered in this fashion.


Known affected versions:
Tested on vB 2.2.9. May affect all versions prior.

Synopsis:

When a registered user modifies his or her e-mail address via the User Control Panel and the "Verify E-mail address in registration" option is set to "yes" in the Administrator Control Panel, vBulletin moves the user into the "Users Awaiting E-mail Confirmation" user group and requires that the registered user reactivate his/her account by clicking on a link that is e-mailed to the user. vBulletin will not require users outside of the "Registered" or "Users Awaiting E-mail Confirmation" user groups to revalidate their account and will therefore accept any e-mail address. This, for illustrative purposes only, could be used for various denial of service attacks, unsolicitied e-mail harassment, and accidental disclosure of sensitive information. Desired behavior would be at the very least that all users, regardless of usergroup, be forced to revalidate their account. We recommend that a separate user group value be added to make e-mail validation a per-user group option.


Severity: Moderate


Mitigating Factors:
Administrator must have "Validate E-mail address in registration" set to "Yes." Forum installations that do not require e-mail validation are not affected by this issue. Only users in usergroups other than "Registered" and "Users Awaiting E-mail Confirmation" (specifically, usergroupids "2" and "3") can exploit this vulnerability.
Steps to reproduce:
Log into the Admin Control Panel Add a new temporary user for testing purposes called 'testuser.' Put this user in any usergroup other than "Registered" or "Users Awaiting E-mail Confirmation." Log out of the Admin Control Panel and log in via the forum as 'testuser.' Click on "user cp." Click on "edit profile." Change the e-mail address. Save.

How this affects your end-users:
While, arguably, it may be a good idea to require Moderators, Super Moderators, and even Administrators to validate their e-mail address once changed, in most cases this is probably not a very large concern. Administrators who have not defined any custom usergroups fall into this category and will need to assess their own vulnerability to this issue. Administrators that have added additional user groups beyond those included in the default installation of vBulletin, may or may not, depending on the users and permissions set for the additional user groups, be at a higher level of risk for users exploiting this vulnerability. Since we do not know how common it is for administrators to specify custom usergroups for their users, we have given this issue a "Moderate" rating. It is our educated guess that most installations of vBulletin will have the majority of registered users set to usergroupids 2 and 3. Theoretically, from what we know about user group permissions in vBulletin 3.x, this should not be an issue for 3.x installations.

Recommendations:
There is no recommended fix at the time of this posting. One may appear from us in the near future, but only if Jelsoft classifies this as a bug. Otherwise, a hack will be posted at vBulletin.org that produces the desired, and what we believe to be expected, result. Administrators are advised to apply any sanctioned fixes offered by Jelsoft if and when they become available. Always remember to backup your databases and files before making any code modifications. Administrators are advised to limited the amount of users that belong to usergroups other than "Registered" and "Users Awaiting Email Confirmation" and and that those with custom usergroups pay close attention to the e-mail addresses of users within any other groups, custom or otherwise. We believe that e-mail validation, as it appears in vBulletin 2.x should be applied as an administrator-definable per-user group setting--that when creating or modifying a user group, the administrator should have the ability to define whether or not users in the user group should be subjected to e-mail verification, if enabled on the forum. Hard-coding usergroupids should be avoided as often as possible.

What LoveShack.org's Web Development Team is doing:
We have released this notification to the vBulletin.com community shortly after the issue was known to us. As this issue is difficult to "exploit" and requires specific permissions, we do not consider it sensitive and have not provided Jelsoft with advanced notification via their support contact. We will work with Jelsoft to provide any additional information requested as it becomes available to us. We will work with users within the context of this thread to provide limited assistance with this issue.Regards,
LoveShack.org Web Development Team I get a headache trying to take that entire post in. Its also not a good idea to post such a lengthy documentation, in the event of the security hole a precise description would explain how to exploit it.

The bug is that it ends up usergroup specific and not dynamic like it should be?
I also fail to see the possible Denial Of Service attack that could result from not activating an email address.

[Stadler]

How about adding a bug tracker like Bugzilla (http://www.bugzilla.org/)? Every bug report could contain lots of information, but it would still be easy to follow all information every bug report contains.

[Reverend]

Surely giving out such graphic details of potential security issues/bugs is a security risk in itself.
Why can't you just post the bug in simple terms,and then follow it up with a possible fix,instead of posting ridiculously long threads that i'm sure most members get confused reading. :mad:

[Chris M]

Originally posted by Reverend
Surely giving out such graphic details of potential security issues/bugs is a security risk in itself.
Why can't you just post the bug in simple terms,and then follow it up with a possible fix,instead of posting ridiculously long threads that i'm sure most members get confused reading. :mad: It isnt confusing...

I just dont understand why Loveshack would want Moderators, Super Moderators and Administrators to be moved from their usergroup for a Email Validation? Surely that is illogical?

Satan

[Paul]

I'm sorry for the delayed reply. For some reason we didn't get any e-mail notifications about new posts made to this thread.

Ken and Erwin: Thank you.

freddie: Which is precisely why there is no suggested fix posted here. However, if someone says "No, this isn't a bug--don't worry about it.. when vB3 is released next May it won't even be an issue" we'll be responsible enough to provide a workaround on vbulletin.org. I'll start privately e-mailing suggested code fixes to Jelsoft when Jelsoft starts mailing me paychecks. ;)

Baragon0: Feel free to contact me directly via PM if you'd wish to further discuss the reasons for providing as detailed an explanation as we could. I will reitterate that this problem relates to the structure of the database and the code. There is no simple code modification that can be applied here to fix this problem without breaking the feature even further. Rest assured that if this involved adding a missing brace to the end of a line of code, that we wouldn't have gone through so much trouble posting.

Scott MacVicar: You do the math: Users that can get e-mail notification on whatever their little hearts desire sent to any e-mail address they choose without them having to validate that they're the recipients. Is there some sort of thread subscription limit that I'm not aware of? Again, we felt this was of "moderate" concern. No one knows how exactly custom usergroups are being used on other sites nor what policies administrators employ when putting users in those usergroups, however the possibility exists.

Stadler: I agree 110%! Something like bugzilla would be terrific here. I think too many posts are overlooked using the forum for bug reporting.

Reverend: The problem described in the original post is not one that we consider to be severe. We explained that reasoning in the original disclosure. We believe that our post:
Provides enough information to developers that they know exactly what the problem is and how to go about fixing it. Provides end-users enough information on how they can prevent being affected by this issue until the developers can provide a fix.We were also careful to point this out in the original post. Our post was not "graphic" at all. I believe that our actions were responsible. If you're upset that there hasn't been a fix provided yet, you'll need to take that up with Jelsoft. We have limited time to work with and we can't take up the responsibility of creating, debugging, and posting bug fixes that won't even be supported by Jelsoft. vBulletin is not a collaborative open-source project.

hellsatan: I think you may have misunderstood a post of mine. I don't know where you got the idea that we think users should be moved out of their usergroups. I did specify earlier in response to a comment by baragon0 that the fix would involve database changes to prevent users in usergroups other than 2 and 3 from being moved into the Registered group after validating so that the original value could somehow be stored once the address was validated. You're pointing out precisely why this can't be fixed by adding a few numbers into the code and why it requires schema changes to the database. You're also pointing out why us providing a fix here is illogical. :)


The issue involves more than changing a few lines of code. The fix would require modifications to the database structure which we don't feel comfortable publishing before Jelsoft comments.

Note that once a user changes their e-mail address, they are put into usergroupid "3". Upon reactivating their account, they'd be put into usergroupid "2". There needs to be a way to store the previous usergroupid on a per-user basis when changing e-mail addresses and a way to flag whether or not the usergroup should be subjected to verification emails.

There's no quick workaround that will fix all the problems associated with this issue without modifying the structure of the database or losing functionality (you could simply force users to e-mail you directly to change their e-mail address). We do not feel comfortable suggesting that users modify their database structure without comment from the author of this software.

If you mean why move moderators into usergroup 3 at all if they change their e-mail address, then that's a whole seperate issue that the developers will need to take a look at when working on a fix. We stated in our original post that we did not think that this alone would be a problem for most administrators--after all, moderators are supposedly trusted users. The real problem here involves custom usergroups.

Best wishes,
Paul

[DWZ]

Originally posted by LoveShack
Stadler: I agree 110%! Something like bugzilla would be terrific here. I think too many posts are overlooked using the forum for bug reporting.Problem with that is a lot of users call things "bugs" when they are simple configuration errors.

i.e. "I found a bug, no one can send email on my board" answer: "Enable it in your admin cp".

If it was some how restricted to the more knowledgeable users it may be OK, but I mean, that isn't very affective for when a new user finds a legitimate bug.

[Erwin]

The fact that a thread is in this forum means a vB staff member has checked and confirmed that this is a true bug.

[ccd1]

Originally posted by Erwin
The fact that a thread is in this forum means a vB staff member has checked and confirmed that this is a true bug.

Yes, and a sophisticated tracking system like Bugzilla isn't needed for a dozen bugs.

[Paul]

Originally posted by Erwin
The fact that a thread is in this forum means a vB staff member has checked and confirmed that this is a true bug.

Actually, threads are traditionally moved into the Bugs forums when a member of vBulletin's support staff verifies that the problem is not something along the lines of a configuration issue. The prefix "[Bug]" has traditionally been added to threads that are verified as a bug by the vBulletin developers. The prefix "[Fixed]" is added once code has been committed to CVS which incorporates a fix for the issue. This fix will then appear in the next release.

You'll note that many threads in the Bugs forums have been prefixed with something like "[not a bug]" or "[design issue]"--clearly these are not bugs.

I would hold off declaring this a "true bug" until such a modification to the title is made. :) We certainly are.

Best wishes,
Paul

[Steve Machol]

I originally moved this to the Bugs forum after duplicating the problem. I was just too busy at the time to post about it. Didn't realize this would develop into a controversy all its own. ;)

[Erwin]

Originally posted by Steve Machol
I originally moved this to the Bugs forum after duplicating the problem. I was just too busy at the time to post about it. Didn't realize this would develop into a controversy all its own. ;) LOL! ;)

[Scott MacVicar]

I was wondering if this is an acceptable fix.

Only allowing usergroups 5,6,7 be exempt from the check.

This is the mods / supermods and admin groups.

[Paul]

Originally posted by Scott MacVicar
I was wondering if this is an acceptable fix.

Only allowing usergroups 5,6,7 be exempt from the check.

This is the mods / supermods and admin groups.

No.

Scenario: User is in custom usergroup 9. User changes e-mail. Moved to "Users awaiting confirmation." E-mail is validated. User gets put in usergroup "Registered". Usergroup "Registered" != usergroup 9.

You have to store the prior usergroup in a new field in the database and put the user back in the appropriate group once the e-mail is verified. This, I believe, would be the simplest way to fix this problem without rewriting usergroups in 2.x (which, to my understanding, have been overhauled in vB3).

Best wishes,
Paul

[Scott MacVicar]

bump so i remember to do this tommorow.

[exTracT]

Love shack, I think you did a great job reporting it. You included all the information needed so people shouldnt have to ask any questions on it.

People would understand if they had to listen to people say things all day like.

"My computer doesnt Work"

you reported the bug right, dont let anyone tell you otherwise.

Peace.