From: <bil...@ca...> - 2007-05-11 04:04:54
|
I'm looking for some advice on how to fix a little problem in the "proon" plugin. It's been broken for a while, but I'm just getting around to working through it. I'm a little hazy on how I came to this conclusion, but somewhere I got the impression that it was OK for a plugin hooked to webmail_top to change the value of "$right_main". (It's likely that I swiped this technique from some other plugin.) "proon" uses this feature (if so configured) to conditionally send users directly to the pruning parameters screen at login. This all worked fine up until SM 1.4.6. In that release, security vulnerability CVE-2006-0188 was addressed. A part of that code change was to switch from "htmlspecialchars($right_frame)" to "urlencode($right_frame)" (for the default case where $right_frame isn't something specifically recognized). The change to urlencode() makes the right_frame value not interpretable by the browser. Instead of getting the appropriate page in the right frame, the user gets a "404 page not found" error. So, was I wrong about plugins being allowed to change $right_frame, or did that policy change? (It's not too clear to me what useful value you could put into $right_frame that would still be useful after urlencode().) Any alternative suggestions for how to achieve my aim, which is to (conditionally) force the user to an alternative page right after login? TIA |
From: <bil...@ca...> - 2007-05-11 19:06:20
|
wjc> I'm a little hazy on how I came to this conclusion, but somewhere wjc> I got the impression that it was OK for a plugin hooked to wjc> webmail_top to change the value of "$right_main". (It's likely wjc> that I swiped this technique from some other plugin.) "proon" wjc> uses this feature (if so configured) to conditionally send users wjc> directly to the pruning parameters screen at login. Sorry, I should have said "$right_frame", not "$right_main". After a little poking around, I see that the "startup_folder" plugin uses this technique if a plugin is selected as the startup location. Since "startup_folder" hasn't been updated since 2004, I'd imagine it is also broken by this change (for the redirect-to-plugin case). |
From: Paul L. <pa...@sq...> - 2007-11-28 09:19:28
|
On May 11, 2007 11:07 AM, WJCarpenter <bil...@ca...> wrote: > wjc> I'm a little hazy on how I came to this conclusion, but somewhere > wjc> I got the impression that it was OK for a plugin hooked to > wjc> webmail_top to change the value of "$right_main". (It's likely > wjc> that I swiped this technique from some other plugin.) "proon" > wjc> uses this feature (if so configured) to conditionally send users > wjc> directly to the pruning parameters screen at login. > > Sorry, I should have said "$right_frame", not "$right_main". After a > little poking around, I see that the "startup_folder" plugin uses this > technique if a plugin is selected as the startup location. Since > "startup_folder" hasn't been updated since 2004, I'd imagine it is > also broken by this change (for the redirect-to-plugin case). This was fixed as of SquirrelMail 1.4.11. Please reference the newest release of Startup Folder (v2.1, released shortly after this mail is to be sent) for a working example. Cheers, Paul |
From: Tomas K. <to...@us...> - 2007-05-12 04:54:25
|
> I'm looking for some advice on how to fix a little problem in the > "proon" plugin. It's been broken for a while, but I'm just getting > around to working through it. > > I'm a little hazy on how I came to this conclusion, but somewhere I > got the impression that it was OK for a plugin hooked to webmail_top > to change the value of "$right_main". (It's likely that I swiped this > technique from some other plugin.) "proon" uses this feature (if so > configured) to conditionally send users directly to the pruning > parameters screen at login. > > This all worked fine up until SM 1.4.6. In that release, security > vulnerability CVE-2006-0188 was addressed. A part of that code change > was to switch from "htmlspecialchars($right_frame)" to > "urlencode($right_frame)" (for the default case where $right_frame > isn't something specifically recognized). The change to urlencode() > makes the right_frame value not interpretable by the browser. Instead > of getting the appropriate page in the right frame, the user gets a > "404 page not found" error. > > So, was I wrong about plugins being allowed to change $right_frame, or > did that policy change? (It's not too clear to me what useful value > you could put into $right_frame that would still be useful after > urlencode().) > > Any alternative suggestions for how to achieve my aim, which is to > (conditionally) force the user to an alternative page right after > login? Bug #1685072 - can't set $right_frame outside of src directory Modification can be explained only by people that have internal information about CVE-2006-0188 Plugins still can redirect people to own page, if it is options page and options use widgets. -- Tomas |
From: <bil...@ca...> - 2007-05-13 19:18:40
|
tk> Bug #1685072 - can't set $right_frame outside of src directory tk> Plugins still can redirect people to own page, if it is options tk> page and options use widgets. Thanks for the suggestion. I'll explore that a little bit when I get a minute. -- bi...@ca... (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 |