Schadsoftware über Radio-Streaming?
- Ersteller toppixus
- Erstellt am
Richtig.Falc410 schrieb:
Richtig.Falc410 schrieb:
Erstens, AVI File ganz andere Baustelle, und streng genommen kein Streaming.Falc410 schrieb:
Gedankenexperiment und mal ein simples Beispiel, weil Du Dich an Dateien aufhängst, und wir beschränken das mal auf eine Audiodatei:Falc410 schrieb:
C:
#include <stdio.h>
#include <stdlib.h>
#include <ao/ao.h>
#define BUF_SIZE 4096
int main(int argc, char *argv[]) {
if (argc < 2) {
printf("Bitte geben Sie den Dateinamen als Argument an.\n");
return 1;
}
FILE *fp = fopen(argv[1], "rb");
if (!fp) {
perror("Datei konnte nicht geöffnet werden");
return 1;
}
ao_initialize();
int default_driver = ao_default_driver_id();
ao_sample_format format;
format.bits = 16;
format.channels = 2;
format.rate = 44100;
format.byte_format = AO_FMT_LITTLE;
ao_device *device = ao_open_live(default_driver, &format, NULL);
if (!device) {
printf("Audioausgabe konnte nicht initialisiert werden.\n");
fclose(fp);
ao_shutdown();
return 1;
}
char buffer[BUF_SIZE];
size_t read;
while ((read = fread(buffer, 1, BUF_SIZE, fp)) > 0) {
ao_play(device, buffer, read);
}
ao_close(device);
fclose(fp);
ao_shutdown();
return 0;
}ao/ao.h
C:
/* library setup/teardown */
void ao_initialize(void);
void ao_shutdown(void);
/* device setup/playback/teardown */
int ao_append_global_option(const char *key,
const char *value);
int ao_append_option(ao_option **options,
const char *key,
const char *value);
void ao_free_options(ao_option *options);
ao_device* ao_open_live(int driver_id,
ao_sample_format *format,
ao_option *option);
ao_device* ao_open_file(int driver_id,
const char *filename,
int overwrite,
ao_sample_format *format,
ao_option *option);
int ao_play(ao_device *device,
char *output_samples,
uint_32 num_bytes);
int ao_close(ao_device *device);
/* driver information */
int ao_driver_id(const char *short_name);
int ao_default_driver_id(void);
ao_info *ao_driver_info(int driver_id);
ao_info **ao_driver_info_list(int *driver_count);
const char *ao_file_extension(int driver_id);
/* miscellaneous */
int ao_is_big_endian(void);
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif /* __AO_H__ */
Code:
ao_device *device = ao_open_live(default_driver, &format, NULL);
:
while ((read = fread(buffer, 1, BUF_SIZE, fp)) > 0) {
ao_play(device, buffer, read);ao_play richtig arbeitet, passiert hier erst mal nichts, egal was Du in die geöffnete Datei neben Audiodaten irgendwo reinsteckst. Es kann der Progammcode abbrechen, aber es passiert hier auch nichts weiter. Siehst Du hier irgendwo eine EXEC, SYSTEM, CONSOLE-Aufruf? Sobald ein Handler eine Datei (was nebenbei in C bzw. Unix/Linux alles als Stream angesprochen wird, wie Du weißt, genau wie ein TCP-Socket, Pipe etc.) öffnet, und das nur gepuffert irgendwo weiterleitet. Und es wird vermutlich auch vom Browser per HTTP/HTTPS auch nur von einer URL nach dem Öffnen gelesen und in einen Puffer geschrieben, richtig?Und jetzt können wir gerne (was aber total OT wäre) diskuieren, wo die Angriffsvektoren wären
- Programm bricht mit Buffer Overflow ab, hat Admin/System/Root Rechte und landet in der Console etc.
- Metadaten werden beim Öffnen gelesen und interpretiert wie ausgeführt
- Codec prüft Datenpakete, und greift darin liegende Metainformationen ab (wenn möglich)...
Alles ist bei Dir sauber und gut. Du rufst die URL auf, auch alles noch gut. Und jetzt ist die Verbindung bereits offen, und der Dateistrom ist als Audio/HTTP/TCP-Stream geöffnet wurden, und lies brav bis zur Puffergröße ein, und spielt ab. Das sehe ich jetzt an dieser Stelle als reinen Audiostream. Kann dann an der Stelle Schadcode - wenn jetzt jemand den Server gekapert hätte - im laufenden Stream nachgeladen werden? So wie oben gezeigt, nicht!
Und dann schauen wir mal an, was der Kollege gepostet hatte:
tomgit schrieb:
Da steht deutlich, der Host ist schon per Malware infiziert, und kann dann die WAV-Datei mit der DLL lesen und den Miner installieren. Daher, warum liest da keiner mal genauer nach, bevor man sowas als "Beweis" hier präsentiert?
Zuletzt bearbeitet:
Marco01_809
Lt. Commander
- Registriert
- Mai 2011
- Beiträge
- 2.036
nutrix schrieb:
nutrix schrieb:
Die Unterscheidung von Datei abrufen und "Streaming" halte ich für hirnrissig. So oder so werden die Daten vom Server zum Client übertragen und der Client decodiert sie und spielt sie ab. Völlig Banane ob man die Daten erst komplett überträgt ("Datei") oder während der Übertragung schon anfängt abzuspielen ("Streaming").nutrix schrieb:
Wenn du eine lokale Datei abspielst - als Beispiel mal ein 5GB Video - springen ja auch nicht sofort die ganzen 5GB in den RAM. Das Video wird sequenziell von der Disk geladen... man könnte auch sagen... gestreamt. Ob die Quelle deine eigene Festplatte oder ein Webserver ist, ist völlig unerheblich.
Einziges Problem ist das Formate wie MP4 einen festen Header haben in dem die Videolänge und andere Metadaten stehen die der Player braucht bevor er loslegen kann. Bei MP4 stehen die standardmäßig am Ende, sind also eher ein Footer. Um den zu lesen müsste der Player zuerst ans Ende der Datei seeken. Bei einer lokalen Datei (
fseek()) oder HTTP (Range: bytes=X-Y header) kein Problem. Aber bei einem Livestream geht das natürlich nicht weil der kein (bekanntes) Ende hat.Die Lösung sind Dateiformate die von Haus aus streamable sind, z.B. FLV. Die kann man einfach per "endlos-Download" streamen; der Server sendet einfach immer weiter Daten genau so als würde er eine endlos lange FLV Datei schreiben. In dem Fall sind "Datei" und "Stream" genau das gleiche.
Oder man zerlegt den Stream in Stücke, sogenannte Fragmente. Alle 1s-10s wird abgeschnitten, ein Video daraus erzeugt und in eine Datei abgelegt. Diese wird dann in eine Playlist eingetragen. In der gleichen Frequenz lädt der Player die Playlist neu runter, lädt neue Fragmente runter und spielt die lückenlos nacheinander ab. Der Clou ist dass jedes Fragment für sich genommen eine normale, vollwertige Videodatei ist. Da jedes Fragment aber ziemlich klein ist kann der Player es komplett runterladen und dann auch problemlos zu den Metadaten seeken.
Und wenn du letzteres nicht Streaming nennen würdest bist du aber absolut auf dem Holzweg was deine Terminologie angeht, denn genau auf die Art implementieren Twitch, Youtube & Co. - eigentlich jeder - Livestreams.
So albern auf diesem "reinem" rumzureiten. OP meinte damit offensichtlich nur die Audio-URL direkt aufzurufen statt z.B. ein integrierter Player auf einer Website. Er hat ja sogar ein Beispiel genannt.nutrix schrieb:
Einen "reinen" Stream gibt es nicht. In der Praxis hat jedes gängige Audio- und Videoformat haufenweise Metadaten die ZWINGEND zum Abspielen gebraucht werden, also weiß ich nicht warum wir so ein Fatansieszenario überhaupt betrachten sollten!? Ohne Metadaten kein Stream. Das einzige was ich gelten lassen würde wäre ein Server der unmittelbar raw audio samples zurückwirft wenn man eine Verbindung mit netcat herstellt. Und selbst dann wird der Stream in Paketen übertragen die TCP Metadaten haben...
Du willst wohl nicht behaupten das Decoder grundsätzlich fehlerfrei sind!nutrix schrieb:
https://nvd.nist.gov/vuln/detail/CVE-2025-1373
https://nvd.nist.gov/vuln/detail/CVE-2019-11339
https://twelveand0.github.io/CVE-2017-11399
Letztere beiden sind out-of-bounds accesses die beim decoden von block daten auftreten, nicht beim parsen des headers, weil dir das ja irgendwie wichtig ist (für alle anderen macht es keinen Unterschied).
Ja naja und dann öffnest du den Downloads-Ordner und der Thumbnailer decodiert die Datei weil er eine Vorschau erzeugen will... Windows parsed dir sogar schon exe Dateien weil die ja hübsche Icons haben könnten die in der Ordnerübersicht angezeigt werden sollennutrix schrieb:
nutrix schrieb:
Ach na toll, und wie decoden wir dann unsere MP3? Stopf mal die MP3 Daten in den audio sink, die Ohren freuen sich...nutrix schrieb:
Denn ist es ja gut...nutrix schrieb:
Ich bin so froh dass du libao genommen hast.nutrix schrieb:
https://nvd.nist.gov/vuln/detail/CVE-2017-11548
CVE-2017-11548 schrieb:
Den exec call brauchst nicht sehen. Den kann der Schadcode synthetisieren oder zu anderem Code, z.B. in geladenen Libraries springen wo es die gibt.
Davon ab ist dein Beispielcode ja witzlos weil du nur rohe audio samples abspielen kannst und keine MP3. Schön anschaulich ist aber das du willkürliche Parameter für das Format hardcoded hast:
C:
format.bits = 16;
format.channels = 2;
format.rate = 44100;
format.byte_format = AO_FMT_LITTLE;Leider nur am Thema vorbei, denn OP hat ja explizit ein Beispiel genannt: Er will MP3 über HTTP streamen allein unter Angabe der URL.nutrix schrieb:
!Achtung!: Bei einer URL handelt es sich um sogenannte Metadaten. Allergikern wird empfohlen beide Augen fest zu schließen während der URL Parser die Server-Adresse aus der URL parsed. Ohne Metadaten wäre unser Projekt an dieser Stelle leider schon vorbei...
Was folgt ist ein abenteuerlich komplexes Konstrukt aus networking library, HTTP Parser, Multiplexer, ggf. TLS Handshake, laufender Decryption & MAC, MP3 Decoder und Audio output. All das verarbeitet Metadaten und ist zwingend notwendig um auch nur einen Ton aus dem Lautsprecher zu bekommen.
Und zum krönenden Abschluss präsentiere ich dir noch die Struktur von MP3, dank der MP3 überhaupt erst streambar ist:
MP3 ist unterteilt in Frames... und jeder Frame... hat einen eigenen Header. Man muss also im laufenden Stream immer weiter Header parsen!! Es hört nie auf! Die Metadaten sind überall!!11
Zuletzt bearbeitet:
Ich wiederhole es noch einmal, weil Du auch darauf reinfällst.Marco01_809 schrieb:
https://www.computerbase.de/forum/t...-radio-streaming.2238141/page-3#post-30525494
Du hast es ja wunderbar und besser beschrieben als ich. 🙂 Du sagst doch selbst:
Deshalb lautet die Antwort mit reinem Radiostreaming Nein und ohne Ja. Meine kritisierte Grundaussage ist nach wie vor richtig.Marco01_809 schrieb:
Trotzdem passiert beim diesem Parsen oder Decodieren aber nichts weiter.Marco01_809 schrieb:
Ich lerne gerne dazu, wußte ich jetzt so noch nicht, danke. Ich dachte, die Metadaten sind nur am Anfang, und dann wird irgendwie intern verkettet verlistet etc. Gut, dann ist hier immer die Gefahr, daß in den Metadaten was anderes drinsteht, was sollte, und es mißbraucht werden kann.Marco01_809 schrieb:
Ansonsten kannst Du hier an der Stelle auch nur als Fazit dem TS sagen: Unsicher, weil da viele Komponenten beteiligt sind, und "reines" Radiostreaming so gar nicht möglich ist. Richtig?
Zuletzt bearbeitet:
Nicht zwangsläufig. Hier im Forum tauchen immer mal Menschen auf, die gerade einen Schizophrenen Schub haben und wahnhaft sind bzw. wo das gerade anfängt. Da ist es essentiell, dass sie zum Arzt gehen (oft ist es auch nicht der erste Schub), damit sie behandelt werden können.nutrix schrieb:
Scheint beim TE nun glücklicherweise nicht der Fall zu sein. Aber der Eingangsbeitrag las sich so, als wenn das hier zutreffen könnte.
Für grundsätzliche Überlegungen ist das irrelevant. Sobald Daten von einre Software verarbeitet werden ist das ein theoretischer Angriffsvektor. Auch für das reine Downloaden einer Datei gab es schon Exploits, in dem Fall über die AV Software. Ein Audio-Stream wird mindestens (zusätzlich) vom Codec interpretiert, wenn dieser eine Schwachstelle hat, dann reicht es schon, einen Stream zu öffnen.nutrix schrieb:
Damit der Stream beim Codec ankommt muss aber auch der Browser erstmal Daten entgegen nehmen und verarbeiten und das ist eine weitere prinzipielle Schwachstelle. Wahrscheinlich ist das alles nicht, aber grundsätzlich möglich.
Keine Ahnung, wieso du dich so stark dagegen wehrst. An jeder Stelle, an der Daten aus dem Internet verarbeitet werden existiert potentiell ein ausnutzbarer Bug.
Im Gegenteil, da passiert ggf. viel und es gab schon Exploits für Bugs in Bildformat-Parsern. Das Erstellen von Thumbnails aus einem herunter geladenen Bild (oder generell aus einer Datei) ist ein Verarbeiten von Daten aus dem Internet und damit potentiell problematisch.nutrix schrieb:
Zuletzt bearbeitet:
Das ist doch ein ganz anderer Fall. Wenn ich per wget, curl, ftp, sftp, http per get usw. einen Dateistrom aufmache, und einfach, ohne alles, direkt den Datenstrom auf meinen Datenträger, RAM sonstwas packe bzw. die Datenpakete da in kopiere, passiert da erst mal gar nichts. Die Dateien liegen doch nur passiv da rum.BeBur schrieb:
Nochmals, andere Baustelle, nicht das, was ich meinte. Natürlich hast Du an allen Stellen Schwachstellen, sobald Du verschachtelst zig Programme auf eine Datei jagst, die mit zig APIs, DLLs, Libs und Co alle möglichen Funktionen darauf ausführen. Dem wiederspreche ich doch gar nicht, abe das ist nicht den Fall, den ich meine!BeBur schrieb:
Das ist auch schon wieder an einer Stelle, die ich nicht meine, und viel zu weit ist. Du machst - wie auch immer - ein Open auf eine Datei, Du machst ein Get/Read dieses, wie es auch immer heißt, Filehandler, TCP-Stack, Pipe sonstwas, und schreibst das, was Du da gelesen hast, über Puffer, direkt und ohne jede weitere Verarbeitung da hin. Da passiert doch nichts weiter, wenn Du rein binär, paketorientiert usw. passiv agierst.BeBur schrieb:
Und nochmals, klar, sobald man irgendwo ein Backdoor hat, ein Programm den Datenstrom anfängt zu interpretieren, sobald ein simples Grundprogramm wie curl, eine Lib, ein Codec, oder der Browser, AV sonstwas selbst kompromiert sind, kann alles mögliche passieren, das bestreite nicht doch gar nicht. Ich bestreite nur, daß bei einer "reinen" einfachen passiven Datenübertragung - wie auch immer - erst mal nichts weiter passiert. Nimm mal als Bespiel ein curl, was natürlich auch Sicherheitslücken hatte
https://www.it-daily.net/it-sicherh...birgt-die-neue-curl-und-libcurl-schwachstelle
Was steht da?
https://nvd.nist.gov/vuln/detail/cve-2023-38545
Nochmals, alles Fehler im "Drumherum". Nirgends ein Fehler, daß direkt dann beim Kopieren von Datenströmen irgendwo irgendwie eine Kompromitierung erfolgen kann.
Und bevor jetzt das Argument kommt, ja Steganographie ist mir bekannt, und ja, natürlich kann man damit alles reinpacken, wie z.B. über ein LSB in Bildern, siehe auch https://reposit.haw-hamburg.de/bitstream/20.500.12738/7606/1/Masterarbeit_Dominique_Dauch.pdf.
BTW suche ich gerade nach einem Beispiel MP3, wo in den Metadaten Schadcode versteckt wurde und das zur Kompromitierung führte. Ich finde nur als Beispiele MP3s, die aber tatsächlich EXE oder .COM/BAT sonstwas waren. Die Infos zu beispielsweise Downloader-UA.h sagen auch nur, daß hier keine echte MP3 Datei runtergeladen wurde, sondern ein URL Script, die weitere ausführbare Dateien runterlädt.
Ähnlich arbeitet Worm.Win32.GetCodec.a über ein WMA-Tag
https://www.computerwoche.de/articl...-ueber-infizierte-mp3-dateien-ins-system.html
Auch hier gemeldete Probleme mit MP3
https://www.zdnet.de/2127871/gefahr-mp3-sicherheitsloch-in-winxp-und-winamp/
betreffen lediglich die ID3V2-Tags, aber nicht den MP3-Stream selbst.
Ein Beispiel, daß direkt über Frames und deren Header, wie von @Marco01_809 gezeigt, irgendwie Schadcode ausgeführt werden kann, finde ich so auf die Schnelle nicht.
Zuletzt bearbeitet:
Nochmal: Um einen Bitstream hören zu können muss dieser verarbeitet und interpretiert werden und das ist eine potentielle Schwachstelle.nutrix schrieb:
Nein. Sobald da ein Bug drin ist.nutrix schrieb:
Das ist ein gutes Beispiel dafür was alles schief gehen kann wenn man vermeindlich nur Daten überträgt und sonst gar nichts damit macht. Hier in dem Fall eine Sicherheitslücke auf der Transportschicht. Das ist ein schönes Beispiel, weil Sicherheitslücken in solchen Schichten natürlich auch triggern, wenn man "nur was runterlädt".nutrix schrieb:
So viel auch zu diesem Teil deiner Aussage:
Allein der Begriff "Paketorientiert" zeigt schon, dass das nicht stimmen kann. Pakete haben ein festes Format und Formate müssen von Software interpretiert werden und diese können Fehlerhaft sein und Schwachstellen enthalten.nutrix schrieb:
Du unterschätzt schlicht die Komplexität heutiger Technologien und wie viel da zusammenspielt und was alles kaputt gehen kann. Die Chinesen haben gleichzeitig 7 Sicherheitslücken ausgenutzt um Schadsoftware von einer Webseite auf die iPhone der Webseitenbesucher zu transportieren.
Du programmierst doch auch, oder hast mal programmiert. Dann weißt Du doch selbst sehr gut, daß Du Bitstreams einfach, ohne weitere Verarbeitung, 1:1 durchreichen kannst. Und nicht jede Verarbeitung bedeutet auch Interpretation. Das ist ein absoluter Trugschluß Deinerseits. Nach Deiner Logik könnten dann so simple Programme wie dd oder tcpdump auch komprimiert werden, wenn sie Datenströme falsch lesen. Rein praktisch tun sie das aber nicht. Auf der einen Seite werden Bits gelesen, auf der anderen Seite ausgegeben. Mit wäre jetzt kein Fall bekannt, wo ein dd wie ein tcpdum plötzlich ein Problem bekommen, und anfängt, ein Programm oder Malware aus den gelesenen Datenströmen, wie auch immer, auszuführen. Fakt ist aber, es wird dergleichen nichts passieren, sondern die Datenströme werden brav von der einen zur anderen Seite durchgereicht, und der Inhalt interessiert null.BeBur schrieb:
Ich habe es mißverständlich ausgedrückt, natürlich Bug im Sinne von Programmierfehler, kompromittiert, und natürlich noch viel mehr, wenn Du willst, unglückliche Konstellation, Features, Backdoors, nicht beachtete Bedingungen, die gleichzeitig zutreffen, Betrieb außerhalb der eigentlichen Specs, wir können das jetzt gerne endlos weiterführen...BeBur schrieb:
Aber nicht die Transportschicht selbst, sondern das Handling drumherum. TLS/SSL Handshake ist über Layer 4 in der Anwendungsschicht 5-7, genau wie HTTP. Ich spreche aber, wenn Du schon damit anfangen willst auf Layer 3-4.BeBur schrieb:
Aber Du lenkst hier ab, worum es mir geht. Sobald Du Datenpakete, wie auch immer, überträgts und schöne zusammenbastelst, so daß wieder eine Datei daraus wird, passiert da doch nichts weiter. Ob die Datei eine gültige Datei ist, spielt keine Rolle, ob da was ausführbares ist, ebenso nicht. Irgendwas landet bei Dir auf Platte oder RAM oder Puffer. Und von diesem Moment spreche ich. So, und nun zeige mir mal, wo da in diesem Moment der Angriffsvektor sein soll? Er kommt, ja, danach. Aber direkt in der "Übertragungsphase", nein.
Das ist doch wieder eine Schicht darüber, und das interessiert doch gar nicht. Du brauchst Dir doch nur mal eben ISO-OSI anschauen. Was passiert den bitte auf Layer 4, wenn ein IP Paket per TCP/UPD nicht passt oder fehlerhaft ist? Es wird verworfen, und neu angefordert. Und ja, natürlich passieren da Fehler. Aber in diesem Moment gibt es keine Ausführung, es werden die Paket hin und hergeschoben, oder nicht. Nach Deiner Logik könnte jeder Switch, Hub sofort kompromitiert werden, wenn die nur ihre Datenpakete durchschleusen. Rein praktisch, schon mal irgendwo beobachtet worden? Hier passieren doch auch nur Vorfälle, wenn man beispielsweise genau weiß, dieser Switch eines gewissen Herstellerst schaut sich genau das Datenpaket XY auf Layer ABC an, und macht da intern ein Budenzauber für Servicezwecke oder sonstwas. Wenn der Switch und Hub nur durchreichen, passiert hier auch nichts.BeBur schrieb:
C'mon dude, echt jetzt? 🙄 Fängst Du jetzt auch so an. Ich unterschätze gar nichts. Ganz im Gegenteil. Nur bin ich anscheinend in der Lage, genauer zu hinterfragen und zu separieren, was Du und anderen eben nicht tun. Ihr werft alles durcheinander, als mal genauer hinzuschauen, und genauer zu differenzieren. Wo ist genau der Angriffsvektor, wo passiert der Bruch, die Kompromitierung. Glaub mir, ich muß jeden Tag das genau so machen und auf verschiedenen Layern rumsuchen und rumkramen. Fakt ist, eine unnötige Paranioa ist genauso gefährlich und falsch wie absolute Sorglosigkeit.BeBur schrieb:
Ja und, wo ist das jetzt ein Widerspruch zu dem, was ich sage?BeBur schrieb:
Wenn ich Daten, ohne Interpretation, hin und herschaufle, passiert nichts, weil der Inhalt der Daten nicht interessiert. Nach Deiner und andere Logik hier wäre demnach schon ein simpler Move oder Copy, IT-technisch gesehen, eine Gefahr.
Hier machen viele den Fehler, alles in einen Topf zu werfen, und NICHT genauer zu differenzieren, weil "Sicherheitslücke". Deshalb hatte ich oben als Beispiel das Beispiel der angeblich gefährlichen WAV-Datei genommen, weil ich mir da ziemlich sicher bin! Was steht da nochmal genauer drin: WAV enthält Malware, die dann NUR von einem bereits kompomierten OS bzw. Programmen ausgeführt werden kann. Spiele ich die WAV Datei simpel mit der obigen (Hinweis nochmal an @Marco01_809) simplen als grobles Beispiel gedachten C-Funktion ab, passiert, egal was da an Malware, Viren, sonstwas Schadhaftes drinnen liegt, hier weiter nichts. Es wird in dem Datenstrom nichts ausgeführt, nichts rauskopiert, er wird gelesen, und der Bitstrom in Klang vom Decoder umgewandelt. Und ja, wenn da tatsächlich mehr als gedacht im Decoder implementiert wurde, kann da was passieren. Wenn er schönde nur seinen Job macht, eben nicht. Und bei Fehler bricht er ab, und der Rest passiert dann auf höheren Schichten, wenn andere Programme oder Prozesse dazwischenfummeln, AV, OS, Treiber....
Aber wir sind hier komplett OT!
Nochmal die Frage vom TS:
Reiner Radiostrom, kompromitierbar oder nicht? Ich sage nach wie vor NEIN!
Mir fehlt bisher der Beweis, daß )wie wirklich sehr schön von @Marco01_809 erläutert und erklärt) direkt Frames und deren Header als Quelle für Malware tauglich sind. Alles was ich fand, war drumherum, was nichts direkt mit den MP3 Audio zu tun hatte.
Radiostrom (ohne das reine), kompromitierbar oder nicht? Hier sind wir ja alle anscheinend d'accord, JA!
Nebenbei würde ich noch fragen wollen, ob überhaupt ein Virenscanner MP3-Dateien richtig auf Viren und Malware prüfen könnten. Meiner Meinung nach tun sie das bis heute eben nicht. Sie prüfen, ob es versteckte ausführbare Dateien sind, die falsch benannt wurden, eventuell noch vielleicht die ID3-Tags, aber mehr machen sie doch bisher nicht, oder? Wird sowas entdeckt, wenn man beispielsweise MP3 + ZIP kombiniert?
https://blog.meister-security.de/steganographie/
Virenscanner ist nicht mein Spezialgebiet, dafür ist eine andere Abteilung zuständig. Ich hab die Dinger früher auch nur installiert und im Firmenkontext mit entsprechender Verwaltungssoftware aka Kasperky oder ESET gewartet.
Zuletzt bearbeitet:
Und an der Stelle bist du eben nicht genau genug oder dir fehlt das tiefergehende Verständnis (vermutlich hast du nie ernsthaft Software entwickelt?). Irgendwo gibt es ein Stück Software das genau das prüfen muss. Und genau da setzen exploits an. Fallbeispiel für ein ACE Exploit:nutrix schrieb:
Quelle
Solche Mechanismen - Bits die Angeben, wie groß der folgende Block ist - gibt es überall in Formaten. Sobald das nicht in allen Randfällen korrekt verarbeitet wird gibt es potentiell ein Problem. Heutzutage gibt es deutlich mehr Sicherheitsmechanismen als noch vor 20 Jahren, aber Software ist auch um ein vielfaches komplizierter geworden. Bluetooth z.B. hat 3000 Seiten Standard. Das ist ein Grund wieso da diverse kritische Sicherheitslücken über die Jahre aufgetaucht sind.
Dein Verständnis Problem liegt in dem Punkt, dass du nie sicher sein kannst und weit unterschätzt, an welchen Stellen überall Daten nicht nur weitergeschoben, sondern irgendwie verarbeitet werden. Das Beispiel mit dem Audio-Codec wurde ja schon mehrfach gebracht und den Punkt hast du offenbar initial übersehen. Hat die Software, die den Stream interpretiert einen kritischen Bug, dann kann schon ein Radiostream an sich kritisch sein.
Zuletzt bearbeitet:
Falc410
Vice Admiral
- Registriert
- Juni 2006
- Beiträge
- 6.723
Also erst einmal sehr schön, dass die Diskussion hier weiter lebt und ein wenig der Aggressivität verloren hat.
Und wie schon mehrfach gepostet, gibt es in Decodern Schwachstellen. Im Endeffekt ist das kein Unterschied zu einem PDF oder Word Dokument, da kannst du theoretisch auch behaupten es steht nur Text drin und trotzdem kann man die Programme dann Exploiten (und ich rede nicht von Office Macros).
Deine Argumentation ist, der Browser kopiert nur Daten in einen Puffer und dabei kann nichts passieren. Dem stimmen wohl die meisten zu (wobei ich auch das nicht ausschließen würde solange ich die Implementierung nicht kenne). Aber sobald der Puffer halt gelesen und die Daten die dort verarbeitet werden, kann es natürlich zu Problemen führen.
Dein Beispiel mit einem TCP Paket welches verworfen wird, habe ich ja im vorherigen Post auch zu entkräften versucht. Wir hatten damals einen Bug gefunden mit IPv6 Paketen die für den normalen Network Stack in Ordnung waren aber beim analysieren durch Suricata gab es dann bei bestimmten Paketen Fehler die zum Absturz geführt haben. Wäre es exploitable gewesen? Keine Ahnung, vermutlich schon. Mir ging es damals darum den Bug zu fixen.
All user input is evil - lernt ja jeder in seiner ersten Programmierstunde. Daten aus dem Internet sind grundsätzlich evil
Wie Marco und Bebur ja schon schön erklärt haben, ist das bei einem Audio oder Videostream aber nicht der Fall, denn hier muss ja dekodiert werden. Dein Beispiel mit dd passt also nicht, da hier wirklich nur Bitweise Daten von A nach B kopiert werden.nutrix schrieb:
Und wie schon mehrfach gepostet, gibt es in Decodern Schwachstellen. Im Endeffekt ist das kein Unterschied zu einem PDF oder Word Dokument, da kannst du theoretisch auch behaupten es steht nur Text drin und trotzdem kann man die Programme dann Exploiten (und ich rede nicht von Office Macros).
Deine Argumentation ist, der Browser kopiert nur Daten in einen Puffer und dabei kann nichts passieren. Dem stimmen wohl die meisten zu (wobei ich auch das nicht ausschließen würde solange ich die Implementierung nicht kenne). Aber sobald der Puffer halt gelesen und die Daten die dort verarbeitet werden, kann es natürlich zu Problemen führen.
Dein Beispiel mit einem TCP Paket welches verworfen wird, habe ich ja im vorherigen Post auch zu entkräften versucht. Wir hatten damals einen Bug gefunden mit IPv6 Paketen die für den normalen Network Stack in Ordnung waren aber beim analysieren durch Suricata gab es dann bei bestimmten Paketen Fehler die zum Absturz geführt haben. Wäre es exploitable gewesen? Keine Ahnung, vermutlich schon. Mir ging es damals darum den Bug zu fixen.
All user input is evil - lernt ja jeder in seiner ersten Programmierstunde. Daten aus dem Internet sind grundsätzlich evil
Ich spreche von Layer 4 OSI und Du kommst mit einem JPEG. Wer ist jetzt hier nicht genau genug? 🙄 Anscheinend hast Du hier noch nie ernsthaft Software entwickelt. Und Du zitierst immer wieder Pufferüberläufe, die ein ganz anderes Ding sind als das, wovon ich rede. Und allen anderen Dingen, die ich erwähnte, weichst Du aus. 🙄BeBur schrieb:
Wobei hier noch KEINER den richtigen Nachweis gebracht hat, wo und wie genau der Angriffspunkt existiert.BeBur schrieb:
Und schon wieder fängst Du mit der Interpretation an, die bei einem normalen Copy, Read, Load, Get nicht habe. Ich hab eher auch den Eindruck, daß Du nicht verstehst, wie das ganze alles so richtig funktioniert, sonst hättest Du schon längst einen richtigen Beweise mal geliefert. Du kannst aus einem laufenden Datenstrom keinen Angriff starten.BeBur schrieb:
"Interessante" Diskussion hier. Theoretisch könnte auch das gesprochene Wort des Streams über „Social Engineering“ Schaden verursachen, via Hypnose oder via „OK Google“ Befehle über das Handy.
Ich würde sagen solange das Streaming aus einer sicheren und vertrauenswürdigen Quelle kommt und zum Abspielen ein Client genutzt wird der wirklich nichts anderes kann, keine Gefahr.
Ein Edge Browser der über „teurehörspielekostenlos.com.ru.to“ streamt, naja...
Ich würde sagen solange das Streaming aus einer sicheren und vertrauenswürdigen Quelle kommt und zum Abspielen ein Client genutzt wird der wirklich nichts anderes kann, keine Gefahr.
Ein Edge Browser der über „teurehörspielekostenlos.com.ru.to“ streamt, naja...
Ach, doch jetzt. Und genau davon spreche ich die ganze Zeit. dd, bitweise, kein Angriff möglich.Falc410 schrieb:
Reiner Audiostream, ohne Interpretation und Decodierung, kein Angriff möglich.
Audiostream, (mit Interpretation und Decodierung) Angriff möglich.
So schwer mit der Sprache?
Auch ein gutes Beispiel: Reine Textdatei, Angriff möglich? Nein. Sobald irgend ein Editor mehr macht als nur die Zeichen darstellen, Angriff möglich.Falc410 schrieb:
Leute, mit Euren Behauptungen überzieht Ihr masslos und schürt eine unnötige Paranoia. Wenn es nach Euch geht, dürfte ich nicht mal mehr mit einem einfachen Editor eine Textdatei mehr edieren, ohne daß ich eine eine Kompromitierung beführchten müßte... Tun aber die Leute, jeden Tag, milliardenfach, ohne das etwas passiert.
Das habe ich so, wenn Du bitte mal genauer liest, so nirgends gesagt oder behauptet.Falc410 schrieb:
Das habe ich so auch nicht gesagt. Fakt ist, daß bisher alle hier gezeigten Lücken und Fehler auf ganz andere Probleme hinweisen. Einen Angriff direkt aus einem "uninterpretierten" Stream - wie auch immer - gibt und gab es so meines Kenntnisstandes nicht, und den Nachweis möchte ich bitte erst mal haben.Falc410 schrieb:
Den Du mir übrigens noch nicht genauer geliefert hast. Suricata, Snort und Co als DPI-Systeme sind noch ein ganz anderes Ding, ja, weil sie den TCP-Strom genauer unter die Lupe nehmen und sich alles anschauen und intern wieder zusammenbauen, genauso wie es diverse Firewalls als "Man-in-the-middle" machen, die in Echtzeit sogar verschlüsselten Datenverkehr aufdröseln können. Natürlich ist dann immer per Sichtheitslücke was machbar. Aber Du nennst hier einen Spezialfall, der eben nicht so normal vorkommt. Und der Angriff erfordert einige Kenntnisse, wie Suricata genau intern arbeitet.Falc410 schrieb:
Zeige mir irgend einen Hub, Switch sonstwas, der durch simple Datendurchschleusung kompromitert werden kann. Zeig mir anhand des oben skizzierten Programmes, daß durch simples open wie fread einer Datei irgendwas passieren kann, wenn kein Pufferüberlauf passiert.
Ja, das ist aber was anderes. Wir sprechen nicht von Userinput, sondern inwiefern wir der Technik ein Stück weit vertrauen können oder nicht. Und wie Du ja oben selbst zugegeben hast, ist ein dd keine Problem, insofern kann man hier darauf vertrauen, daß das blockweise Kopieren von Daten hin und her kein Risiko darstellt, weil der Inhalt nicht angefaßt wird. Wenn dem tatsächlich so wäre, müßte sich jede Datenrettungsfirma ernsthaft Gedanken machen, wenn sie so Datenträger auslesen, weil das sonst nicht sicher wäre. Und genau von diesem einem Punkt spreche ich, und Ihr kommt alle mit - aus meiner Sicht - übertriebenen und vor allen Dingen schon weiterführenden Problemen, wo ich technisch im Gedanken noch gar nicht bin.Falc410 schrieb:All user input is evil - lernt ja jeder in seiner ersten Programmierstunde. Daten aus dem Internet sind grundsätzlich evil
Ich wiederhole, zeigt mir bitte einen Angriff aus einen laufenden Datenstrom, der wie ein Lesen, Kopieren, Vervielfälltigen agiert, der KEIN Pufferüberlauf, keine Interpreation, keine Decodierung sonstwas beinhaltet. Das ist wie mit einem Gottesbeweis, nicht ich kann Euch beweisen, daß es keinen Gott gibt, Ihr müßt mir beweißen das es einen gibt. Daher, faselt nicht weiter immer nur drum herum, liefert mir bitte einen festen Beweis, daß so ein Angriff wie oben skizziert möglich ist.
Zuletzt bearbeitet:
Was für eine Diskussion, eigentlich ist es doch ganz einfach. Das vom TE genannte Beispiel (Webbrowser, http, Consumer-Betriebssystem, Internetseite) ist kein reines Streaming mit einem reinen Streaming – Client.
Kann das übertragene Bild- und Ton Material etwas Schadhaftes verursachen? Nein. Kann in der Konstellation auf Grund der Gegebenheiten was passieren? Ja.
Kann das übertragene Bild- und Ton Material etwas Schadhaftes verursachen? Nein. Kann in der Konstellation auf Grund der Gegebenheiten was passieren? Ja.
Eben. Oder sogar das Lesen. 🙃Ja_Ge schrieb:
Man kann es mit der Paranoia auch übertreiben, und das sage ich jetzt als Berufsparanoiker.Ja_Ge schrieb:
Und ein großer Teil des Problems liegt bis heute auch darin, daß teilweise unreflektiert permament OSS Software von Hobbyprogrammieren, die das nebenbei betreiben, wichtige Funktionen verwenden werden, ich nenne nur mal open_ssl und log4j, was den meisten hier inklusive mir schlaflose Wochen bereitete, weil wir auf zig Systemen rumpatche mußten. Und das gleiche Drama haben wir mit ffmeg, was mittlerweile auch überall und jeder verwendet. Keine gescheiten Sicherheitsüberprüfungen, keine Audits, Tests, weil denen auch zum großen Teil die Mittel und Kapazitäten fehlen.
Ergänzung ()
Der TS will ja alte Hardware wiederverwerten. Da macht man eben folgendes:Ja_Ge schrieb:
- Ding einmal sauber nur als reines Internetradio aufsetzen, möglichst schlank
- Image sichern.
- Browser oder Player in einer Sandbox betreiben, noch paranoider in einer VM in einer Sandbox
- Ding mit Radiostream verwenden
- In einem bestimmten Zyklus Image regelmäßig recovern und dann darauf Updates machen, wieder zu Punkt 2. und runter.
Zuletzt bearbeitet:
Du hast halt dein Argument zwischendurch geändert. Du schriebst:nutrix schrieb:
Und das ist komplett falsch wie du offenbar auch zwischenzeitlich festgestellt hast. "Stream wird nicht interpretiert" (also das neue Argument) ergibt im Kontext des Threads auch gar keinen Sinn, damit kamst du erst an als Falschaussagen von dir korrigiert werden mussten.nutrix schrieb:
Daten werden an allen Ecken und Enden interpretiert, auch wenn man als Laie oder Halblaie ggf. nicht damit rechnet.
Falc410
Vice Admiral
- Registriert
- Juni 2006
- Beiträge
- 6.723
Aber das ist doch geanu der Fall. Deswegen hat Microsoft ja auch MotW eingeführt und behandelt Dateien aus dem Internet entsprechend anders und warnt vor dem öffnen jener. Die meisten Angriffe, wie du selbst wissen dürftest, gehen über manipuliert PDF Dateien die dann beim öffnen den Inhalt lesen und eine Schwachstelle im Adobe Acrobat PDF Leser ausnutzen. Dicht gefolgt von Schadcore der als Macro in Office Dokumenten hinterlegt ist - hier wird aber keine Schwachstelle der Software ausgenutzt - deswegen ist ja noch User Interaktion erforderlich (Macros aktivieren, irgendwo klicken etc).nutrix schrieb:
Also es gibt genug Beispiele die mindestens wöchentlich kommen, wo das reine öffnen einer Datei dann eine Schwachstelle im entsprechenden Programm ausnutzen. Bei zip / 7z gab es dann in den letzten Monaten häufiger. Auch beim VLC siehe https://nvd.nist.gov/vuln/detail/CVE-2024-46461
Ich möchte hier keine übertriebene Paranoia schüren, aber man sollte Dateien aus dem Internet nur mit einem System / Software öffnen die immer auf dem neuesten Stand ist. Und der springende Punkt bei der ganzen Diskussion hier ist eben, dass der Stream vom Browser mit 3rd Party Libraries dekodiert wird. Wenn ich alte Hardware verwende die eben auch Software-technisch auf einem alten Stand ist, ist das Risiko vorhanden. Jetzt ist halt die Frage wie gehe ich damit um? Klassisches Risikomanagement. Entweder akzeptiere ich es, oder ich verwende Maßnahmen um die Eintrittswahrscheinlichkeit oder die Auswirkung zu minimieren.
Der Stream dürfte ja eine vertrauenswürdige Quelle sein. Kann natürlich passieren das der von Angreifern übernommen wird und dann Schadsoftware verbreitet. Aber was können die Auswirkungen sein wenn das System übernommen wird? Sind dort wichtige Daten drauf? Nein. Kann das System ggf. weiterere interne Systeme angreifen? Ja - dann stell ich das halt in ein extra Netz bzw. limitiere den Datenfluss mit einer Firewall etc.
Dein Beispiel mit den Switches und Hubs - ja bei einem Hub gebe ich dir Recht aber bei einem Switch der eben ins Paket schaut und die Daten interpretiert (also mehr macht als nur Netflow), kann es sicher Schwachstellen geben.
Ergänzung ()
Dann verstehe ich deine ganze Argumentation nicht, denn genau das ist ja bei den Browsern auch der Fall. Ich sehe das mit OSS auch eher als Pluspunkt, denn so werden Sicherheitslücken gefunden und bekannt wohingegen properitäre Software das nicht so schnell bekannt gibt i.d.R.nutrix schrieb:
Dass es heutzutage zu viele Abhängigkeiten gibt und die Komplexität ein (fast) nicht mehr manage-bares Volumen erreicht hat, ist das Problem. Hab vor Jahren mal ein simples Maven Projekt gebaut und dann hatte das Teil erstmal 150 Libraries reingeladen. Das wird bei closed-source auch so sein und wenn die Hersteller ihr Supply-Chain Management nicht im Griff haben, dann sucht man eben lange rum um herauszufinden ob log4j oder ähnliches verwendet worden ist oder nicht. Wobei man sowas mit SAST Scannern eigentlich ziemlich leicht abhandeln könnte, macht nur kaum jemand leider.
Aber ich sehe schon, wir alle lieben unsere Jobs wenn wir uns auch am Wochenende noch so lange mit den Themen beschäftigen. Ich klink mich trotzdem mal aus für heute. Jetzt wird essen bestellt und danach Cocktails getrunken. Genug Arbeit für heute
Zuletzt bearbeitet:
Du schwubelst schon wieder außenrum. Ich hab gar nichts geändert. Nochmals, zeige mir an einem konkreten Beispiel, wo ein - ich nenne es jetzt allgemeiner - kontinuierlicher Datenstrom aus sich selbst heraus irgendwas kompromittieren kann. Das geht so von alleine nicht. Und genau darauf will ich die ganze Zeit mit "reinem" Datenstrom raus. Es braucht IMMER die Zuhilfenahme von mehreren gleichzeitig wirkenden Komponenten und "Zufällen" von darüberliegenden Komponenten, beispielsweise:BeBur schrieb:
- Buffer Overflow
- -> der dann auf irgend einer Ebene zu einer Codeausführung, unbeabsichtigter Weiterleitung, oder gar Session- wie Pointerübergabe führt
- Falsche Interpretationen von Metadaten, Headern, sonstwas innerhalb des Datenstroms.
Weiterhin behaupte ich (aufgrund meiner langjährigen Erfahrungen), daß selbst ein Buffer Overflow nicht kritisch (aber unschön) ist, wenn nach das System (Programm, App, API, Lib) sauber abbricht, und das Programm selbst sich nicht im Executive Mode als Root oder Admin oder sonstwas außerhalb landet, wo per System Call, SQL sonst weiter uneigenschränkt Unsinn gemacht werden kann.
Ein Datenstrom, wie auch immer der gestaltet ist, kann NICHT aus sich selbst heraus irgendwelchen Schadcode irgendwo starten und ausführen. Genau diesen Fall skizziert Ihr hier permenant, und den will ich so endlich mal von Euch konkret demonstriert haben.
Ganz klar, es gibt in der Verarbeitung Lücken drum herum, aber nicht innerhalb des Datenstroms selbst. Wenn dem tatsächlich so wäre, wurde Informationsweiterleitung gar nicht funktionieren.
Beispiel: Packe C4 in ein Paket, gut und sicher verpackt, und Du kannst es weltweit versenden, ohne daß irgendwo was passiert. Und Ihr behauptet jetzt, daß wenn ich die allein Adresse von dem Paket lese, das Ding explodieren wird. Wird es nicht, außer man leitet das Paket mit vielen anderen auf Verdacht in eine Druckkammer mit goßer Hitze (was man ja auch so üblicherweise mit allen Paketen immer so macht 🙄 ). Solange kein Zünder am C4 angebracht ist, wird das Ding von alleine nicht zünden.
Ergänzung ()
Siehste, wir verstehen uns doch nicht. Du sprichst von PDF, wo natürlich viel über die Metasprache interpretiert wird. Ich spreche von nackten blanken ASCII-Textdateien. Hier ist mir auch nicht bekannt, daß jemals eine blanke Textdatei als Hack mißbraucht werden kann, wenn nur ASCII gelesen und geschrieben wird. Klar, wenn ein Editor hier mehr macht, als er sollte, dann ja, aber nicht, wenn er nur das tut, was er sollte.Falc410 schrieb:
Sehe ich auch so, schönes WE.Falc410 schrieb:Aber ich sehe schon, wir alle lieben unsere Jobs wenn wir uns auch am Wochenende noch so lange mit den Themen beschäftigen. Ich klink mich trotzdem mal aus für heute. Jetzt wird essen bestellt und danach Cocktails getrunken. Genug Arbeit für heute
@toppixus
Wäre schön zu erfahren, was Du jetzt genau machen wirst.
Zuletzt bearbeitet:
Hallo Leute! Musste zwischenzeitlich auch mal arbeiten, daher jetzt erst. Danke erstmal für die Antworten der IT-Fachleute, insbesondere nutrix&co.. Ich bin, wie gesagt, Leihe :-(. Daher konkretisiere ich nochmal: Mir ging es eigentlich um den Unterschied bzw. Gewinn an Stabilität und Sicherheit bei folgenden zwei Szenarien: 1) Android mit diversen Radi-Apps und anderen gegenüber 2) Browser, der lediglich direkt einen Radio-Stream streamt. Kann über einen solchen Radio-Stream das geschehen, das über solche Apps geschehen kann? Also: Zugriff auf System, Sensoren, private Daten usw. (ich meine ohne kriminelle Energie, sondern rechtskonform von einem Radio-Sender oder so...)? Macht es also Sinn, das ganze so weit zu vereinfachen? Zur Info: Ich höre ohnehin nur ausgewählte ca. 10 Radio-Sender, ich brauche keine 60.000 Radio-Sender..... Ich mag es halt einfach und gut :-). Danke im Voraus! MfG
Ergänzung ()
Danke für den Tip! Mache ich bereits. Nutze seit geraumer Zeit Debian+Rythbox. Streamt Radiosender, spielt Musik ab, ist stabil, schnell, alles super! Wollte aber das ganze tetsächlich mal mit einem Android-Smartphone umsetzen, das wäöre einfach kleiner und mobiler.... Ist bei Android inder Art und Weise aber eben schwieriger, ohne sich zuzumüllen und die Hosen runter zu ziehen :-(. MfGGarmor schrieb:
Ergänzung ()
Danke für die Nachfrage. Wie bereits geschriebe, habe ich mit Linux bereits entsprechende Erfahrung. Wollte es aber gerne mit Android-Smartphone umsetzen. Naja.... ob es sich lohnt weiß ich nicht, dahe frage ich und prüfe die Optionen. Mit einer entsprechenden App und Müll und Verfolgung seitens Google und der App-Betreiber geht es ja einfach. Nur das ist halt nicht die Kunst. Mal schauen, wenn wir hier Spaß haben un gemeinsam eine gute Lösung finden, wäre es doch super. Unde wenn nicht, lernen wir halt was dabei :-)! MfGnutrix schrieb:
Zuletzt bearbeitet:
Ähnliche Themen
- Green Mamba
- Gaming-Audio, Streaming-Setups, Podcasting etc.
