Forum OpenACS Q&A: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!)

4: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 1)

Posted by Jade Rubick on 05/28/04 07:13 PM

You're right, I overstated my case. I could only get the permissions of the Aolserver, which wouldn't be root.

Still that's the first step in getting root access. Once you have access to a user account, you have a lot of access. And there are a lot of privilege escalation bugs you could exploit to get root access from there.

5: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 4)

Posted by Jeff Davis on 05/28/04 07:21 PM

I think you can execute arbitrary unix commands as the servers uid on 5.1 with the on a server with the permissive settings in about 10 minutes (well, really you need to wait until someone who has admin viewing a page with an IMG tag or a style attribute in it). You would have to find a local root exploit to escalate though (and such things are not as uncommon as remote root exploits).

6: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 5)

Posted by Tom Jackson on 05/28/04 07:26 PM

What would lead to such access? How is the ability to execute arbitrary unix commands related to an admin account on OpenACS and the img tag? Is this a unique to OpenACS5.1 issue? If not I guess I'm going to toggle 'registration requires admin approval'.

7: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 6)

Posted by Jade Rubick on 05/28/04 07:41 PM

Tom, the vector of attack is:

Post a comment in a visible place. Use HTML, and include an IMG tag that links to the admin page that grants site-wide-admin privileges.

Wait for the admin to visit that page. Now you have site-wide-admin privileges.

Now install developer-support, use the shell page, and you can execute arbitrary Unix commands, delete the database files and backups, etc.. You can also subtly change information on the webserver (since you have database access), and edit your posting, removing all trace of what happened. Then you can take away you privileges, and nobody would know.

Most OpenACS sites should not be vulnerable to this.

Toggling 'registration requires admin approval' won't help. You have to not allow all HTML tags. That's why that was put there in the first place. By default, it was very secure, but in OpenACS 5.1, it was made more lax.

So all OpenACS 5.1 installations (that weren't upgrades from something else) need to go into the parameters and remove the * from the HTML permitted section.

I've changed this in the 5.1 branch, so new installations from this date forward will be secure.

But beyond this, what are we going to do going forward?

On IRC, people are talking about making the admin pages be in forms, because then you can sign the variables. This is a very good and important idea, but it needs volunteers, and as much as I'm bitching right now, I'm not volunteering :)

9: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!) (response to 7)

Posted by Jeff Davis on 05/28/04 07:59 PM

The reason to make admin actions (and actions generally) forms is because you want to make them "POSTs" and have the page only accept posts. That will then prevent the involunatry "GETs" issued to retrieve images (via IMG OBJECT ... tags, and via style="background: url( ... )"). You can sign things in a get as easily as a post.

I do think we should add a -post flag to ad_page_contract which would throw an error if the page was not posted to.

I have been looking at what other people do and most of the php things use a sanitize script to remove dangerous things. We in fact already have something that does this but it's not really used (util_close_html_tags can be told to remove tags, remove tag content, etc). But it's slow and I think if we really did it we should return the sanatized html + a list of removed tags and attributes.