Sun-developer boos op Apple om wijziging debugtool

Een van de ontwikkelaars van de opensource debug-tool Dtrace heeft ontdekt dat Apple aanpassingen in de broncode heeft doorgevoerd, waardoor bepaalde programma's niet meer getraceerd kunnen worden.

Het door Sun ontwikkelde Dtrace is, al dan niet in combinatie met de gui Instruments, sinds de introductie van Leopard in OS X beschikbaar als debugging tool. Met behulp van een scriptingtaal kan Dtrace processen volgen en het uitvoeren van code in kaart brengen. Adam Leventhal, een van de ontwikkelaars van de debugger, ontdekte echter dat Dtrace onder bepaalde voorwaarden geen toegang meer krijgt tot bepaalde processen.

Leventhal liep bij toeval tegen een onverwacht resultaat in de output van Dtrace aan, dat hij kon herleiden naar iTunes. Nadere analyse wees uit dat dit programma volledig onzichtbaar voor Dtrace was. Dat zou het gevolg zijn van een wijziging in de broncode van het opensourceprogramma, waardoor Dtrace volgens Leventhal niet langer correct functioneert en geen betrouwbare resultaten meer levert. Aangezien iTunes ook de GNU-debugger blokkeert, en de Fairplay-drm van iTunes onder Windows dankzij low-level tools gekraakt is, is het niet ondenkbaar dat de Dtrace-beperking bedoeld is om de kopieerbeveiliging van Apple te beschermen.

Reacties (68)

[nhbergboer]

Dit is weinig verbazend:


DRM is een wiskundige onmogelijkheid: je geeft de klant niet alleen de encrypted content, maar noodzakelijkerwijs ook de key (zijn computer moet immers de content kunnen afspelen). Iemand met zowel de encrypted content als de key, is altijd in staat om de cleartext te verkrijgen. Bijgevolg is elk DRM systeem per definitie gebouwd op "security through obscurity".


Daarom zul je ook nooit een open-source DRM systeem vinden; dat is een oxymoron, omdat op dat moment het "obscurity" gedeelte wegvalt.


Daarom wil Apple liever niet dat jij de systeemprocessen kunt monitoren, omdat daarbij (in ieder geval een deel van) de "obscurity" wegvalt.


Nogmaals: DRM _kan_ nooit veilig zijn. Je hoeft ook nooit een encryptie te "kraken"; je hebt immers de key. Het enige wat DRM enigszins "beschermt" is dat men redelijk verstoppertje weet te spelen met die key.

[smokalot]

Je hebt gelijk, maar op het moment dat niet de user die key heeft, maar de computer van de user, en de user dus niet meer overal bij kan (de computer is dus niet meer van de user, maar van de DRM-enforcer), kan het wel veilig zijn. Nou ja, als de hele keten veilig is, 1 lek en het systeem stort in. Plus dat the analog hole ook bijna onmogelijk te patchen is, als je het kunt horen kan je het oppikken met een microfoon, en als je het kunt zien kun je het opnemen met een camera.

[Anoniem: 249914]

het enige nadeel van dat analog hole is de omzetting van digitaal terug naar analoog en achteraf terug naar digitaal (als je er een mp3 of drm-vrije aac van wilt bakken)

om te omzeilen kan je (voorlopig nog) virtual drives gebruiken om je drm-zooi op audio-cd te "branden" en terug te importen achteraf

[kozue]

De user heeft de key ook niet, dat doet software voor m (de software heeft de key). Het enige wat een beetje moeite kost is die key in het geheugen terug vinden. Ik snap je gedachtegang niet zo, maar whatever je in gedachten had, het kan niet. Zelfs als je met 'computer van de user' een stukje hardware zoals een TPM chip bedoelt, kun je nog steeds die key uitlezen, de software moet er immers bij kunnen.

[smokalot]

maar ik moet diezelfde computer gebruiken om de key in het geheugen (of TPM-chip) te vinden, dus als die computer mij dat niet toestaat gaat het hele feest niet door.

De consoles gebruiken vergelijkbare methoden, en die zijn niet echt gekraakt. Er zijn imperfecties in de implementaties gevonden, waar omheen gewerkt kan worden, maar het principe staat nog steeds. Een PC moet natuurlijk ook zelfgeschreven software kunnen draaien, dus dat is weer moeilijker te beveiligen, maar t zou kunnen.

