Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 118 reacties

Mediaplayer Kodi, voorheen beter bekend als XBMC, bevat een kwetsbaarheid die door man-in-the-middle-aanvallen misbruikt kan worden, zo heeft Bitdefender ontdekt. De kwetsbaarheid is te vinden in het updatemechanisme voor add-ons. De Kodi-developers werken inmiddels aan patches.

KodiAls Kodi wordt opgestart, controleert de software direct of er updates voor add-ons beschikbaar zijn. Als deze er zijn, worden deze opgehaald en automatisch geïnstalleerd. In dit mechanisme heeft beveiligingsbedrijf Bitdefender een probleem gevonden. Zo wordt bij het updaten uitsluitend onversleuteld http-verkeer gebruikt. Allereerst wordt de md5-hash voor addons.xml, een configuratiebestand waarin versienummers van add-ons staan, opgevraagd. Als deze hash verschilt ten opzichte van een reeds lokaal opgeslagen md5-hash van addons.xml worden de updates opgevraagd. Op dat moment kan een man-in-the-middle aanval worden uitgevoerd door een willekeurige md5 retour te sturen. Deze wordt volgens Bitdefender zonder meer geaccepteerd door Kodi.

In een tweede stap van de aanval kan er een aangepaste addons.xml worden verstuurd waarin een add-on met een hoger versienummer is opgenomen. De aanvaller kan in deze add-on kwaadaardige code verpakken en deze, samen met een correcte md5-hash, opsturen naar het doelwit. Kodi zal deze 'update' automatisch installeren.

Bitdefender wist met deze aanvalswijze onder andere YouTube-inloggegevens te bemachtigen op OpenElec-systemen door een aangepaste YouTube-add-on te versturen naar een slachtoffer. Daarnaast waren zij in staat om met een gemanipuleerde add-on voor Dropbox, Dbmc geheten, heimelijk bestanden uit een Dropbox-folder te uploaden naar een willekeurige ftp-server.

Volgens Bitdefender is de beschreven aanvalsmethode niet alleen succesvol gebleken, maar ook niet erg complex om uit te voeren. In theorie kan een complete machine worden overgenomen of een aanvaller kan gevoelige data zoals wachtwoorden bemachtigen. Het beveiligingsbedrijf stelt daarom dat ook software als Kodi gebruik moet gaan maken van versleutelde verbindingen, omdat de verstuurde informatie zich anders te gemakkelijk laat manipuleren.

Bitdefender heeft de Kodi-ontwikkelaars ingelicht over het probleem. Zij zouden momenteel werken aan patches, al is nog onduidelijk wanneer we deze kunnen verwachten in nieuwe builds van de populaire mediaplayersoftware.

Moderatie-faq Wijzig weergave

Reacties (118)

Ik ben een van de ontwikkelaars van Kodi. Kodi is niet bepaald geschreven met security in het achterhoofd. Zo zijn er talloze plaatsen waar een man-in-the-middle aanval mogelijk is, al is deze inderdaad wel erg makkelijk uit te voeren. Een ander eenvoudig voorbeeld is via json-rpc. En wat lastiger, maar zeker niet onuitvoerbaar, is iets voor elkaar te krijgen via een bug. Trac staat er vol mee ;-)

Mocht je bang zijn voor een aanval, zoek dan de /share/kodi/addons/repository.xbmc.org directory in je installatie en verwijder deze, of verplaats deze naar een tijdelijke directory buiten het /addons pad
Voor een systeem dat zo veel gebruikt wordt vind ik dat best wel behoorlijk jammer, om niet te zeggen onverantwoordelijk.

Dat er security-bugs zijn neem ik op zich niemand kwalijk, ik weet hoe moelijk het is om dingen veilig te maken, maar tegenwoordig zou iedere aanbieder van software onmiddelijk in actie moeten komen bij dit soort problemen.

Uit jouw reacties proef ik dat jullie als beheerders het allemaal niet zo belangrijk vinden en dat stelt me droevig. Ik snap dat het leuker is om mooie features te bouwen maar veiligheid hoort er ook bij.
Uit jouw reacties proef ik dat jullie als beheerders het allemaal niet zo belangrijk vinden en dat stelt me droevig. Ik snap dat het leuker is om mooie features te bouwen maar veiligheid hoort er ook bij.
Dat is inderaad het grote probleem. Vanuit ons (XBian) zijn er meerdere fouten / slechte implementaties in Kodi gerapporteerd. De reacties daarop hebben ervoor gezorgd dat we er maar mee opgehouden zijn. Een tweetal simpele voorbeelden:
- Er is ťťn master thread die in Kodi alle python plugins afhandelt. Als er een probleem in een van de plugins optreed, dan loopt de hele boel vast.
- Er is niet te achterhalen wanneer Kodi daadwerkelijk helemaal geladen is. Het klinkt misschien vanzelfsprekend. Er wordt wel een "Home" event verstuurd via de JSON RPC, maar die is vrij willekeurig, aangezien het geen rekening houdt met het inladen van de plugins. Kodi kan dus zeggen dan hij geladen is terwijl allerlei plugins nog steeds aan het opstarten zijn.

Sommigen zullen ook de discussies omtrent SuperRepo nog wel herinneren. Dat is zo uit de hand gelopen dat BartOtten zich genoodzaakt voelde om te stoppen bij XBian om ook XBian niet mee te slepen in het conflict. Het probleem is dat alle threads omtrent dit conflict verwijderd zijn van het Kodi forum alsof het nooit heeft plaats gevonden.

Een ander treffend voorbeeld was hoe een belangrijk XBMC team lid zich uitte in de reacties onder dit artikel onder gebruikersnaam 566698. Er is tevens een glimp op te vangen van de discussie over SuperRepo.
nieuws: XBMC 13.0 biedt hardwarematige versnelling van videoweergave op Android

Niemand zal je er op aanvallen dat je fouten maakt in je code. Wat telt is hoe je er mee omgaat en in hoeverre je open staat voor hulp van buitenaf.

Binnen XBian hebben we nu een goede samenwerkingsrelatie met XBMC team leden Fritsch en Anaconda. Die handelen nu voor XBian de code verbeteringen af, zodat onze ontwikkelaars uit de frontlinie kunnen blijven. Het is alleen heel jammer dat het zo gaat. Niemand schiet er wat mee op.

[Reactie gewijzigd door CurlyMo op 23 juni 2015 18:41]

Vanuit ons (XBian) zijn er meerdere fouten / slechte implementaties in Kodi gerapporteerd.
Rapportages is meestal het probleem niet. De tijd, en soms kennis van zaken, van de developers wel.
- Er is ťťn master thread die in Kodi alle python plugins afhandelt. Als er een probleem in een van de plugins optreed, dan loopt de hele boel vast.
Het grootste gedeelte van de Python implementatie in Kodi is gemaakt door een developer die het Team verlaten heeft. En de meeste anderen, waaronder ik, hebben geen idee hoe dit probleem aan te pakken zonder eerst een hele lading vrije tijd te steken in het uitvogelen hoe alles met Swig en de lokale interpreter in elkaar gevogeld is. En dan ben ik nog een van de developers die al jaren bekend is met het grootste gedeelte van onze codebase.
- Er is niet te achterhalen wanneer Kodi daadwerkelijk helemaal geladen is. Het klinkt misschien vanzelfsprekend. Er wordt wel een "Home" event verstuurd via de JSON RPC, maar die is vrij willekeurig, aangezien het geen rekening houdt met het inladen van de plugins. Kodi kan dus zeggen dan hij geladen is terwijl allerlei plugins nog steeds aan het opstarten zijn.
Ene meneer Turing heeft in 1936 bedacht dat dit niet via een algoritme kan worden bepaald. Was best een bekende jongen ;)

De enige manier om dit dus op te lossen is met behulp van callbacks vanuit elke add-on. Maar wanneer is een add-on geladen? Als een of andere loop gestart is? Of als de add-on al zijn dependencies/plaatjes/whatever via een internetverbinding heeft ingeladen? Wat als een add-on de callback vergeet, of als het erg lang gaat duren voor het allemaal geladen is?

