rise the priority - security issues have to fixed ASAP. thanks.

i am failing to see how this is security issue with the test case given.

1) u are grabbing cookie content while LOGGED IN with credentials
2) u log out
3) now you login with another person's credentials and paste contents of cookie that were captured while logged in. in both cases u have to know credentials of each user. 

i could see this as a problem if you captured the content while logged out and you were able to log in as someone else.

Hi Shannon,

  thank you for your reply.

(In reply to comment #4)
> i am failing to see how this is security issue with the test case given.
> 
> 1) u are grabbing cookie content while LOGGED IN with credentials
> 2) u log out
> 3) now you login with another person's credentials and paste contents of cookie
> that were captured while logged in. in both cases u have to know credentials of
> each user. 
> 
> i could see this as a problem if you captured the content while logged out and
> you were able to log in as someone else.

I think the problem Corey is referring to is in steps 10) and 11):

10. Create a new cookie from scratch, containing the details you copied in step 4, being careful to use the correct cookie name, content and server

11. Load katello server page.

With the result:

In step 11, content from a cookie can be used, even after browser session itself has been terminated - that is, after the browser has been closed - to craft a new authentication cookie.

Thus (based on above description assuming, didn't try it) some remote attacker could just sniff the cookie content on the network. Save particular values, create new cookie, and the successfully log-in to the Katello web UI service just due knowledge of the cookie.

Assuming, what Corey is trying to say, that there isn't some random / unique value contained within the cookie, so it couldn't be used again (under different user) for replay attacks.

Corey, is this the way you thought the attack would be possible?

If not, please correct me.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Correct, if the cookie content is sniffed -- or in my case, copied out -- and regenerated after the user has been logged out and subsequently had his session invalidated, the cookie is essentially not rejected as invalid.

Shannon, i just re-read this:

3) now you login with another person's credentials and paste contents of cookie
that were captured while logged in. in both cases u have to know credentials of
each user. 

No, you don't need to know the user's credentials.  Once you copy and paste the cookie contents, you do not need to physically login. The cookie is valid - you can enter the UI system w/o actually logging in.

Does this sound like an accurate short summary of the issue?

When user selects logout action in katello webui, her session is not closed / invalidated on the server side.  Even though local cookie gets destroyed (server reply to logout request overwrites session cookie(s)), the session can be resumed by manually restoring session cookie(s) values.

Tomas, that sounds like an accurate summary of the issue. 

How would a attacker 'sniff' a cookie value if all our comms are on HTTPS?  

Seems to me the only way you can get access to a valid or invalid cookie is by having access to the machine running the browser where the cookie is stored which would indicate larger problems.

I'm going to move this off katello-blockers unless someone convinces us otherwise that this needs to get fixed ASAP.

How long does the cookie stay valid?  Even if it's not our job to prevent hijacking the cookie locally, if there *is* some exploit to get it, like cross site scripting, we don't want the attacker to be able to continue to use it even after the original session is logged out.

Of course, if using SSL and if app has no XSS issues, there should be no easy way for any attacker to get access to the cookie.  This still sounds like a bug, and something that probably should not be too hard to fix.

mass move to CFSE product.

I looked into the technical details to remove the replay attack vulnerability. The cookie data is comprised of the session data, then a '--' delimiter followed by the HMAC of the session. the user would not be able to tamper the data since its signed but there is indeed a replay attack vulnerability when i signed out and sent the same cookie headers back to the server. 

we would need to change the store mechanism from cookie_store to a db/active record store so we could delete session records on user logout. I created a session table and modified the store but looks like we have to make some changes to our session logic (especially user_sessions in views) to make this work correctly. predicting a lot of regression testing would need to be done to get the confidence rating up for robustness. 

I'll check up with a couple other team members who might see an easier path but looks like regression would take a hit since this is our session layer.

I do not believe this is an issue any longer, I am moving to ON_QA for 6.1 to verify.

Nope, this is still valid (and I had little reason to suspect anything was changed to fix it, tbh).  

I just copied session id from admin user, created a new user 'hacker', logged out as admin and logged back in as 'hacker', copied the session id back and voila, I was admin again.

I am not sure why we are not simply crafting a new unique session id for each login, that gets destroyed once that account is logged out.