[Anoniem: 112442]

Dit is weinig verbazend:

Ik vind het wel, je gaat toch geen debug tools verminken. Getuigt IMO op weinig respect.

[mashell]

Je gaat toch ook geen software debuggen waar jij dat niet van mag? Dat getuigt ook van weinig respect.

[Anoniem: 112442]

Zoiets moet in een debug package opgelost worden en niet in de code waar het over gaat?

Als je namelijk per ongeluk de zelfde key words gebruikt als Apple doet zal een debug voor je eigen programma niet werken. Aangezien het niet gedocumenteerd is kan het erg veel tijd kosten om dit te vinden.

Vandaar weinig respect.

Dtrace is door Sun ontwikkeld in de code die voor overgrote deel uit Sun code bestaat gaat Apple aanpassingen maken die de werking van het programma in negatieve zijn beïnvloed. Waardoor ook (open)Solaris gebruikers mogelijk foute debug informatie krijgen. Dtrace is initieel voor Solaris ontwikkeld.

[Reactie gewijzigd door Anoniem: 112442 op 23 juli 2024 08:17]

[TheCapK]

Het is dus belangrijk om te weten hoe Apple dit heeft gedaan. Is er nu maar 1 versie te krijgen die altijd de Apple toevoeging heeft of krijgen alleen de Apple gebruikers deze versie en krijgen andere gebruikers de originele versie. In dat laatste geval is er namelijk helemaal niets aan de hand voor andere dan Apple gebruikers.

[Mr_Light]

dat doet er niet toe, alle programma's beinvloeden alle andere programma's.
Dit komt omdat ze allemaal resources moeten delen: cpu tijd geheugen etc. Door de aanpassing van apple ken je niet alle krachten die op je systeem werken waardoor de debug resultaten van alle andere programma's ook minder waardevol zijn.

[Anoniem: 19339]

Logisch dat Apple dit inbouwt, ze zullen wel onder druk van de muziekindustrie maatregelen hebben moeten treffen om geen debuggers op iTunes los te kunnen laten. Ik vind de keuze om de meegeleverde DTrace aan te passen daarom ook zo gek nog niet. En als ze zich aan de licentie van DTrace houden (zal ook wel iets zijn als "wijzigen mag, zolang je de broncode maar meelevert") is er ook juridisch niet aan de hand.

Erger is dus dat dit nadelige effecten heeft voor het debuggen van andere processen, en dat kan natuurlijk niet de bedoeling zijn. Het originele artikel laat zien hoe een simpele trigger die elke 1/1000 seconde afgaat, een hoop keren gemist wordt als iTunes draait. Mag natuurlijk niet, dit schaadt serieus het nut van DTrace.

Ik vind het dus erger dat er een bug in DTrace zit, dan dat Apple probeert z'n eigen (closed source) applicaties af te schermen van nieuwsgierige aagjes die dit voornamelijk doen om iTunes' Fairplay te hacken.

Maar goed, het is negatief nieuws over Apple, dus let the flames begin...

De titel van het artikel is ook weer zwaar overdreven... De developer is helemaal niet boos. Uit het originele artikel:

To say that Apple has crippled DTrace on Mac OS X would be a bit alarmist, but they've certainly undermined its efficacy and, in doing do, unintentionally damaged some of its most basic functionality. To users of Mac OS X and of DTrace: Apple has done a service by porting DTrace, but let's convince them to go one step further and port it properly.

[Reactie gewijzigd door Anoniem: 19339 op 23 juli 2024 08:17]

[Carbon]

Er is inmiddels een eenvoudige oplossing die werkt zonder een recompile van DTrace

[Anoniem: 157697]

Mag je een (opensource)broncode zo wijzigen dat je bepaalde programma's censureerd?

[Carbon]

In het geval van DTrace (copyleft) mag dat mits je de aanpassingen maar openbaar maakt, en dat heeft Apple gedaan!

Het gaat om de volgende code:

#if defined(__APPLE__)
/*
* If the thread on which this probe has fired belongs to a process marked P_LNOATTACH
* then this enabling is not permitted to observe it. Move along, nothing to see here.
*/
if (ISSET(current_proc()->p_lflag, P_LNOATTACH)) {
continue;
}
#endif /* __APPLE__ */

[SPee]