Geen onoverkomelijke problemen, maar het zal wel uitgedacht en geÔmplementeerd moeten worden.
Sommigen zullen ook de discussies omtrent SuperRepo nog wel herinneren. Dat is zo uit de hand gelopen dat BartOtten zich genoodzaakt voelde om te stoppen bij XBian om ook XBian niet mee te slepen in het conflict. Het probleem is dat alle threads omtrent dit conflict verwijderd zijn van het Kodi forum alsof het nooit heeft plaats gevonden.
Geen idee wat daar precies gebeurd is, maar SuperRepo begon geloof ik zonder illegale add-ons en deze zijn er later bijgekomen. En onze regels verbieden, terrecht, verwijzingen naar repositories die dit aanbieden. Nu is het SuperRepo en daarvoor van het XbmcHub. Wij willen niet dat er een link gelegd wordt tussen Kodi en illegale streams of andere meuk. En de reacties die ik hier vaak lees over Kodi-gerelateerde zaken leren dat het nog veel tijd en moeite gaat kosten (voor diegenen die zich ermee bezig houden) voor deze link bij de meeste mensen verdwenen is.
Binnen XBian hebben we nu een goede samenwerkingsrelatie met XBMC team leden Fritsch en Anaconda. Die handelen nu voor XBian de code verbeteringen af, zodat onze ontwikkelaars uit de frontlinie kunnen blijven. Het is alleen heel jammer dat het zo gaat. Niemand schiet er wat mee op.
Eigen keuze van jullie developers en goed dat 2 mensen die oppikken. Ik kan wederom niet ingaan op de details, omdat ik er niet mee bekend ben, maar als het onterechte kritiek is geweest of iets dergelijks, dan wordt dat normaal binnen het Team besproken, al gebeurt dat vaak niet publiekelijk.
Het grootste gedeelte van de Python implementatie in Kodi is gemaakt door een developer die het Team verlaten heeft. En de meeste anderen, waaronder ik, hebben geen idee hoe dit probleem aan te pakken zonder eerst een hele lading vrije tijd te steken in het uitvogelen hoe alles met Swig en de lokale interpreter in elkaar gevogeld is. En dan ben ik nog een van de developers die al jaren bekend is met het grootste gedeelte van onze codebase.
Als iedereen bij jullie nou zo eerlijk was. Nu had de reactie de strekking van "go fuck yourself".

Daarnaaste gaf ik al aan een tweetal simpele voorbeelden te noemen. Dit is niet de plek om er dieper op in te gaan.
Geen idee wat daar precies gebeurd is, maar SuperRepo begon geloof ik zonder illegale add-ons
SuperRepo begon ooit nadat BartOtten meerdere malen dingen te horen kreeg in de strekking van "go fuck yourself" toen hij met een uitgebreid voorstel kwam om de XBMC repo te professionaliseren.
SuperRepo begon ooit nadat BartOtten meerdere malen dingen te horen kreeg in de strekking van "go fuck yourself" toen hij met een uitgebreid voorstel kwam om de XBMC repo te professionaliseren.
Daar kan ik me weinig bij voorstellen. We hebben diverse leden die zich bezig houden met add-ons en hoe dit verder uit te breiden, en we hebben het er ook over gehad op de voorlaatste DevCon. Wellicht ook de laatste, daar was ik niet bij.

Een reactie als "go fuck yourself" komt niet uit de lucht vallen. Er is vast meer hieraan vooraf gegaan. Als je denkt dat iedereen met een (goed) idee een dergelijke reactie krijgt van teamleden, dan heb je het toch echt mis. Ik weet zeker dat we dan nog minder developers gehad zouden hebben dan nu.

Wat het verhaal ook is, als je constructief bezig bent dan wordt dat vast opgemerkt. Wat meestal neerkomt op het delen van code. En daar zat voor jou het probleem ;-)
Wat het verhaal ook is, als je constructief bezig bent dan wordt dat vast opgemerkt. Wat meestal neerkomt op het delen van code. En daar zat voor jou het probleem ;-)
Voor mij persoonlijk wel, maar vanuit XBian wordt er gewoon verbeteringen opgenomen uitgevoerd door Fritsch en Anaconda. Juist om die "Fuck yourselves" te vermijden.
Dat lijkt me onzin. Ik reageer zelf ook niet altijd even politiek correct als ik voor de zoveelste keer een pull request zie met knip en plak code dan heb ik ook niet altijd zin om een uitgebreide uitleg te geven. Maar bij voorbaat al zeggen dat dit zou kunnen gebeuren lijkt me wat kort door de bocht.
In een open source project met puur vrijwilligers, en niet alleen Kodi, werkt het nu eenmaal niet zo. Elke developer pakt op wat hij of zij op wil pakken. En vrijwel altijd komt dat neer op het toevoegen van features die deze ontwikkelaar mist of belangrijk vind. Zo heb ik me lange tijd bezig gehouden met PVR.

Als iemand zich geroepen voelt om zich met veiligheid bezig te houden: je bent van harte welkom.

Nu moet je niet uit mijn reactie opmaken dat dit probleem in het geheel niet opgepakt wordt. Er is wel degelijk gepraat over een oplossing hiervoor en die komt er zeer waarschijnlijk ook snel aan. Maar er zijn talloze manieren om een Kodi installatie over te nemen die hier niet genoemd worden. Denk bijvoorbeeld aan het gebruiken van een add-on repository die wij niet beheren. Veel gebruikers doen dit, en er is slechts 1 iemand nodig die toegang heeft tot deze repository die alles kan doen via een aangepaste add-on. Ik weet zeker dat 99% van de gebruikers dit niet snel gaat opmerken.
Het jammere is dat SuperRepo hierover in gesprek wilde gaan 2 maanden geleden (dat ging over exact dit): http://forum.kodi.tv/showthread.php?tid=224399 . Buiten die post om (die voornamelijk gold als een: zo kan ik het aantonen) heb ik enkele teamleden gesproken en was de reactie vooral: "Ach, er zijn meerdere manieren en dit waait wel weer over".
Maar er zijn talloze manieren om een Kodi installatie over te nemen die hier niet genoemd worden.
Dat dus. Er zijn meerde issues....Dus fixen we er geen?
Denk bijvoorbeeld aan het gebruiken van een add-on repository die wij niet beheren. Veel gebruikers doen dit, en er is slechts 1 iemand nodig die toegang heeft tot deze repository die alles kan doen via een aangepaste add-on. Ik weet zeker dat 99% van de gebruikers dit niet snel gaat opmerken.
Dat klopt helemaal .Maar Team kodi doet alsof het -dus- hun verantwoordelijkheid niet is. In het geval van SuperRepo leggen ze WEL alle verantwoordelijkheid bij mij (ipv de gebruiker) en noemen de repo zelf een gevaarlijk gedrocht (zie o.a. links van Curlymo).

Ikzelf voel me wel verantwoordelijk voor wat er door SuperRepo stroomt en SuperRepo heeft dan ook meerdere technieken ingebouwd (o.a. prioritering van bronnen, een virusscanner enz) om problemen te voorkomen. Het fungeert bij tijd en wijle als firewall tussen addon developers en de gebruikers en is aanzienlijk veiliger dan andere mass installers. Toch is er geen repo die zo nasty behandelt wordt door enkele Team Kodi leden als SuperRepo.

Waarschijnlijk zijn er weinigen (zo niet: niemand) die meer ervaring heeft met repo's dan ik. Daarnaast heb ik talloze ideeen om Kodi wat betreft de addons weerbaarder te maken, ook in combinatie met externe repo's. Maar zolang Team Kodi weigert in gesprek te gaan, schieten we weinig op. Mijn laatste email richting Team kodi kreeg welgeteld 1 reply: een rant van Ronie over SuperRepo.

Ach ja...zo eens per jaar hang ik ook eens de vuile was buiten.


@DusHmaniac: Als ik alleen op zou pakken wat ik zou willen doen, dan had ik weinig van de restricties die Team kodi me oplegt in SuperRepo verwerkt (en dan had het waarschijnlijk nog beter gewerkt ook). Ergens krijg je gewoon te maken met "too big to fail" en bijhorende rotklusjes. En Kodi heeft die grens lang geleden overschreden.

[Reactie gewijzigd door BartOtten op 23 juni 2015 19:42]

Voor de duidelijkheid was de letterlijke reactie van een van de XBMC teamleden op de vraag van BartOtten of er niet iets aan dit probleem gedaan moest worden:
ohh man...
Een goede verstaander weet dat BartOtten deze reactie regelmatig krijg en het dus iets betekent van "Heb je hem weer...."

[Reactie gewijzigd door CurlyMo op 23 juni 2015 20:20]

Voor de duidelijkheid was de letterlijke reactie van een van de XBMC teamleden op de vraag van BartOtten of er niet iets aan dit probleem gedaan moest worden:

[...]

Een goede verstaander weet dat BartOtten deze reactie regelmatig krijg en het dus iets betekent van "Heb je hem weer...."
Je moet de reactie van een van de Team leden, waaronder mijn reacties hier, niet zien als de visie van het hele Team. "ohh man..." kan heel goed betrekking hebben gehad op de voorgeschiedenis tussen het betreffende teamlid en Bart. Geen idee zonder het complete verhaal.

Maar zie vooral de reactie van 1 lid niet als de reactie van het hele Team. We zijn geen bedrijf waar elke reactie aan een protocol dient te voldoen of moet worden goedgekeurd door een meerdere ;-)
We zijn geen bedrijf waar elke reactie aan een protocol dient te voldoen of moet worden goedgekeurd door een meerdere ;-)
Misschien moet er juist eens nagedacht worden over een organisatiestructuur en omgangsvormen. Dat gebeurt in XBian ook geregeld. Ik kan me niet voorstellen dat het lekker werken is met teamleden die op deze manier naar buiten treden. En de mensen die ik hier heb besproken zijn echt niet de enige XBMC teamleden waar we slechte ervaringen mee hebben.
Er is geregeld discussie geweest in het verleden over dit soort zaken en kan je garanderen dat dit wel degelijk is aangekaart.

