Bank-Apps besonders betroffen: Open Source oft ein Sicherheitsrisiko

Viele kommerzielle Anwendungen setzen auf Open-Source-Komponenten, um ihre Dienste zu realisieren. Eine Studie warnt jetzt, dass Entwickler dabei oft veraltete oder fehlerhafte Versionen verwenden, bei Banking-Apps ist dieses Problem besonders ... mehr... Sicherheit, Sicherheitslücken, schloss, Abus, Kette Bildquelle: John Dierckx / Flickr Sicherheit, Sicherheitslücken, schloss, Abus, Kette Sicherheit, Sicherheitslücken, schloss, Abus, Kette John Dierckx / Flickr

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Alles wie gehabt...
 
Hätte man closed source Software benutzt, für die es auch dokumentierte Schwachstellen gibt, wäre das nicht so schlimm?
Vielleicht sind die Entwickler auch nur so fähig, dass sie es nicht für notwendig erachten, bekannte Schwachstellen in ihren Produkten zu schließen.
Hm...liegt wohl echt an diesem bösen open source Zeug...
 
@Chosen_One: Jein. Es liegt am Support. Daß Banken einmal einrichten und dann laufen lassen ist mehr oder weniger üblich... nicht schön, aber verständlich; so große Unternehmen laufen halt langsamer als kleinere.

Ob die jetzt auf OSS gesetzt haben, um Geld zu sparen.... mag ich lieber nicht fragen, und schon gar nicht beantwortet haben.
 
@RalphS: der support kann auch keine sicherheitslücken in vorhandener software schließen, OpenSource oder nicht.
bei OpenSource sind aber auch die bugs und lücken für jeden einsehbar.
bei apfel, ms und co ist das ein bisserl anders, das können die nur jeweils selber fixen (siehe kopfgeld für bugs in deren software).
und manche finden halt fehlerchen und nutzen diese (aus?), ob quelloffen oder nicht ist dabei doch egal.
 
@sashaman: Nicht ganz. Das heißt: nicht ganz in Abhängigkeit davon, was Du hier unter Support verstehst.

Guter Support schließt auch Personen ein, die mit Dir in persönlichem Kontakt stehen (einschließlich Nase-zu-Nase) und damit natürlich auch Besprechungen re: Wir haben da was gefunden.

Und sei es nur als Mail-Rundschreiben. Das muß natürlich wer lesen.

OSS Entwickler können das oft nicht, weil das in den meisten Fällen entweder Einzelfiguren sind (=> QA fürn Hund, zwangsläufig) oder weil es viele Unabhängige sind, wo man schlicht keinen Ansprechpartner findet.

Der Rest für OSS sind Unternehmen, die sich da drauf spezialisiert haben. DIE können aber natürlich ebenso zwangsläufig nicht 'alles' wissen und haben den Mehraufwand, stets informiert zu bleiben (entsprechend kostet OSS Support auch sehr viel).

Was meinst Du wohl, warum End-of-Support bei Microsoft so kritisch ist? Kein Support heißt, keiner befaßt sich mehr damit und die Kompetenzen werden abgezogen für andere Projekte.

Entsprechend schau mal in die OSS-Lizenzbedingungen (egal welche). Die Chancen stehen gut, daß jegliche(!) Garantien abgesprochen werden. GPL ist da besonders toll; das läuft auf "wenn es funktioniert wie angedacht, dann war es wohl Zufall".

Nein, Support kann natürlich nicht alles regeln.

Aber Support kann *viel* regeln. Der kostet dann aber auch was.
 
@RalphS: gibt nix, wo ich dir widersprechen wollte oder könnte.
ich würde programmierer jedenfalls nicht zum support zählen, deshalb oben kommentiert.
daß über bugs berichtet, und fehler kommuniziert gehören ist klar, aber meine definition von support kann halt keine fehler beheben...

mir ist schon klar, daß die banken eine kosten-nutzen-analyse erstellen.
wenn das fixen und umstellen des systems nämlich mehr kostet,
als der verlust durch hacker, geprellte kunden und deren support, dann wird das halt in kauf genommen - ist ja billiger...
 
@RalphS: Open Source ist nicht schuld, das sagt der Artikel auch gar nicht (auch wenn die Überschrift das suggeriert). Open Source ist aber keine Garantie für qualtitativ gute Software, wie es so manche OSS-Fanatiker behaupten.
 
@Chosen_One: ich weiß nicht wie du darauf kommst dass hier open source irgendwie beschuldigt wird, kleiner beißreflex?
 
@0711: In der Tat. Text falsch gelesen und die Überschrift hat ihr übriges getan.
 