Ik zou ook kwaad zijn, als opeens zo'n stuk code in mijn programma terecht komt.
Vanuit Apple gezien is het wel te begrijpen, maar vanuit de gedachtegang van die applicatie, is dat niet gewenst en dus een verminking.

Een 3rd partij werkt code bij, maar tijdens 1 van die updates wordt je applicatie verminkt in functionaliteit.

Op zich is het maar een klein stukje code dat hiervoor zorgt, maar ik zou toch een extra '#if defined(_EVIL_APPLE_)' ertussen zetten. Zodat je dit stukje niet meekrijgt als je het niet wilt.

[humbug]

Vergeet niet dat volgens de licentie (copyleft) de developers het prima vinden als mensen hun code naar believen aanpassen. Nu doet Apple dat en gaat er toch iemand klagen. Gebruik dan een andere licentie.... Dus SPee, als je niet wil dat zoiets in je programma terecht komt gebruik dan een licentie die dat verbiedt. Doe je dat niet moet je niet klagen...

[Anoniem: 97509]

DTrace is beschikbaar gesteld onder CDDL (Mozilla license derivaat).

Er is geen boosheid over het feit dat Apple de code veranderd heeft. Wat steekt is dat door de veranderingen de reele kans bestaat dat perfect valide DTrace scripts onvolledige of verkeerde output geven. *dat* mag natuurlijk niet gebeuren (ookal zou het volgens de licentie wel mogen, het is natuurlijk waardeloos als je de output van een tool, met name DTrace, niet meer kan vertrouwen).

Dat is de crux van het verhaal. Het heeft niks met licenties of toegestane veranderingen aan DTrace te maken.

[Anoniem: 112442]

Vergeet niet dat volgens de licentie (copyleft) de developers het prima vinden als mensen hun code naar believen aanpassen.

Klopt maar alleen als de code minimaal op het zelfde niveau blijft. Dat is hier niet het geval, de code is verminkt.

[Bigs]

Onzin.. Apple heeft DTrace geport naar OS X geport en daar een stukje functionaliteit aan toegevoegd. Voor de mensen die DTrace gebruiken op Solaris verandert er niks.

Het is Open Source software, dus niemand hoeft ervan te balen 'als opeens zo'n stuk code in mijn programma terecht komt'.

[Jeanpaul145]

@Bigs:

Het hangt er een beetje vanaf waardoor je plots niet meer aan die processen kan attachen. Als het, zoals kozue al zei, in de kernel is veranderd, is dit idd meer een stukje code om een error te vermijden.
Aan de andere kant, als dit nieuwe stukje code er juist voor zorgt dat DTrace niet meer kan attachen aan bepaalde processen, dan zou ik dit geen "toegevoegde functionaliteit" noemen, eerder "de functionaliteit verkreupelen" ofzo.

[HAL 9000]

Apple heeft DTrace geport naar OS X geport en daar een stukje functionaliteit aan toegevoegd.

Reeds gebrainwashed door Apple blijkbaar: ze hebben juist functionaliteit weggehaald uit het programma, géén toegevoegd.

[heyajohnny]

Dus nu moet DTrace updates uit gaan voeren, omdat Apple dit even zonder te melden in zijn iTunes zet?

Zou het niet beter zijn van Apple om de wijzigingen aan bepaalde developers door te geven, zodat zij op de hoogte zijn van de wijzigingen?

[Janoz]

@heyajohnny
Dit staat niet in iTunes. Dit is een stukje source van DTrace.

[trogdor]

wat weerhoudt men ervan deze if er uit te slopen?

[kozue]

Je kan de if er wel uitslopen, maar voor zover ik het begrijp (uit het stukje over GDB waarnaar werd gelinkt in het artikel) voorkomt de if alleen maar dat je een error terug krijgt. Apple heeft blijkbaar iets in de kernel ingebouwd waarmee processen zichzelf aan kunnen geven als 'niet debugbaar', en zo'n proces kan dtace zowiezo niet bij. Als iTunes tegen de kernel verteld dat een debugger er niet bij kan, en apple laat dtrace die processen al uit zichzelf skippen, helpt het dus niks om die if te verwijderen.

Wat waarschijnlijk beter werkt, is ervoor zorgen dat iTunes zichzelf niet als ondebugbaar proces kan instellen, bv met deze kernel module, zodat die hele if niks meer doet.

[Carbon]

Niets

[Carbon]