Ik kan niet ingaan op wat er in dit geval precies is voorgevallen hier omdat ik er niet bij was, maar ik kan begrijpen waar de frustratie van anderen vandaan komt. Zoals al vaker aangegeven hier, de link tussen illegale add-ons en Kodi developers (zoals ik) is wat er, denk ik, voor zorgt dat niet alle Teamleden even netjes reageren.
Je framed het nu de hele tijd negatief. Er was geen repo met (illegale) add-ons, dat is er pas gekomen doordat alle pogingen om serieus iets voor XBMC te kunnen betekenen werden gefrustreerd.
Wat er eerst was maakt op dit moment niet meer uit, maar die illegal add-ons is nu juist wat een eventuele oplossing in de weg staat. Team Kodi/XBMC wil hier niks mee te maken hebben, wil niet dat de naam Kodi of het logo gebruikt wordt door sites die dit aanbieden, enz.

Niemand van ons team zal je kunnen verbieden om dit soort add-ons aan te bieden, maar zodra je dat doet maak je het simpelweg onmogelijk om (normaal) samen te werken.
Het jammere is dat SuperRepo hierover in gesprek wilde gaan 2 maanden geleden (dat ging over exact dit): http://forum.kodi.tv/showthread.php?tid=224399 . Buiten die post om (die voornamelijk gold als een: zo kan ik het aantonen) heb ik enkele teamleden gesproken en was de reactie vooral: "Ach, er zijn meerdere manieren en dit waait wel weer over".
Ik was niet bij die discussie betrokken, maar ik weet dat er wel degelijk over oplossingen gesproken is en dat die er ook aankomt. Ik geloof dat er nog iets was met de mirrors en certificaten. Bovendien zal er een oplossing door iemand geÔmplementeerd zal moeten worden, wat waarschijnlijk een nieuwe dep naar openssl betekent. Geen groot probleem, maar niet iets dat even met 2 regels code aangepast is.
Er zijn meerde issues....Dus fixen we er geen?
Ik geloof niet dat ik een patch heb gezien hiervoor die geweigerd is, maar ik kan me vergissen.
Dat klopt helemaal .Maar Team kodi doet alsof het -dus- hun verantwoordelijkheid niet is. In het geval van SuperRepo leggen ze WEL alle verantwoordelijkheid bij mij (ipv de gebruiker) en noemen de repo zelf een gevaarlijk gedrocht (zie o.a. links van Curlymo).
Nu haal je zaken door elkaar. Het probleem dat in dit artikel genoemd wordt gaat over het overnemen van een installatie door een hack. Het probleem met jouw repos is enerzijds het soort add-ons voor illegale streams dat wordt aangeboden, waarvan wij ons als Team zover mogelijk willen distantiŽren, en als ik me goed herinner een issue met duplicaten van add-ons en add-ons die zonder permissie van de auteur waren overgenomen. Hier waren verschillende developers niet blij mee. Maar ook hierbij was ik niet betrokken; ik houd me bezig met PVR, CEC en nog wat andere zaken en niet met (Python) add-ons. Ik hou me dan ook buiten de discussie over jouw repos.
Ikzelf voel me wel verantwoordelijk voor wat er door SuperRepo stroomt en SuperRepo heeft dan ook meerdere technieken ingebouwd (o.a. prioritering van bronnen, een virusscanner enz) om problemen te voorkomen. Het fungeert bij tijd en wijle als firewall tussen addon developers en de gebruikers en is aanzienlijk veiliger dan andere mass installers.
Sorry, maar je kan onmogelijk elke add-on die in jouw repos zit controleren en als zeker niet automatisch. Zeker niet als je het hebt over add-ons die streams aanbieden, en die zaken downloaden om de lijst met streams te laten zien.
Toch is er geen repo die zo nasty behandelt wordt door enkele Team Kodi leden als SuperRepo.
Ik ken de redenen van andere Team leden niet, maar ik verwacht dat dat alles te maken heeft met het soort add-ons in jouw repos. Zo wil ik persoonlijk niet bekend staan als iemand die zich bezig houdt met hoe anderen gratis de laatste films en sport evenementen kunnen bekijken. Sterker nog, ik had meer dan een jaar voordat de nieuwe binary add-on types werden geÔntroduceerd al een implementatie hiervoor klaar (die ik helaas niet kon delen omdat deze niet gebruikt is door de opdrachtgever en nu door de nieuwe ontwikkelingen ingehaald is). Hiermee is het mogelijk om (betaalde) diensten als Spotify en Netflix te implementeren, gebruik makende van een binary-only component.
Waarschijnlijk zijn er weinigen (zo niet: niemand) die meer ervaring heeft met repo's dan ik.
Been there, done that, lang voordat jouw repos bestond ;-)
Daarnaast heb ik talloze ideeen om Kodi wat betreft de addons weerbaarder te maken, ook in combinatie met externe repo's. Maar zolang Team Kodi weigert in gesprek te gaan, schieten we weinig op. Mijn laatste email richting Team kodi kreeg welgeteld 1 reply: een rant van Ronie over SuperRepo.
Ik kan me geen e-mail herinneren, maar waarschijnlijk zal de reactie van de meesten zijn geweest: patches welcome. Iedereen heeft ideeŽn, maar iemand zal ze moeten implementeren.
Als ik alleen op zou pakken wat ik zou willen doen, dan had ik weinig van de restricties die Team kodi me oplegt in SuperRepo verwerkt (en dan had het waarschijnlijk nog beter gewerkt ook).
Ik heb geen idee waar je het over hebt :)
Ergens krijg je gewoon te maken met "too big to fail" en bijhorende rotklusjes. En Kodi heeft die grens lang geleden overschreden.
Kodi is gewoon een open source project met (zeer) veel gebruikers en maar een handvol actieve developers. En die nu eenmaal doen waar ze zin in hebben in hun vrije tijd.
Het zou fijn zijn als Team Kodi de bedachte oplossing deelt. Dan kunnen de repo's beginnen met de implementatie.
Ik heb geen idee waar je het over hebt
Dat blijkt :p Ik neem het je niet kwalijk, enkele leden van Team Kodi hebben wat topics naar /dev/null verhuist in de begindagen van SR (terwijl ik ondubbelzinnige en soms zelfs stimulerende toestemming had van andere teamleden). Zie ook de reacties hier van getuige Curlymo.

Enkele leden lijken er baat bij te hebben eeuwig tegen SR te schoppen en oude koeien te kleuren en vervolgens uit de sloot te vissen. Daarom zou ik het waarderen als je niet alles klakkeloos zou overnemen wat je gehoord hebt / te horen krijgt. Er zijn ook devs bij Kodi die geen moeite hebben met SR maar die houden (waarschijnlijk wijselijk) hun mond stijf dicht.

Groetjes,
De man die Team Kodi via via helpt met de redirector omdat die op omvallen staat ;)
Daarom zou ik het waarderen als je niet alles klakkeloos zou overnemen wat je gehoord hebt / te horen krijgt.
Dat is het nu juist, dat probeer ik niet te doen.

Als ik nu kijk in jouw repos, dan zie ik daar een hele lading add-ons staan die bij vermelding op ons forum direct een ban ontvangen. Daarom zal je waarschijnlijk niet snel iets horen, en publique, van leden die wel blij zijn met jouw repos.
Dat begrijp ik 100%. SR houdt zijn mening over addon devs ook voor zich. Maar dat is dan zowel positief als negatief.

Martijn lockt topics over SR omdat het 'illegaal' is, maar nooit zonder nog een sneer uit te delen voor dat het topic gelockt wordt. Of hij lockt niet, en laat dan alleen negatieve recensies staan. Of hij haalt Reddit posts over SR weg, maar laat die van Total staan enz enz. Zo ontstaat nogal een eenzijdig beeld bij mensen die het lezen (en vervolgens weer doorvertellen, want gelezen...)

[Reactie gewijzigd door BartOtten op 24 juni 2015 22:30]

Je kan zaken als 1channel en weet ik wat er tegenwoordig allemaal is moeilijk legaal noemen. Je hoeft geen rechtsgeleerde te zijn om erachter te koment dat gratis alle laatste series, films en sportevenementen op je scherm toveren niet legaal kan zijn.
In een open source project met puur vrijwilligers, en niet alleen Kodi, werkt het nu eenmaal niet zo. Elke developer pakt op wat hij of zij op wil pakken. En vrijwel altijd komt dat neer op het toevoegen van features die deze ontwikkelaar mist of belangrijk vind. Zo heb ik me lange tijd bezig gehouden met PVR.
Ik ken genoeg projecten waar het wel zo werkt en de developers ook dingen doen die ze niet leuk vinden omdat ze zich verantwoordelijk voelen ten opzichte van hun gebruikers. Er zijn inderdaad een hoop projecten waar de veiligheid wordt genegeerd net zoals er een hoop automobilisten te hard rijden en niet in hun spiegels kijken. Dat vind ik onverantwoord.

