Hallo Forum, habe im Linux Magazin 01/21 das dfu cli Programmchen gefunden und von github heruntergeladen. Was mich nach dem Compilieren/Build via "go build" etwas irritiert ist der Lange Output von objdump -x, siehe Anhang. <Paranoia> Wie vertrauenswürdig ist so ein Programm und wie leicht kann man damit Informationen aus dem System abgreifen und weiterleiten. </Paranoia> Bin mit Go nicht so vertraut und mich irritieren die ganzen URL's im objdump-Output. Muss das Go-Programm diese Resourcen onlien nachladen, oder ist das nur ein Verweis auf die Herkunft/Version der verwendeten Module. Markus
Gast
#6513713
Gegenfrage: Wie vertrauenswürdig ist eine .txt.zip-Datei in einem Forum? ;-)
Gast
#6513715
> ... die ganzen URL ...
Go, die Sprache des Universalschnüfflers Google?
@von CC wie wäre es mit unzip -l Aber ich kann Deine Bedenken verstehen, in diesem Fall vorher ein Upload bei Virustotal.com Man kann sich also so vergewissern, dass der Anhang sauber ist. Markus
Übrigens für das go Binary spuckt VT auch keine Alarms aus. Wie verlässlich das aber ist, kann ich leider nicht beurteilen. Ihre Eigenen Spionage-Routinen werden sie wohl kaum monieren. Markus
Angehängte Dateien:
-
vt_dfu_scan.jpg
(150 KB)
Gast
#6513824
Da es ja von GitHub ist: Lade da doch einfach den Sourcecode runter, prüfe ihn auf Sicherheitslücken, und kompiliere es selbst. Das dürfte um viele Größenordnungen einfacher sein, als das Binary zu prüfen. Wenn du noch paranoider bist, prüfe gleich den Sourcecode von Go mit. Eine "echte" Malware braucht übrigens keine URL im Binary um "nach Hause" zu telefonieren. Das Vorhandensein einer URL ist also weder hinreichende noch notwendige Bedingung für Schadsoftware...
@Programmierer
>Was mich nach dem Compilieren/Build via "go build"
das habe ich doch bereits gemacht -> aus der Source
das Binary erzeugt - oder?
Was das Reviewen des GO Cdes angeht - da habe ich keine Erfahrung,
wo man was verstecken könnte.
Markus
Gast
#6513839
Äh ja, das hab ich irgendwie übersehen. Wenn der Sourcecode des Tools OK ist, musst du also nach Malware/Lücken im Go-Compiler suchen.
Gast
#6513841
Markus W. schrieb: > Was das Reviewen des GO Cdes angeht - da habe ich keine Erfahrung, > wo man was verstecken könnte. Aber wer dann? Google hat offenbar selber keine Probleme gefunden, ich kann das bestimmt auch nicht besser als Google, aber wer sonst? Ein Security-Audit-Gott hier im Forum?
Gast
#6513849
Die URLs sind übrigens ELF-Symbolnamen, d.h. auf die hat das Programm nichtmal direkten Zugriff. Das werden so eine Art Konstanten mit Read-Only-Daten der entsprechenden Pakete sein.
@Programmierer
Wie ich schon geschrieben habe, irritiert mich die
Tatsache, dass ein Programm, das lediglich den Diskspace
auf Kommandozeilenebene anzeigt mit Hilfe des objdumps
so viele Passagen im Binary beinhaltet.
df hat einen Bruchteil davon, selbst mit den beteiligten Libs
linux-vdso.so.1 (0x00007ffe983a6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f27313ad000)
/lib64/ld-linux-x86-64.so.2 (0x00007f27315be000)
Markus
Gast
#6513888
Libraries kann man immer alle möglichen einbinden. Wenn die zum Grundsystem von Go gehören oder von dessen Standardbibliothek benötigt werden, sind sie immer dabei. Heutzutage sind die Features von Software wichtig, nicht die Größe der Datei.
Libraries kann man immer alle möglichen einbinden. Wenn die zum Grundsystem von Go gehören oder von dessen Standardbibliothek benötigt werden, sind sie immer dabei. Heutzutage sind die Features von Software wichtig, nicht die Größe der Datei.
Der Thread ist alt, trotzdem... die "runtime" von Go(lang) versucht, im Falle eines Absturzes oder einer Panik (panic()) einen Stacktrace auszugeben, also: Informationen darüber, in welcher Funktion oder Methode der Prozeß abgeraucht ist, wo diese Funktion oder Methode aufgerufen wurde, und so weiter. Deswegen sind die Namen, die Herkunft und -- wenn man "-trimpath" nicht benutzt -- der Pfad zu den lokalen Dateien in normalen Binaries enthalten.