* apr-util-ldap-1.3.9-3.el6_0.1.x86_64
* candlepin-0.9.32-1.el6.noarch
* candlepin-common-1.0.8-1.el6.noarch
* candlepin-selinux-0.9.32-1.el6.noarch
* candlepin-tomcat6-0.9.32-1.el6.noarch
* elasticsearch-0.90.10-7.el6.noarch
* foreman-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-compute-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-gce-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-libvirt-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-ovirt-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-postgresql-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-proxy-1.7.0-0.develop.201410081229git52f0bac.el6.noarch
* foreman-release-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-selinux-1.7.0-0.develop.201409301113git2f345de.el6.noarch
* foreman-vmware-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* katello-2.1.0-1.201410091751gitc9c45c1.el6.noarch
* katello-certs-tools-2.0.1-1.el6.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-2.1.0-1.201410021645git304e036.el6.noarch
* katello-repos-2.1.1-1.el6.noarch
* katello-server-ca-1.0-1.noarch
* openldap-2.4.23-32.el6_4.1.x86_64
* pulp-docker-plugins-0.2.1-0.2.beta.el6.noarch
* pulp-katello-0.3-3.el6.noarch
* pulp-nodes-common-2.5.0-0.7.beta.el6.noarch
* pulp-nodes-parent-2.5.0-0.7.beta.el6.noarch
* pulp-puppet-plugins-2.5.0-0.7.beta.el6.noarch
* pulp-puppet-tools-2.5.0-0.7.beta.el6.noarch
* pulp-rpm-plugins-2.5.0-0.7.beta.el6.noarch
* pulp-selinux-2.5.0-0.7.beta.el6.noarch
* pulp-server-2.5.0-0.7.beta.el6.noarch
* python-ldap-2.3.10-1.el6.x86_64
* ruby193-rubygem-ldap_fluff-0.3.1-1.el6.noarch
* ruby193-rubygem-net-ldap-0.3.1-2.el6.noarch
* ruby193-rubygem-runcible-1.2.0-1.el6.noarch
* rubygem-hammer_cli-0.1.3-1.201409240954gitf3c47c7.el6.noarch
* rubygem-hammer_cli_foreman-0.1.3-1.201409191432gitc38f9c8.el6.noarch
* rubygem-hammer_cli_foreman_tasks-0.0.3-2.201409091410gitc96619d.git.0.37f3704.el6.noarch
* rubygem-hammer_cli_import-0.10.4-1.el6.noarch
* rubygem-hammer_cli_katello-0.0.6-1.201410091836git8886ff0.git.0.9402d12.el6.noarch

Yes. I just triaged it and I was able to reuse the session_id from the admin. Rails 4 made a few improvements where I can't decode it now, but if it's not revoked upon logout, it'll still be available. I'm investigating how can we expire the session id on logout.

It puzzled me a bit that activerecord_session_store (db session store) would do that. Bryan, you were right after Rails 4 this shouldn't have happened.

Apparently there was a bug that sometimes would not respect the session expiry. It was fixed on http://projects.theforeman.org/issues/14338 - so we can cherrypick it for this version easily.

Connecting redmine issue http://projects.theforeman.org/issues/14338 from this bug

Upstream bug component is Provisioning

VERIFIED

on sat 6.2.0 Beta (GA12.1)

The cookie is invalidated on logout:

<pre>
# after updating the 'hackers' session cookie by admin one: 
2016-05-23 10:44:31 [app] [I] Started GET "/users/8-hacker/edit" for 10.34.131.38 at 2016-05-23 10:44:31 -0400
2016-05-23 10:44:31 [app] [I] Processing by UsersController#edit as HTML
2016-05-23 10:44:31 [app] [I]   Parameters: {"id"=>"8-hacker"}
2016-05-23 10:44:31 [app] [I] Redirected to https://dell-pe-fc630-01.rhts.eng.bos.redhat.com/users/login
2016-05-23 10:44:31 [app] [I] Filter chain halted as :require_login rendered or redirected
2016-05-23 10:44:31 [app] [I] Completed 302 Found in 6ms (ActiveRecord: 0.7ms)
2016-05-23 10:44:31 [app] [I] Started GET "/users/login" for 10.34.131.38 at 2016-05-23 10:44:31 -0400
2016-05-23 10:44:31 [app] [I] Processing by UsersController#login as HTML
2016-05-23 10:44:31 [app] [I]   Rendered users/login.html.erb within layouts/login (3.3ms)
2016-05-23 10:44:31 [app] [I]   Rendered layouts/base.html.erb (1.8ms)
2016-05-23 10:44:31 [app] [I] Completed 200 OK in 12ms (Views: 6.9ms | ActiveRecord: 0.7ms)
</pre>

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1501