Voor add-on repo's zal niemand Kodi verantwoordelijk houden. Dingen die gebruikers zelf toevoegen of veranderen zijn uiteraard niet jullie verantwoordelijkheid.

Hoe dan ook, succes met het oplossen van de problemen.

Maar laat ik ook uitdrukken dat ik blij ben dat er nu wel aan een oplossing wordt gewerkt en er in ieder geval niet wordt gewacht tot het ook echt in praktijk wordt misbruikt.
Ik ken genoeg projecten waar het wel zo werkt en de developers ook dingen doen die ze niet leuk vinden omdat ze zich verantwoordelijk voelen ten opzichte van hun gebruikers. Er zijn inderdaad een hoop projecten waar de veiligheid wordt genegeerd net zoals er een hoop automobilisten te hard rijden en niet in hun spiegels kijken. Dat vind ik onverantwoord.
Als de developers zich niet verantwoordelijk zouden voelen voor gebruikers, dan waren er geen binaries, dan was er geen support voor de meest idiote dingen die je kan verzinnen, in mijn persoonlijke geval geen support voor PVR in mainline, en een hele zut aan andere dingen die onze gebruikers vanzelfsprekend vinden. Het grootste gedeelte van je tijd als developer zit in zaken die je doet omdat je je verantwoordelijk voelt voor anderen, vanwege "it works on my machine".
open source of niet, dit is niet wat je wil als gebruiker en eigenlijk is dit te zot voor woorden... Je kan gewoon geen programma ontwikkelen voor de grote massa zonder dat je rekening houd met beveiliging. Ik heb er echt geen woorden voor, je ontwikkeld wel voor een doelgroep waarvan je kan weten dat die niet of troep zitten te wachten. Ik ben dan ook heel blij dat ik Media Portal gekozen heb. Ik heb het idee dat die toch echt wel een stuk professioneler te werk gaan. Iig luisteren die naar hun achterban en dat is iets wat je ook vooral moet doen want die moet je tenslotte tevreden houden.
Je kan gewoon geen programma ontwikkelen voor de grote massa zonder dat je rekening houd met beveiliging.
Je snapt hopelijk dat de massa pas naderhand kwam en dat Kodi/XBMC/XBMP is ontwikkeld door mensen die gewoon een film o.i.d. op hun PC wilden zien en wat meer eraan vast geknutseld hebben?

Maar de rest van jouw post laat zien dat je niet echt weet waar je het over hebt ;)
Ik heb het hieronder ook al aangegeven, maaf nogmaals voor de duidelijkheid: mijn visie != de visie van het hele Team. Ik ben slechts 1 van de developers.
In theorie kan een complete machine worden overgenomen [...]
Ik ben een van de ontwikkelaars van Kodi. Kodi is niet bepaald geschreven met security in het achterhoofd.
Dat is zelfs nog een understatement ;)

Kodi (net als bijna alle andere software) hoort natuurlijk niet met volledige permissies te draaien. In XBian draait Kodi onder de xbian gebruiker. Ik weet niet hoe dat bij andere distributies geregeld is. Een korte blik op de Jessie XBMC deb pakket laat zien dat alles gewoon als root geÔnstalleerd wordt. De pakketten van het XBMC team zelf doen het niet veel beter.
~ # dpkg -x xbmc_13.2+dfsg1-4_all.deb xbmc
~ # ls -Al xbmc/usr/bin/xbmc-standalone
-rwxr-xr-x 1 root root 1800 Nov 8 2014 debian/usr/bin/xbmc-standalone
http://ftp.debian.org/debian/pool/main/x/xbmc/
~ # dpkg -x kodi_14.2~git20150327.1058-final-_all.deb kodi
~ # ls -Al kodi/usr/bin/kodi-standalone
-rwxr-xr-x 1 root root 1830 Mar 27 11:18 kodi/usr/bin/kodi-standalone
http://ppa.launchpad.net/.../ubuntu/pool/main/k/kodi/

Dan is er nog de optie dat de permissies achteraf goed gezet worden vanuit het post installatie script, maar dat gebeurt ook niet:
#!/bin/sh
set -e
# Automatically added by dh_pysupport
if which update-python-modules >/dev/null 2>&1; then
update-python-modules kodi.private
fi
# End automatically added section
# Automatically added by dh_installmenu
if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; then
update-menus
fi
# End automatically added section
Reactie op hieronder:
Om even mijn antwoord verder toe te lichten. Ondanks dat je Kodi niet hoeft te starten als root, wordt dit wel mogelijk gemaakt. Waar ik op doel is dat Kodi zoveel mogelijk een security-by-design aanpak zou moeten kiezen. Dus gewoon op de eerste plaats weigeren als root te starten. Dat is misschien wel het simpelste wat je kan doen als ontwikkelaar:
if(geteuid() == 0) {
printf("kodi cannot be started as root\n");
exit(EXIT_FAILURE);
}
Daarnaast wordt ook terecht opgemerkt dat op deze manier Kodi installeren er vanuit gaat dat je Kodi start vanuit je desktop, waarin je vrijwel nooit inlogt als root. Echter, het platform waar Kodi op dit moment het meest wordt gebruikt is de Raspberry Pi. In dat geval wordt Kodi dus gewoon opgestart vanuit de cmdline of als laatste programma van de init procedure. @DLGandalf geeft hieronder aan dat bijv. het immens populaire OpenElec Kodi gewoon draait onder de root gebruiker.

[Reactie gewijzigd door CurlyMo op 23 juni 2015 20:14]

Een korte blik op de Jessie XBMC deb pakket laat zien dat alles gewoon als root geÔnstalleerd wordt. De pakketten van het XBMC team zelf doen het niet veel beter.
De user en groep op de binary zegt helemaal niets over veligheid, alleen welke gebruiker en groep met de "u" en "g" rwx vlaggetjes worden bedoeld. Aangezien het "x" vlaggetje ook voor "o" aan staat kan dit als gewone gebruiker worden uitgevoerd en alleen root kan de binary overschrijven en dat lijkt me ook prima.

Het is nu niet dat kodi met een suid vlaggetje draait of zo want dat zou wel een enorm lek zijn. Ik zie eigenlijk helemaal geen probleem met die "ugo" instellingen.
Het is heel simpel. Aangezien Kodi als root draait kan het in potentie alles. Onafhankelijk van de gebruikersrechten van het betreffende bestand.
Maar Kodi draait helemaal niet als root, Kodi draait als de gebruiker die de applicatie opstart. Als je als root gaat werken, ben je zelf niet goed bezig.

Mogelijk zou Kodi vrijwillig permissies kunnen droppen, maar draaien als nobody lijkt me niet realistisch.
Dat snap ik. Echter, de meeste programma's (zoals Apache) zullen voor zichzelf bij de installatie een aparte gebruiker aanmaken (www-root, httpd, e.d.) en standaard onder die gebruiker draaien. I.p.v. de extra handeling om niet als root te draaien heb je daarbij extra handelingen nodig om wel als root te draaien. Dat is het cruciale verschil.

Idealiter zou Kodi gewoon moeten weigeren om als root te starten mits je dat handmatig overruled.

[Reactie gewijzigd door CurlyMo op 23 juni 2015 17:59]

Lijkt mij dat er een verschil is tussen software als apache,wat als service op de achtergrond draait en Kodi wat als programma op de voorgrond wordt gedraaid.

Ik draai al tijden geen xbmc laat staan Kodi.. Maar volgens mij is het geen service. Dus draait het onder hetzelfde account als de gebruiker en heeft het geen eigen user.

[Reactie gewijzigd door Vesper64 op 23 juni 2015 18:19]

Mits je het op een desktop PC installeert. Op bijv. de Raspberry Pi start je Kodi vanuit de cmdline of aan het eind van je init. Het starten van Kodi als root gebruiker is dan verreweg het makkelijkst.
Dat heeft toch niets met die ugo vlaggetjes te maken? Als die ugo vlaggetjes op user "pietjepuck" en groep "puistenkop" staat maar je start KODI vervolgens op als root gebruiker vanaf de init dan draait KODI net zo hard met root permissies. Die ugo vlaggetjes zeggen helemaal niets over de rechten waaronder het programma draait, alleen in combinatie met de rwx vlaggetjes wie het bestand mag lezen, overschrijven en opstarten. Alleen met het suid bitje veranderd de zaak maar die staat alleen aan als het echt moet (bijvoorbeeld het programma sudo).

[Reactie gewijzigd door pe1dnn op 24 juni 2015 15:56]

