Mal was altes. Die verlinkte Security-Meldung bezeichnet die freie Anlegbarkeit von Accounts auf Radio Community Servern (gilt so für alle xmlStorageSystem basierten Server, also z.B. auch für die Python Community Server) als grosses Sicherheitsloch und empfiehlt allen Nutzern ihre Community Server abzuschalten.Liest man sich das ganze durch, so ist das Problem folgendes: jeder kann sich per XMLRPC (das wird ja von den Clients benutzt) über das xmlStorageSystem API auf einem Community Server einen Benutzer anlegen und den mit Inhalten füllen. Im Ergebnis bedeutet das, das dadurch natürlich jeder beliebige Files auf den Community Server legen kann. Horror für viele Systemadministratoren. Für mich ist das ein klassischer Konflikt zwischen offenen Systemen (jetzt nicht im technischen Sinne, sondern im Sinne der Kommunikation) und geschlossenen Systemen. Vertreter der geschlossenen Systeme werden natürlich immer auf die mit offenen Systemen verbundenen Sicherheitsprobleme hinweisen. Vertreter der offenen Systeme werden natürlich immer auf die mit geschlossenen Systemen verbundenen Hürden der Kommunikation und Nutzung hinweisen. Beide haben Recht.
Aber was genau passiert, wenn ein solches offenes System missbraucht wird? Im Prinzip werden natürlich Daten verteilt. Es gibt keine direkten Verantwortlichen, da ja die Daten bei der technischen Anmeldung gefälscht sein können. Der Administrator muss im Nachhinein reagieren - jemand weist auf illegale Inhalte hin, der Administrator sperrt den entsprechenden Account (und damit alle Dateien, die dort liegen). Das ist natürlich in der heutigen paranoiden Zeit für viele nicht sicher genug - aber ist es wirklich so katastrophal, wie es in der Security-News beschrieben wird?
Was ist mit Wikis - jeder kann alles da hinenschreiben. Manche Wikis erlauben Dateianhänge - damit kann jeder Files hochladen. Was ist mit Forensystemen wie Advogato, Kuro5hin oder ähnlichen - jeder kann da alles reinsetzen, teilweise sogar anonym. Alles offene Scheunentore? Oder ist es nicht vielleicht einfach so das es Systeme gibt, bei denen die Offenheit schlicht und einfach ein Feature ist?
Natürlich, jedes der offenen System wird irgendwann mal von Clowns missbraucht, die meinen das es absolut cool ist überall virtuelles Geschmiere zu hinterlassen - nahezu jedes grössere Wiki durchläuft diese Phase mehr als einmal. Dazu gibt es dann passende Mechanismen um solche Aktivitäten rechtzeitig zu bemerken und die entsprechenden Massnahmen zu ergreifen - teilweise muss man dann eben für eine Weile das System restriktiver betreiben. Aber das ganze dann auf Dauer nur mit Schutzmauer und dickem Stacheldraht?
Wollen wir uns tatsächlich nur noch gegen Vorlage des Personalausweises und polizeilichem Führungszeugnis der Welt öffnen? Irgendwie ist mir das zu öde, sorry. Ich habe also weiterhin - entgegen der Empfehlung aus dem referenzierten Artikel - einen offenen Community Server, auf dem jeder sein Blog selber anlegen kann. Denn dafür ist der Community Server nunmal da.
earl Oct. 3, 2003, 1:39 a.m.
"Beide haben Recht."
exactly. und sich so wie du kritisch mit der situation auseinanderzusetzen und aus "beide haben recht" das persoenlich richtige zu waehlen, ist auch der einzig vernuenftige weg.
eine ganz kurze diskussion: klassische wikis sind mit der rcs situation nicht zu vergleichen; "jeder kann alles da hineinschreiben" ist von der dimension ganz anders als ein oeffentlicher fileserver. von diesem aspekt her ist offenes system auch nicht gleich offenes system. die offenheit muss von system zu system neu evaluaiert werden und kann leider nicht a'la "wikis gut, alles offene gut" pauschaliert werden. [wikis mit vergleichbar offenen moeglichkeiten dateianhaenge betreffend sind allerdings in vergleichbarer situation zum rcs].
anonymous ftp server (mitsamt upload moeglichkeit) und andere public fileserver waren eine lange zeit durchaus ueblich. allerdings hat die warez-szene hier mit der zeit unglaublich massive probleme bereitet, der untergang von "free internet storage" providern wie freedrive, x-drive und wie sie nicht alle hiessen ist eindrucksvolle macht-demonstration der warez-szene. die gecrackte iso irgendeiner aktuellen software in 5mb paketen auf einem oder mehreren community server clones liegend, koennte diese sehr schnell traffic-maessig in die knie zwingen. von legalen folgen ganz abgesehen ...
nichtsdestotrotz - es bleibt eine persoenliche entscheidung. um diese allerdings ueberhaupt erst treffen zu koennen, muessen userland kunden (wie zB salon.com) oder auch community server clone benutzer ueber die potentiellen risiken informiert sein. und genau das ist sinn solcher security bulletins.
hugo Oct. 3, 2003, 12:32 p.m.
Tja - aber ein Problem gibt es dabei schon, bei dem Bulletin: es ist extrem einseitig und ignoriert komplett den IMO wesentlichen Aspekt der gewollten Funktion. Schliesslich ist es definierte Aufgabe des Community Servers, das jeder ein Blog dort anlegen kann und mit Inhalt füllen kann.
Ich sehe da eine Reihe von Probleme mit der Haltung wie sie im Bulletin eingenommen wird:
- freies Einstellen von Informationen ist auch heute nicht unüblich. Zum Beispiel kann jeder Anwender auf deinen privaten Rechner illegale Inhalte einstellen, völlig ohne Probleme. Wenn du was dagegen hast, musst du eMail verbieten :-)
- der Community Server erlaubt mitnichten jedem Inhalte einzustellen. Nur jedem, der einen Account hat. Was besonders ist, ist die Erlangung dieses Accounts: es geht per programmatischem Interface. Aber 99% aller Websysteme mit Accounts erlaubt das auch - ein HTTP POST zur Anmeldeausfüllung ist sehr einfach automatisierbar. Wir müssten also erstmal alle Web-Systeme mit Benutzeraccounts verbieten (nahezu alle Portalsysteme erlauben Usern eigene Bereiche mit eigenen Informationen - z.B. alles was auf Zope CMS oder Plone aufsetzt, um nur mal eine im Moment recht beliebte Variante zu erwähnen)
- eine zusätzliche Prüfung der Anmeldung ist eine Scheinsicherheit. Wenn du echte Sicherheit willst, musst du eine Personalienprüfung machen, am besten mit Ident-Verfahren, die Bonitätsprüfung nicht vergessen (was nützt es dir, wenn du den Schaden nicht vom Verursache beglichen bekommen kannst?) und eine Historienprüfung des Benutzers im Web, um eine Risikoeinschätzung zu haben. Und das polizeiliche FÜhrungszeugnis nicht vergessen. Und vielleicht noch die politische Ausrichtung? Und selbst dann kann es sein das der harmlose Lehrer mit 20 Jahren im Beruf, keinen Auffälligkeiten, geregeltem Einkommen und erstklassigem Leumund ein ganz übler Kinderficker ist.
Von daher halte ich das Bulletin für alles andere als Hilfreich, eher für eine ziemlich üble Aufbauschung. Vermutlich war da jemand wegen Dave Winer angepisst (eine nicht ganz unübliche Reaktion auf Dave Winer ist es ihn zu hassen ;-) ) - und die Nicht-Reaktion von Userland hat da natürlich nicht gerade geholfen.
Es gibt _sehr_ gute Gründe für die Art und Weise wie die Community-Server arbeiten. Und das hat mit Security nichts zu tun - sie sind nicht sicherer oder unsicherer als andere Systeme mit komplizierterem Workflow. Sie sind aber sehr viel bequemer im Betrieb und in der Benutzung. Letzteres ist sicherlich mit ein Grund warum gerade über Radio so viele Weblogs entstanden sind.
Die Unsicherheit liegt nicht wie im Bulletin behauptet im Design von xmlStorageSystem - das ist Quatsch. Danach wären alle Protokolle und Systeme mit anonymem oder Pseudo-Anonymen (über Fake-Accounts auf Drittsystemen wie Webmailern) unsicher, somit nahezu das gesamte Web was Portale etc. angeht. Kein Mensch hat aber ein Bulletin geschrieben das Slashdot unsicher ist, und abgeschaltet werden solle, weil man sich dort anonym seine Inhalte reinstellen kann (Texte können ja auch ohne weiteres illegale Inhalte enthalten!).
Die Unsicherheit liegt in den Dateninhalten selber - sobald illegale Inhalte transportiert werden, gibt es mit _jedem_ Protokoll oder System Probleme. Stell dir nur vor, das jemand dir Mails mit (unverlangter!) Kinderpornographie schickt. Die geht in dem Wust an Spam unter. Und er zeigt dich bei der Polizei an. Die findet die Mail. Klar, hypothetisches Szenario, aber nicht zu abwegig - würdest du deshalb eMailing verbieten?
Von daher ist das Bulletin in seiner Form wie es geschrieben ist eher polemisch gegen RCS und verwandte Systeme, als wirklich Aufklärung über eine Sicherheitslücke.
earl Oct. 3, 2003, 5:53 p.m.
das design von xmlStorageSystem erlaubt programmatische ausnutzung die zB bei der warez distribution potentiell extrem hilfreich ist. prinzipiell ist die nutzbarkeit des RCS der eines public anonymous ftp mit upload moeglichkeit gleichzusetzen. das ist ein faktum.
wie im ersten kommentar schon angemerkt: jedes system das vergleichbare registrations- *und* file-uploadmoeglichkeiten bietet, offenbart aehnliche risken. und wie auch schon im ersten kommentar angemerkt: die potentiellen risken von freier texterstellung sind bezgl traffic (und das ist nun einmal das hauptpropblem bei public file servern) mit den risken freier file-uploadmoeglichkeiten nicht vergleichbar.
die von dir als problematisch kritisierten haltung des bulletins kann ich nicht nachvollziehen. alle der von dir angefuehrten punkte kann ich im kontext des bulletins nicht herauslesen. das bulletin informiert ueber ein potentielles risiko und bleibt dabei durchaus neutral bezgl der evaluierung dieses risikos im persoenlichen kontext des lesers.
das der "wesentliche Aspekt der gewollten Funktion" komplett "ignoriert" wird, ist schon gut so, die kenntnis der gewollten funktionalitaet ist bei RCS kunden ja durchaus vorrauszusetzen.
einzig die bezeichnung der vulnerability als "design flaw" mag ein wenig harsch sein. die nachfolgende empfehlung an kunden "to shutdown their Radio Community Servers immediately" betrachte ich als durchaus gerechtfertigt in anbetracht des potentiellen risikos. sollte eine persoenliche evaluierung feststellen, dass im evaluierten umfeld die vulnerability nicht relevant ist, dann ist eh alles ok.
wird in einer konkreten situation allerdings die gefahr auf einmal gecrackte win2003 server isos ueber die eigenen server zu verbreiten als real bewertet, dann ist die abschaltung der RCS server (oder zumindest das unterbinden der freien registrationsmoeglichkeit) bis zur problemloesung wohl der einzig gangbare weg.
deine analyse von scheinsicherheit und der "_sehr_ guten Gründe für die Art und Weise wie die Community-Server arbeitet" moechte ich gar nicht werten (dh weder widersprechen noch zustimmen) - in meinen augen ist diese entscheidung eine von jedem RCS-benutzer selbst zu treffende.
hugo Oct. 3, 2003, 7:01 p.m.
Sorry, aber es ist eben *keine* Vulnerability. Die Sicherheit des Servers wird in keiner Weise kompromittiert, keine Userdaten werden kompromittiert und es gibt keine Relay-Funktionalität, die irgendeinen anderen Angriff verschleiern könnte - es gibt nur eine (im Protokoll öffentlich definierte) Funktionalität, die durch die Art der Nutzung potentiell Probleme im juristischen Umfeld macht. NDas hat aber nichts mit Vulnerability zu tun!
Ich denke schon das es Sinn macht wenn sich Security-Bulletins auf die _Betriebssicherheit_ im technischen Sinne beschränken. Angriffe auf das System mit denial of Service, mit Datenausspionieren, mit Fakes von angeblich validen Verbindungen mit dem Zweck der Datenspionage, mit Angriffen auf Clientsysteme die sich darauf verbinden oder ähnlichen Szenarien beschäftigen. Das Bulletin geht aber in keinster Weise auf diese Punkte ein. Durch die gewollte Funktion des Community Servers wird weder der Server noch der Client in irgendeiner Weise in seiner Funktion beeinträchtigt.
Von daher ist die Forderung nach der Abschaltung im Bulletin völlig überzogen, genauso wie von einem Design Flaw zu reden. Wie gesagt, die gleiche Funktionalität hat man bei jedem Mailsystem. Bei nahezu jedem Webportal mit Benutzerbereichen. Bei nahezu jedem Mailinglistensystem. Eigentlich überall wo es Accounts und Datenablage gibt - aber niemand würde auf die Idee kommen, da ein Security Bulletin drüber zu verfassen. Natürlich sind Kombinationssituationen denkbar, in denen ein RCS einem den Angriff einfacher macht - die Vulnerability liegt dann aber definitiv in dem eigentlichen Sicherheitsproblem, nicht in den Teilen die hilfreich sind. Ansonsten müssen wir die Existenz einer shell auf einem Unix-System ja auch als Vulnerability bezeichnen, weil ihre Existenz es dem Angreifer einfacher macht eine Rootshell zu bekommen ...
In dem Bulletin wird einfach mit einer Vokabel falsch umgegangen. Und das unseriös. _Das_ stört mich an dem Bulletin. Wäre es als _Information_ gekennzeichnet und hätte es nicht die Forderung nach der Abschaltung und die Behauptung eines Design Flaws, dann hätte ich mit dem Teil wesentlich weniger Bauchschmerzen. Denn als Information ist es durchaus korrekt, was dort steht - nur kann das jeder in der öffentlichen Dokumentation des Protokolls nachlesen, es kann also eigentlich keiner behaupten er hätte sich darüber nicht vorher informieren können.
So in seiner jetzigen Form hat es für mich was von der typischen Anfänger-Security-Nachricht mit dem Inhalt das man ganz erstaunt festgestellt hat, das man Absenderadressen in eMails fälschen kann. Hui. Ich bin beeindruckt - üblicherweise beantwortet solche Mails bei uns dann president@whithouse.gov ;-)
earl Oct. 3, 2003, 9:01 p.m.
ich wage zu bezweifeln, dass es hierzu eine "richtig" meinung gibt. aus sicht des protokolls hast du natuerlich vollkommen recht: xmlStorageSystem works as designed - ganz klar. bezgl deiner ausfuehrungen hast du auch recht: die sicherheit des servers wird (im klassischen sinne) nicht kompromittiert (abgesehen davon, dass das XSS natuerlich sehr Denial-of-Service Attack anfaellig ist, aber auch das ist beim lesen des protokolls ganz offensichtlich). und wie mehrfach erwaehnt: exakt die selbe situation wie beim anbieten eines public ftp services.
$ ftp muensterland.org
Connected to muensterland.org.
220 ProFTPD 1.2.5rc1 Server (simon.bofh.ms) [simon.bofh.ms]
Name (muensterland.org:earl): anonymous
331 Password required for anonymous.
Password: anonymous@hotmail.com
530 Login incorrect.
Login failed.
anscheinend gibt es aber doch gruende kein public writeable ftp service anzubieten. soviel zum technischen. aus der "business view" schaut das ganze allerdings vielleicht ein wenig anders aus. offensichtlich bist du dir durchaus bewusst, welche integritaet bei absenderadressen in emails zu erwarten ist. lesen wir mal kurz ein wenig auf zB http://www.salon.com/blogs/:
"The software and service are free for a 30-day trial, then costs $39.95. The fee includes one year of software updates and Web site hosting."
oder aber auch:
"Your Salon Blogs Radio Userland license entitles you to free use of up to 40 megabytes of storage space per year. If you find you need additional storage space on the server, you can purchase it here."
sind sich die salon blogs betreiber (und andere, zahlende RCS kunden) nun bewusst, dass sie de-facto free internet storage provider sind? dass beliebige personen ihre server zur speicherung ihrer privaten webseiten, mp3s, zur ablage von photos oder auch zur warez distribution nutzen koennen?
im dem falle also, dass ich ein business bin, dass zwar gegen entgelt blogging services, nicht jedoch deswegen gleich ein komplett offenes file-sharing service anbieten will, kompromittiert das default RCS behaviour meine intentionen sehr wohl. ich behaupte folglich, dass auf _dieser ebene_ sehr wohl von einer _potential_ vulnerability gesprochen werden muss.
hugo Oct. 3, 2003, 9:27 p.m.
Zum FTP-Server: der ist nicht nur kein public FTP mit freiem Upload, sondern generell kein anonymous FTP. Was aber ganz andere Gründe hat: FTP ist ein bescheidenes Download-Protokoll (HTTP ist viel effizienter) und für Uploads ist es nur für die Leute relevant, die Websites hosten.
Was die RCS-Installationen mit Bezahlung angeht: RCS hält nach wann ein Benutzer sich angemeldet hat. Wenn dann nach einiger Zeit keine Bezahlung kommt, wird der Account eben geschlossen. Das lässt sich leicht automatisieren. Und ich vermute mal das es bei RCS auch automatisiert ist - beim PyCS muss man es manuell als Admin machen, das liegt aber einfach daran das ich keine Lust hatte bisher den Teil zu schreiben. Sind eh nur wenige User auf muensterland.org. Ausserdem gibt es keine kommerziellen Betreiber von PyCS Installationen, daher ist die Nachfrage nach Accounting-Systemen dafür doch eher gering ;-)
Und was MP3 Uploads angeht, oder Warez: das gleiche Problem hast du auch wenn du ganz normal Webspace anbietest. Egal welches Protokoll darunter liegt und welche Aktionen für die Benutzeranlage notwendig sind. Gegen illegale Inhalte hilft eben nur eine entsprechende AGB oder Nutzungsbedingungen und die Reaktion des Betreibers auf Beschwerden. Das steht bei muensterland.org übrigens auch in den Nutzungsbedingungen, das inakzeptable Inhalte zur Löschung des Accounts führen.
Wie gesagt, die diversen Hüpfer und Riten die bei diversen anderen Diensten gemacht werden müssen um ein Weblog anzulegen sind genausowenig sicher. Sobald du _irgendwie_ Filetransfers und Veröffentlichungen von Daten anbietest, hast du das Problem. Daher ist es irgendwie doch etwas übertrieben im Zusammenhang mit dieser Dienstleistung von Vulnerabilities zu sprechen.
Die programmatische Benutzeranmeldung (denn genau die ist ja letztendlich das Feature, das in dem Bulletin angesprochen wird - nicht jeder kann Daten hochladen, das ist Quark. Aber jeder kann ein Blog registrieren über eine Programmschnittstelle) ist einfach ein Feature von RCS, ein Leistungsmerkmal. Wenn aber ein Admin einen Service aufsetzt ohne sich vorher darüber zu informieren welche Leistungen dieser Service bietet, dann ist das Dummheit. Ok, Dummheit von Administratoren _ist_ eine Vulnerability, aber keine die allzuoft in Security Bulletins explizit genannt wird. Und vor allem keine die an einem Protokoll oder einer Implementierung dieses Protokoll festgemacht werden kann :-)
Und last but not least: man kann auch die Neuanlage von Blogs sperren. Der editthispage.com Server von Userland zum Beispiel ist schon seit Jahren gesperrt - weil er sonst übergelaufen wäre. Wer also keine freie Bloganlage will, kann das dicht machen. Auch ein Detail, worauf das Bulletin in keinster Weise eingeht (ok, daran ist wohl sicherlich auch die Nicht-Reaktion von Userland schuld - und deren Nicht-Reaktion ist ein viel grösseres Problem als die Features der Software!).
earl Oct. 3, 2003, 9:50 p.m.
bezgl der accounting basierten loesung: weder auf userlands servern noch bei salon ist dergleichen im einsatz. nachdem die registration eben offen ist, und nicht an eine lizenz gebunden ist, ist das tracking vielleicht auch nicht so einfach machbar. irgendein zusatzschritt (freischalten der registrierten RCS usernum, oder mitschicken einer lizenznummer beim registrieren) waere da denke ich noetig - bin aber nicht imtim vertraut mit RCS interna :)
"Und was MP3 Uploads angeht, oder Warez: das gleiche Problem hast du auch wenn du ganz normal Webspace anbietest."
ja, selbstverstaendlich. freehoster wie geocities oder yahoo haben das auf ziemlich brutale weise lernen muessen :) momentan versuchen sie, programmatische registrierung mit bildern in denen codes drinstehen zu verhindern. aber sicherheit ist sowieso immer relativ.
die moeglichkeit das freie registrieren abzuschalten, wird im bulletin schon angefuehrt:
"There is a setting in the RCS software that restricts remote new user registrations. - By turning these remote registrations off, which are on by default, you can work around this problem"
und ja leider, dummheit von administratoren _ist_ eine vulnerability :)
hugo Oct. 3, 2003, 10:43 p.m.
Dochdoch, auf den Userland-Servern ist mit Sicherheit eine Accounting-Software aktiv. Ich hab schon erlebt das User abgeschaltet wurden, weil sie nicht gezahlt haben. Die Registrierung ist zwar offen, aber die Registrierung wird in den Benutzerdaten festgehalten mit der Zeit und dem Datum der Anmeldung. Dazu schickt der Client eine Seriennummer mit - wenn er nicht registriert ist, steht da irgendwas von "unregistered Trial" drin, ansonsten eben eine gültige Seriennummer. Also sowohl RCS als auch Client wissen Bescheid, ob ein Benutzer bezahlt hat oder nicht bezahlt hat. Genauso wie der RCS genau weiss ob bezahlt werden müsste oder nicht.
Ich kenne mich mit dem XmlStorageSystem relativ gut aus. Liegt vielleicht daran das ich Entwickler sowohl eines freien RCS Clones als auch eines freien Radio Userland Clones bin, da kann man es nicht vermeiden das Protokoll ein bischen zu kennen ;-)