*hatschi* Entschuldigung, ich bin allergisch gegen Bullshit. Und genau das ist die Überschrift. Hier ist nicht OpenSource das Sicherheitsrisiko, sondern mangelhaftes Lifecycle-Management. Und das ist immer ein Problem, egal ob Open- oder ClosedSource.
 
@Thanatos81: Ne ne... Die Überschrift ist schon korrekt. An ClosedSource-Code wäre man ja gar nicht erst heran gekommen, sondern hätte sich selbst Gedanken machen müssen. Dadurch entstehen andere, aber nicht bereits bekannte Lücken. Und wenn man schon OpenSource-Code nutzt, sollte man sein Programm auch weiterpflegen, auch wenn das bedeutet, dass der OpenSource-Teil, den man immer wieder erneuern muss, mal das Programm zum Straucheln bringt und man Wochenlang nach Fehlern im eigenen Code suchen muss.
 
@SunnyMarx: so ist das aber auch nicht richtig. quelloffen oder nicht macht null unterschied dabei, ob man fehler findet und (aus)nutzt.
bei quelloffenem code kann aber jeder den bug fixen.
bei proprietärer software kann nur der entwickler den quellcode einsehen und bereinigen - und das kann schon mal paar monate oder jahre (apfel+ms, gar nicht lange her)) dauern.

beim heartbleed (openssl = opensource) hats jahre gedauert, bis der bug gefunden wurde. aber er konnte sehr schnell bereinigt werden.
bei "herstellersoftware" ist es eher umgekehrt, da findet man sehr schnell bugs, aber es kann halt mal dauern bis die dann entfernt werden (wenn überhaupt lol)

klar ist open source ein sicherheitsrisiko, wenn die teilweise von 3-7 jahre alten branches weitercoden.
und dann noch dazu ihren eigenen zusammengeschusterten code reinpflanzen.

und Thanatos81 hat mit lifecycle auch völlig recht.
uns (dem konsumenten) wird pc, handy, tv (siehe dvb-t) u.ä. verkauft, und nach 1-2 jahren kannste die dinger f ähhh knicken, weil end of life (EoL), keine softwareupdates etc. pp. - so läufts halt mit software - und die kommt immer aus nem quellcode - offen oder nicht - und der wird irgendwann nicht mehr "gepflegt" oder gewartet.

mfG
 
@sashaman: Bei Quelloffenem Code kann auch "jeder" absichtlich gut versteckten Schadcode einfügen. Dazu muss man nur ein besserer Programmierer sein als diejenigen die den Code überprüfen (wenn er überhaupt überprüft wird).

Es bleibt dabei das Open Source nicht sicherer oder unsicherer ist als Closed Source.
 
@James8349: richtig, und bei opensource können alle den (wenn auch absichtlich) fehlerhaften code einsehen (und fixen).
daß dieser dann nicht geprüft wird, liegt ja nicht daran, daß er opensource ist.
(p.s.: auch bei closed source kann jemand absichtlich fehlerhaften code oder backdoors einbauen, bloß müssen diese schwachstellen erstmal gefunden werden, und fixen is dann auch nich)

"Es bleibt dabei das Open Source nicht sicherer oder unsicherer ist als Closed Source." -> und nichts anderes war der kern meiner aussage.

ich hab mich nur an SunnyMarx' aussage drüber gestört, der behauptet nämlich, OS ist weniger sicher als CS, was absolut nicht stimmt.
 
@sashaman: Ich wollt ja auch nicht widersprechen. Nur ergänzen. Wobei man schon sagen muss: Es kann zwar jeder den Code einsehen, aber verstehen, geschweige denn fixen dürfte für die meisten eher utopisch sein. Besonders wenn es um Sicherheitskritische Aspekte geht. Da gibt es wenige die wirklich Ahnung haben und die haben eher anderes zu tun. Genauso kann nicht jeder selbst kompilieren und viele verlassen sich da auf diverse Sicherheitsmechanismen dass das Kompilat auch wirklich unverändert aus den Quellen gezaubert wurde.

Die Sache bei Closed Source ist die, das die Hemmschwelle ggf. größer ist. Wenn es rauskommt ist man nämlich mit ziemlicher Sicherheit seinen Job los. Das Problem gibt es bei Open Source eher weniger.

Schlussendlich ist es aber so: Open Source kann je nach Anwendungszenario tatsächlich unsicherer sein. Für Closed Source trifft das auch zu, nur bei anderen Szenarien.
 
@sashaman: Wenn man Code für seine eigene Software nutzt und den Code nicht veröffentlicht, wer fixt denn dann? Klar, verstößt das gegen die OpenSourceRegeln. Aber wo ist DVDFab Quelloffen? Die setzen auch auf OpenSource. Und? Was bringts, wenn ein Fehler in der Software steckt? Eben. Keiner kommt ran, außer dem Hersteller der geschlossenen Software.