Je blijft maar reageren op het permissie puntje, terwijl mijn verhaal breder is. Kodi zou gewoon niet als root gestart mogen worden. Het is aan Kodi zelf hoe moeilijk ze dat maken. Nu wordt er in ieder geval geen enkele moeite voor gedaan om het te voorkomen.
Tegen domheid is geen enkel systeem bestand. Dit is schijnbeveiliging, het echte beveiligingsprobleem zit in dat geval tussen de stoel en het scherm.
Als je weet dat je doelgroep voor namelijk bestaat uit onwetende linux gebruikers (zie het Raspberry Pi media center topic), dan mag je als ontwikkelaar toch wel iets meer verantwoordelijkheid nemen.
Je maakt wel wat aannamen, maar wat je zegt klopt ook iig voor openelec:
xbmc:~ # ps aux |grep kodi
743 root 199:46 /usr/lib/kodi/kodi.bin --standalone -fs --lircdev /run/lirc/lircd
5250 root 0:00 grep kodi
Je maakt wel wat aannamen, maar wat je zegt klopt ook iig voor openelec:
Dat zijn geen aannamens, maar een redelijke kennis van Kodi als XBian manager ;)
Ik heb de addon verplaatst van appdata...naar .../.. :) bedankt!
Waar in xbmc moet je het pad veranderen?
Als je het pad bedoelt naar de server, in de addon.xml van de add-on die je zojuist verplaatst hebt.
Nee die bedoel ik niet. Xbmc heeft toch in instellingen het pad naar die verplaatste adddon.xml ergens staan om uit te voeren? Als je een bestand verplaatst van een programma in de persoonlijke folder dan moet het programma toch weten waar het nieuwe verplaatste pad is om het aadon.xml te vinden en uitvoeren?! Of ben ik op verkeerde "pad"? Als ik in windows een bestand van snelkoppeling verplaats moet ik ook in de instellingen van de snelkoppeling het pad naar dat verplaatste bestand wijzigen! Werkt toch iden in xbmc (kodi)?
Dit is hardcoded om eerst in the user profile folder te kijken, dan in de shared system folders.
Staat er iets op de roadmap hoe/wat/wanneer deze security bugs worden opgelost? Ondanks dat het content op de mediaplayer zelf niet erg interessant is (behalve dan in sommige gevallen wachtwoorden e.d.), hangen ze wel aan een netwerk waar veel meer te halen valt.
Ik heb nog geen patches gezien en nog niemand gehoord die dit groot nieuws vond ;)
Oke, zal zelf is even rond gaan zoeken in de bugs of ik nog ergens mee kan helpen.
Net een glaasje azijn op? :)
Je bent uiteraard vrij om iets anders te gebruiken of, beter nog, de zaken aan te passen die jij denkt dat beter kunnen. We zijn een handvol vrijwilligers die een mediaplayer onderhouden met honderdduizenden gebruikers, in onze vrije tijd, omdat we dat leuk vinden. Meer vrijwilligers met goede ideeen zijn altijd welkom.

edit: typ0s

[Reactie gewijzigd door DusHmaniac op 23 juni 2015 16:30]

Waar kan ik solliciteren?

- bekend met het onderhouden van honderduizenden gebruikers
- beheer een dual core server die wel 6k requests per seconden aankan :P
- ken het addon systeem door en door en weet genoeg zaken die redelijk eenvoudig op te lossen zijn en de (third party) repo's minder wild westen zou maken.
Onze "solicitatieprocedure" is geen geheim.

- Voor developers heel eenvoudig: genoeg pull requests aanmaken tot iemand je vraagt. Die maakt vervolgens een voorstel thread aan op het interne gedeelte van ons forum, en bij genoeg +1's en geen of weinig -1's wordt je officieel uitgenodigd.
- Voor de zaken die jij aangeeft: we hebben evenveel server admins als actieve devs op dit moment geloof ik ;-) Maar als iemand jouw werk nuttig vindt dan volgt het dezelfde procedure als voor een developer.

Het grote probleem dat ik echter verwacht is dat jouw naam verwijst naar SuperRepo, wat weer verwijst naar de illegale add-ons waar we niks mee te maken willen hebben. Jouw naam is daardoor, in mijn ogen, "besmet". Wellicht is een nieuwe nick een idee? ;-)
Een nieuwe nick won't work. Zodra Martijn en Ronie me ruiken heb je een teamsplit te pakken.

Ik vind het ook helemaal geen ramp om via de achtergrond te werken, maar het is gewoonweg rot als je vervolgens op de 'voorgrond' neergetrapt wordt door enkele haatdragende teamleden (lees: Martijn en Ronie) of eeuwige 'horen van'. Die twee bepalen met z'n tweeŽn de hele sfeer rond SR (nogmaals: zie de links die Curlymo hier in zijn reacties geplaatst heeft)
Ik denk dat als je alles waarmee wij als teamleden niks te maken willen hebben zou verwijderen, dat beiden heel wat meewerkender zouden zijn :)

edit: overigens was de nieuwe nick niet serieus bedoeld ;-)

[Reactie gewijzigd door DusHmaniac op 24 juni 2015 20:22]

Ik denk dat de gebruikers ze dan alsnog zouden gebruiken maar dat partijen als voormalig Hub ze dan leveren. Er zijn dagen bij dat dat de enige reden is dat ik SR online houdt.

Drugs are bad. Maar als men ze toch wil gebruiken, zorg dan dat er een vorm van controle is op de shops ;)

Ps. De nickname is serieus besproken :p

[Reactie gewijzigd door BartOtten op 24 juni 2015 22:25]

Er zullen altijd mensen blijven die illegale streams gebruiken, zeker. Ik zou echter niet bekend willen staan als degene die dat mogelijk maakt.

Ik heb persoonlijk geen moeite met zaken als Oscam, die het mogelijk maken om met een betaald abonnement TV te kijken. Er kan echter veel meer me dan alleen dat wat niet helemaal de bedoeling is.

1channel en vergelijkbare add-ons zijn een ander verhaal. Deze zijn puur gemaakt om zonder te betalen de laatste series en films te bekijken. Daar wil ik niet aan gekoppeld worden.
daarover verschillen de meningen... zo vind ik hem zeer gebruiksvriendelijk (met de amber skin)
Amber is inderdaad, op wat kleine zaken na, naar een erg gebruikersvriendelijke skin. En ik heb de skinners gehoord over het vervangen van Confluence door iets nieuwers als default skin, al herinner ik me niet meer over welke skin dat ging. Zou Amber kunnen zijn.
Zonder tutorial is het voor een normaal iemand niet te doen om Kodi in te stellen.
Mocht je problemen hebben met de configuratie: http://kodi.wiki/

Maar de meeste zaken zou je zonder hulp voor elkaar moeten krijgen. Misschien heb je de Helix release niet getest? Daarin zijn veel configuratie-dialogen aangepast en is er uitleg toegevoegd voor veel instellingen, direct in het dialoog.
Ik als al vele jaren super-xbmc-fan begrijp wel wat je bedoeld. Je moet op zich wel een beginner-tweaker zijn om xbmc perfect in te stellen en te beheren. Er is altijd wel iets te "pielen" en dan is het niet handig als dat niet je hobby is. Maar dan doel ik voornamelijk op mooier maken en de wat gevorderde dingen lekker te laten lopen.
Laatste jaren is het hobby-matige eraf en gebruik ik hem uitgekleed puur voor films en series van mijn eigen nas en is hij al jaren stabiel. Maar zou het nog steeds niet bij m'n ouders installeren vanwege "gedoe".
Op wat voor instellingen doel je dan? Ik had nergens last mee...
Kodi is gebruiksvriendelijker dan Plex, al kan Plex meer, zeker met de chromecast.

Heb je eventueel alternatieven?
Bitdefender heeft de Kodi-ontwikkelaars ingelicht over het probleem. Zij zouden momenteel werken aan patches, al is nog onduidelijk wanneer we deze kunnen verwachten in nieuwe builds van de populaire mediaplayersoftware.
Zo kan het, inderdaad. Of je moet (net als bijvoorbeeld Microsoft updates, of packages bij veel Linux distributies) de databestanden en software zelf van handtekeningen voorzien, of je moet de boel aanbieden via TLS.
En gewoon in het geheel GEEN MD5 meer gebruiken. Het is al een jaar of tien niet meer als veilig te zien.

Edit: Oke, het overstappen naar een algoritme van de SHA-2 familie had deze hack misschien niet voorkomen, maar het voorkomt mogelijk wel problemen in de toekomst omdat er (zonder quantum computers) geen collisions mogelijk zijn.

De oplossing voor dit probleem is gewoon het gebruik maken van pubkeys, om te checken of er niet is geknoeid met de updates.

[Reactie gewijzigd door Eloy op 23 juni 2015 22:02]

MD5 voor hashing in dit soort toepassingen heeft niks met de onveiligheiden van het algoritme te maken, dat is puur van toepassing op bijvoorbeeld het opslaan van hashes van wachtwoorden.

