[freeside-users] Fwd: Freeside SelfService CGI|API 2.3.3 - Multiple Vulnerabilities
Ivan Kohler
ivan at freeside.biz
Thu Jul 5 15:32:48 PDT 2012
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
More information about the freeside-users
mailing list