[fixed] Users > Find > [email password]

[Byron]

From Control Panel

Users > Find > [email password]

[email password] opens a new browser with a blank screen.
Also did not send any email.

[Chris Schreiber]

Yes this did the same thing for me, I'm moving this into bugs for further research.

[Kier]

I'm pretty sure I know what's causing this, but I'm away from my main PC at the moment, so I can't access the code. If no one else picks this up, I'll fix it this afternoon (about 6 hours time from now).

[bira]

changing


if ($HTTP_POST_VARS['action']=="emailpassword") {


in member.php

to


if ($action=="emailpassword") {


Fixes it.

(though not sure if that goes against the fix of the mysterious security issue you discovered)

[bira]

actually, upon reflection, I'm rather sure this IS the fix, because $HTTP_POST_VARS only applies to variables submitted from a form.

Since the variable "action" is not submitted via a form, then it isn't part of the $HTTP_POST_VARS array (which is why the page just sits there blank -- it doesn't have any variable $action="emailpassword" in the script).

So yeah, just run the above fix.

[Chris Schreiber]

Originally posted by bira
(though not sure if that goes against the fix of the mysterious security issue you discovered)

Yes that code will solve the problem, but not the security issue.... I am sure Kier will post a fix when he gets the chance.

[bira]

Chris, if you look at the scripts you'll see that variables passed through a URL and NOT through forms submit are STILL $action==. The only ones to have changed are those 'action' that were passed from a form.

Eg, in member.php:

if ($action=="logout") {
if ($action=="login") {
if ($action=="markread") {
if ($action=="lostpw") {
if ($action=="editprofile") {
if ($action=="editoptions") {

etc.

Notice that these are ALL url-passed variables (member.php?action=logout, member.php?action=editoptions etc)

And, in contrast, you have examples like:

if ($HTTP_POST_VARS['action']=="updateprofile") {
if ($HTTP_POST_VARS['action']=="updatepassword") {
if ($HTTP_POST_VARS['action']=="updateavatar") {

etc.

Notice that these are ALL form-passed variables (<input type="hidden" name="action" value="updateprofile"> for example.).

So there could be no other way to fix this 'bug', I'm afraid, short of making "email password" a form rather than a link (which makes no sense).

[Chris Schreiber]

Ahh ok I see what you are saying.

[tubedogg]

Originally posted by bira
So there could be no other way to fix this 'bug', I'm afraid, short of making "email password" a form rather than a link (which makes no sense).

Actually, that's not entirely true. Look in functions.php for the forcepost function.

[bira]

tubedogg, forcepost would be a moot point at this case, if you know what the security issue is. If a variable can be passed via a URL then it can be passed locally or remotely, and therefore has nothing to do with what the security fix is up for. There's no point in forcing post on a variable that by default is passed via url.

[bira]

oh, and I just looked at function.php.


if (!isset($HTTP_POST_VARS["$varname"])) {
// not through POST, so die..
exit;
}


So how exactly does this function help you? :D

[tubedogg]

OK I just realized something. Never mind, I'm stupid. :D

[leadZERO]

What was the security bug, I would like to make sure I don't have it in my own scripts...

[Chris Schreiber]

Originally posted by leadZERO
What was the security bug, I would like to make sure I don't have it in my own scripts...

It will be reported to everyone only after we have given everyone time to update to the latest version, and have notified other software developers of the risk.

[leadZERO]

Originally posted by Chris Schreiber
and have notified other software developers of the risk.

Where will you be reporting it, email me or PM if need be... That's the reason I'm interested. PHP runs my site and it is heavily integrated into vB, so If I need to make any modifications to the integration code I would like to do so before the public knows. :)

[Kier]

Find this code in admin/user.php, a little below if ($action=="edit") {:

echo "<p><a href='../member.php?s=$session[sessionhash]&action=emailpassword&email=$user[email]' target=_new>[email password]</a></p>";
if ($user[usergroupid]==3) {
echo "<p><a href='../register.php?s=$session[sessionhash]&action=emailcode&email=$user[email]' target=_new>[email activation codes]</a></p>";
}

replace it with this:

doformheader("../member","emailpassword",0,0);
makehiddencode("email","$user[email]");
doformfooter("Email Password",0);

This will fix the email password problem when you are viewing a user's details.

Coming next, a fix for the [email password] link on the screen just before you view a member's details.

[Kier]

Again, in admin/user.php, find this code:

if ($displayoptions==1) {
echo "<td><p>".
makelinkcode("edit","user.php?s=$session[sessionhash]&action=edit&userid=$user[userid]").
makelinkcode("email password","../member.php?s=$session[sessionhash]&action=emailpassword&email=$user[email]",1).

replace it with this:

if ($displayoptions==1) {
echo "<td><p>".
makelinkcode("edit","user.php?s=$session[sessionhash]&action=edit&userid=$user[userid]").
makelinkcode("email password","user.php?s=$session[sessionhash]&action=emailpassword&email=$user[email]").

Then, find this: if ($action=="edit") { and right above it, add this:
// ###################### Start email password #######################
if ($action=="emailpassword") {

doformheader("../member","emailpassword");
makehiddencode("email","$email");
maketableheader("Email password reminder to user");
makedescription("Click the button below to send the password to $email");
doformfooter("Email Password",0);

}
This will fix the email password link from the user list page.

[Kier]

One other thing, do not repace if ($HTTP_POST_VARS['action']=="something") with if ($action=="something") anywhere in the vBulletin code. Bad things could happen.

[SAWolf76]

Same problem with [email activation codes] .....

Would you please look into it?

[Kier]

Originally posted by SAWolf76
Same problem with [email activation codes] .....

Would you please look into it? Sorry... where abouts is this link?

[SAWolf76]

its in the users profile in the admin control panel..........

[Kier]

are you sure that isn't a hack? i don't have it in my CP here...

[SAWolf76]

nope not a hack...... u would find it in the profile of a memebr that didn't activate his account........

[bira]

Kier the link will show up only for a user who is in usergroup Awaiting Email Confirmation.

For other users, the link won't show.

Find a user in ugid 3 and look at the bottom, right under "email password"

[Kier]

gotcha... the reason i couldn't find it is because i accidentally deleted it :rolleyes::eek:

find the code just after the first fix in this thread, which starts with if ($user[usergroupid]==3) { and ends with }, then replace it with this:

if ($user[usergroupid]==3) {
doformheader("../register","emailcode",0,0);
makehiddencode("email","$user[email]");
doformfooter("Email Activation Codes",0);
}

[Joshs]

Huh? So what am I fixing now? I fixed it originally and now you changed it...

[SAWolf76]

that fix opens for me the user interface where I have to insert the users email to send the activation code....... it should send it with out asking for the email address...........

[Kier]

Sorry, my mistake. I have altered the code above.

[Nicholas Brown]

Originally posted by Joshs
Huh? So what am I fixing now? I fixed it originally and now you changed it...

c'mon - give poor Kier a break :)
The guys have been under a lot of stress and at least they are posting fixes, unlike other BB manufacturers which will remain anonymous ;)

[Joshs]

I wasnt being rude, I just dont know what to do now...

[bira]

Joshs,

assuming you followed the initial instructions, then open admin/user.php and find:


doformheader("../member","emailpassword",0,0);
makehiddencode("email","$user[email]");
doformfooter("Email Password",0);


Right under it add:


if ($user[usergroupid]==3) {
doformheader("../register","emailcode",0,0);
makehiddencode("email","$user[email]");
doformfooter("Email Activation Codes",0);
}


Hope that helps.

[Joshs]

Thanks!

[Access Admin]

Originally posted by bira
changing


if ($HTTP_POST_VARS['action']=="emailpassword") {


in member.php

to


if ($action=="emailpassword") {


Fixes it.

(though not sure if that goes against the fix of the mysterious security issue you discovered)


thnx m8 it solve this prb


http://64.124.220.154/images/access.jpg

Access-FxP Admin &
Founder Of Access-Fxp

[Jujubee]

I'm running RC3 and I don't see the "[email activation codes]" link in the "Users awaiting email confirmation".

My options are:
[edit] [email password] [remove] [edit access masks]



BTW, I assume we have to wait for the next release to get edited versions of the PHP files that contains the above fixes?

[Joshs]

You have to click the edit button, and scroll towards the bottom of the page to see what you are looking for.

[tubedogg]

Originally posted by Jujubee
BTW, I assume we have to wait for the next release to get edited versions of the PHP files that contains the above fixes?

Yes. That's why it's called a release. ;)

[isman]

So can I assume that this will fix the automatic email confirmation?