Dus MD5 hashes (gesalt of niet) opslaan van wachtwoorden = niet doen
MD5 hashes van data maken om als checksum te gebruiken = geen probleem

[Reactie gewijzigd door Mathijs1 op 23 juni 2015 14:45]

MD5 moet vooral nooit gebruikt worden voor checksums. MD5 is onveilig en moet nooit worden gebruikt. Het is triviaal om een MD5 checksum collision te genereren. http://www.mathstat.dal.ca/~selinger/md5collision/
Je hebt helemaal gelijk dat MD5 checksums niet veilig zijn, maar dat is voor deze toepassing niet erg. Als je een versleutelde verbinding gebruikt dan kan er door een man-in-the-middle namelijk helemaal niet geknoeid worden met de hash. Alleen de server zou dat kunnen doen, en als je die niet vertrouwt zul je je add-on updates sowieso ergens anders vandaan moeten halen.
Mja, om te kijken of een bestand gewijzigd is op deze manier kan het geen kwaad omdat het geen enkele betrekking heeft op de veiligheid. Dat gezegd hebbende is het slimmer om het nooit te gebruiken, doe je het ook nooit per ongeluk als het wel met de beveiliging te maken heeft.
With great power, comes great responsibility..
md5 is puur gebruikt voor simpele validatie hier.

"nooit gebruiken" is compleet afhankelijk van de applicatie. Voor mijn werk schrijf ik vooral C voor embedded low powered ARM spul (lpc17xx, lpc18xx, avr192xx, dat soort spul) en daarin gebruik ik ook md5 voor de validatie van bestanden waarvoor veiligheid niet van belang is. md5 is prima voor dit soort toepassingen vanwege de kleine memory footprint, de weinige rekenkracht die het nodig heeft en de mogelijkheid om de matrix vooraf te berekenen voor de echt trage chips.

Voor de veiligheid zal niemand ontkennen dat je geen md5 moet gebruiken, maar voor simpele validiatie voor echt low powered devices wil je geen rsa gebruiken met een key van 4k voor simpele zaken ;)
Helemaal mee eens. Het algoritme voldoet niet langer aan de originele design requirements; gebruik iets dat dat wel doet (SHA2) tenzij je een heel zinnig tegenargument hebt.
Als het verschillen van twee md5 checksums een security-implicatie heeft dan is het een slecht plan inderdaad, maar de praktische kans dat je een collision krijgt is niet zo groot dus voor non-security related dingen (zoals besluiten om wel/niet een update te fetchen) maakt het niet uit.
Dus MD5 hashes (gesalt of niet) opslaan van wachtwoorden = niet doen
If anything dien je MD5 in z'n geheel niet meer te gebruiken; als je hier probeert te betogen dat MD5 te 'snel' is voor wachtwoordhashing dan heb ik slecht nieuws voor je, snelheid is bij een hashingprimitieve juist wenselijk.

Dat er alternatieven zijn die beter geschikt zijn voor wachtwoordhashing is irrelevant.
Bij hashes van wachtwoorden is snelheid juist niet wenselijk. Daarom is het ook verstandig om vele recursieve hashing-iteraties te doen waarbij je het gehashte wachtwoord opnieuw hasht, opnieuw voorzien van salt. Door dit enkele duizenden malen te doen is het algoritme dermate vertraagd dat het brute-forcen vrij tijdrovend maakt.

Maar MD5 is inderdaad niet veilig te noemen, dus voor wachtwoordhashing heeft dat sowieso al afgedaan. Als checksum om te controleren of je download helemaal goed overgekomen is voldoet het wat mij betreft uitstekend. Ter verficatie dat een MITM er niet wat onwenselijke zaken mee uitgespookt heeft is het dan weer onbetrouwbaar, maar dat hangt maar net van af hoe waarschijnlijk je het acht dat iemand je download zou willen manipuleren en wat de gevolgen daarvan zouden kunnen zijn.
In dit geval maakt het niet zoveel uit omdat hier alleen addons.xml mee wordt gehashed om te kijken of er al dan niet updates zijn.
Het gaat hier niet om credentie data, waar je een punt zal hebben.

Md5 word nog zoveel toegepast in dergelijke situaties (bv voor controle of je download al dan niet corrupt is) en is hartstikke prima daarvoor
MD5 wordt hier enkel gebruikt om vast te stellen of het bestand is gewijzigd en er dus noodzaak is om de addons bij te werken.
tja, daar heb je geen md5 voor nodig, simpele versie check is voldoende...
Opzich is het waar dat md5 behoorlijk zwak is, maar dat heeft niks met dit lek te maken. Een md5 hash wordt alleen gebruikt om te kijken of er nieuwe updates zijn, en wellicht na het downloaden om te checken of deze beschadigd is.

Bovenstaand lek zou onveranderd werken als ze sha2 of elk ander hashing (of checksum) algo zouden gebruiken.
Volgens mij is MD5 nooit bedoelt geweest als beveiliging, maar alleen als controle of bijv. de gedownloade bits overeenkomen met de bits die zijn verstuurd. Zoals ook in het artikel te lezen is werkt gewoon het controle mechanisme niet goed, heeft verder niks met MD5 te maken. Daarnaast is de verbinding niet beveiligd waardoor iemand er tussen kan komen. Twee zaken die ervoor zorgen dat dit update mechanisme niet goed en veilig werkt.

Note: zie dat een aantal mensen hierboven mij voor was :D

[Reactie gewijzigd door William_H op 23 juni 2015 14:53]

Overigens is md5 ook niet geschikt om t.b.v. de beveiliging te kijken of een bestand gewijzigd is. Een kwaadwillende derde kan het bestand hebben aangepast en de hash overeen laten komen om je te doen denken dat je het goede bestand hebt.
Dan vraag ik mij toch af waarom zelfs betrouwbare partijen nog steeds gebruik maken van MD5 hashes als je wat download. Dan maar overstappen op SHA?
Dat is vanwege de gewoonte. Het is voor die doeleinden onveilig omdat het relatief triviaal is om een willekeurig bestand dezelfde md5 hash te geven als het bestand dat je wilt vervangen. Zie ook deze link, die eerder gepost werd door Mega1mpact.
Precies. TLS is onhandig. Nog los van dat CA certificaten behoorlijk duur zijn voor een project als Kodi is het hele CA systeem sowieso niet echt geschikt hiervoor. Een systeem zoals Ubuntu met zijn repo's gebruikt is veel beter geschikt, en kost bovendien niks.

Ik vertrouw liever de Kodi admins dan een willekeurige CA uit een ver land. Zeker gezien je de Kodi admins toch al moet vertrouwen om hun software+repo's te gebruiken in de eerste plaats.

Edit: opzich is het een optie dat Kodi zijn eigen Root CA wordt. Het cert hoeft tenslotte niet geaccepteerd te worden door OS'en en browsers, maar alleen door Kodi zelf. Dit komt dan feitelijk neer op een mooie hybride tussen beide systemen. En je kan de bestaande http-infra en -code blijven gebruiken (ervanuitgaande dat alles toch wel tls support heeft)

Edit2: TLS is nog steeds onhandig, ookal zou je een eigen CA zijn of gratis certs krijgen. Mirrors kunnen vaak geen TLS aanbieden, en al zou een mirror TLS hebben, dan is er nog geen signing vanaf de developen naar de end-user (zie ook post van Thralas hieronder)

[Reactie gewijzigd door Peetz0r op 23 juni 2015 15:09]

Precies. TLS is onhandig. Nog los van dat CA certificaten behoorlijk duur zijn voor een project als Kodi is het hele CA systeem sowieso niet echt geschikt hiervoor. Een systeem zoals Ubuntu met zijn repo's gebruikt is veel beter geschikt, en kost bovendien niks.
Eens, maar een SSL certificaat verkrijgen hoeft niets te kosten. Kodi is een niet-commercieel project, waardoor ze zelfs een gratis certificaat bij StartSSL op zouden kunnen halen. Bovendien controleert 99,9% van de massa niet of een certificaat alleen maar domain validated is.
Ik vertrouw liever de Kodi admins dan een willekeurige CA uit een ver land. Zeker gezien je de Kodi admins toch al moet vertrouwen om hun software+repo's te gebruiken in de eerste plaats.
Daarom schreef ik 'eens'. Het past beter bij sleutelbeheer in een grootschalig softwareproject. Een andere reden is dat je zo mirrors (mogelijk gehost door vrijwilligers) ontlast, omdat die alleen maar 'dom' HTTP en/of FTP hoeven aan te bieden.

[Reactie gewijzigd door The Zep Man op 23 juni 2015 14:53]

