Mit XPages lässt sich ein Domino Server auf einfachste Weise lahm legen, da man über die Java Runtime beliebige Threads starten kann.
Ein kleiner Button startet z.B. Notepad auf einem Windows Domino Server:
<xp:button value="Start NotePad!" id="buttonStartNotePad">
<xp:eventHandler event="onclick" submit="true"
refreshMode="norefresh">
<xp:this.action>
<![CDATA[#{javascript:
java.lang.Runtime.getRuntime().exec("notepad");}]]>
</xp:this.action>
</xp:eventHandler>
</xp:button>
Bei jedem Klick wird auf dem Domino Server einmal Notepad gestartet. Eine kleine Schleife, und auch ein großzügig dimensionierter Server geht in die Knie.
Richtig übel wird es allerdings, wenn dieser Button geklickt wird:
ACHTUNG! NICHT AUF PRODUKTIVEN SYSTEMEN AUSFÜHREN!
<xp:button value="KILL NOTES!" id="buttonKillNotes">
<xp:eventHandler event="onclick" submit="true"
refreshMode="norefresh">
<xp:this.action>
<![CDATA[#{javascript:
java.lang.Runtime.getRuntime().exec("nsd -kill");}]]>
</xp:this.action>
</xp:eventHandler>
</xp:button>
Dann ist der Domino Server weg!
Bei dem „zerlegten“ Server handelt es sich um eine Standard-Installation. Die java.policy wurde nicht geändert.
Ging mit LotusScript auch schon! Deshalb ist es wichtig genau hinzuschauen wer im Server Dokument das Recht bekommt XPages auszuführen. Das darf ja nicht jeder.
Verwundert hat es mich schon. Ich hätte erwartet, dass der SecurityManager hier etwas abblockt, und nicht, dass alles erlaubt ist. Zumindest auf dem Domino Server.
Eine Einstellung wie „Sign or run restricted LotusScript/Java agents“ wäre auch nicht verkehrt, wenn es die für XPages gäbe.
Bei Lotus Script ist m.W. kein Security Manager -Konzept vorhanden, wie es bei Java implementiert ist. Und das die IBM hier einfach mal den Security Manager hätte richtig konfigurieren können, anstatt einfach nur ein
grant codeBase „file:${notes.binary}/osgi/-“ {
permission java.security.AllPermission;
};
in die java.policy einzutragen, wäre in meinen Augen selbstverständlich gewesen.
P.S.
Mit Lotus Script war so etwas nicht möglich:
com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.getInstance().serverTerm();
😉
As with any system you need to manage who has the ability to make changes to the system to ensure that the system is secure.
To implement either of these buttons or any similar code you need the right to create code on the Domino server along with the ability to execute that code. As mentioned in other comments this is controlled via the server document and should be locked down to just the database signers that are trusted within your organization.
If your implementing an application from a third-party then you need to review that system before putting it in production and when you sign the database your basically giving it your seal of approval.
There are, however, cases where code similar to the above can actually be part of the application, obviously not to start notepad or run nsd-kill but for legitimate uses within the application. In one of my internal applications I make use of similar code to run an external file archive ( 7zip ) application.
It would only be a backdoor if your or one of your developers made it into a backdoor.
Yes, you are right: there are cases where external code can be part of the application. But if so, it would be the better way to *allow* this explicitly (via Java Policy), not to allow everything by default!?
It is normally not possible to review ALL components of a third party application., especially if there are JARs included etc. But theses JARs could easily do something harmful to the system. In my oppinion, if the policy would be set up correctly (restrictive), the third party app would not be able to execute something. Currently, it is possible, and this makes a review more complicated.
As far I can say, it is already a backdoor, opend by IBM, and all developers have to be very carefull not to open this to the rest of the world.
Just my two cents…
Hi,
I can’t see how this is a „backdoor“. You have created code that will execute on the server. You then have to put that application onto your server, sign it with a signature that is allowed to run code on your server (and marked to allowed to run XPages).
But this is a good example why you never let developers near your production machines. All code execution should be controlled by the administrator and have a change request logging system in place.
It is fine that all the code execution is controlled by the administrator and a change request logging is always a good idea, but what about a code injection into JSF? Do you think that this is not possible if an administrator has signed the database instead of a developer?
The attacker would have the full control about the machine, just because the XPages are running with full rights in the JVM (and I don’t think that this is required).
This is a high security risk in my opinion.
> but what about a code injection into JSF?
Code injection is a different issue and I do not see an example of it here.
If the code could be injected, it would also need to be signed with a signature that has been given XPages execution rights on the server, or it will not run (will display as XML instead).
The intention of writing this blog entry was not the example listed above: Mainly I have posted this because I was very confused that there are no security restrictions set to XPages excecution in the JVM.
If code will be injected during runtime and that is why it is not required to sign this code. The affected XPage is checked if there is a valid signature, but the injected code would run without restriction.
I have no working example – for me, it is enough to know that this *could* happen. If the JVM would have restrictions set up correctly, this would be no problem.
But this is not the case. I would be very happy if someone could explain to me why this limitations are not set up by default.
I am not aware of any way to inject the code above without already having access to the system to begin with (but if such a system existed, yes that would be an issue).
The Domino server requires the code to be signed, and to do that you need the private key of the signature. Which is not possible to get unless you have the ID as well, in which case you can run anything you want on the server without the administrator.
So you would need to be able to write a design element to the database, sign that design element before the code will compile+execute on the server.
But if you believe this to be an issue, can you open a PMR with IBM?
This is just a simple example that code can be added during runtime.
OK, never use the eval-Statement as in this example, but this should just demonstrate what can be done without signing the code:
< ?xml version="1.0" encoding="UTF-8"?>
< xp:view xmlns:xp="http://www.ibm.com/xsp/core" >
< xp:button value="Label" id="button1" >
< xp:eventhandler event="onclick" submit="true" refreshMode="complete" >
< xp:this.action>< ![CDATA[#{javascript: var code = getComponent("inputText1").value; if( code == null ) return; eval(code);}]] >
< /xp:this.action >
< /xp:eventhandler >
< /xp:button >
< xp:inputtext id="inputText1" value="#{viewScope.Test}" / >
< /xp:view >
Now, open the page, enter java.lang.Runtime.getRuntime().exec(„notepad“) in the field and press the button.
On the server, notepad will be started.
In JSF 2.0 there is a vulnerability for code injection as described here, just to give you an example that there are existing security flaws for JSF.
I’ve passed the JSF link onto XPages development (in case they are not already aware of it). Thanks.