[freeside-users] Fwd: Freeside SelfService CGI|API 2.3.3 - Multiple Vulnerabilities

[Ivan Kohler]

On Thu, Jul 05, 2012 at 08:34:49AM -0500, Zachery Peres wrote:
> Anyone know a fix, or one in the works?

First I've heard of it.  We were not notified before publication.

> Or when there will be an official fix?

Looking over the advisory, 1.1 seems the most potentially troubling (SQL 
injection via selfservice.cgi).  I've tried the "proof of concept" and 
looked over the code in question, and I'm having a hard time seeing an 
actual problem here so far.

svcnum is searched for using a placeholder so the first "proof of 
concept" URL doesn't run any "injected" SQL, and the second PoC URL is 
even harder see any sense in: action is explicitly checked against a 
list of allowable values.

At first look, I think this section of the advisory may be in error and 
there is no real SQL injection issue, but I will continue to look 
carefully before stating that definitively.  More eyes / clarification 
is certainly welcome.

1.2 concerns cross-site scripting issues in the backend.  It affects 
folks with malicious/untrusted employees, or folks running Freeside in a 
multi-tenant capacity with similarly possibly-untrusted downstream 
company employees.  I don't believe this is particularly high-risk, but 
it will be corrected shortly.

1.3 concerns cross-site scripting issues in the self-service interface.  
Again I don't believe this is particularly high-risk, but there is the 
possibility it could be leveraged by an attacker to trick individual end 
users' browsers into doing things in the self-service interface.  

Realistically this would seem very tough to exploit in practice - with 
the session ID in the URL and expiring in an hour, the attack would have 
to work in conjunction with a browser "history sniffing" vulnerability 
and be carried out less than an hour after the user's last self-service 
visit.

It will also be corrected shortly.

I should emphasize that neither of these cross-site scripting issues 
expose data or allow any privledge escallation or changes.

A public/formal response will be published shortly.

> We could fix these ourselves for the time being.

Contributions are always welcome if you'd like to work with us on the 
codebase.  You know, open-source and all.  :)

-- 
_ivan