De budgetten bij Kodi zijn voldoende toereikend om deze kosten te kunnen dragen:
https://docs.google.com/s...zQHqNgsrqkPlSA/edit#gid=8
Maar waar moeten we dan het bier van betalen op de jaarlijkse DevCon? ;)
Er zijn inderdaad gratis certs die prima voldoen, maar dannog.
Een andere reden is dat je zo mirrors (mogelijk gehost door vrijwilligers) ontlast, omdat die alleen maar 'dom' HTTP en/of FTP hoeven aan te bieden.
Dat is inderdaad een goed punt wat TLS nog verder ongeschikt maakt. Vergeet mijn edit in mijn vorige post.
Precies. TLS is onhandig. Nog los van dat CA certificaten behoorlijk duur zijn voor een project als Kodi is het hele CA systeem sowieso niet echt geschikt hiervoor. Een systeem zoals Ubuntu met zijn repo's gebruikt is veel beter geschikt, en kost bovendien niks.
Het systeem in kwestie heet PGP (Pretty Good Privacy) en wordt door talloze Free Software projecten gebruikt. Al gebruikt men meestal de GNU-implementatie, GPG. Er is een veel ervaring met dit systeem onder ontwikkelaars van Vrije Software en er is een hoop software te krijgen om te helpen bij het beheer.
Edit2: TLS is nog steeds onhandig, ookal zou je een eigen CA zijn of gratis certs krijgen. Mirrors kunnen vaak geen TLS aanbieden, en al zou een mirror TLS hebben, dan is er nog geen signing vanaf de developen naar de end-user (zie ook post van Thralas hieronder)
In plaats van TLS op de webserver zou ik de X509-certificaten gebruiken om de bestanden te signen. Dan maakt het niet uit hoe de bestanden op het systeem komen (https, http of per postduif) maar het systeem kan nog steeds controleren dat ze echt van Kodi komen. Eventueel kunnen ze ook certificaten aan de developers geven. Persoonlijk vind ik PGP handiger in zo'n systeem maar het kan ook met X509.
Eventueel kunnen ze ook certificaten aan de developers geven.
Da's niet echt een eventueel, dat moet wel. Kodi gaat echt niet alle add-ons van iedereen ondertekenen, al was het maar omdat een deel ervan niet in ieder land legaal is. Maar ook omdat ik niet verwacht dat ze daar de mankracht voor hebben. (of je gaat automatisch ondertekenen, maar hoe nuttig is het dan nog..)

Als developers hun eigen add-on ondertekenen dan zal je bij eerste installatie van een add-on aan moeten geven dat je die developer wil vertrouwen. Bij updates kan je dan controleren of het met dezelfde key is ondertekend. MitM werkt dan niet meer.
Ze moeten dan wel een relatie hebben met die developers. Als die developers dingen doen die niet door de beugel kunnen dan kan ik me voorstellen dat ze die ook geen certificaat willen geven.
Wat dat betreft is PGP iets makkelijker omdat je geen centrale partij nodig hebt, het is wat meer peer2peer.
Tien euro per jaar bij bekende certificaatboeren. Als kodi dat niet kan missen zou ik het zelf nog lappen ook.
De reden waarom zo'n beetje alle distro's GPG keys gebruiken om hun pakketten te signeren is omdat ze alleen HTTPS niet voldoende vonden, lijkt mij de meest veilige manier :) Maakt misschien het uitbrengen van updates wat lastiger omdat je alles moet signeren maar met een optie er in om ook niet gesigneerde pakketten te accepteren of de onbekende gpg key van het pakket te accepteren moet dat geen probleem zijn.
De reden waarom zo'n beetje alle distro's GPG keys gebruiken om hun pakketten te signeren is omdat ze alleen HTTPS niet voldoende vonden,
Onwaar. De reden waarom de meeste distributies dit doen is omdat de mirrors vaak HTTP (zonder SSL) of FTP gebruiken. Zie Debian, Arch... Een andere reden is dat zo wellicht beter in het package management process en bijbehorend sleutelbeheer valt.

Overigens maakt WSUS van Microsoft ook gewoon gebruik van HTTP verbindingen voor de overdracht van ondertekende bestanden.

[Reactie gewijzigd door The Zep Man op 23 juni 2015 14:50]

Onwaar. De reden waarom de meeste distributies dit doen is omdat de mirrors vaak HTTP (zonder SSL) of FTP gebruiken.
Ook niet helemaal waar. Stel dat alle mirrors [i]wel]/i] SSL gebruikten, dan nog biedt SSL enkel garanties ten aanzien van de mirroroperator, terwijl je juist zekerheid wilt hebben dat de packages van de developers afkomstig zijn. Enkel GPG biedt die garanties (naast andere reeds genoemde voordelen).

[Reactie gewijzigd door Thralas op 23 juni 2015 14:58]

Ik snap niet echt waarom Bitdefender nu al met dit lek naar buiten komt, en waarom ze niet even wachten totdat Kodi een patch heeft gemaakt.
Nu lopen ruim een half miljoen gebruikers een groter risico om ongewenste updates te krijgen.

Heb niks tegen onderzoekers die lekken openbaar maken, maar alleen als ze de ontwikkelaar iig voldoende tijd hebben gegeven om een patch te maken.

@Association: Mee eens, het gevaar is niet echt enorm, maar waarom niet 1~2 maanden wachten, het nieuws wordt er niet minder groot om, terwijl je potencieel je het gevaar meer uitsluit.

Terwijl als ze in overleg werken, een vermelding en bedankje van het vinden van lek hadden kunnen krijgen.

[Reactie gewijzigd door player-x op 23 juni 2015 15:25]

Zoals BartOtten hierboven al aangeeft heeft hij hier twee maanden geleden al de discussie over willen openen. Er was echter niemand die bereid om er serieus het gesprek over aan te gaan.
Zoals al meerdere malen aangegeven: probleem aankaarten is 1 ding, probleem oplossen door patches aan te leveren of te wachten tot een dev dit oppakt is iets anders.

Ik kan talloze manieren verzinnen om Kodi te hacken. En, met wat meer zoekwerk, alle afgeleide varianten als Plex, zijn in 9 van de 10 gevallen net ook vatbaar hiervoor. De vraag is alleen hoeveel moeite je erin moet steken om het voor elkaar te krijgen en hoeveel installaties er vatbaar voor zijn (bijv. via de webserver).

Deze add-on update hack is vrij eenvoudig uit te voeren, maar met wat meer moeite is er veel meer mogelijk dan dit. Ik heb al een paar voorbeelden gegeven in andere posts.

Wil je Kodi compleet veilig krijgen, dan moet je add-ons gaan sandboxen, binary add-ons verbieden, etc.
Zoals al meerdere malen aangegeven: probleem aankaarten is 1 ding, probleem oplossen door patches aan te leveren of te wachten tot een dev dit oppakt is iets anders.
Wat mij als dev weerhoudt om patches aan te leveren is dat er binnen Kodi geen "normale" manieren van erkenning is voor het werk van ontwikkelaars. Overal in jullie code is deze header te vinden:
/*
* Copyright (C) 2005-2013 Team XBMC
* http://xbmc.org
*
* This Program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2, or (at your option)
* any later version.
*
* This Program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with XBMC; see the file COPYING. If not, see
* <http://www.gnu.org/licenses/>.
*
*/
Op dit manier is iedereen verantwoordelijk voor alles en dat betekent dus niemand.

Pak een willekeurige driver van de officiŽle linux kernel en je ziet dit:
/*
* HID driver for some a4tech "special" devices
*
* Copyright (c) 1999 Andreas Gal
* Copyright (c) 2000-2005 Vojtech Pavlik <vojtech@suse.cz>
* Copyright (c) 2005 Michael Haboustak <mike-@cinci.rr.com> for Concept2, Inc
* Copyright (c) 2006-2007 Jiri Kosina
* Copyright (c) 2008 Jiri Slaby
*/

/*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
* Software Foundation; either version 2 of the License, or (at your option)
* any later version.
*/
Jullie implementatie betekent ook dat wanneer jullie van licentie zouden willen wisselen, ik als meedenker geen poot heb om op te staan, omdat je impliciet afstand doet van je intellectuele eigendom.
Dit is een bewuste keuze geweest in het verleden, en door code te submitten doe je inderdaad afstand van je intellectuele eigendom. Deze policy gaat, om meerdere redenen, niet snel veranderen.

Als je erkenning van je werk wil in de code je geschreven hebt tot het einde der tijden, dan is Kodi niet het juiste project voor jou. Al hebben we sinds we naar git geswitched zijn een mooie ranking: https://github.com/xbmc/xbmc/graphs/contributors (en ik ben gezakt naar de 7e plaats :( )
Dat betekent dus tevens dat Kodi zonder ruggespraak opeens een commercieel gesloten pakket kan worden zonder dat je er als ontwikkelaar ook maar iets over te zeggen hebt. Dat is in mijn ogen een van de kern problemen van XBMC dat mij ervan weerhoudt om eraan bij te dragen.
Kodi is GPL2+, zoals een groot deel van de open source software die jij waarschijnlijk gebruikt. Zoals bijvoorbeeld de driver die je hierboven aanhaalde.

