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
@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
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
:
Bearbeitet durch User
Ä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.
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?
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
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.
Programmierer schrieb: > 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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.