when I upgrade openfire to 4.7.5 the cmmoand :curl -v -H “Authorization: ${password}” -H “Content-Type: application/xml” -X POST http://localhost:9090/plugin/restapi/v1/users always redirect me to login page, here is the curl command response :
My Question is that is there any setting for us to set ?
I found some error in back-end logs
java.sql.SQLSyntaxErrorException: user lacks privilege or object not found: ENCRYPTED in statement [INSERT INTO ofProperty(name, propValue, encrypted, iv) VALUES(?,?,?,?)]
at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.jdbc.JDBCPreparedStatement.<init>(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.jdbc.JDBCConnection.prepareStatement(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.apache.commons.dbcp2.DelegatingConnection.prepareStatement(DelegatingConnection.java:696) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at org.apache.commons.dbcp2.DelegatingConnection.prepareStatement(DelegatingConnection.java:696) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at org.jivesoftware.util.JiveProperties.insertProperty(JiveProperties.java:357) [xmppserver-4.7.5.jar:4.7.5]
at org.jivesoftware.util.JiveProperties.put(JiveProperties.java:290) [xmppserver-4.7.5.jar:4.7.5]
at org.jivesoftware.util.JiveGlobals.setProperty(JiveGlobals.java:833) [xmppserver-4.7.5.jar:4.7.5]
at org.jivesoftware.util.SystemProperty.setValue(SystemProperty.java:357) [xmppserver-4.7.5.jar:4.7.5]
at org.jivesoftware.openfire.update.UpdateManager$1.run(UpdateManager.java:174) [xmppserver-4.7.5.jar:4.7.5]
Caused by: org.hsqldb.HsqlException: user lacks privilege or object not found: ENCRYPTED
at org.hsqldb.error.Error.error(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.error.Error.error(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.ParserDQL.readSimpleColumnName(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.ParserDQL.readSimpleColumnNames(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.ParserDML.compileInsertStatement(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.ParserCommand.compilePart(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.ParserCommand.compileStatement(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.Session.compileStatement(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.StatementManager.compile(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
at org.hsqldb.Session.execute(Unknown Source) ~[hsqldb-2.4.1.jar:2.4.1]
The error seems unrelated to the REST API issue. The REST API issue that you are experiencing is caused by an additional level of security that was added in Openfire 4.7.5, in reaction to our fixes for CVE-2023-32315.
The new configuration properties that were added as a result of that can interfere with the functionality of certain Openfire plugins. This is especially true for plugins that bind a (web)endpoint to the embedded webserver that serves the Openfire administrative console, like current versions of the REST API plugin do. For these plugins to remain functional and/or reachable, it might be required to toggle the property adminConsole.access.allow-wildcards-in-excludes to true , and to avoid binding the embedded webserver to the loopback network interface only.
If the admin console is unreachable to you, then this could be caused by some kind of networking issue in your local network. As a work-around, you might be able to log into the admin console from a browser on the server on which Openfire is installed, by going to either:
it will always redirect me to the login page, Can u help check if the command has something wrong. This command can work in 4.7.4, but when I upgrade to 4.7.5, it will failed.
I suspect that you need to set the property adminConsole.access.allow-wildcards-in-excludes to true. If you have already done this, please make sure that you did not have typos.
By setting adminConsole.access.allow-wildcards-in-excludes do we make 4.6.8 susceptible to CVE-2023-32315 again?
Apologies if I’m misunderstanding.
I’ve patched to 4.6.8 and experience issues with REST API.
If allowing wildcards makes system vulnerable again, I wonder if my safest option is to not patch to 4.6.8. Instead, just make changes to AuthCheck in plugins/admin/webapp/WEB-INF/web.xml ?
No. In 4.6.8, multiple layers of protection against this particular vulnerability were added. By switching that setting, you’re undoing one of them. The fixes for the root cause (incorrect URL decoding) will remain in place.
After setting adminConsole.access.allow-wildcards-in-excludestrue and restarting the Windows Openfire service, debug log showed “Unable to get user: no auth token on session” when trying to use RestAPI with ‘secret key auth’
As a test, I switched REST API config to basic auth, restarted service, and saw same error.
However, when I switched REST API config back to secret key auth and restarted service, REST API started working again.
As a final test, I set adminConsole.access.allow-wildcards-in-excludes back to false
REST API would not work with this setting.
Thanks for all your help. Confirming I have working REST API 1.6.0 on Openfire 4.6.8, secret key auth and adminConsole.access.allow-wildcards-in-excludes set true
Nothing special on the command line, e.g. curl -v -H 'Authorization: ...' -H 'Content-Type: ...' -X GET '.../plugins/restapi/v1/users' style
Maybe a lack of cookies perhaps? Not sure, I’ve never much delved into the session or cookie management side of test code and production code - except to note that it doesn’t appear to have or rely on any.
I spent three days being completely lost until I finally found this topic. I confirm that the setting on adminConsole.access.allow-wildcards-in-excludes finally fixes the issue.
However, this was pretty painful, because even on a new fresh installation the REST API plugin simply does not work. At a minimum I think the README of REST-API should specify this fix or something.
I had to upgrade because we were hit with the security vulnerability, and as I was desparately trying to find a solution to upgrade, I got lost doing many different tests. Can we contribute (if nothing else, then the README PR) to make this clear for anyone else wanting to use the API plugin?
With this setting true and with all openfire versions after 4.7.5 the issue is comming back after some time (minutes or hours). The login page is the response for all restapi requests
When the plugin is reloaded the issue is resovled.
We manage to resolve it with a “dirty” solution by restarting the plugin every 5 minites with a cron job like : */5 * * * * touch /usr/share/openfire/plugins/restAPI.jar
Any assistance you can provide would be greatly appreciated.