Commercieel gebruik is zeker toegestaan, gelukkig maar. Stel je voor dat de Linux kernel niet commercieel gebruikt had mogen worden :)

Gesloten niet; je moet de wijzigingen delen als je Kodi gebruikt in een commercieel product.
Dat is in zijn geheel niet wat ik probeer duidelijk te maken ;)

Als je je eigen software project van een andere licentie wil voorzien, dan moet iedereen die er aan bijdragen heeft en dus een deel van de codebase bezit, daarmee instemmen. In jullie geval, draagt iedereen zijn werk over aan XBMC en verliest daarmee de copyright over zijn eigen bijdrage. Het XBMC team heeft daarmee de macht om wanneer het wil van licentie te veranderen zonder dat daar de ontwikkelaars die er aan bijgedragen hebben er ook maar iets over te zeggen hebben.

De Linux kernel kan niet zomaar van licentie veranderen, want iedereen die er een bijdrage aan heeft geleverd moet er dan mee instemmen. De enige optie die ze hebben is modules weggooien van mensen die niet instemmen.

Dat is iets waar ik me als ontwikkelaar bewust van ben. Daarom zou ik dus nooit een bijdrage doen aan XBMC, maar wel aan de Linux kernel (en dan heb ik in het verleden dan ook gedaan).
Ik geloof dat je je eens moet verdiepen in hoe Kodi in elkaar zit en waarvoor er een XBMC Foundation is (ja, nog steeds XBMC ;))

Zelfs als de Foundation het voor elkaar zou krijgen om naar een gesloten licentie over te stappen, wat niet gaat gebeuren door de regels waaraan de Foundation zich dient te houden, dan zou je nog altijd de zaak kunnen forken en verder kunnen gaan waar je gebleven was.

Team Kodi heeft geen macht om van licentie te veranderen, en zelfs als we dat hadden, dan zou elk lid ermee in moeten stemmen.
Ik geloof dat je je eens moet verdiepen in hoe Kodi in elkaar zit en waarvoor er een XBMC Foundation is (ja, nog steeds XBMC ;))

Zelfs als de Foundation het voor elkaar zou krijgen om naar een gesloten licentie over te stappen, wat niet gaat gebeuren door de regels waaraan de Foundation zich dient te houden [...]
De huidge manier waarop jullie code van anderen opnemen onder "Team XBMC" biedt echter geen enkele bescherming voor een mogelijke licentie wissel.

Het is daarnaast de Foundation zelf die de regels bepaald en die zijn dus prima veranderbaar.
[...] dan zou je nog altijd de zaak kunnen forken en verder kunnen gaan waar je gebleven was.
En jullie zouden daarnaast gewoon onder een andere licentie verder kunnen gaan zonder dat ontwikkelaars buiten de Foundation daar enig bezwaar tegen kunnen maken. Het erkennen van contributies door het noemen van individuele ontwikkelaars zou daar een keiharde bescherming tegen zijn. Zo simpel is het :)
Het is onmogelijk om Kodi een nieuwe licentie te geven. Zelfs als de Foundation dat zou willen en toestemming zou krijgen van alle board leden. Dat laatste gaat simpelweg al niet gebeuren, maar zelfs als dat al zou gebeuren dan zou elke individuele developer die ooit code heeft geschreven die nog in de codebase zit op dat moment toestemming moeten geven voor deze aanpassing.

Ik heb me zojuist laten vertellen door de mensen die er meer vanaf weten dan ik dat de contributor expliciet toestemming moet geven wanneer hij/zij het eigendomsrecht overdraagt. Dat gebeurt bij ons niet, dus blijf je zelf eigenaar.

Maar ik zie dit als een puur theoretische discussie. Dit gaat simpelweg nooit gebeuren en vind dit een slecht argument om niks bij te dragen.
Beetje jammer inderdaad. Kodi is dan ook nog eens een open source pakket met zeer toegankelijke devs.
Behalve als het gaat om repo's....de mensen die daar verantwoordelijk voor zijn, zijn verre van toegankelijk :( Dat de rest prima mensen zijn, lost dit probleem dus niet op.

[Reactie gewijzigd door BartOtten op 24 juni 2015 19:08]

correctie: repositories met een bepaald soort content ;)
I stand correced. Over en uit :)
Marketing en goede, gratis, reclame. Het boeit ze niks dat gebruikers at risk zijn. Gaat om eigen gewin. Het gevaar valt overigens ook wel te overzien maar goed.
Allereerst dikke duim voor de software ontwikkelaars van Kodi. Plex werkt verschrikkelijk slecht, en dat ziet er gewoonweg niet uit (of ik doe iets verkeerd).
Ik heb een computer in m'n tv-meubel staan waar enkel win8 met Kodi op staat en alle mediafiles. Voor iets anders wordt deze niet gebruikt, dedicated mediacenter als het ware. Er zijn nooit paswoorden op gebruikt, er staat geen antivirus of iets dergelijks op, enkel windows firewall en windows defender. Er wordt ook nooit internet op gebruikt. Ik kan wel via de smartphone met Yatse op Kodi. Is mijn systeem dan vatbaar voor problemen via Kodi ?
Vatbaar wel maar echt gevaar loop je niet als je alleen maar wat films bekijkt. Ook moet al iemand op je LAN zitten en verkeer onderscheppen en aanpassen. Zal niet zo snel gebeuren. Waarom zet je er trouwens geen OpenElec op? Heeft hetzelfde lek maar gezien je toepassing van de pc heeft Windows + Kodi geen meerwaarde. OpenElec is lichter en sneller en minder gezeur met Windows Updates etc.
Ik ben niet zo heel technisch aangelegd wat computersoftware betreft. Als er iets fout zou lopen met windows, dan kan ik er nog wel mee weg maar van Linux weet ik eigenlijk niets. Daarom windows dus. En wat de snelheid betreft, op een kleine 20 seconden is windows opgestart en een paar seconden later Kodi. Ik vind windows handig om bestanden te verslepen van m'n Synology naar het mediacenter, waar de bestanden dienst doen als backup. Ik zal eerst eens wat openelec met Kodi installatie- en gebruikersfilmpjes moeten bekijken alvorens ik weet waar ik mee bezig ben.
Webapps zouden zichzelf sowieso niet moeten updaten. De gevolgen die dat heeft voor de beveiliging zijn verschrikkelijk. Hiervoor geef je feitelijk via een webinterface toegang tot de core files van de software en het is een kwestie van (niet al te lang) afwachten totdat daar gaten in gevonden worden waardoor je zelf de code kunt aanpassen. Door gewoon niet te implementeren dat bestanden aangepast, toegevoegd of overschreven kunnen worden voorkom je een dergelijke aanvalsmethode.

En hoe erg is het nou helemaal om zelf eerst de update naar je PC te downloaden en vervolgens handmatig op de server te uploaden middels SFTP oid?

edit:
Realiseer me net dat Kodi helemaal geen web-app is. Alsnog... updates moeten aan een update-manager overgelaten worden, en niet door het programma zelf geinstalleerd worden. Ik werk over het algemeen ook met een white-list systeem voor uitgaande verbindingen voor applicaties, ze mogen alleen "naar huis bellen" als ik dat expliciet goedgekeurd heb. Scheelt een hoop gedonder

[Reactie gewijzigd door MadEgg op 23 juni 2015 16:39]

Persoonlijk verrast dit bericht me weinig. Ik kan best waarderen dat men zich meer focust op veiligheid, maar aan de andere kant zie je ook dat wanneer "onderzoekers", "nieuwe kwetsbaarheden blootleggen", deze berichten vrij gemakkelijk worden overgenomen. Gemakkelijk scoren dus.
Kodi/XBMC is al jaren onveilig, zeker als je hem draait onder root. Het lijkt mij niet nodig voor een MC toegang te hebben tot alles, maar ik begrijp wel dat het een moeilijke taak kan worden.

Een tijdje geleden ben ik eens gedoken in een add-on ontwikkeld voor IPTV. Het mooie is dat de ontwikkelaar(s) alle vrijheid hebben, maar dat is ook in een keer een groot nadeel. Als ze zouden willen konden ze bijvoorbeeld mijn hele schijf scannen en deze gegegevens sturen naar een server. Je hoeft ook niet super geskilled te zijn, aangezien dat allemaal vrij makkelijk gaat in Python (en als root).

Inmiddels daardoor maar besloten om Kodi niet meer te grbruiken. Met Chromecast kan ik immers ook alle content op de TV krijgen en dat ook nog met minder resources.
Ik ben al heel lang een tevreden gebruiker van xbmc/kodi.
Ik verbaas me alleen over alle kritiek als er een security leak is gevonden in kodi.
Kodi is in mijn ogen de beste media player ter wereld en het mooiste van de software is dat het nog gratis is ook !
De mensen achter deze software verdienen een dikke pluim in plaats van welke vorm van kritiek ook.

Keep up the good work !!!!!
Jpam
Een tevreden gebruiker met of zonder security issue

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True