Dus nu moet DTrace updates uit gaan voeren, omdat Apple dit even zonder te melden in zijn iTunes zet?

Die wijziging heeft alleen invloed als je DTrace compileert voor OSX, dus hoezo updates?

Zou het niet beter zijn van Apple om de wijzigingen aan bepaalde developers door te geven, zodat zij op de hoogte zijn van de wijzigingen?

Daarmee zou Apple de voorwaarden (copyleft) overtreden.
Alle wijzigingen moeten openbaar gemaakt worden.

[Sijmen]

Deze code hoeft helemaal niet in de officiele DTrace codebase opgenomen te worden, mochten ze dat niet willen.

[Anoniem: 20901]

Ok, maar waarom is die dude dan boos? Lijkt me vrij simpel op te lossen...

[Carbon]

Hij is ook niet boos

Je laat je teveel lijden door de kop van het artikel.

[Reactie gewijzigd door Carbon op 23 juli 2024 08:17]

[Kapotlood]

Sun kan wel kwaad worden, maar het is van Apple's kant begrijpelijk dat ze hun DRM veilig willen stellen. Ze kunnen natuurlijk ook gewoon Apple contacten en kijken of ze samen met een oplosing kunnen komen voordat ze openlijk via het internet beginnen te miepen

[sopsop]

Niet als je die wijziging close source houdt.

[TommyCP]

Als ik me niet vergis hangt dit volledig van de licentie af. Software met een GPL-licentie mag bijvoorbeeld niet gesloten worden, software met een BSD-licentie echter wel. Of iets 'open' is zegt dus niets over de voorwaarden.


