Utilisation et diffusion de ce document
Les avis de sécurité du consortium ESUP-Portail portent sur des vulnérabilités des logiciels diffusés par le consortium. Il est de la responsabilité de chacun des destinataires de ce document de ne pas le rediffuser en dehors du cadre pour lequel il a été écrit, pour des raisons évidentes de sécurité des Systèmes d'Information de tous les établissements du consortium ESUP-Portail.
Vulnérabilité dans uPortal
Date de la première version
25 juillet 2007
Date de la dernière version
16 octobre 2007
liste de diffusion jasig-members du consortium JASIG
Diffusion de cette version
Usurpation de l'identité des utilisateurs dans uPortal par récupération de l'identifiant de session.
- Toutes les distributions uPortal depuis la version 2.1
- Toutes les distributions uPortal-esup
uPortal est distribué avec une configuration proxy qui autorise une attaque de type Cross Site Scripting (XSS).
- Installer les classes du correctif ESUP-2007-AVI-003-COR.zip dans les sources de uPortal. Le correctif peut être téléchargé depuis le site web du consortium ESUP-Portail (http://www.esupportail.org)
- Positionner la propriété org.jasig.portal.serialize.ProxyWriter.resource_proxy_enabled du fichier portal.properties à off.
- Commenter ou supprimer la servlet HttpProxyServlet dans le fichier WEB-INF/web.xml
- Redéployer uPortal
- Redémarrer Tomcat
XSS Vulnerability Proxy Exploit Notification
William G. Thompson, Jr. <email@example.com>
30 août 2007
This is a private notification of an identified uPortal security vulnerability and workaround. JA-SIG intends to reach as many known uPortal adopters as possible with this information privately prior to public announcement. Public announcement will be made approximately 2 weeks from this notice.
All versions prior to uPortal 2.6.0, including 2.1, 2.2, 2.3, 2.4, 2.5.
uPortal ships with a proxy servlet allowing it to proxy over SSL content that would otherwise be vended in the clear so that the annoying "Mixed content" browser advisory message can be avoided. While some (many?) uPortal deployments are not intentionally making productive use of this servlet, its default configuration is to be nonetheless latently available and so available for exploit using a cleverly crafted URL. You can turn off the feature of proxying resources via the portal.properties property org.jasig.portal.serialize.ProxyWriter.resource_proxy_enabled but this will not turn off the vulnerability. When this feature is deliberately used, its use involves detecting URLs needing to be rewritten via a SAX filter and re-writing them to point at the proxy servlet which then proxies the originally intended content.
The web proxy channel's proxying of URLs specified at runtime is already throttled by configuration parameters added to address a previous security vulnerability (that of illicitly proxying local files). Portal administrators should configure each web proxy channel instance as restrictively as possible, such that only trusted content is included within the scope of allowable proxies. Web proxy channels configured such that they will proxy arbitrary content provided by the Adversary can in theory be exploited to execute crosssite-scripting attacks.
Http proxy servlet
The uPortal Http proxy servlet will no longer proxy any content other than elements with a mime type of
image. Two changes are involved:
Summary: Applets, IFrames and Scripts are no longer rewritten by the serializer to use the proxy servlet.
Description: when uPortal serializes its response to the browser it passes the response through a filter (org.jasig.portal.serialize.ProxyWriter) which inserts additional URL path elements as configured by the property, org.jasig.portal.serialize.ProxyWriter.resource_proxy_rewrite_prefix. In the past the ProxyWriter class operated on 6 elements: "image","img","script","input","applet","iframe".
The patched version will operate on three element types only: image, img and input. Although it may be convenient to proxy other elements to avoid the mixed content message, this vulnerability response opts for a simpler approach of avoiding entirely these other types of content proxying.
This change comports the proxy writer behavior with the now-more-restricted scope of the HttpProxy servlet -- this change to ProxyWriter does not itself secure anything, as the nature of the exploit is to generate proxy servlet instructions by means other than the proxy writer.
Summary: HttpProxyServlet will respond with an error code (404) and no content for all objects that do not have a MIME type that begins with: "image".
Description: this internal proxy handles requests for the proxied embedded content as the browser renders the response. Previously, the proxy servlet would proxy most anything. With this change, the proxy servlet will proxy only images. Returning only elements with proper mime type of image the browser is able to protect
itself from illicitly proxied scripts -- in order for the servlet to proxy, the content must appear to have a mime type of "image", which will discourage the web browser from executing the content.
Alternative solutions for resource proxy
uPortal deployers should consider running external standalone web proxy solutions, such as Squid. External dedicated proxy solutions have their own security issues and configuration needs, but these tend to be well documented and worked through by a larger community dedicated to the problems of proxying. uPortal 2.6.0 GA ships with a fix similar to the attached patches, pre-applied. An alternative to patching an existing install to deal with this issue is therefore a full upgrade to uPortal 2.6.
Configuration to block the exploit in Web Proxy and CGenericXSLT channels
The uPortal Web Proxy and CGenericXSLT channel includes features for restricting the URLs a channel instance will proxy, as implemented in a previous security fix. uPortal deployments must configure all web proxy and CGenericXSLT channel publications with a maximally restrictive match prefix. For example, if a web proxy instance proxies a remote application at
that links to other parallel paths like
but not like
An appropriate URI match prefix would be:
This would prevent the channel from proxying content at
even if a user were to be convinced by the Adversary to click an external link illicitly instructing the channel to proxy that URL.
Replace HttpProxyServlet.java and ProxyWriter.java in your local uPortal source tree with the attached files. Rebuild and re-deploy your uPortal. Rebuilding your uPortal class files with this updated source is the recommended way to address this exploit in your local uPortal environment.
Replace HttpProxyServlet.class and ProxyWriter.class with the attached .class files intended for use in uPortal 2.5.x. When using this approach, you'll need to also fix the issue in your local build environment (e.g. by replacing the .java files as described previously) so that when you perform a new build, the exploit remains fixed.
If you applied a previous patch for this issue, you will first need to undo the steps you performed in applying that patch before applying these steps and this patch.