Und genau darum gehts. ClosedSource kann nicht erlaubt oder unerlaubt in andere Software eingepflegt werden und somit werden auch Sicherheitslücken aus ClosedSource nicht mit kopiert und anschließend offen gelassen.
 
@SunnyMarx: schon mal reversed? oder gehört? reverse engineering? (nicht jede) software kann zu programmiercode zurückentwickelt werden. bei vielen programmen ist das nicht mal notwendig, da ist der gesamte oder fragmente vom quellcode drin.
daß closed source nicht in anderen code eingebaut werden kann, stimmt also nicht.
und wie du richtig andeutest: "Was bringts, wenn ein Fehler in der Software steckt? Eben. Keiner kommt ran, außer dem Hersteller der geschlossenen Software."
also nicht nur opensource, sondern auch nicht quelloffener code GEHÖRT GEWARTET.
daß das aber bei beiden sparten nicht immer passiert, kann niemand leugnen.

es ist also nicht die frage opensource oder nicht.
die frage ist, wird aktiv dran entwickelt und der code gewartet.
bug ist bug, OS oder CS.
zu sagen, eines wär schlechter/besser als das andere ist humbug.

mfg
 
Joo, genau, nach dem Wikileaks clusterfuck sind ploetzlich zahlreiche Luecken ueberall "entdeckt" worden und alle kamen zur dem fazit: OpenSource == unsicher, also proprietary sources == sicher!
 
@Synapsis: da können wieder paar leute nicht den sarkasmus rauslesen glaub ich...
 
ich sehe das problem ehr bei den banken, die veraltete software benutzen...die meisten geldautomaten zB laufen noch mit win xp.
ich benhaupte sogar das solche lücken ehr von der überheblichkeit der banken kommen.

an win10 ist sehr gut zu sehen, das im internet sicherheit nicht existiert, da jeder jeden ausspioniert.
 
@Thoretische-Technik: soso an Win10 sieht man das also..., woran machst du das fest bzw. was macht den Unterschied zu anderen OS?
 
@PakebuschR: Ist doch klar... Es steht Microsoft dran. ;o)
 
@Thoretische-Technik: und was ist an xp verkehrt? die Version die darauf läuft hat bis 2019 Support aber wie auch hier mit der open soruce Software spielen die banken entspechende fixe nicht ein....
 
@Thoretische-Technik: Dein inkompetentes Getrolle nervt!
 
Welcher Entwickler ist eigentlich so inkompetent, dass er es nicht auf die Reihe kriegt, freie Softwarelösungen lizenzkonform einzubinden? Selbst, wenn man die wenigen großen Lizenzen nicht so gut kennt, gibt es Internetseiten, die kurz und knapp und idiotensicher auflisten, was man jeweils tun muss, um lizenzkonform zu sein. Vielleicht sollten die Entwickler der freien Software ein bisschen abmahnfreudiger sein, bis ein Lerneffekt eintritt.

Was die Sicherheitsfrage betrifft: Sicherheitslücken nach dem Patchen bekanntzugeben, gehört zur guten Praxis. Der Ball liegt bei demjenigen, der genutzte Komponenten nicht patcht und dafür kann es kein Verständnis geben. Das hat allerdings wenig mit OpenSource zu tun. Ich kann mir genauso gut die CVEs einer proprietären Bibliothek ausgeben lassen um Software anzugreifen, welche die entsprechende proprietäre Bibliothek in einer veralteten Version nutzt.

Der einzige Unterschied ist vielleicht, dass proprietäre Bibliotheken nicht unbedingt unter Lizenzen stehen, die verlangen, dass man ihre Nutzung bekannt macht. Aber wenn dynamisch gelinkt wurde, dann kann man das trotzdem sofort nachvollziehen (man schaut einfach, welche .SOs bzw. .DLLs das Programm so mitschleppt und schaut mit ldd/DependencyWalker zu welchen es linkt, bzw. bei Java-Programmmen z.B. welche .JARs im Programmverzeichnis rumliegen) und selbst bei statisch gelinkten Programmen, kann man gucken welche Symbole das Binary enthält bzw. könnte es vermutlich auf Teile des Binärcodes der jeweiligen Bibliothek untersuchen.
 
@dpazra: - Zeitdruck
- Desinteresse
- Nicht "in scope"

Dürften so die üblichen gründe für nicht lizenzkonformes einbinden der Software sein
Kommentar abgeben Netiquette beachten!
Einloggen