_{Edit: typo's...}

[Reactie gewijzigd door TommyCP op 23 juli 2024 08:17]

[Anoniem: 157697]

okey... maar het blijft zo dat het verkeerd is om te doen.
toch?

Het is opensource, kan je de code er niet uit schrijven? (A)

[Reactie gewijzigd door Anoniem: 157697 op 23 juli 2024 08:17]

[Randal Peelen]

Het feit dat het om een open source programma gaat maakt ook dat je juist deze wijzigingen zelf ongedaan kunt maken, plus dat er een vorm van openheid over deze wijzigingen zou moeten bestaan.
Het OS van Apple hangt trouwens sowieso van open source programmatuur aan elkaar; veel wijzigingen die zij in deze software inbouwen om zichzelf te 'beschermen' zou net zo discutabel kunnen zijn als deze.

[mashell]

Het OS van Apple hangt trouwens sowieso van open source programmatuur aan elkaar

Als die open source onder BSD licentie staat is daar natuurlijk helemaal niets mis mee.

[s463042]

DTrace is ontwikkeld door Sun en vrijgegeven onder de CDDL (lees ook) licentie. Maar ook onder deze licentie moeten deze wijzigingen openbaar gemaakt worden.

[Reactie gewijzigd door s463042 op 23 juli 2024 08:17]

[Anoniem: 247379]

Dat ligt maar net aan de licentie die je gebruikt.

[johnbetonschaar]

En dat mag dus volgens veel OSS licenties (zoals GPL) niet. OSS gebruiken in een product dat gedistribueerd wordt (op wat voor manier dan ook) betekent in dat geval dat *alle* wijzigingen aan de source code openbaar worden. Dat is dan ook de reden dat veel Apple code zijn weg ook naar Linux vindt, zoals bijvoorbeeld verbeteringen aan de Konqueror rendering engine (die door Apple als 'WebKit' wordt doorontwikkeld), en de broncode van de firmware van veel routers vrij te downloaden is.

[smokalot]

ligt eraan welke licentie van toepassing is op die code, met GPL mag het niet, met BSD/Apache mag het wel. En DTrace zal dus wel BSD-achtig zijn.

[Anoniem: 112442]

Deze actie zegt IMO ook iets over het security niveau van Apple.

Je moet erg naïef zijn om te denken dat een aanpassing in een debugger voorkomt dat een DRM misbruikt kan worden. Ze zullen al heel snel zien, door het ontbreken van info van Apple programma's, dat er iets mis is met Dtrace. Waarna de code snel gevonden zal worden en verwijderd kan worden uit dtrace.

Op slashdot.org had ook nog iemand een interessante opmerking. Als je de NOATTACH flag in je rootkit code zet zul je met de Dtrace van Apple deze rootkit niet meer ontdekken.

[Reactie gewijzigd door Anoniem: 112442 op 23 juli 2024 08:17]

[Anoniem: 58827]

Toch vooral begin ik steeds sterker het gevoel te krijgen dat Apple de kant van Microsoft op gaat. Sommigen beweren dit van Google welk deels ook wel waarheid is. Maar Apple voert er bijna een race op om eenzelfde soort bedrijf te worden.

[kozue]

Ze gaan die kant niet op, ze zijn die kant al op. Het grootste probleem met MS is hun proprietary formaten/protocollen, en de vendor lock-in die je daarvan krijgt. Apple is net zo bezig, door mensen te verplichten met iTunes te werken als ze een iPod hebben, en alles zo gesloten mogelijk proberen te houden.

Over google is onzin trouwens. Ze zijn een aardig groot voorstander van open source en proberen dit ook te promoten (summer of code enzo), en google heeft geen gesloten protocollen (pop/imap voor gmail, jabber voor gtalk, etc). Als google je niet bevalt kun je gewoon iets anders gebruiken, er zijn namelijk nog veel meer aanbieders van online search, mail, maps, etc. Met MS/Apple heb je last van gekoppelde producten, waardoor je andere software verplicht wordt als je 1 product van hun gebruikt, met google niet.

[humbug]

En wat doet Microsoft dan? Winst maken en de markt beschermen? Echt zaken die je niet zou verwachten van een bedrijf.... Elk bedrijf gaat die kant op.

[Tjeerd]

Begrijpelijk dat Apple zo'n soort wijziging heeft doorgevoerd om bijv. een programma zoals iTunes (lees: kopieerbeveiliging) te beschermen. Feit blijft wel dat het een vies truukje is om zo'n soort aanpassing in de broncode van een debugger te doen. En nu maar wachten op de reactie van Apple: broncode-wijziging ongedaan maken of zeggen dat het per ongeluk gegaan is?

[elmuerte]

Begrijpelijk!? Het is gewoon een domme actie. Er zijn genoeg tools die je wel de mogelijkheid geven (zoals je eige gefixte versie van DTrace).
Security through obscurity werkt gewoon niet.

[Anoniem: 112442]

Het is totaal niet begrijpelijk. En ook onzin, want iedereen die weet dat deze aanpassing gedaan is kan de Apple code eruit halen, waardoor de DRM code debugged kan worden.

Iemand die niet bewust is van deze aanpassing en toevallig de zelfde soort calls gebruikt wordt op het verkeerde been gezet.

IMO zijn dit soort acties zo wie zo verkeerd. Als Apple wil dat hun code niet debugged kan worden lossen ze het maar anders op!

Apple verdient hier zo wie zo een schop onder hun kont voor, door debuggers te verminken!

[Anoniem: 162126]

Volgens mij is Apple met itunes druk bezig om drm vrij te (gaan) leveren?
Aan de andere kant zou het best eens kunnen dat ze dit niet willen m.b.t. de iphone
hacks die deels d.m.v. itunes tracing/hacks tot stand zijn gekomen.

[Zware Unit]

Ze verhuren en verkopen ook video's. Hierbij is voor het verhuren DRM noodzakelijk.

[Vaudtje]

Wat is nou de ophef hierover?
Iedereen die met DTrace werkt lijkt mij ook in staat om even zelf een bersie in elkaar te compilen waar de gewraakte code niet meer in zit?

[Anoniem: 84766]

Ik denk dat het niet zo eenvoudig is, er zullen vast meer aanpassingen geweest zijn om processen goed te kunnen tracen in OSX en Mach messages.

[Anoniem: 112442]

Iedereen die met DTrace werkt lijkt mij ook in staat om even zelf een bersie in elkaar te compilen waar de gewraakte code niet meer in zit?

Dus de meerderheid zou de code die door de ultra kleine minderheid (Apple zelf) eruit moeten slopen voor een correcte werking? Ik kan me niet voorstellen dat deze code in het belang is van de Apple gebruiker die wil debuggen.

[mOrPhie]

Ik snap werkelijk niet wat het probleem is. Apple heeft voldaan aan de voorwaarden van het vrijgeven van de wijziging. Dat die sun-developer het als fork ziet is wat anders. Desalniettemin maakt Apple alleen maar gebruik van de kracht van Open Source, alleen heeft in dit geval veel mensen niet veel aan de patch van Apple's kant. Life's a bitch.