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

It turns out that OpenACS 5.1 was shipping with a default setting in the parameters section that allow any sort of HTML to be let through the security filters (to remove this, take out the *). This makes it trivial to completely take over an OpenACS server. I believe I could root a box in about 10 minutes with this security hole.

My basic argument is that the core of OpenACS should be secure by default, and that any packages that are insecure by design should be clearly marked as insecure.

Lars agreed that security was important, but thought that we too often sacrifice usability to obscure security issues. And he pointed out what a large usability problem our security filters have been in the past. Hopefully I've summed up your argument well, Lars?

In any case, I think our discussion (see https://openacs.org/irc/log/2004-05-26) brings up a larger issue of a security policy for OpenACS.

Perhaps we need both a security policy and some usability guidelines. To some extent, the conflict between usability and security can be alleviated by careful design, but it typically takes a lot more work to do so.

I personally would like to see our code held up to very high standards for both usability and security. But if we don't clarify what those standards are, and if they're worthwhile or not, we'll all have our own individual standards and no coherent strategy for OpenACS.

Any thoughts on this?

My proposal would be:

1) OpenACS *core* will be as secure as possible by default. Any changes that introduce a potential security hole have to be TIPped.

2) When security issues cause usability problems, we will make it clear to administrators how to lower the security, and what the risks are in doing so. (This should be in our usability guidelines).

3) Individual package writers should inform the public (via the forums) if they are aware of security holes in their software, so that concerned individuals can either fix it themselves, or not use that package.

