Re: [uportal-dev] uPortal Security Notice: RemoteUserSecurityContext exploit
Hi, As Bill has mentioned I will be taking care of 2.5 branch that includes 1- Create Jira issue for this issue 2- Apply the patch on rel-2-5-patches tag 2-5-3-1-RC1 and request to test it. 3- Tag 2-5-3-1-GA after successful test reports. 4- Post the security notice and patch somewhere appropriate on the uPortal wiki. (Suggestions are welcome for the appropriate place) 5- Build the uPortal-only and quick start for 2-5-3-1-GA (Since this is a critical bug I think we should do this step). 6- update the website 7- Announce the availability of 2-5-3-1-GA on the user list. Note: I have not created the quick start and never updated the website before, I will be very happy to get any to do task list or any advice. Thanks every one. Faizan William G. Thompson, Jr. wrote: Folks, Faizan will be working up a SECURITY release for the 2.5 branch this week and Andrew is taking care of the 2.6 branch. Bill William G. Thompson, Jr. wrote: This is a public notification of an identified uPortal security vulnerability and workaround. All uPortal adopters are encouraged to review the following notice immediately and take appropriate action as necessary. --- *Title:* RemoteUserSecurityContext exploit *Summary:* RemoteUserSecurityContext may allow an authenticated user to authenticate as another user knowing only that user's account name. A patch for this vulnerability is attached to this message. *Issue:* The vulnerability is exposed when the RemoteUserSecurityContextFactory is used in conjunction with another security context factory under the UnionSecurityContextFactory. The result of this configuration is any user that can access uPortal with REMOTE_USER set can become any other portal user. If authentication is attempted with the other security context the provided user id will be set on the principal, when the RemoteUserSecurityContext executes it attempts to set the user id of the principal to the REMOTE_USER and returns that the principal is authenticated. Since the principal already has a user id set the setting by RemoteUserSecurityContext fails silently, resulting in an authenticated principal with the user id provided by the attacker, not the value specified in the REMOTE_USER field. An example vulnerable configuration from security.properties: root=org.jasig.portal.security.provider.UnionSecurityContextFactory root.a=org.jasig.portal.security.provider.RemoteUserSecurityContextFactory root.b=org.jasig.portal.security.provider.SimpleSecurityContextFactory *Versions Affected:* All (2.0, 2.1, 2.2, 2.3, 2.4, 2.5) *Resolution:* The resolution involves adding a check to RemoteUserSecurityContext to verify the setting of the REMOTE_USER user id was successful for the principal. If it was not the RemoteUserSecurityContext will not mark the principal as authenticated. *Patching:* The attached patch should be applied to the file /uPortal/source/org/jasig/portal/security/provider/RemoteUserSecurityContext.java After application of the patch compile and deploy the file to the application server. --- -- Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA. Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source For more information registration visit: http://www.ja-sig.org/conferences/07summer/index.html --- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] -- Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA. Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source For more information registration visit: http://www.ja-sig.org/conferences/07summer/index.html --- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] -- Faizan Ahmed Sr. Application Developer Enterprise Systems and Services, Rutgers University voice: 732 445-2763 | fax: 732 445-5493 |e-mail: [EMAIL PROTECTED] -- Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA. Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source For more information registration visit: http://www.ja-sig.org/conferences/07summer/index.html --- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
[uportal-dev] 2.5.3.1 security release versus 2.5.4 patch release
Faizan, +1 for a minimal diff 2.5.3.1 security release. I think an inclination to prioritize getting out the simplest possible release including this critical security fix is sound. Simplest Thing That Could Possibly Work and all that. As you note, there are a number of changes latent in 2-5-patches targetted for a 2.5.4, including a significant JSR-168 support improvement courtesy Cris Holdorph. Getting a 2.5.4 release out sometime is probably therefore also a worthy goal, maybe depending on how steep the upgrade path to 2.6 is felt to be. Andrew Hi! again!! I just looked at the current rel-2-5-patches head and the rel-2-5-3-GA. A quick compare gave me a significant number of differences between both code bases. That means there have been several changes that went in on 2-5-patches branch sine the release of rel-2-5-3-GA. These changes are targeted to rel-2-5-4 as JIRA pointed out. Here is what I am thinking in present situation -Branch of from tag rel-2-5-3-GA (I will call branch name rel-2-5-3-patches) -Apply the security patch in this branch and also in the head of rel-2-5-patches. The tag "rel-2-5-3-1" will be done on the newly created branch (2-5-3-patches). I will wait till 1330 EST to wait for any negative response. If I do not get any negative response about my plan by then, then I will execute my plan as I have mentioned above. Thanks. Faizan -- Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA. Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source For more information registration visit: http://www.ja-sig.org/conferences/07summer/index.html --- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
Re: [uportal-dev] 2.5.3.1 security release versus 2.5.4 patch release
To be fair/correct, I talked about the change, but I believe it was Brad Johnson who actually did the work to get an upgraded pluto 1.0.1 zip into uPortal 2.x. Maybe I contributed another change, but at least in the linked article, I was only talking about a change Brad Johnson had made. Cris J H Andrew Petro wrote: As you note, there are a number of changes latent in 2-5-patches targetted for a 2.5.4, including a significant JSR-168 support improvement courtesy Cris Holdorph http://support.unicon.net/node/596. Getting a 2.5.4 release out sometime is probably therefore also a worthy goal, maybe depending on how steep the upgrade path to 2.6 is felt to be. Andrew -- Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA. Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source For more information registration visit: http://www.ja-sig.org/conferences/07summer/index.html --- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
[uportal-dev] on what to name the bikeshed, Tomcat context file
Cris,
My viewpoint is this: this is a bikeshed
issue. What is needed is for someone to take ownership of it, to
make it better, and to be done with it. I'm hoping that someone will
be you.
[
If I did make a suggestion for the renaming, it would probably be to
rename it "uPortal_tomcat_5.5.xml" or something similar. I always
thought "uportal.xml" and "uportal55.xml" suggested a problem with the
'naming convention'.
]
Please just go ahead and rename the file to whatever you think best,
updating comments as necessary.
Bikeshed issues are those where a developer comes along and proposes to
make a simple, small, but real improvement. Usually it's something
that's needed done for a long time and no one did anything about it.
Since it's a simple improvement, many people *could* have an opinion
about the issue, and even *could* have addressed it at any time.
Since anyone could plausibly weigh in on details about the bikeshed
issue, often attempts to make progress on bikeshed issues are derailed
by endless discussion. I'm probably guilty of participating in that
sort of thing way too much. And it can even reach the point where
*fear of a bikeshed discussion* impedes progress.
I'd love to rename the file,
but didn't think I'd have as good a shot at getting consensus
buy-in for that.
"I'd love to make uPortal better, but bikeshed discussions about
details of what a context file is named prevent my contributing."
Cris, just re-name it. Feel fully empowered to name this file
whatever's the best quickly-thought-of name you can come up with,
update the comments, make sure the build works, and we can move on.
I would suggest that anyone who feels the need to push back on you
about that can find lots of other uPortal issues to work on. Maybe
could work on a featureful layout manager for uPortal 3.
uPortal is entitled to cause deployers a little pain in upgrading minor
versions where doing so improves the platform. Existing deployers can
deal with the file rename.
Andrew
Well, I'd
love to rename the file, but didn't think I'd have as good a shot at
getting consensus buy-in for that. I do think it could be confusing
for upgraders and therefore thought I'd get some push back.
I'd also like to try this under Tomcat 6 sometime, but I just don't
have the cycles to do that this week. I think a more important step is
to fix the Portlet deployment situation so it doesn't rewrite the
web.xml to a an ancient servlet spec version, which makes using any of
the latest servlet/jsp stuff impossible (which is presumably one reason
you'd be using Tomcat 6).
If I did make a suggestion for the renaming, it would probably be to
rename it "uPortal_tomcat_5.5.xml" or something similar. I always
thought "uportal.xml" and "uportal55.xml" suggested a problem with the
'naming convention'.
But overall at this point, I'd rather make the very very small, slight
change of simply removing the Tomcat 5.0 config file and commented out
lines from build.properties. This change would not it impossible to do
any other rename change in the future, it's just a step along the way.
Cris J H
Jason Shao wrote:
On Jun 15, 2007, at 11:36 PM, Andrew Petro
wrote:
1. Should the current uPortal55.xml file be renamed to uPortal.xml?
This would be consistent with past practice, but potentially confusing
for upgraders. Or Does uPortal{VERSION}.xml become the new naming
convention? Or is there tooling that can always generate the right
target file for us?
2. Do we need a tweaked file for Tomcat 6?
Jason
--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA.
Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source
For more information registration visit: http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Re: [uportal-dev] on what to name the bikeshed, Tomcat context file
I think it should be blue. :-o
Andrew Petro wrote:
Cris,
My viewpoint is this: this is a bikeshed issue
http://en.wikipedia.org/wiki/Color_of_the_bikeshed. What is needed
is for someone to take ownership of it, to make it better, and to be
done with it. I'm hoping that someone will be you.
[
If I did make a suggestion for the renaming, it would probably be to
rename it uPortal_tomcat_5.5.xml or something similar. I always
thought uportal.xml and uportal55.xml suggested a problem with the
'naming convention'.
]
Please just go ahead and rename the file to whatever you think best,
updating comments as necessary.
Bikeshed issues are those where a developer comes along and proposes
to make a simple, small, but real improvement. Usually it's something
that's needed done for a long time and no one did anything about it.
Since it's a simple improvement, many people *could* have an opinion
about the issue, and even *could* have addressed it at any time.
Since anyone could plausibly weigh in on details about the bikeshed
issue, often attempts to make progress on bikeshed issues are derailed
by endless discussion. I'm probably guilty of participating in that
sort of thing way too much. And it can even reach the point where
*fear of a bikeshed discussion* impedes progress.
I'd love to rename the file,
but didn't think I'd have as good a shot at getting consensus buy-in
for that.
I'd love to make uPortal better, but bikeshed discussions about
details of what a context file is named prevent my contributing.
Cris, just re-name it. Feel fully empowered to name this file
whatever's the best quickly-thought-of name you can come up with,
update the comments, make sure the build works, and we can move on.
I would suggest that anyone who feels the need to push back on you
about that can find lots of other uPortal issues to work on. Maybe
could work on a featureful layout manager for uPortal 3.
uPortal is entitled to cause deployers a little pain in upgrading
minor versions where doing so improves the platform. Existing
deployers can deal with the file rename.
Andrew
Well, I'd love to rename the file, but didn't think I'd have as good
a shot at getting consensus buy-in for that. I do think it could be
confusing for upgraders and therefore thought I'd get some push back.
I'd also like to try this under Tomcat 6 sometime, but I just don't
have the cycles to do that this week. I think a more important step
is to fix the Portlet deployment situation so it doesn't rewrite the
web.xml to a an ancient servlet spec version, which makes using any
of the latest servlet/jsp stuff impossible (which is presumably one
reason you'd be using Tomcat 6).
If I did make a suggestion for the renaming, it would probably be to
rename it uPortal_tomcat_5.5.xml or something similar. I always
thought uportal.xml and uportal55.xml suggested a problem with
the 'naming convention'.
But overall at this point, I'd rather make the very very small,
slight change of simply removing the Tomcat 5.0 config file and
commented out lines from build.properties. This change would not it
impossible to do any other rename change in the future, it's just a
step along the way.
Cris J H
Jason Shao wrote:
On Jun 15, 2007, at 11:36 PM, Andrew Petro wrote:
1. Should the current uPortal55.xml file be renamed to uPortal.xml?
This would be consistent with past practice, but potentially
confusing for upgraders. Or Does uPortal{VERSION}.xml become the new
naming convention? Or is there tooling that can always generate the
right target file for us?
2. Do we need a tweaked file for Tomcat 6?
Jason
--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27,
2007 in Denver, CO USA.
Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity
Management, and Open Source
For more information registration visit:
http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
[EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in
Denver, CO USA.
Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity
Management, and Open Source
For more information registration visit:
http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
