Trying out Openfire 3_10_2 for the first time. Testing on a Windows 8 desktop and it installs OK until I need to set password and admin login… Taking the simplest route of embedded database and default user and group system. At the menu for the default admin password, email, new password, it fails like this:
“There was an unexpected error encountered when setting the new admin information. Please check your error logs and try to remedy the problem.”
The openfire log is blank and the windows log does not show problems. Tried uninstall reinstall. Tried shutting off firewall.
Are you installing into Program files folder? This can be due UAC protection. Try running Openfire launcher (if using one) via Run as administrator or installing into C:\Openfire.
Relocating a folder will save you time in the future if you (or you colleagues) forget to run it as admin. I have moved my installations of Openfire to C:\ to not deal with UAC anymore.
Thank you for pointing that out. Right now I am testing in fake environment but I will remember this for deployment. Your advice is very much appreciated.
Nobody is insisting on that. This software started long before UAC, so historically it was like that (there were no such problems with XP\Server 2003). Also, as it is a multi-platform software, it was probably easier to keep things similar, no matter on what system it runs (Linux\BSD\Windows\Mac).
Now, Openfire and all other projects don’t have any company behind them for many years. There are only a few volunteers doing some stuff on their free time. Many of them don’t use Windows, so they don’t have incentive to change that. But this is an open source project, so anyone is free to propose a patch. The least i (as not a developer) was able to do is to point out this issue in the installation guide. Well, and help with that in the forums.
Making it configurable won’t help much as many users tend to not read documentation or messages during the setup. So, i think a patch should just change the location to %AppData%\Openfire\conf. Not sure about the embedded database though. It kind of feels wrong to put the DB into appdata, but most of the production will use a remote database probably. That said, this patch should also have a backwards compatibility for all the current installations. Like at some point Spark’s profile folder has been moved to AppData and it has a code to import stuff from the old place.
Personally i don’t have problems with installing into C:\Openfire (one doesn’t have to play by MS “rules”). As i use embedded database i just have to copy one folder for backup, it is easier to navigate than going to AppData. Maybe it is even easier to just modify the Windows version of install4j installer to default to C:\Openfire (not sure if this is possible).
First of all let me apologize for the way my post sounded, I realize now that it came out wrong. I was merely trying to emphasize how after all these years most people miss the whole point of UAC and how it enhances security.
I do realize this is an open source project and based on volunteer work (I myself have volunteered in another open source project and know how you feel). Unfortunately I don’t have any experience in Java and no free time to help.
Making it configurable is a first step. This will allow some flexibility. For example existing installations don’t need to change the data location. Also systems that don’t impose data/code separation may keep data with the code as is the case currently. The second step of course would be to change the installer to default to %AppData%\Openfire for Windows installations. For upgrades it could even offer to move data from its current location to AppData. Regarding the DB, it should be in AppData as well (MySQL does the same IIRC).
As for installing into C:\Openfire, it has nothing to do with playing with MS “rules”. It’s all about security. And since this is a server software, and one that may be open to attacks, it is best to take all measures to prevent those attacks. UAC and the code/data separation prevents many code injection attacks by design. As a matter of fact linux also uses a similar principle to UAC (sudo) but the code/data separation is easier to overlook as there is no standardization (i.e. standard locations that are write protected and designated for executable exclusively), leaving the choices and all the work to setup the necessary permissions up to the developer.
I prefer to use every tool I have at my disposal to make sure my server is not compromised and Openfire currently does not help at that. Installing into C:\Openfire is insecure. The same goes for running Openfire with administrative rights.
Well who knows, maybe if I get some free time I refresh my Java skills and try to provide a patch.
Edit: I did have a quick look at the code and it does seem to be possible to configure the “home” path. That is where the conf directory is, but I am not sure what else is supposed to be in the home directory plugins also live in the “plugins” directory under the home directory. As far as I can tell you can either set the “openfireHome” system property (whatever that means) or create an openfire_init.xml file containing the path of the home directory. However since conf (data) and plugins (code) both live in the same home directory it requires quite more work to do the separation and it certainly requires extensive testing to make sure no code makes any assumption on the relative location of data and code.
Most production environments would use Openfire as a service, which is running with Local System account permissions and has no problem writing into Program files folder, so no UAC warning is shown nor one has to run anything As administrator. In that case i don’t see difference in what location Openfire is installed. Windows Service is already mentioned in the installation guide, but maybe it should be emphasized in the beginning of the guide.
As about code injections. What scenario exactly do you have in mind? A hacker gaining access to the system exploiting OS vulnerability and modifying applications sitting in C:\ as opposed to Program files? I suppose UAC might theoretically help in such case, though there were a lot of UAC bypassing techniques discovered over the years. And the hacker would still be able to access AppData and alter\damage data, if config and database are stored in there. I think in that case it’s not so important what hacker can or cannot reach, the whole system is already compromised and that’s the main point. Another scenario that i could think of, is that a client sends to a server malformed xml (or injecting something into URL while accessing Admin Console) which server will interpret incorrectly and this code would damage something on the system. This scenario sounds like very unlikely in my opinion. And it would probably be a DEP task to prevent damage in such case, not UAC.
Most production environments would use Openfire as a service, which is running with Local System account permissions and has no problem writing into Program files folder, so no UAC warning is shown nor one has to run anything As administrator. In that case i don’t see difference in what location Openfire is installed. Windows Service is already mentioned in the installation guide, but maybe it should be emphasized in the beginning of the guide.
Actually a windows service should not run as Local System unless absolutely necessary. In this case if Openfire where installed so that data is in AppData and code in ProgramFiles, there would be no need to run as Local System. It could run as Local Service, Network Service or its own restricted account. So again installer goes against security best practices ( and yes, linux also suggest that daemons run under a user with the least possible privileges - but that is usually up to the admin to configure properly, although some installers do create least privilege users or even jailroot and/or containers)
wroot wrote:
As about code injections. What scenario exactly do you have in mind? A hacker gaining access to the system exploiting OS vulnerability and modifying applications sitting in C:\ as opposed to Program files? I suppose UAC might theoretically help in such case, though there were a lot of UAC bypassing techniques discovered over the years. And the hacker would still be able to access AppData and alter\damage data, if config and database are stored in there. I think in that case it’s not so important what hacker can or cannot reach, the whole system is already compromised and that’s the main point. Another scenario that i could think of, is that a client sends to a server malformed xml (or injecting something into URL while accessing Admin Console) which server will interpret incorrectly and this code would damage something on the system. This scenario sounds like very unlikely in my opinion. And it would probably be a DEP task to prevent damage in such case, not UAC.
It has nothing to do with OS vulnerability, it has everything to do with application vulnerability. If a hacker would exploit some application vulnerability, with UAC and the application running under an unprivileged account, all he could to do is mess with the application data. Yes this is bad in itself, but other applications will be unaffected, the OS itself will be unaffected and other systems on the same network will be unaffected. A good backup strategy will get you back in business in no time. If however a hacker exploits an application running under a privileged account (Administrator, LocalSystem etc) he can install executable code, replace system files, attack other systems on the same network using the credentials of the privileged account, or extract sensitive data. He can bring the whole system down but most probably he will take control of the system and use it to attack other system (even unrelated ones). He would do this to hide his identity and/or attack a system that trusts the compromised server (more than a random host on the internet).
BTW DEP does help with some exploits but it no “cure all” type of thing, just an extra measure.
PS: Even in linux, the typical location for log files is /var/log (or similar), yet openfire chooses to write its log files in the application directory !
If however a hacker exploits an application running under a privileged account (Administrator, LocalSystem etc)
How does installing into Program files can help with that in the current situation, when Openfire is being run as Administrator when installed into Program files or as Local System in either location?
It is not installing in Program Files that helps. It is the separation of data from code.
Installing at C:\Openfire won’t be as bad as running as Administrator or LocalSystem. It does however open an attack vector: you are allowing the system to run code from a location that is not write protected for regular users (C:\Openfire), so an attacker may place ANY executable code in C:\Openfire and run it. An application exploit might have limited potential for running arbitrary code but may be enough to replace certain Openfire binaries.
What i meant is that installing into Program files currently is not providing additional security as the application is already running with the elevated privileges and application exploit would be able to add any code to Program files folder as easy as to C:\Openfire. I’m talking about the current situation to see what is better to suggest users and how to update the documentation. When i suggest to install Openfire into C:\ for me it is obvious, that it shouldn’t be available for regular users. But, maybe not for everyone I have removed that suggestion from the documentation.
Trying to wrap my head around all the changes that are needed to fix the current situation i see that it won’t change any time soon. You’ve already mentioned config, logs and plugins. There is also an embedded database (if used), audit logs (if used), certificates security store and probably other things that i don’t know which live in the Openfire folder. Separating everything and also making sure it works for all platforms seems like a huge task.
So in the meantime the most secure way to run Openfire on Windows it seems is installed into C:\ and running with launcher as a non-administrative user. But of course, this is not convenient. When using as a service it can be installed in either location, but it will run as Local System, so one will have to keep that in mind. Maybe it is easier to change the service installer to make it run as Local Service or Network Service (not sure if this will work fine when running from Program files). If it won’t run correctly from Program files (without data separation) as Local Service/Network Service, then change the default installation path to C:\Openfire and suggest that in the documentation. I mean, until the proper separation is done (if ever).
And of course the usual security measures: restricting access to Admin Console with firewall/proxy/other tools, restricting access to the server hosting Openfire.
IMHO, the best (temporary) solution is to install by default in C:\Openfire, run as service using Local Service and set proper permissions in home directory and subdirectories. Now setting proper permission is the hard part. You want full access for local administrators, read-only access for all other users and read/write access in select subdirectories (conf, embedded-db, logs) for Local Service.
I could go as far as suggest that after initial configuration, even conf subdirectory should be changed to read only, but that may not be possible - I don’t know if Openfire writes to that subdirectory under normal operation.