Of course, if we had the manpower and the inclination (we don't), we could put stuff in the APM that reflected whether packages had been audited for security and against our usability standards. I don't see any volunteers for this, I believe?

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.

Once someone has an admin account on OpenACS he could install acs-developer-support and and execute code via the its tcl shell feature.

This is not restricted to just 5.1, I believe...

Okay, it is all coming back to me now. This is a problem with OpenACS, not the src attribute. If I was smart, I would just send a tempting email to all the admins:

Hey X,

Check out this link on XSS: http://example.com/XSS.html

Then construct my unchecked src attriute on XSS.html

It seems the agreed upon solution is to require a tie between the form and the form processing script, and to require POST. I would add an 'I'm a human' test to certain actions as well.

Jeff, you once provided great links to open source tools for generating images to read, but I wasn't sure if the intent was to point out they are easily broken?? The nonce idea (or any tying method) would mostly eliminate simple attacks since it would require more than one request, but I'm starting to think that you could do something like

 src="http://example.com/get-nonce"
 src="http://example.com/use-nonce"

That is, two images loaded in sequence. At the very least I have noticed that Mozilla serializes frame source loading.

confirmation page:
set security_key [ns_rand 1000000000]
nsv_set user_transfer_approval $user_id $security_key
# send $security_key with form

action page:
# read $security_key from form
catch {
    set t [nsv_get user_transfer_approval $user_id]
}
if {![info exists t] || $t != $security_key} {
    ad_return_error "Transfer not approved" "
    Go back and approve the transfer first.
    "
    return
}

I figure there's better odds than 1 in a billion that an attacker will find some security hole I haven't patched, so this is "secure enough" for me.

Anyway, if you limit this to POST (which I didn't think of), it seems to me you don't even need to bother with this, as long as you're having util_close_html_tags strip out FORM tags.  I'm reasonably sure you can't use javascript to POST w/o a FORM.  Certainly adding util_close_html_tags calls will be easier than adding code like mine here.  (Besides, it should be done anyway since users are stupid and don't, well, close their tags which is what that proc was originally for.)

Currently a site-wide admin is always a site-wide admin. This is equivalent to using root on your Linux/Unix box all the time and do things like surfing the web.

Here is a quick idea: We could set a second cookie for all admin pages and that cookie expires after 15/30/60 minutes (apm parameter) and it determines whether you need to enter a password before being able to perform admin activities.

A real sudo and a root-like account would be cooler, but it may require a lot more changes.

Jonathan's trick is essentially a nonce that expires when the server restarts. The downside is that relying on a shared variable like that means that if you have multiple frontend servers you need to sync these (whereas something signed with a random session cookie + a server secret + user_id would not need to be synced between the front ends, would survive server restart, could be made to expire by adding an expiry to the signed key, and would be equally secure).

Oh, one issue with making all the pages that do actions only accept POST is that if your login expires the whole redirect for registration relies on being able to do redirects to propigate state which of course result in GETs. That means if you fill out a form, send a post, it does a redirect to register with a return_url; signing in then does a redirect to the return_url which (because the target URL only accepts posts) fails.

It also means single page add-edit screens would need to be reworked since the initial link to the page would be a GET (i.e. you could only check it was a POST when you really went to modify state).

Anyway, there are a bunch of cases like that where the assumption is that GET == POST and fixing it in a way that is both secure and not horribly unpleasant to use is not-trivial I think.

Jeff, let me clarify: the problem is with handling form input, not the src attribute. You can't clean the entire internet of malicious src attributes, that is just a 'feature' of HTML/HTTP. But OpenACS doesn't yet have a general method of handling the issue. Blocking usage of the src attribute will not fix the issue, it only limits it usage on a particular server. If you set your browser up to not accept images except from the same server as the web page, this will help a lot. But you need admins to do this always and in every browser they use, but this only works for images, probably not for frame/iframe/object tags. Admins also shouldn't load images in email messages by default.

This doesn't mean that these attributes couldn't be used for other badness. If a site like a slashdot allowed something like this, it could be used to spam another site with lots of hits, shutting down the site with a DOS type attack. So limiting the use of these attributes is still important in general.

So OpenACS didn't cause the root of the problem, and it can't really be solved by disallowing usage of certain attributes. But OpenACS can be fixed to make this kind of attack very difficult if not impossible.

I have a blog/cms package which allows images in a safe way, probably you could apply it to OpenACS. It just allows special tags which construct the url of the local image, avoiding the issue of user supplied urls. The tag is included in the main message content, and the content is run through ns_adp_parse. For instance an image tag looks like: <image name="myimage" id="1"> and returns a formatted img tag.

In this case myimage is an attribute of the content item, the first one uploaded is given an id (really the sort order) of 1. If the image uploaded was named myjpg.jpg the src returned would look something like '/somepkg/files/[1234%23]/1234/myimage/1/myjpg.jpg' where /somepkg/files/index.vuh exists to get the actual content.

</blockquote>

If acs-developer-support is such a powerful tool why make it available for install from the repository? Atleast if it was a local install only you would need access to the local file system before being able to install it.

    - Steve

src="https://openacs.org/permissions..blah,blah,blah

And post into this forum a url to my site that says here's how to make acs secure. Then someone will click the link and be screwed.

Barry, you are right: we can't fix the way the internet works. I'm not sure why an attacker would go to the trouble of using an image tag to break into OpenACS, given the ease it can be accomplished by tricking someone into visiting an offsite page. The offsite page could use every possible device to break in, not just a src attribute.

One way to fix it, mentioned by me before in this thread and others, is to tie the form to the form processing page. Forms should be tied to a session. Variables used in the form should be tied to the form. In the cases where ad_form is used, this might be possible without visible code changes to each page (where the default formtemplate tag is used), but I'm not a expert on ad_form.

Fixing the exploit code (developer support) isn't a long term solution. Someone could upload their own exploit code once they have admin access.

The more I think about it the more I think sudo is the answer because it solves the real problem which is you don't want to run as root all the time. If I'm paranoid I could authenticate on every admin action without changing code. If I want to run as root all the time on my dev box that's ok too.

I looked at the code a bit and I think all you would need to do call sudo::checkauth in the request processor just before the other permission checks. If it's been too long since you authenticated redirect to reauthenticate and set a cookie that's a database key to the time.

You would also need a tcl interface so on package installs you could set defaults

If each entry in the sudo table is an object you could have even more control. For example I could create a /manage directory under a package and control access just like /admin

 
 #####
    #
    # Make sure the user is authorized to make this request.
    #
    #####
    sudo::checkauth -url [ad_conn extra_url]

    if { ![empty_string_p [ad_conn object_id]] } {
      ad_try {
        switch -glob [ad_conn extra_url] {
            admin/* {
              permission::require_permission -object_id [ad_conn object_id] -pri
vilege admin

namespace eval sudo {
        ad_proc checkauth { -url } {} {

                ns_log Notice "sudo login $url"
                if { $url eq "admin/" } {
                set val ""
                if { [catch {set val [ad_get_signed_cookie sudo]} err] == 1 } {
                        set val ""
                }
                if { $val eq "" } {
                        ns_log Notice "sudo login $err"
                        ad_returnredirect "/sudo/login"
                        ad_script_abort
                }
                }
        }

        ad_proc addurl { -url } {} {
        }

}

} -after_submit {

    # We're logged in
    set age 300
    set key 300
   ad_set_signed_cookie -signature_max_age $age sudo $key
ds_comment "cookie"

    # Handle account_message

Obviously not complete but it works

So if someone of these folks is logged in and surfing the forums, he's entitled to do administrative tasks as well. Even worse if that person is surfing other sites, "dodgy" http requests may lead to "dodgy" requests on openacs.org.

So my analogy is: think Linux and you fire up firefox from your root account to surf the web.

(Windows users know that situation quite well: they usually use an "Adminstrator" account all the time)

Instead of trying to sanitize and parse html code to death we should just take Barry's sudo package and also add a switch to the form_builder and ad_page_contract to require a "second" login for pages where it seems necessary e.g. an order confirmation page or user-dependant "nuke" pages.

Would this require a TIP? Or is it considered a security fix ?

That is just wrong. Security is not just one thing. I don't see any reason to require a password for certain actions. Have you ever ordered something from Amazon.com?

Increasing the security of certain forms is a good idea. Requiring authentication for certain actions is a good idea. Improving the signing of variables is a good idea.

The way to secure against a unknown vunerability is to have security in layers. Site-wide admin actions such as granting site-wide admin privilege is the type of action that can require additional authentication.

Of course if you allow javascript, then you can issue multiple document.write statements to build a form and then submit that form.

If you forceably eliminate javascript, then post only checking should be sufficient? It's certainly more easily do-able than the other suggestions.

I also like Jonathon's method of putting a big ns_rand into an nsv of allowed "keys" and popping it out in the relevant admin pages.

Let's keep it simple if we can!

<Mark madly checks all his oacs sites for insecure antispam settings...>

• Drop my admin privilege for now, until I tell you otherwise.
• Turn on my admin privileges today (for X hours). [Requires password.]

By default, when an Admin logs in, he should have only the privileges of a normal user, because most Admins are also normal users of the site, and are usually logging to use the site, not to immediately start doing protected Admin activity. However, you might as well give Admins a checkbox on the log-in screen, defaulted to off, which says, "Enable my Admin privilige immediately, for the next 10 minutes."

Probably, when an Admin tries to do an admin-thing the system should ask him for his password and implicitly push a "Turn on my admin privileges for the next 10 minutes" button for him. However, it wouldn't be so bad just to deny the action and give him link to the "turn on my Admin privileges" page instead.

But if an Admin needs to, he should be able to explicitly enable - and leave enabled - his Admin-ness for some longer period of time. Depending on the site, this time should probably 1 to 24 hours.

And of course, very preferably, the "10 minutes" expiration time, just like with sudo, should be counted from the last successful Admin operation, not from the time it was turned on. This means if an Admin is admining away feverishly for 3 hours, the "10 minute" time will never expire until he's done. It's not absolutely critical, because an Admin should always be able to just explicitly turn on his privileges for longer instead, but actual real-world security will probably be better with the smart "timeout clock starts from last admin operation" feature.

to the site-master.adp file

and

if { [site_node::exists_p -url /sudo] } {
set sudourl [sudo::endsessonurl]
} else {
set sudourl ""
}

to site_master.tcl

http://trsvax.com/trsvax/apm/sudo-1.0b.apm

I propose a separate security forum, that is only for security updates and warnings. I know nobody likes having separate forums because it can fragment conversations, but the advantage is that nobody should have to follow any of the other forums if they only want security updates. And security updates are pretty manditory.

You don't need to disable all HTML, Kjell, just not allow * for HTML.

Is this something that the OCT is willing to discuss and make some decisions about?

If a remote page (called B) contains an img tag that GETs a URL on your site (called A), you GET this page on B, then you'll issue a GET request to your resource on A as well - with your credentials on A.

So HTML parsing WON'T solve this problem.

(However disallowing * will significantly reduce risk)

This is, in effect, a remote root compromise of any machine running OpenACS.

A security forum is a nice idea, but at a bare minimum, advisories should go to the usual places (bugtraq, etc.)

It's probably worth pointing out that this is by no means limited to OpenACS; someone brought up a similar point with PhpNuke in a posting to bugtraq about three months ago, and made the point that most web applications are affected by similar attacks. Unfortunately, there weren't any responses to it, let alone anything smart :). IMO, the sudo-style approach is the way to go (not necessarily with referer checks), as you can still send out emails to administrators with links to perform actions, e.g. approving requests etc. The super-paranoid could always set the time between reauthentication to 0.

Relying on the referer header and being able to turn that off is imho a very sane solution. It provides close-to-optimal security with a minimum of fuss, new code, and UI hassles.

The stuff you've implemented (plan to implement?) should become part of the stock distro of OpenACS with a default setting of enabled.

Most sites describe referer checking as the 90% solution mostly due to the cases where the requests are legimate, but turned down because of the reasons you gave above (link in an email, bogus proxies, etc)

I don't have commit privileges to CVS but I can send you the current version. There is a required change to the request processor and I also made a change to the template so you can tell when you are in sudo mode. If the package is not mounted then the system works as before.

Also I'll be out of town this weekend and without email

Let us know if you have an Oracle and Postgres version available. :)

1) String match should be faster than a regexp for that (on Tcl 8.4 anyway.)

2) OpenACS is not the first or only platform to break that rule. I believe we discussed changing the most serious actions to forms when someone had time to work on it.

It would be really nice to get this plugged! Any updates?